FinalPrototype-Group:PollPrecision
From CS160 User Interfaces Fa06
Each team member’s name and role in this assignment
- Keenahn Jung
- Responsible for overseeing this write-up and submitting the final version. Take screenshots.
- David Eitan Poll
- Continued ownership of the ballot-making task (and all implementation therein), production of PollPrecision-ized ballots, and write-up for the ballot maker's final interface.
- Hiroki Terashima
- Implemented the bulk of BallotViewer (voting task): got pen to stream, application to load the regions correctly and associate regions with categories. Write-up for BallotMaker's final interface with Eric.
- Eric Vacca
- Write-up of BallotMaker step, final presentation preparation (making PPT) with David, design new ballots for David to anoto-ize.
- Heung Tai
- Polish PollGraph, write-up for PollGraph's final interface.
Oral Presentation Materials
Powerpoint slides:
New ballot:
Code:
Problem and solution overview (1 paragraph)
Electronic voting systems have been a topic of much debate of late. There have been concerns and allegations of tampering and insufficient record-keeping, making vote verification difficult and recounts nearly useless. Yet the value of such voting systems is also great. They make counting and analysis of votes much simpler, and are less prone to human error in data entry because the voter interacts directly with the system. Our aim is to address the criticisms of such systems and to simplify the task of conducting surveys, taking polls, and recording and interpreting the collected information. We accomplish this with a suite of three separate applications that work closely together. The first, our ballot designer, allows users to import an image of their completed ballot, and then add Anoto readable fields to it. The second is an application that allows users to view and analyze the data collected. The third is what the voter actually sees on a monitor in the voting booth, providing feedback that their votes are being recorded electronically.
Target user group (1 paragraph)
Our target users fall into two categories:
- Surveyors, Pollsters, and Data Miners
- These are the people who seek to acquire data, for whatever reason
- Most likely the direct client of our software
- Need:
- System for easy and accurate collection of data from survey subjects and voters
- Integration with data mining tools such as database software or other common scripting applications
- Want:
- Verifiability of results
- Highly customizable ballot templates
- Voters and Survey Subjects
- These are the people who will respond to requests and surveys from pollsters and surveyors
- Most likely users of the system
- Need:
- Method of data entry that will allow them to effectively communicate with their pollster
- Want:
- Reassurance that their submissions were successful and received with high levels of accuracy
- Easy data entry that doesn't requrie them to learn something new in order to provide feedback
Tasks (1/2 page)
3 representative tasks to test your interface (easy, medium, hard). Remind us why you chose these tasks.
- Easy
- Make selections on a ballot or survey
- Voter or survey taker makes selections on a survey or ballot. He weighs his options, and responds to various questions that have limited choices (a list of names, a place to write-in, yes/no, etc.). Selections are made by punching the ballot, writing with a pen, or interacting with a digitally displayed interface.
- Submit a vote or survey
- After making his selections, the voter or survey taker must submit his vote or survey for counting and analysis. He does this by completing a wizard on a computer and/or handing his paper ballot or survey to the administrator.
- Make selections on a ballot or survey
- Moderate
- Analysis of results
- The pollster or election administrator needs to be able to do something useful with the results of the survey or vote. He must count votes, acquire statistics about surveys, and interpret written information. Transmission of this information might be digital or constrained to compiling information from raw ballots and survey submissions.
- Correcting errors
- Pollsters and administrators need to be able to cope with errors made in casting ballots or submitting surveys. In elections using paper ballots, improper chads must be considered and counted based on certain arbitrary rules for qualification. Surveys that have been filled out incorrectly might still contain useful data. It is up to pollsters and administrators to resolve, based on their own critereon, errors made in voting and survey-taking.
- Analysis of results
- Difficult
- Create a ballot
- Ballots and surveys must be designed prior to administration of the poll or election. These might be designed in any sort of publication application ranging from Microsoft Word to Publisher, etc. Ballots have fields that must be specified. For example, holes to be punched must be specified in punch-card ballots. Digital interfaces might have buttons or controls that the user can interact with to make their selections. In all of these cases, the ballot-maker must somehow make it clear to the voter how to make a valid selection.
- Verify results
- Voting, in particular, requires a certain level of verifiability. Usually, this involves recounting votes for a particular region. Recounted votes need to be reprocessed or hand counted, helping to ensure accurate results. Hand counting involves poll workers visually examining votes and manually entering new data.
- Create a ballot
Design Evolution (2 pages + sketches & screen shots)
Since our application is really a suite of three distinct, but interdependent, interfaces, we will discuss the evolution of each one separately.
Easy Task: Voting and using the Ballot Viewer
The major changes in this were the addition of live feedback via a computer monitor while the user votes on the paper ballot. Overall, the evolution was pretty linear, making incremental improvements at each stage. We started with the basic idea, implemented a “Wizard of Oz” version for our interactive prototype, and have a final working version. Future work in this area would be to implement the sign-in sheet, to extend this to multiple page ballots (get automatic page flipping to work).
Our UI from initial sketches:
Dataflow diagram:
Voting Storyboard:
As you can see, we had the basic ideas that would find their way into our later iterations. We did not yet think of having live, immediate feedback on a computer monitor when voting, so the ballot viewer was not even part of our initial design. We envisioned an Anoto enabled sign-in sheet to add another layer of security. Our idea was to perform handwriting recognition on the signature and match it against a database of signatures. This is left as a feature request for future iterations.
Our low fidelity prototype:
We wanted to give the users immediate feedback on a computer monitor while they voted on the paper ballot. This is indicated by the highlighting on the ballot (which is supposed to be displayed on a computer screen).
Our interactive prototype:
We implemented the designs we outlined in our initial sketches and low fidelity prototypes. We got the regions to highlight on the screen, but had yet to have this actually react to input from the Anoto Pen. At this point, that piece of the application was still demonstrated via the “Wizard of Oz” method.
And our final product:
We got communication between the Anoto pen and our app to work! Marking a region on the paper ballot causes the correct region to be highlighted on the screen. This will be easy to generalize over different ballots. Furthermore, we added some intelligence to the feedback mechanism, and it will tell you in real time if you make a mistake, such as voting twice in a “choose 1” category.
Moderate Task: Viewing the Results
This application was not part of our initial sketches. We initially thought that users would just connect to the vote database using their favorite shell and access the data directly. We decided around the time of our low fidelity prototype that we should provide a simple application for viewing the data.
Our low fidelity prototype:
We decided that a graphical display of the results was needed. It was to be as simple as possible, so we just had it show histograms of the various votes in the categories. Originally, we envisioned using a drop down menu.
Our interactive prototype:
We implemented it in Swing and got it to display the histograms, scaling them as necessary based on the number of votes and the number of items in a category. At this point, we hardcoded the numbers.
And our final product:
In our final product, we read the numbers in from a file. A simple extension to this is to have it read from a database. We still use the “Wizard of Oz” technique for simulating the database connectivity.
Difficult Task: Adding Regions to a Ballot using our Ballot Designer
In our original sketches, we did not even think about what the interface for our Ballot Designer would look like. We assumed that it would be similar to a word processor, but did not even sketch it out.
Our low fidelity prototype:
We decided on a distinct two panel window, with the left larger area as the main work area and the right area as having various buttons. You can also see that we had some buttons near the top of the screen, these would be moved to the right panel later.
Our interactive prototype:
We implemented the design in Java. At this point the open and save buttons did nothing. Also, the wording was a bit confusing. As you can see, we have a few huge buttons on the right panel, which is a change from our previous iteration. We also decided to use different mouse cursors for each different mode. Furthermore, messages were displayed in different colors, again helping the user distinguish between warnings (red) and labels (blue or green). We also added a small “Rendering page, please wait” screen that popped up while loading the PDF file to give the user immediate feedback that our application was doing something. We did not anticipate the need for this until we started building the low fidelity prototype. All in all, this is a great interface, and we fixed the few problems we had for our final iteration.
We changed the wording to make things clearer. Categories are now “Measures,” which makes more sense in relation to ballots. We also added the very useful “flood fill region” button on the right panel. This creates another mode in our application where we can draw regions. However, instead of clicking and dragging, the user simply clicks on empty “space” on the PDF and our app will create a region that “fills” it approximately. That is, it will create a rectangular region about as tall and wide as the boundaries of the space clicked on. This is similar to using the “magic wand” in Photoshop, which selects all adjacent pixels of a similar color, or the “paint bucket” which fills a region of adjacent pixels of a similar color with another color. This makes it much easier to add regions one after another. A feature request for future iterations would be to be able to select multiple regions and set their measures all at once. We also added checkboxes for displaying the category and value information since the screen can get a bit full sometimes. Also, the save and open buttons are fully functional in our final version.
Final Interface (4 pages + screen shots- reference figures!)
- Describe the final UI design
- Describe the functionality (i.e., what are the operations you can do with it)
- Describe the user interface design (i.e., how you use the functionality)
- Describe your implementation. What was most difficult to implement and why?
- What was left unimplemented
- What was left out and why
- Any wizard of oz techniques that are required to make it work
Ballot Viewer
Before describing the final UI design, it is important to note that the real user interface for the voting task is the pen and paper, and the BallotViewer has always meant to be a passive axillary interface. In the design of the Voting model, the BallotViewer came naturally as a debugging tool, and because we are unable to simulate a full election, remains (for now) as the main feature of the voting process.
The UI for the BallotViewer gives feedback and allows the voter to vote. The program must be running for the voter's votes to count. The voter does not have control over the BallotViewer, as the BallotViewer's job is to locally keep track of the votes and give appropriate feedback. With the program running, the voter would vote on the PollPrecision ballot (created using BallotMaker) using an Anoto pen. The voter selects the candidates of his choice by filling in/checking the boxes that are associated with them or by writing in the candidates' names in the appropriate box. As the voter selects candidates, the BallotViewer keeps track of the votes and updates the screen by highlighting the candidates that were chosen. In order to keep the feedback passive, the BallotViewer also changes pages automatically with the voter; as soon as a selection is made on a different page, the viewer changes to that page. Also, if the voter makes a mistake and chooses two candidates in a measure which only takes one choice (i.e. Presidential Election), the BallotViewer would pop up a feedback dialog informing the voter about the mistake and suggesting that the voter retrieves another ballot.
The most difficult of the BallotViewers features to implement was getting the pen to stream. As of now it remains a 3-4 step process in order to ensure that the pen and the computer are communicating to each other.
In the BallotViewer, the only features left out were the ballot summary and displaying the write-in on the viewer. We planned to have either a ticker or text box of votes that the voter had already made. From our user tests, we learned that the feedback was not used very much by average voters, but certainly a summary box would increase confidence and save time in the end. Instead of displaying what the user wrote in the write-in boxes, the write-in boxes get highlighted like the fill-in boxes. Again, the displays on the screen were not much used by average voters, so we opted to spend our efforts elsewhere while still providing a basic acknowledgment that the voter's write-in will be counted.
The voting process is not easy to make a digital model of, so there are a few steps that were left out. We had a difficult time implementing the pen and without the pen's basic functionality, the other steps in the process were not relevant, so we focused on getting the pen to work. As mentioned in earlier reports, concerns of security were for the most part not addressed, because we decided on achieving functionality before ensuring security measures. An important step for security is the check-in process which remains unimplemented. Also we did not design an UI for poll workers to dock the pen to count the vote. Our initial design was that docking the pen would be the only way to record a vote, but because the UI for the poll worker to do so is still unimplemented, votes are currently tabulated from the streaming feedback.
Poll Graph
The top part has a heading that informs the administrator that the results were submitted and when. There is a scrolling list to let him or her choose which category to look at. Some category examples are president, policy A, judge, etc. After the administrator makes his selection, the bottom half of the screen will display the results using a histogram as presentation. Finally, the administrator can quit the program by pressing the exit button.
The drawing of the histogram uses the Histogram.java got from http://www.cs.princeton.edu/introcs/33modular/. The original version of the histogram is a stand-alone program with its own user interface and only deals with number range (opposed to Candidates, which is hard to position the string). The hardest part is to separate out the drawing of the histogram from the original program and made it integrated to my program.
The print function is not implemented. In order to implement it, the program has to render the graphic of the histogram on the printer. This is very hard to do without knowing how the histogram was drawn at the first place. Considering the printing of the histogram is not a significant feature of the overall program, I left this feature out. A workaround is using screen shot to capture the entire program's screen and produce a jpg file. Then print the file out.
Ballot Designer
The ballot designer has come a long way. It is, in essence, a document editor. Given a PDF, it allows an election administrator or ballot designer to PollPrecision-ize the ballot, giving it Anoto-readable regions for voting and adding markup to allow our system to know what those votes mean.
Most of the functionality is accessible directly from the main window. From here, you can import a PDF, open an existing ballot, or save your current one. There are also controls for interacting with the regions on the ballot (draw, flood-fill, delete, and change measure and value). These buttons, text fields, and combo boxes allow the user to change the content of the current page of the ballot. Also visible are checkboxes for enabling and disabling some visual features that would otherwise clutter the display. Finally, there is a button for editing the measures that will be available throughout the ballot for voting.
The button mentioned above opens a new dialog (modal, the user has to finish there before he can continue editing the ballot), which contains a list of the ballot measures and tools for editing the selected measure.
Throughout the application, buttons are enabled or disabled as appropriate, and any changes made are immediately visible. As you type text to change a field's value, for example, you can see that field's value changing on screen with each key press. The area where the ballot is shown is controlled using scrollbars and a forward/back button to change pages. (You can also change the number in the text box between these buttons to change pages, for convenience). Rendering a page of a PDF is a time consuming process, and there would be a moment of unresponsiveness to the application with each page change if this were left unchecked. As a result, we show a "Please wait" dialog, while a page is being rendered, to provide immediate feedback to the user that the page is changing and that their button-clicks have been recognized.
As far as implementation goes, this was a big one. We made use of the model-view-controller architecture, which was well-suited to this kind of application. It made handling changes to the data easy to keep current throughout the application. In addition, we took advantage of JAVA's event model (adding our own events for changes to the data of the ballot) to allow for much simpler modification of the code, as pieces were not dependent upon each other, just the model. The most difficult things to implement were definitely the drawing portions of the functionality. Keeping the data fresh while responding to clicks and mouse-moves appropriately was non-trivial to keep track of, but to a large extent we succeeded.
Still unimplemented is the ability to change where the ballot is being saved to or opened from. Importing presents the user with a standard open dialog, but opening and saving simply write to the running directory. This simplifies a lot because our output includes quite a few files, so we would really need to be careful in how we choose to allow users to open and save. In addition, it would have been nice to have more advanced editing for the ballot maker, such as resizing of regions and non-rectangular ones.
All in all, however, the ballot maker is a functioning application. We were able to use it to create a PollPrecision ballot from a real sample ballot and use it with our system. Thanks to the convenience of the added flood-fill region tool, this process became much faster (10 to 15 times, actually), and the ballot maker continues to demonstrate its effectiveness. No wizard-of-ozzing is required to make this piece of the project work. The only thing we're handwaving in this process is how the files would be moved onto the machine for administration of the voting process, but this was not among our tasks.
