Developing Polls and Surveys
August 10, 2001

by Carla King

You've been charged with putting a poll in place for your company's Web site. How you do this, of course, will depend on the technology you're currently using, and its restrictions. For example, you can't run a serious, scientifically bulletproof poll if you're using run-time memory or flat file to store votes instead of a database. This article discusses the mechanics of building a simple poll (such as the one shown on the Dot-Com Builder Web site), which includes the following tasks:

• Writing the application
• Displaying results
• Data storage considerations
• Handling state
• Handling ballot stuffing

Writing This Application

Your system is the biggest factor for determining what kind of polling is possible on your site. If you're creating a poll to use with systems based on Java technology, you'll be working with Java servlets and JSP pages, which provide you with a mature, object-oriented application development platform with hooks to the entire library of Java technology features and integration capabilities.You can use other technologies, too, such as PHP and Perl, to achieve similar speed and scalability.

You probably already understand the limitations of the technology you have in place now, and you may need to provide a reality check for those in your company who would like to implement polls beyond your system's capabilities. If your site is mostly static -- with light database traffic -- adding a poll to your front page can really burden your infrastructure, and you may actually need to advise against it.

Here are some options for writing your polling application. You could:

• Create a new, static Web page each time you need a new poll.
• Use a flat file or a config file that contains the poll, and send the ID of the poll to the server.
• Create an application that displays the poll via JSP pages and servlets, templates, or server-side includes.

Once voting is complete, polling results are usually displayed to users in numbers or in graph or bar charts. Because content developers will need to access this formatting code, it's important to keep the formatting code of the results away from the code used to implement the poll.

Data Storage and State

Database and flat-file solutions account for the bulk of polling solutions, with about 95 percent of solutions using a database. If you have no storage capabilities, you can hold the results in run-time memory only until your server is shut down, so your poll can only be used for entertainment purposes. Issues surrounding each data storage option, with comments on state, are explained in the following:

• Database Storage
• Flat-File Data Storage
• No Data Storage

Database Storage

If you are working with a database system, you'll use either a GUI or SQL scripts to load the data into the database. Your Web GUI will determine the questions, possible answers, and how to show results. Most server technologies allow you to interface with a database, which is the best solution if:

• You need to keep votes over the long term.
• You need to keep a record of your polls.
• You expect your site to grow (scalability).

With a database you can use a connection pool so that connections to the database are not opened every time there's a vote. This reduces the voting overhead on your systems and increases the level of concurrency by providing multiple connections at a time -- allowing many people to vote simultaneously -- which speeds up the voting process. Since connection pools need persistence, this is much more easily accomplished using JSP pages and servlets with built-in persistence.

Flat-File Data Storage

If you're creating a poll using flat files, you can manually input the questions and possible answers of the poll in the flat files or write a GUI Web-based application to do it.

If you need to keep the data, you can use server-side code to direct the data to be stored in flat files on your operating system. You can use any technology you wish for this task.

If your site attracts a lot of visitors, locked flat files or overwritten votes due to more than one visitor voting at the same time could be a problem, and you'll have to provide the coding to keep this from happening. However, this situation would rarely occur on low traffic sites.

No Data Storage

Because the Web is stateless, you must implement state in order for your system to count votes and to remember who voted. Servlet engines allow for application-wide persistent data, which is stored for the entire polling application until the Web server is shut off. Therefore, you'll need to write application code that will create a new poll when the server starts up again. If you're using Java servlets or JSP pages, you can use their available, application-wide persistence storage facilities to keep track of votes. If you need to store votes for the long term, you should use a more permanent method of data persistence.

Handling Ballot Stuffing

To prevent a visitor from voting more than once you can:

• Set a cookie.
• Implement servlet sessions.
• Implement IP logging.

The pros and cons of each are discussed in the next sections.

Cookies
To prevent visitors from voting more than once, you can set a cookie that will not allow them to vote more than once. However, this is not a foolproof solution. Visitors can disable cookies, switch browsers, or vote from a different computer. Ballot stuffing on the Dot-Com Builder site is prevented by interrogating the POLLS_TAKEN cookie. The value of the cookie is a comma-separated list of polls taken. If the cookie value contains the given poll_id, then the submitted vote is ignored. This is done within the service() method in the PollTabulationServlet shown in Figure 1.

public String parsePoll(int total_votes, 
  Vector answers, String entry_html_file)
{
  ParsedFileBuffer entry = 
    new ParsedFileBuffer(new 
      FileInputStream(entry_html_file));

  Map subs = new HashMap();
	
  StringBuffer buf = new StringBuffer();
	
  for (int idx = 0; idx < 
    answers.size(); idx++) {
    String[] record = (String []) 
      answers.elementAt(idx);
		
    // make sure the record has only 
    // two entries
    if (record.length == 2 && record[0]
      != null &&
      !record[0].equals("")) {
		    
        String answer = record[0];
	String votes = record[1];
			
	int ratio = 
	  Integer.parseInt(votes) * 
            1000 / total_votes;

	subs.put("answer", answer);
	subs.put("votes", votes);
	subs.put("percent", 
          Integer.toString(ratio / 10));
	subs.put("percent_real", 
	  Double.toString((double) ratio /10.0));
		
    buf.append(entry.getParsedContents(subs))
      .append("\n");	   	
				
        }
    }
	
    return buf.toString();
}      

