FoodAware - GR2 - Designs

GR2 - Designs

Objective

Help people with dietary restrictions safely explore the food options offered by restaurants.

User Classes

There are two user classes, the server and the patron.

Originally we intend to focus entirely on the patron side, but without the server integration, one cannot be certain with the food ingredients that may present hazards. Therefore, it is also crucial for the servers to be able to adopt our system.

Scenario

David, the restaurant owner, want to add a new daily special item to his menu. He visits FoodAware and enters the food item and its ingredients.

Sasha, before going to the restaurant, browses the restaurant's menu over on FoodAware. She filters the menu by her restrictions and preferences. She then proceeds to the restaurant and orders.

Primary User Goals

Server

The server would like to an efficient way of entering menu items and their ingredients, with the ability to add new food items on the fly to accommodate for the changing menus offered by the restaurant. 

Specifically, our group will focus on the entering new item aspect, as it is a frequent task that hinders the digitization of a restaurant's menu. We will not focus on the actual registration of the restaurant with FoodAware.

Patron

The patron would like to safely explore her options prior to visiting the restaurant, and avoid the lengthy discussion of allergies with the server, as some restrictions are hard to explain.

Specifically, our group will focus on the browsing experience of the patron and provide her with the needed information. We will not attempt to create an online-ordering interface for her, but rather, presents her a well organized digital menu of the restaurant.

Individual UI Designs for Server

These designs will focus on the efficiency of the server, allowing them update and create menu items with ingredients. They will also address safety issues, making sure the ingredients are labeled correctly.

Design for adding a daily special (Damian)

This UI element allows for the server/menu owner to upload a daily special to the menu. Clickable photo area allows the server to search their personal photo drive to upload a picture taken in the restaurant.  Combobox of known ingredients is used to populate an ingredients listbox of known ingredient types, and a separate combobox is used to annotate substitutions.  Text entry input is included for the food name and food description.

Pros:

• The combobox with an add and remove button allows for a safe design.  No opportunity to misspell a word that would be used in a search.
• Food item takes majority of display to allow the server to know that he selected the correct word.

Cons:

• As the size of the ingredient list grows, the efficiency of the combobox input drops.
• Menus and forms approach used for data entry might affect the learnability of the interface

Consistent view design for adding menu items (Evan)

In this design, we try to mimic the view of the patron on the server side. This way, the server knows exactly how the menu items and ingredients will be presented to the user. A new item is created with a template, with its contents editable, and layout exactly the same as it would appear for the patron. Note that this is only a concept at this point, because we have not settled on a particular patron's design, and would have to mimic differently depending on that.

Pros:

• High feedback and consistency between the server and the patron. The server can best present the menu item/ingredients.

Cons:

• The server will perform more actions than just displaying the menu item, the metaphor won't completely follow.

Checkbox-based ingredient list (Patrick)

The server can type in the title and description of each individual item; ingredients are specified using a checkbox, as well as a 'custom ingredient' field that adds an ingredient to the database. A picture can also be provided, and is displayed on screen even before the item has been submitted to the database. The system recognizes words from the description and automatically checks them off in the ingredient list while highlighting them in blue.

Pros:

• We gain some safety by presenting all ingredients at once, as long as the list is not too long. That way, users are invited to look over the ingredient list, as opposed to trying various names for an ingredient ('milk' vs 'dairy' vs 'lactose') to see which one is in the database.
• The auto-highlight system increases efficiency, since the server is likely to include many ingredients such as 'chicken' in the description.
• It also fails safe, since it is not dangerous to add an ingredient not actually present in the dish.

Cons:

• Adding a new ingredient does nothing to make sure that all other meals are appropriately tagged with that ingredient, decreasing safety. The user must remember to manually go through all items and check off the ones that have that ingredient.
• The ingredient auto-add system can add spurious ingredients, and implementing a system that will not re-add them every time the description is edited would be difficult.

Individual UI Designs for Patron

These designs will address the safety concerns of the patron, and make the exploration of safe items accessible.

Wordless design (Patrick)

This design is intended for illiterate users. Since indicating an item without knowing its name might be problematic, and expecting patrons to memorize names at home and recite them at the restaurant might be difficult, this design is intended to be used at the restaurant along with a server who will be able to identify the items.

(note that text is for illustrative purposes only)

Pros:

• Simple and learnable; pressing ingredients 'disallows' them, causing forbidden items to disappear, and clicking them again causes them to reappear
  Cons:
