GR6 - User Testing
1. Design
1.1 Meals
The Meals page (formerly called the Meal Log) of our final implementation is not drastically different from the design used in earlier GR’s. It mimics the Google Calendar interface for good learnability, which was received positively by users in the heuristic evaluation and user testing stages. Unlike Google Calendar, meals (events in Google Calendar) are not centered around times of the day (3AM vs. 5PM), but rather by their meal type (breakfast vs. lunch). This makes the most sense for DailyDigest since we do not handle data about the time of day that meals were eaten at.
...
We also changed the Add Meal dialog. Initially it was a form that allowed users to enter multiple items at once, but we changed it to adding one item at a time, which would be saved in a buffer before a meal (with multiple items) could be saved. We changed this so that the form would be consistent with the one on the Groceries page.
1.2 Groceries
In our final implementation, the grocery list is on a separate page than meal entry. We decided to separate these two functions because the grocery list is non-essential, but rather a tool for efficiency, and new users were confused by it when presented with it right away (before learning the main purpose of the site). We also added a brief explanation to the top of this page, since we realized that even if the grocery list by itself is made very learnable, the purpose of the grocery list is not by itself completely self-explanatory.
...
The grocery list demoed in GR5 morphed out of a design that was created after the computer prototyping and discarded shortly before the GR5 submission. This design was itself a halfway point, a “halfway list” that consisted of a form with a single input item, that when submitted would push its contents into a viewable list. There were a few problems with this design. For one, editing items required either opening up the current details in a new window or sidebar, which involved making a replica of the form used to enter items in the first place. This did not seem elegant. The alternative was to push all editing of details to that one form and to limit users to either adding an item or to editing an item. This discarded design still might have created confusion for users.
1.3 Analytics
The final Analytics page was designed to resemble the Meals page for internal consistency. On the left-hand side of the page, toggles like the ones on the Meals page are used to select statistics for different food groups or meals, and calendars are used to select the date range for the analytics. The graph itself shows details of data points when hovered over, and takes up the same space as the Meals calendar.
...
Users had also complained that the interface was completely different for this page than for either other page. We decided that the Google Calendar interface would be most familiar to most of our users, and so we wanted to keep the basic layout from the Meals page for the Analytics page.
2. Implementation
2.1 Meals
The calendar itself is a table with CSS-stylized divs. Every time that the date range or the date granularity (day vs. week vs. month) is changed, the rows of the table are changed dynamically. The meals are also divs that sit inside the cells of the table. The datepicker is a JQuery UI plugin stylized to look like Google Calendar’s. Because of the implementation of drag-and-dropping meals, we could not correctly implement the feature of clicking directly on the calendar to add a meal. Many of our users in User Testing and evaluators in Heuristic Evaluation expected this functionality (because it is used in Google Calendar), but we were not able to correctly implement it.
The backend consists of a MySQL database that stores meals, items, and the relationships between meals and items. We use PHP and AJAX calls to interact with the database.
2.2 Groceries
The grocery list is implemented as an unordered list of divs. Each grocery item is allotted two divs--one that contains a textbox for editing the name, and another that displays the text in an uneditable div and displays the "edit" and "delete" buttons for that item. The divs are alternately displayed and hidden when clicked.
...
- Adding items from the middle of the list: In the current implementation, pressing “Enter” while an item in the middle of the list is selected will move the selection to the existing item below it, not create an empty space for a new item, as might be expected. (Currently, the Down arrow key also results in this behavior, which is actually the right response.)
2.3 Analytics
The analytics page uploads all of the analytics data in the database for the user on page load. This enables the page to dynamically display different data from different date ranges without waiting for AJAX calls. This was perhaps the most important design decision for this page. While this may cause the page to load slowly, there shouldn’t be a noticeable difference in performance until the user has a little more than 10 years of data. The data is loaded into a plotting plugin called “Flot.”
...
Unfortunately, the dynamic sizing and resizing of the graph didn’t work for lower screen resolutions, which led to some usability problems. Users had to scroll the page to see the rest of the graph and the legend.
3. Evaluation
The facilitator briefed the user on the purpose of DailyDigest (using the same script as in GR3) and how user testing would proceed. After the briefing, she gave the users a list of four tasks to perform:
...
The transcripts from our user tests can be found here.
4. Reflection
We should have done more paper prototypes and earlier iterations before moving into the computer prototypes. We came up with several new ideas, but simply picked one for the computer prototype instead of creating another paper test. Because of this, we created a computer prototype that was not as good as it could have been, and we missed an opportunity for feedback on a design more similar to our final one.
...