You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

GR2 - Designs

Scenario

Erin is going out to buy food for the week. Before leaving, she uses Dough to check how much money she has left for food this week. As she is putting away her food, she logs the food she purchased in dough. She also adds the total receipt amount, $57.45 to her budget tracking. Erin is hungry after shopping. She uses dough to look up suggestions of food to use to prevent waisting food from last week. It turns out she still has a bunch of asparagus in the back of her communal fridge. Erin didn't cook the asparagus earlier because she wasn't sure what to cook them with, so she uses dough to query external recipe sites for suggestions.

Designs

Design 1:

When Erin navigated to the website, she sees the login dialog. 

After entering her username and password, she it taken to the Dough home page. It contains a menu bar on the left side, status messages at top, and a list of items, separated by location and initially organized by expiration date. Food can be shown by location by clicking the arrow near the location name. This causes all the items to be displayed below. The top status bar displays hint for using the system and (when applicable) and link to undo that most recent acton, such as adding food (like in gmail). On top of the menu bar is a box that displays the current budget progress, how much money out of the total amount that has been spent in the current month. Looking there, Erin can quickly check how much money she has left. 

After going to the store, Erin comes back to this same page.  To enter her purchases, she clicks on the Add Food button on the menu bar. 

Food is added by storage location. Erin specifies location by clicking on the appropriate tab. She enters the food items one by one, specifying their expiration date (if they have one listed) and any other notes. By default the food is listed as purchased on the current date. This can either be changed item by item or for all items using the purchase data at the top of the window. Changing the data on individual items overrides the data set on the top. If more items need to be added, more item entries can be added using the plus sign. Items are submitted by clicking the button at the bottom right of the addition window. (looks like a smudge on the scan). 

On the budget page, the budget can be set and previous purchases are displayed by month. Erin can cycle through her previous purchases by month using the arrows on the top of the box displaying purchases. Erin adds her purchase on the add purchase line. 

Erin goes back to the Kitchen Contents page and sees that she still has asparagus from last week. She checks the box near asparagus, as well as the frozen greens she has in her fridge. Then she click the recipes button and is taken to an external recipe site with a query using those items in a new tab.

Evaluation: 

This design values efficiency over learnability. There are no splash screens explaining procedures. Each entry box has a label near it, however, as well as having the mode displayed on the menu bar by means of highlighting the name current page. The nested menu idea (with the clickable triangles) used for displaying food is similar to file systems in operating systems like Mac OS X aiding learnability. I expect the most complicated part to learn would be searching for recipes, as there is no dedicated search page. The status bar at the top will initially include a message about selecting the check boxes near food and then hitting the recipe button, but there is no guarantee that users would read that. Efficiency is hindered slightly by the fact the users must separately enter items and price. Users also must specify a location for food items, and add items in different locations in different views. For users who don’t organize food by location in their head (aka, want to add milk, then cereal, then ice cream, each in different locations), this system would not be efficient. This tradeoff is made to prevent users from having to type/select the location for each food item, would would also not be efficient. In looking for items, users can either scroll through the entire list, or use the search at the top of the page, speeding up the process.

Users are prone to make errors when they type, and there is a lot of text entry in this design. Suggestions for items names help prevent these errors, but they will still happen. The status message includes a link that will allow you to undo the last action (such as add food) so that users can undo a change if they notice quickly. Otherwise, if a user added the wrong food, (and it was more than one click on the sight ago) they just have to delete all the foods they added and re-add the correct items. The time to do this would be improved by searching for the item, but it’s still not fast. The same holds for adding purchases to the budget page.

Design 2:

Upon loading the website, Erin sees the Dough home page. It is easy for her to find the login button at the top, and she enters her username and password in the modal dialog box that appears when she clicks it.

After logging in, she is presented with her dough splash page. It gives her a brief summary of the most relevant information to her regarding food supply, recipes, and food budget. Each section of the page supplies a link to a more in-depth page for each area, and links are also provided at the top in the form of tabs.

