GR2 - Designs

Objective

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

Individual UI Elements

Damian

1. Server entry of the daily special
2. User search of restaurant specials in the area
3. Menu inspection with focus on Safety

Server entry of the 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

User search of restaurant specials in the area

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

|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

Wei

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.

|------------------------------------------------------------------------------------------------end-----------------------------------------------------------------------------------------------------------------------------------------------------|

Yewen

1. a
2. b
3. c

|-------------------------------------------------------------------------------------------------end----------------------------------------------------------------------------------------------------------------------------------------------------|

Patrick

1. a
2. b
3. c

|------------------------------------------------------------------------------------------------end-----------------------------------------------------------------------------------------------------------------------------------------------------|

Scenario

Sasha browses the restaurant's menu over on FoodAware. She filters the menu by her restrictions and preferences and she sees an item she wants but it conflicts with her diet.  She sees that she can make a substitution on the menu and makes a vegetarian substitution on that item. She then proceeds to the restaurant and orders the item through her server.

Group Designs

We present three designs:

1. Single Window Design
2. Dual Window Design
3. Shopping Cart Design

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.

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

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