• Item_ _pictures can be ambiguous: is a picture of a cow representative of beef or dairy (here, dairy is represented with a bottle of milk)? How do you indicate gluten (in this sketch, we use wheat)?
• Non-searchable; efficiency is sacrificed in the name of compatibility with illiterate users. In order to find an item, users need to scroll through the entire list.

Text-heavy design (Patrick)

Here we have a list of ingredients on the left, with accompanying text in ambiguous cases. Clicked items are toggled between allowed and forbidden, and a tab up top lets the user switch between what kind of item they are looking at. Each individual item has a name, a description, and an ingredients list. The safe ingredients list is automatically saved in a cookie and restored on reload.

Pros:

• The green checkmark and red X are fairly universal symbols for 'OK' and 'bad', making it clear whether each ingredient is allowed or not, enhancing learnability and safety. Text descriptions allow users to ensure that pictures mean what they think they mean.
• Cookie-saved preferences enhance efficiency, since dietary restrictions are unlikely to change over time.
  Cons:
• Somewhat unsafe; by default all ingredients are allowed, meaning the user might forget to exclude one of their allergies/restrictions.

Dual Screen Design (Evan)

Keep a duality of views of ingredients and food items. We notice that we can also filter the ingredients by selecting the food item and listing its relevant ingredients on the side. By playing with both sides of the panel, the user can iteratively refine the search.

Pros:

• Iteratively refines the item and ingredients by toggling between the food items and ingredients
• The food items promote exploration, the ingredient items ensures safety
  Cons:
• The live updates of the food/ingredient panels might be confusing to the user
• The user might not be aware of the focus of the panel (food item ideally should have more focus)

Design for searching restuarants (Damian)

Upon login to our application, the user is presented with a list of participating restaurants with specials in the area.  Only daily specials are shown for each participating restaurant.  A dual list box is populated in the bottom right that either shows the diet restriction itself, for example the "South Beach Diet" or the list of ingredients in the special

Pros:

• Efficient design to both advertise and explore food options in the area.
• Focus is to showcase the food item with as much display area as possible to show the menu item

Cons:

• Limited ability to provided to peruse an individual restaurant menu in lieu of displaying "specials"

Menu inspection with focus on "Safety" (Damian)

From our user interviews, we assumed the two areas of focus of the application should be towards safety as the results of an incorrect menu selection could be catastrophic and accessibility for all users.  

This UI element for menu inspection provides a text input with autocomplete to prevent spelling mistakes for both ingredients or for special known diets.  These text input fields are nullable as well to prevent filtering unwanted search queries.  A clear button is provided to clear entries that have been mistakenly entered.  Finally, a dynamic list of available menu items is shown on the right.  This prevents the user from even considering an unsafe food item choice.  Ingredients are all shown in case the filter does not filter to a specific need or ingredient has synonym.

Pros:

• Safety in selection of filter categories
• Safety in selection of safe food items

Cons:

• Menu item is not on a large display to entice user to patronize restaurant.
• Menus and forms approach might lead to learnability issues.
• No ability is provided to search for a variety of different restaurants

Random Suggestion Design (Evan)

The key focus of this design is efficiency. If a user has few/no restrictions, a random item is likely sufficient. This design also promotes exploration, because it is an easier task to decide if one likes an item than to choose from a set of items. In this design, a random menu item is generated, along with its ingredients. If the item is good, the user can settle with this item. However, if the user cannot choose this item, he can tell why such item is bad (contain restricted items from his diet, does not like chicken, etc). Based on the additional information, the interface suggests a new random item that meets these requirements. Again, the user can add more requirements, to refine the suggestions by the system.

Pros:

• Easier for patron to decide, not overwhelmed with information
• The patron can literately refine his restrictions, depending on the item suggested

Cons:

• Can become a problem if patron is actively searching for a menu item
• If multiple suggestions of the item is rejected, the patron will become impatient

Wei:

Design Sketches:

Multi-Language Design

Server side can update menu, add new meal and review before submission. For patron side, patrons can save meals and review chosen meals.

To deal with language barriers, we have pictures and also multi-language display options.

Stored Allergies Design

This design focus on the food safety side. People can choose allergies, and also to enter preferences, before they view the filtered personalized menu for them.

 It also use images and multi-language display option to deal with language barrier issue.

Children Friendly Design

