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

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

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.

Individual UI Designs for Patron

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

Design for searching restuarants

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"

From our user interviews, I 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.  My focus area is on safety.

My 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

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/Patrick: (add more designs/sketches here, keeping the format as the items above)

Design Sketches:

1. User can enter and save  food allergies and preferences, with immediate visual feedback

        Show Sketch:

2. User can review  and save what meals are already chose
        Show Sketch

3. Sort the menu by different categories
         Show Sketch

One of my design (#1) extends to the extreme case for illiterate people.

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
4. Server Side: 

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.

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. 

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.

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'?