...
The downside of server-side logic is that frequent server requests cause some delay. This was occasionally evident in our GR5 staging, as we deployed our project on a free -and inherently slow- Heroku account. However, because the reading and switching of paper ballots restricts the speed of the election audit task, a blazingly fast system is not immediately necessary.
We used intro.js bootstro to implement the interface tutorials, a Javascript library for easy interface tours.
Evaluation
For our user tests, we tested 3 employees of the Town of Concord. One was the town clerk, and the other two worked in the office. All of them have administered elections and counted ballots. We did not conduct a demo, because our interface has a tutorial built in and would not have a demo in normal circumstances.
Briefing
You will be entering ballots today as part of an election audit. You have been assigned 5 ballots and will complete the audit. This is the auditor side interface, so assume a town clerk or warden had already set up the election options and given you a username.
Tasks
- Enter the site and make your way to the main audit page. (We let them choose whether or not to take the tutorial in order to get a feel of whether people would take it).
- Enter 3 ballots with given values.
- Fix a mistake on the current ballot.
- Fix a mistake on the previous ballot.
- Complete 2 more ballots.
- Fix a mistake on ballot 1 (i.e. restart the election).
- Finish entering ballots and find the number of votes that Elizabeth Warren received.
Evaluation of the Issues discovered during the User Tests:
Issue | Severity | Possible Solutions |
Didn’t notice that the Fix Mistake Menu had a tutorial | Minor | Despite not using the tutorial, she was still able to navigate the menu and complete her tasks. This is just a matter of changing the wording at the end of our first tutorial to make things clearer. |
User wanted to try the tutorial but accidentally clicked “Skip” instead of “Continue” | Cosmetic | We think this is because the “Skip” button has a brighter color (red). This should be an issue of just changing the button colors to be more intuitive. |
Expected to see a ballot-like UI, which listed candidates in order. Commented that this felt slower. (Current approach is based on a pie-menu) | Minor | This is a new UI, but we put a lot of thought into how to make this most efficient. After a bit of practice, we think this would be faster. This implies our learnability could be higher but the tradeoff is for long-term efficiency. |
The order of candidates on the page seemed random | Minor | Again, we considered efficiency and placed the candidates based on party and frequency with which that party is selected. Once again this is probably a trade-off we consciously make between learnability and efficiency. |
No place to write in the name of a write-in candidate | Minor | We were told in our first interview that usually the write-in ballots are put to the side and not recorded, so we are handling the needs of many of our users. |
User didn’t see the “cancel” button to return from the fix mistake menu | Minor | She just went back to the previous element so it was not too inefficient. |
“This would be so much better than the hand counts” | Good | She thought this system as a whole was a success and an improvement on the existing methods. |
Restarting from a mistake somewhere on this ballot or the previous ballot rather than allowing a fix of just one mistake was a good decision for elderly users | Good | She thought it was very helpful that the elderly users won’t need to jump around pages but can just back track a little bit to be sure of accuracy. |
Wanted a “fix one mistake” option for ballots more than 2 ago. Currently we assume that means the audit is off and requires a reset. | Minor | Mistakes that long ago were not a major concern of hers, and she said this makes sense too. |
...