...
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 the form would be consistent with the way that groceries are added in one on the Groceries page.
Groceries
...
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 create have created confusion for users.
Analytics
The final analytics Analytics page was designed to resemble the Meals page for internal consistency. Toggles were created 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 were are used to select the date range for the analytics. The graph itself was interactiveshows details of data points when hovered over, and took 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 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 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.
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-delete: User can delete multiple noncontiguous items at once by selecting several items and pressing the “Delete” key.
- Adding items from the middle of the list: Pressing 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.)
...
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 While this may cause the page to load slowly in the long run, there shouldn’t be a noticeable differences difference in performance for until the user has a little more than 10 years . By then, we hope to have developed a more efficient solution. of data. The data is loaded into a plotting pluging plugin 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.
...
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:
...
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 or by making a duplicate of the button elsewhere on the screen. We might also 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, and push added items downwards rather than upward. 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 came up with several new ideas, and we never had opportunity to test these ideas on actual usersbut simply picked one for the computer prototype instead of creating another paper test. Because of this, our design suffered unnecessary complexity, both in the implementation and in the front-end.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.
We could We should have focused more on learnability , and separated beginner and advanced users. Perhaps , perhaps by 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.both.