She wants to look at her budget before going shopping, so she clicks the budget tab. Here she views a progress bar representing the percentage of her monthly budget she has used. Her $300 goal was originally set during the sign up process for Dough, but she could change it at any time with the "edit budget" link. She could also view a graph charting her spending over time, see her latest purchases, and edit previous purchase amounts using the "edit purchases" link.

Erin goes shopping, and when she returns she loads up Dough again and proceeds to the food tab. Here she can see her food supply presented in thumbnail form. Each food thumbnail has a checkbox at the upper left corner so that multiple foods can be selected and have operations performed on them (delete, move, and change label). The foods are sorted by the time until they expire, and a progress bar at the bottom of their image represents the approximate time they have left. An icon at the upper right corner of the thumbnails represents where each of the foods is located (critical information for estimating time until expiration); ice represents food in the freezer, a refrigerator represents the fridge, and a cabinet represents food that is not cooled. These locations are changed with the "move to" command. It is also possible to change which types of foods are being displayed with the view multiple select boxes.

Erin selects "add food" on the previous page to enter the foods she has just purchased. This brings up a modal dialog box with several spaces for food. Entries can be removed with the minus sign, and more entries can be added to the list with the plus. If enough entires are included, a scroll bar will appear to scroll through them. To enter the foods, Erin can click "add food", or to quit she can press "cancel" or the x in the top right corner.

Erin begins to enter the food she bought. When she begins typing beef, the box predicts her entry with autocomplete. She only has to type "be" before it recognizes "beef" for her. Upon recognizing the word beef, Dough also fills in an estimated expiration date and desired storage location for her. Erin is able to go back and change these defaults if she so desires, but she is satisfied with the default result.

She presses "add food" to add all the new foods to her food supply. Dough prompts her in another modal dialog box to enter in her total bill for the food. Here she has the option to simply enter the amount or cancel it and do it later via the "budget" tab. She enters the amount she spent and presses "ok".

After seeing that the new items are added to her food supply, Erin goes to the recipes tab to find something to cook. Pressing "go" on this page would suggest all recipes that she can make with her food, but she has more specific ideas in mind. She presses the advanced option link to open up the advanced tab.

Under advanced options she can see different ways to refine the recipe search. On the lower left there is a list of items in her food supply sorted by expiration date. She notices the asparagus at the top and decides she should really use it up. She clicks the check mark next to it to select it and find only recipes involving asparagus. She presses go to query external recipe sites.

The recipe tab now displays the results of her search. She can scroll through them, click on individual ones to view them, or press back to go to the main recipe search page.

Erin decides poached eggs and asparagus sounds good, so she clicks on it. It brings up a pop up page containing the recipe from an external recipe site.

Efficiency and Learnability:

In several parts of this design, it was difficult to achieve both efficiency and learnability. For instance, the thumbnail page presents a lot of information to the user at once, but it is quite efficient because an experienced user could quickly glance at the information, process it, and perform selections and actions on many food items at a time. However, a new user may not understand what the pictures, progress bars, icons, and check marks on this page mean. Specifically, the food location icon at the top right corner of each thumbnail might be confusing (refrigerator, cabinet, ice). They may also not know what the progress bar indicating time until expiration means. The tabbed organization of the website as a whole also represents a battle between efficiency and learnability. It would be possible to combine all the functionality thats separated into these tabs into one page. For instance, a recipe search could be done efficiently from the food page by selecting foods and clicking a "find recipes" button. However, from a learnability standpoint it made more sense to keep the site more modular. If you want to do something, you go to the corresponding page. This gives new user a clearer idea of what goes on where.

Visibility:

Overall, this design has good visibility. The state of the program (the current foods the user has, their food budget, etc.) is presented to the user with graphs, charts, and pictures of their foods.

Error prevention/correction:

There are strengths and weaknesses in error prevention/correction in this design. Though there are many text boxes to fill in while entering foods, autocompletion and predictions about the user's entries can easily help them fill in the fields quickly (also an efficiency benefit) and generally without error. Nonetheless, users may also ignore the autocompletion or forget to fill in values on their own. Even worse, they may not realize that they did not change the predicted value and not know to correct the error. In most cases, errors are easily recovered from. Food entries, for instance, can be moved around and deleted with ease. Any errors made with the budget can be changed on the budget page. Modal dialog boxes also help with error prevention. They prompt the user for necessary information and, because of a faded background, clearly indicate to the user that a new mode has been entered.

