Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

This 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.

...

  • 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, if you have any, keeping the format as the items above)

Design Sketches:

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

...

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

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.

...

  • 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 Interface is scaled to one restaurant and does not show browsing multiple restaurant menus at once. Image Removed 

Patron Side: Dual Display

...

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

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

...

  • 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. Image Added

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.

...

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

  Image Removed