...

This page would not exist without the valuable feedback we got from the heuristic evaluations. Previously users would not be able to see what calls they had and instead had to cancel them from memory, but this page provides much more transparency so that the user is much more in touch with the actual model.

Implementation

Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.

Our project was designed as a web-app using htmlHTML, cssCSS, jQuery/javascript, phpPHP, and a MySQL back-end. We did not use any frameworks, but mainly because we were new to all of these the technologies involved and were unaware of the benefits of other approaches.  We had to limit the focus of our project to a single browser (Chrome) because of the variability of interpretations of CSS across the browser landscape; this severely impacts usability, and given more time we would have worked to improve compatibility with other browsers.

Because there was no other way to access the user's microphone from their browser, we were forced to use Flash for the recording widget.  This completely breaks compatibility with Safari, and introduces yet another technology that our site must be dependent on.  Luckily, we found the WAMI Recorder, which allowed us to create and manipulate a Flash-based recording widget using HTML and javascript.

Our original intent was to create our own database of representatives, but we ended up using the Sunlight Congress API instead.  Every time users search with their zip code, the API is queried.  This means our site will stay up-to-date even after election season, with no more work on our end.  But it also means that if the API ever becomes unavailable our site will be completely unusable.

We had to partition the work among three people, so we each worked on separate pages; if we had not communicated effectively and reviewed each other's work, the internal consistency of our interface would have been greatly diminished.  We took turns working on the common style elements in the default stylesheet, so there were a couple instances of someone's "improvements" accidentally breaking another person's work.

Evaluation

The user test was conducted on a laptop with the user in control and the facilitator and observer behind the user on either side. Our users were all MIT students who had no previous experience contacting policy makers. While perhaps more technicaly inclined than other users in our proposed population, these test subjects still had the esential trait we were looking for: a lack of experience contacting policymakers.

...

• Time selection widget unnatural (moderate)
  • Remove the widget and just specify a format for user to type time
• The user asked about
  • The user did not have her phone with her, so she was not alerted by it ringing as would normally be the case
• The voicemail record button has a microphone icon while external consistency calls for a red circle (cosmetic)
  • Change the icon to a red circle
• the politician's office hours (minor)
  • We could gray out the unavailable hours in the date and time selection widgets
• The "View Scheduled Calls" link in the menu bar was not immediately visible (minor)
  • Provide visual distinctions for buttons (colored boxes, perhaps)
• The now button on the time entry widget confused the user because she had already entered a future date, and now does not make sense in that regard (mild)
  • Remove the now button when the date is not set to today
• The time entry widget is not intuitively mapped (mild)
  • Use a more intutive time selector widget
• The header buttons are not obviously buttons (cosmetic)
  • Change the background color and edges of the header hrefs to be more button like

...

• it did not affect the date, only time (minor)
  • Have the now button apply to dates too
• Possible safety issue for accidentally canceling scheduled calls (minor)
  • Add a confirmation dialogue

User 3

• The "View Scheduled Calls" link in the menu bar was not immediately visible (minor)
  • Perhaps draw attention to the button temporarily after a call is scheduled for the first time
• From the Scheduled Calls page, there is no way to return to the results -- home and New Search do the same thing (minor)
  • Perhaps make the home button "Expect Us" return to the results page, or add a "Most Recent Search" button in the menu bar
• It was not obvious to the user when the recording widget started recording, so they did not know when to speak (moderate)
  • Add some sort of feedback mechanism, such as the number of seconds the widget has been recording.
• The security hole presented by the lack of verification of phone numbers made this user hesitate to use the site at all (minor)
  • Text the user a verification code that they must enter before using that number for calling.

Reflection

The iterative design process was useful, because it allowed us to make changes rapidly and then get feedback to double check that we had actually made an improvement with that change. If we were to do this again, we would probably investigate which technologies to use more carefully. For all of us this was our first time using cssCSS, javascript, or phpPHP, and while we got the work done, we had to spend more time learning the technology than we would have liked. However, now that we know the technology better, it would be useful to run more high fidelity tests, because we believe the feedback from testing phases that actually involved a computer (heuristic evaluation and final user testing) to be the most valuable and actionable. For example, even though our paper prototype had radio buttons on the filter tab, none of our test subjects commented on them, and this was likely due to the low fidelity of paper. Again, web Web prototyping is so quick, that we think it might have been more useful to test a wire-frame prototype a little earlier on.