Figure 1: Preventing ballot stuffing using the service() method in PollTabulationServlet

Servlet Sessions

• Pros: Servlet sessions are easier to code than cookies because the servlet engine takes care of most of the cookie maintenance.
  
  
• Cons: If the servlet session does not use cookies, the user record persists only for the life of the browser; so users will be able to vote again if they close and reopen the browser. Sessions can be persisted, so if cookies are enabled, the session can be held open for quite some time -- unless cookies are turned off.

IP Logging

• Pros: Saving users' IP addresses is a sure way to prevent site visitors from voting more than once.
  
  
• Cons: The IP address reported to you may be the address of the proxy server. So in the case of AOL, every AOL user accessing your site via the same proxy server would appear to be the same user, and would not be counted after the first AOL user voted. (The host system may change the person's IP addresses during the session.) For this reason, IP logging is a good method to use in a controlled environment, such as an intranet, rather than for the Internet.

Displaying Results

There are several ways to display the poll tally. Each is suited better or worse for a specific task. Here are some pros and cons for the different ways they can be displayed.

Pop-up Window

• Pros: This method is a good use of resources because the entire page does not have to reload.
  
  
• Cons: You'll need to make sure your pop-up window can be used across platforms, since coding involves the JavaScript programming language. Also, many visitors dislike pop-up windows.

Java Applet

• Pros: Applets don't require you to reload the page.
  
  
• Cons: Writing Java applets is a more time-consuming process than pop-up windows or page reloading. Also, you'll need to ensure that the JDK version you choose is supported by all browsers.

Page Reload

• Pros: A server-side include of a static HTML page creates a conditional decision inside the page in order to detect whether a user just voted (so the system can decide whether or not to display the voting form). Page reloads have a better appearance than other methods.
  
  
• Cons: Unless the page was already dynamic, this method is inefficient and uses a lot of resources because it creates a dynamic page from a static page. It's not a good idea if you have a lot of traffic.

Code Snippet

The PollResultsBean.java code snippet in Figure 2 shows how a custom class named ParsedFileBuffer uses an HTML template file to output the poll results. The function of a ParsedFileBuffer is to load in a chunk of HTML and replace the tokens (surrounded by percent signs) with their corresponding values. This approach allows content experts to modify the look and feel of the results without having to modify Java code.

The parsePoll() function in the PollResultsBean snippet takes as input a list of pairs of answers and vote counts. This is stored as a vector of arrays.

public void service(HttpServletRequest req,
		    HttpServletResponse res)
   throws IOException, ServletException

{
   String[] values = 
     req.getParameterValues("pollId");

   //
   // check that we got a valid poll id
   //

   if (values == null) {
      res.sendError(400, "invalid poll id");
      return;
   }

   String pollId = values[0];

   boolean pollAlreadyTaken = false;
   String pollsTakenList = null;

   //
   // get the list of polls already taken.
   
   Cookie existing = 
     HttpUtils.getCookie("POLLS_TAKEN", req);

   if (existing != null) {

      //
      // walk through the list and see if they 
      // have already taken this poll.
      
      StringTokenizer st = 
        new StringTokenizer(existing.getValue(), 
          ",");
      
      while (st.hasMoreTokens()) {
	 
	 String value = st.nextToken();
	 
	 if (value.equals(pollId)) {

	    // the user has already taken this poll.
	    
	    pollAlreadyTaken = true;
	    
	    break;
	    
	 }

      }

      // 
      // If the user hasn't already taken the poll, 
      // add the id to the already taken list.
      
      if (!pollAlreadyTaken) 
	 pollsTakenList = existing.getValue() 
           + "," + pollId;
   } else {
      pollsTakenList = pollId;
   }

   //
   // If the user has not already taken this poll, 
   // update the POLLS_TAKEN cookie

   if (!pollAlreadyTaken) {
      Cookie cookie = new Cookie(_cookiename, 
        pollsTakenList);
      
      cookie.setPath("/");
      
      res.addCookie(cookie);

      recordVote(req);
   }
}

Figure 2: Outputting the poll results using PollResultsBean.java

Acknowledgments

Phil Bartholo is a software developer specializing in server-side Java technology. He has written for Dot-Com Builder, java.sun.com, and developer.iplanet.com.

Kito D. Mann is cofounder of Virtua Communications Corp., the developer of FastVote, a Java technology-based Web survey system.

Joe Mocker is the lead developer for Dot-Com Builder, Java Developer Connection, and Solaris Developer Connection. He designed the polling and survey system used on these sites.

Resource

• FastVote:
  http://www.virtua.com/virtua/fastvote/