GR6 - User Testing
Design
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.
One of the components that we changed was the togglers on the left side of the screen. In pre-GR5 versions, the user could show or hide certain meals in a day/week/month, but evaluators in the heuristic evaluation suggested changing it to allow showing/hiding meals that contain a certain food group. This is more useful than toggling meals because meals are already segregated in the week view. We considered making the toggles different colors for good visibility, but we decided against it since it a meal can contain multiple food groups and it would have been too cluttered to represent multiple colors for every meal.
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 it would be consistent with the way that groceries are added in the Groceries page.
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 is no longer a form as it was in the paper and computer prototypes. A form seemed bulky to use, especially since people may want to enter in 20+ grocery items at a time after they go shopping. Users could also potentially lose a lot of data if an error occurred before they submitted but after they had already entered their 20+ grocery items and details. A form also didn’t match the metaphor of a real-life list.
Now the grocery list is closer to Google Tasks in look and feel, which is in line with the Google Calendar analogy on the View Meals page. It looks and feels more like a “list,” as it’s supposed to be. Users can type directly into the list, so they get immediate feedback about the data they’re entering, and it’s less likely they will lose much data if an error occurs because they only enter one item at a time. Users input the name of an item first, then click the ‘edit’ button on that entry to expand on details for individual items. The downside to this design is that each edit of these details now requires a click per grocery item. One way to fix this is how Google Calendar deals with editing details of an event: by implementing a shorthand language for the details. For example, entering “3-5PM Lecture” in Google Calendar creates an entry at 3-5 PM for “Lecture.” Similarly, entering “Bagel $2 350 g” could be shorthand for a bagel that costs $2, has 350 calories/serving, and is a grain/carbohydrate.
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 design still might create confusion for users.
Analytics
The final analytics page was designed to resemble the Meals page for internal consistency. Toggles were created, and calendars were used to select the date range for the analytics. The graph itself was interactive, and took up the same space as the Meals calendar.
The page has gone through several completely distinctive phases. User testing was particularly helpful on this page. Going into the design, we knew that we wanted the user to be able to compare different types of information at the same time. Our original solution was to have multiple graphs, but users found this confusing. Then we decided to allow the user to dynamically add graphs side-by-side, but heuristic evaluators found this at once too complex, and not flexible enough. Finally, we decided to display all of the information on one large graph, and allow the user to dynamically change the content of that graph.
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.
Implementation
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.
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 when clicked.
Because of time, the following features were not implemented in the grocery list, but could greatly enhance its usability. These changes would make the list easier to edit, and some of these would make it externally consistent with other similar lists.
- Shift-click for selection: User can select multiple items by holding down the shift key and clicking on many items.
- Shift-click-delete: User can delete multiple items at once by selecting several and pressing the “Delete” key.
- Adding items from the middle of the list: 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.)
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. We decided that, while this may cause the page to load slowly in the long run, there shouldn’t be noticeable differences in performance for a little more than 10 years. By then, we hope to have developed a more efficient solution. The data is loaded into a plotting pluging called “Flot.”
All of the datepickers and toggles update the graph in real time. The date pickers also update the text caption above the graph. We used JQuery UI to create the datepickers.
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.
Evaluation
The facilitator briefed the user on the purpose of DailyDigest and how user testing would proceed. After the briefing, she gave the users a list of four tasks to perform:
- View all the vegetables you ate over the past week
- Record what you had for lunch today
- Add an item to your grocery list
- View the cost of your breakfasts over the past month
She also told them to speak aloud their thoughts while going through the interface to allow us to pinpoint usability problems. Then the facilitator and observer watched them complete the tasks.
We found our users by asking students who were in the vicinity when were started conducting user tests. They represent different groups of our user population: those who rely on a dining plan, those who often order out, and those who frequently cook for themselves.
On the Meals page, one problem users helped us identify was the “Add Meal” button. It did not pass the squint test, and users (used to Google Calendar) first tried to actually double click on the calendar interface to add a meal. We might solve this problem by using colors or size to make the button stand out more, and we might find a way to implement adding meals by double clicking on the calendar.
On the Groceries page, the biggest problem that our users had was with finding how to add an item. Currently, the “Add Item” field is in the very bottom of the list. The most obvious fix would be to move that field to the top of the list. Additionally, some users expected a button as was on the Meals page. That would add internal consistency and make it more obvious how to add items.
On the Analytics page, the biggest problem was understanding how to control the graph. In particular, we realized that our labels “Food Groups” and “Meals” didn’t convey many affordances for their actual purpose. Easier to understand labels would help here.
The transcripts from our user tests can be found here
Reflection
We should have done more paper prototypes and earlier iterations before moving into the computer prototypes. We kept coming up with new ideas, and we never had opportunity to test these ideas on actual users. Because of this, our design suffered unnecessary complexity, both in the implementation and in the front-end.
We should have focused more on learnability, and separated beginner and advanced users. Perhaps having an “Advanced” page that the user can select to access the additional options. If it’s good for everything, it’s good for nothing. We tried to accommodate both experienced users and beginners, and made it difficult to use for either. We should have gotten more user input as we came up with new ideas, rather than just assuming that all new ideas would be good ideas for the end user.