Trying to make the design as simple as possible while also keeping the food safety issue in mind.

Use big images and immediate visual feedback to make it affordable to children.

Group Designs

After merging our individual designs, we present these designs as a group:

1. Patron Side: Single Window Design
2. Patron Side: Dual Window Design
3. Patron Side: Shopping Cart Design

Patron Side: Single Window Design

The focus of this idea is on the food; details appear in an overlay when the food items are clicked on, and dietary restrictions are moved off to the side. 

Allows a restaurant to upload daily specials to the menu listings.

Pros:

• Devotes large amounts of space to the primary 'target' of the UI, the food itself. 
• The single window design also has an affordance to upload food items to the server/database using a GUI window devoted to the task. 
• This menu presentation also highlights food specials with a border and food that are suitable with a substitution with a border. 
• Menu items that are sorted to show specials first, regular menu items second, and restricted items with substitutions last. 
• Pictorial representations of restrictions and menu items are shown in a format discernible to all languages.

Cons:

• Might be difficult to select restrictions, both due to limited screen estate and difficulty of finding them.
• No ability is maintained to keep a user preference history.
• Interface is scaled to one restaurant and does not show browsing multiple restaurant menus at once. 

Patron Side: Dual Display

The idea of the dual display is to keep both the information of food items and ingredients on the same screen.

Manipulation of items on the food panel alters what is being displayed on the ingredients panel.  The same action on the ingredients panel produces a similar effect on the food panel side.

The panels are sorted by importance, with more preferred items higher on the food side, with dangerous, and common allergens higher on the ingredient side. These importance are subject to change based on user actions, leading to a re-arrangement's of the lists.

For instance, selecting a menu item brings up the ingredients of that menu item in the ingredients panel, giving the user feedback on what goes into the dish.

Conversely, selecting a preference or restricting the ingredients filters and re-orders the menu items, reflecting the user's choices. 

Addressing the prioritizing issue, the ingredient side of the panel should be shrinked to a smaller scale, giving food item more prominence.

Pros:

• High level of feedback between the interplay of food versus ingredients.
• Learnability is very high because menu and food items are shown simply.
• High level of language independence with large picture icons

Cons:

• Screen space might become cluttered;
• Having two independently-scrolling panes might be confusing

Patron Side: Shopping Cart

The flow here is designed to be similar to a shopping cart, with entering of dietary restrictions and preferences kept separate from food selection. We also provide here a 'summary' view at the end so that users can view all the food that they have chosen and see the total price. We also use text entry as opposed to pictorial selection to choose allergens/preferences.

Storyboard - 

First, server use FoodAware to update menu. They can upload a picture of the meal, enter the name and price of the meal. They can also choose from a list of ingredients from the ingredient box (forgot to draw it there). Each ingredient will have a check box in front of it.  If some ingredient is not there, they can enter it by text. They do the same for the substitution. Choose it from a list of ingredients, and if it is not in the list, they can enter it manually. 

Then we move on the patrons side, who will be browsing either at home or at the restaurant. Patrons can choose to enter food allergies/preferences first by text. They may also choose to skip the section. As they enter the food allergies/preferences, they will be able to see the direct visual feedback on the right. We will implement auto-complete to help the user to enter the choices. The idea is to keep it simple, so that users don't have to search from a long list of possible food allergies. We assume that most people are not allergic to too many food items. 

Then,patrons can proceed to choose from the filtered menu. Each item would have a check box in front for the user to save it. They can also review their saved items by clicking the Like_List button, which will bring up a window for them to do a final modification. They can also sort food by different categories such as price/preference/calories/chef_recommendation and so on. They may also search for a specific item they really like. For example, maybe Sarah really wants to check all the item that has fish in it.  If the view button is clicked, patrons will see more details, including a full list of ingredients. Substitution availability would also be visible. They will be highlighted for the patrons.

After the patron is satisfied with her/his choice, she/he can save the list and order food. 

Pros:

• Text entry obviates the need to hunt through a list of pictures to find their allergens/preferences
• Save user profile allows for tracking of preferences over time.
• Many opportunities allowed to fix an incorrect entry for a safer design.  For example, the user can remove items from the queue on the "checkout" screen.

Cons:

• 'Linearity' might be excessive and cause an efficiency issue for long time users.
• Text entry can be difficult and auto-complete is required for implementation. For example what if the user doesn't know spells oregano 'aregano'?