DailyDigest Design #1
Index
Storyboard (top)
Armed with a Trader Joe’s receipt, Fred goes to the DailyDigest website to record the groceries he just bought and to record the meals he ate last night and today. He lands on the homepage and clicks the login link.
He lands on the Food History tab, but sees the tabs to go to the Food Stock and Analytics tabs. He wants to record his groceries first, so he clicks on the Food Stock tab. He clicks on the Add Item button to add an item. A pop-up appears, so he enters the details and clicks Save. The item instantly appears in the list. He adds the rest of his items by clicking the Add Item button once for each item. After entering in “aspargus,” he sees his mistake in the list, so he clicks on the entry. A pop-up appears to allow him to edit the entry. He fixes the typo and clicks Save.
After he finishes his phone call, he forgets that he hasn’t finished entering his receipt, but he does remember that he still needs to record the food that he ate for dinner last night and for breakfast and lunch today. He clicks on the Food History Tab and clicks the Add Meal button. A pop-up appears. He fills in the details for his dinner, ignoring the drop-down lists that contain ingredient suggestions pulled from his Food Stock. He moves onto breakfast, but this time he does not ignore the suggestion drop-down lists. He creates five ingredient fields and selects bread, peanut butter, egg, banana, and milk from the drop-down lists.
He remembers that he forgot to enter in the last item on his receipt into the Food Stock, so he clicks on the Food Stock tab to fix the error. He then returns to the Food History tab to fill in the details for today’s lunch. He remembers that he also got a snack from a multicultural exhibit, but doesn’t know the ingredients but can guess the number of calories it contained. The fields in the Add Meal pop-up are optional, so he only enters in the number of calories and a name to indicate that it was a snack from the exhibit.
Fred is curious about his eating habits so he remains on the Food History Tab. He clicks on the Week button since the Month button was initially toggled. This sets the time range to the current week. Glancing over it, he sees that he made a mistake recording yesterday’s dinner, so he clicks on it. A pop-up appears with the option to edit that entry. He clicks edit to fix the entry.
Next, he wants to see some statistics about his eating habits, so he clicks on the Analytics tab. He set a goal to eat more vegetables and spend less money on snack food, so he clicks on the food group image that’s shown on the Analytics tab.
He adjusts the time range and a bunch of graphs appear. He checks the vegetable graph and is satisfied, so he navigates back to the Analytics tab to click on the cost analytics image.
He adjusts the time range and clicks on the Criteria drop-down menu to select “Meal.” Four graphs show up, one for Breakfast, one for Lunch, one for Dinner, and one for Other (he categorizes snacks as Other). He looks at the Other graph to see how much money he has spent on snacks in the past month.
If he wanted statistics on where he gets his food, he could have clicked on the location analytics page.
He’s finally satisfied and closes his web browser window.
Usability Analysis (top)
Overall Usability (top)
DailyDigest is organized into three tabs, each of which covers one of the application’s three major functionalities: Food History (what the user has eaten), Food Stock (what the user owns but has not eaten yet), and Analytics. The tabs are always shown at the top of the page so that the user’s location in the website is always visible. We predict that the Food History and Food Stock will be used much more often than Analytics, so the ordering of the first two tabs is somewhat arbitrary; they can be switched around with little effect on efficiency. In all pages of the application, the login/logout link is always at the upper right hand corner of the page, which is consistent with the interfaces of most modern websites. The user’s name is also in that corner so that it’s easy for users who use the same computer to tell who is currently logged in. In addition, there is always a bar at the bottom of every page with links to product information (e.g. About Us), which is consistent with most websites as well.
Login Page (top)
This is first page that potential users see. It contains a brief description of DailyDigest. If they want to start using the application, they can choose to login with MIT certificates by clicking the “login” link. This page is intentionally simple, so there isn’t much learning, doing, or error-making involved.
Food History (top)
This is the first tab that the user lands on after logging in. The interface looks like Google Calendar’s (GCal’s) interface. Each meal is analogous to a GCal event and can be handled the same way. If the user wants to view more details for, edit, or delete a meal, he can click on it, which will generate a pop-up with those options. The user can specify the size of the time range that he is interested in (i.e. single day vs. week vs. month). He can also specify the time range by navigating the small calendar that’s shown on the left side of the page. If the user is only interested in seeing certain meals (e.g. breakfasts and lunches but not dinners and other), he can do that by toggling the four labels that are shown under the small calendar. In addition to viewing his food history, he can also add a meal by clicking on the “Add Meal” button above the small calendar, which would generate a pop-up with the form to enter details.
Learnability
The vast majority of our users (MIT students) are active GCal users, so the similarities between the two interfaces make our interface easy to learn.
Visibility
All information about Food History is visible at all times. When the user clicks on the Add Meal button, he is not redirected to a separate page with a form to enter the details. Instead, a pop-up with the form appears. The user does not lose sight of the food history. There is a trade-off between visibility and efficiency. In our scenario, Fred’s first goal in opening the application is to record newly-purchased groceries or recently-eaten meals. Although the Add Meal button is clearly visible and easily accessible from the current page, he would have to click it once for every item he wants to add, which decreases efficiency. Instead of having a button, we could have the form where the user provides meal details directly on the food history page so that he could immediately start typing in an entry. However, this design would cause the page to seem too cluttered, making normally visible objects difficult to see.
Efficiency
Users like Fred eat their groceries (items in their Food Stock), so once the user has opened the meal entry form, he’ll want to pull ingredients from his Food Stock. As he types the name of an ingredient into a textbox, a dynamically-changing list will drop down from the textbox to provide suggestions from his Food Stock. He has the option of choosing one or none. This feature allows him to complete his task more quickly. Although we make it more efficient to enter ingredients, the whole notion of splitting a meal into its ingredients and classifying their food groups might actually decrease efficiency since it puts too much mental strain on the user. However, it would make the analytics more precise, thus increasing the application’s value.
Errors
An added item instantly appears in the history, so if the user made an error in an entry, he can immediately see it and click on it to fix the error. Every decision is reversible (e.g. a toggle can be untoggled).
Food Stock (top)
The items in the user’s Food Stock are shown in a list grouped by food group (vegetable, fruit, grain, meat, poultry, and dairy). There is an Add Item button at the top that allows the user to add something to the Food Stock. Similar to the Add Meal button in the Food History tab, clicking it will show a pop-up with the form to add details instead of redirecting the user to a separate page. To edit an item, the user can click on the item, which will show a pop-up that looks like the pop-up to add an item.
Learnability
The interface is very straight forward. The only thing that the users need to learn is to edit an item. To help them figure out that the entries are clickable, each the background of an entry/row will change color if they hover over it with their computer mice. This affordance typically suggests that it’s clickable.
Visibility
All items are initially visible, but if there are too many items and the user does not want to scroll through all of them, he can click on the -/+ that’s on the right end of each food group label to collapse or expand the corresponding section. This method of indicating that a section is collapsible is consistent with other websites that do the same thing, so it’s not hard to learn.
Efficiency
This tab has the same efficiency problem that the Food History tab had. The user would have to click the Add Item button once for every item that he wants to add. It would be more efficient to have the Add Item form on the page to reduce the number of clicks, but it would make the page more cluttered. The item editing function could also be more efficient. Instead of having a pop-up, we could have allowed editing inline (i.e. the user could click on the text, which would turn the text into a textbox). To change an item’s category, the user could drag it to another category. However, this approach would be too error-prone. To edit an item’s text, the user would click on it to switch to text editing mode. To get to dragging mode, he would also click on it. Thus, it’s not clear where he should click to get to the correct mode. He would have to spend more time trying to aim his mouse to the correct part of an entry to activate the correct mode. A pop-up avoids that ambiguity.
Errors
We chose to have the add item/edit item dialogs appear on the same screen as the Food Stock instead of navigating to a different page so that all information is visible. This lets the user see what he has or has not entered yet, which helps him correct the type of mistakes that Fred made when he forgot to input the last item on his grocery receipt. Once an item is added/edited/deleted, the changes are immediately reflected on the page. This helps Fred correct his asparagus mistake sooner rather than later.
Analytics (top)
This tab initially contains four pictures (only three are shown in the storyboard). Each one represents a different way of cutting and showing information about the user’s eating habits. The four ways are by food group, cost, location, and calories. Each image is a link to more detailed information about each area. Each image is a graph of the overall trend in their respective areas (e.g. the one that’s displayed for cost shows the amount of money that the user has spent across some time range). After the user clicks on one of the four images, he will be redirected to the appropriate page with a bunch of graphs and widgets to specify the time range that he wants to view analytics for.
Learnability
The interface is straightforward. Everything is labeled with words, so there’s nothing that needs to be learned.
Visibility
The top of each analytics page has a calendar and radio buttons to allow the user to change the time range. This is probably the first thing that the user will want to do when looking at Analytics, so the time range controls are placed at the top for maximum visibility and efficiency. Cost analytics page contains an additional drop-down menu that allows the user to specify the criteria with which the data will be cut (e.g. it could display a graph for each meal or a graph for each food group).
Efficiency
The detailed graphs are positioned side-by-side for quick viewing. Users who are concerned with every detail of their nutrition can click on a graph to enlarge it. The time range controls require a very small amount of clicking, so users can get their information quickly.
Errors
There are very few errors that a user could make with this interface. The user could accidentally choose the wrong time range, but this mistake would be visible enough (the selected time range is displayed) that he could notice it and change it.