Design 3:

Before going out to buy food, Erin checks her budget on Dough.  When she goes to the website, she first sees the homepage.

When she enters her username and password and clicks "Login", the login bar at the top changes to display "Welcome, Erin".  Wanting to check her budget, she clicks the rightmost column, labeled "Budget".  This takes her to the budget page.

Here Erin can see how she has spent her money recently, and how much money she has left.  She selects "weekly" on the right, to know how much she has left to spend this week.  She can customize her budget by clicking "Change budget".

Notice that when she leaves the homepage, the three large column buttons reduce into three small icons in the bottom right corner.  These three icons stay on the screen when the user scrolls down, and are links to the three different pages.

When she returns from the store, she logs in to Dough again.  This time at the homepage she clicks "Food", the leftmost column, taking her to the food page.

Here she can see a graphical display of her categories, in this case fruits, meat, drinks, and other.  She adds her items as follows:

  • The cursor is already in the input box at the top left.  She types "be", and autocomplete fills in "beef".
  • At this point, a default price (the last she paid for beef) fills the price field, a category (meat) fills the category field, and an estimated expiration date fills the last field.
  • The "fridge" button is then highlighted, since Erin usually puts her beef in the fridge.  She could press "enter" to put her beef in the fridge, but if she wants to put it in the freezer, she clicks the "freezer" button.
  • This enters "beef" in the meat category and returns the cursor to the input box.

She continues this method for all her items.

Now, on this same page, she can check which items are going bad.  Since the food is by default sorted by expiration date, she looks at the top of her fruits and vegetables list, and realizes asparagus is about to expire.  When she checks the box to the left of asparagus to note that she would like to use it in a recipe, a box saying "find recipes" pops up in the lower left of the page.  Thinking she would also like to use chicken, she checks the box next to chicken and clicks "find recipes".  This takes Erin to the recipe page.

Here she can navigate to different recipes involving asparagus and chicken, and when she clicks on one, it appears on the right side.

If Erin had not selected ingredients, and had simply clicked on the recipes icon or column from the welcome screen, the page would have looked like this.

Evaluation: 

Learnability:

This design favors learnability, since it has an initial welcome screen with descriptions on what to do.  There are some things that are not as learnable though.  For instance, the check boxes on the food page that allow a user toAgain, the check boxes mentioned in learnability are also not as visible as some other aspects.

search for a recipe from those items has no affordances.  A user would have to click them to find out what happens, or go through a tutorial.

The toolbar at the bottom is also unusual. Although it makes things more visible and efficient in the long run (since it floats and is always visible), it is a little more difficult to get used to than more popular navigation methods, with selection on the top or left side.

Visibility:

In general, most things are visible in this design.  Each page displays all the information at once.  An example of this is that the recipe page shows recipes returned from the search (or if there was no search then popular recipes or recipes you can make) on the left, and specific recipe details on the right.  This omits lots of clicking the back button to see the list again (which increases efficiency also).

Efficiency:

This design also tries to make things efficient for the user.  Autocomplete and filling in defaults is an example.  Also, the fact that the input field to add new food is at the top of the screen instead of in a modal dialog makes it easier for the user to add things instantaneously.  The check boxes on the food page are an example of choosing efficiency over learnability.  Since the user only has to learn this feature once, and it is a more advanced feature, he can check items more quickly than going to the recipe page and entering that information there.  A problem with efficiency is that the user enters a price for each item, instead of listing all the items on a grocery list with one price.  This is a trade-off with the accuracy of the data, though, since it could be useful to the user to know how much was spent on which items.

Error Prevention:

One of the things designed for error prevention was putting the check box for recipe searching on the left of the food items, instead of the right.  Putting this on the right would mean it is near the delete button, and that could cause errors.  This design tries to keep those types of buttons apart.  A weakness of this design in this area is the default values automatically completed.  A user may enter an item and not want the default values, but automatically click enter because it is the easiest thing to do.  This is a trade-off with efficiency.

  • No labels