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.
...
- 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.
...
- 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.
...
- 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.
...
- 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.
...
- 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. 
...
- 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
...
- 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.
...
- 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.
...
- 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:
- Patron Side: Single Window Design
- Patron Side: Dual Window Design
- 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.
...
- 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.
...
- 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.
...