GR6 - FoodAware User Testing

Design -

Our application has truly evolved from the start of this course.  Our central problem we wished to solve and the task scenario have remained constant throughout the project. To refresh, the central problem was that people with dietary restrictions have difficulty finding foods.  Our task scenario revolves around a vegetarian that finds it safe to consume chicken perusing a menu and selecting items that he/she wants to eat. 

Design follows from growth from our dual pane concept from GR2 as our base design. The central ideas of the dual pane concept from GR2 to GR3 paper prototype were:

• Allow the user to see his own dietary restrictions and preferences to ingredients alongside the menu items of a preloaded menu. 
• Dynamic feedback to show the user how adding restrictions and preferences dynamically sorts and filters menu displayed to user.

From GR3 feedback we decided to incorporate into our GR4 design:

• A restaurant chooser menu to allow the user to select from menus from different restaurants
• An introductory home page describing the task descriptions for each page of our application to aid in learnability
• A summary page to print menu order selections and provide an end goal to the user

From GR4 and HW2 feedback we decided to incorporate some new additions to our design including:

• A search bar to search for ingredients from the list of all the ingredients from other restaurants to aid in efficiency
• A "shopping cart" on the menu page to allow the user to know what items are selected from the menu
• A total price display to allow the user to track the approximate bill if ordering from the restaurant

Feedback from GR5 was mostly cosmetic touches to our webpage to include:

• A consistent proceed button location between the Menu page and Restrictions and Preferences page
• Gridding issues on the menu page between the two columns of the menu column and the restrictions/preferences/cart column
• Providing for more restaurant metadata on our restaurant search page

Shown below is a photo of our introductory page with our program flow-path instructions:

Shown below is a photo of our ingredient preference and restriction page:

Shown below is a photo of our restaurant search page:

Shown below is a photo of our menu page:

Shown below is a photo of our summary page:

Implementation -

We relied on functionality from Parse to implement our design in order to share data between webpages.  Page logic and interaction is accomplished client side and data such as restrictions, menu selections, and restaurant choice are loaded by querying a Parse account on each page load.

Evaluation -

We tested our implementation on three people.  We allowed each person to choose items pertaining to their dietary restriction and tasked each user to enter their restrictions, browse restaurants and menus, and select items they would like to eat.  We found users who indicated that they have food restrictions. Our users include a vegan, a chicken vegetarian, and a person who is on the paleolithic diet. 

Note:

• chicken vegetarian - user whose dietary restriction is that he cannot eat meat ingredients with the exception of considering chicken as an acceptable meat to consume.
• user 3 is on the paleolythic diet which means that he eats items that are what a "caveman" would have consumed.  He cannot eat products that have been through processing and he cannot grains or dairy products.  He was able to complete the task scenario to completion and print his menu summary for a Kale Salad order.

 Briefing:

• This is a website that helps you to find online food that are safe (met your food restrictions) for you to eat.
•  It is not an online ordering system. 

 Task:

• Enter your food restrictions
• Browse restaurant menus 
• Find some dishes that are safe for you to eat

Usability Issues Observed: 

Users find it not easy to learn that the buttons on diet profile page are accordions and can be expanded.  (Learnability - Major)
Users kept clicking the "minus" icon, and learned what that did. It took quite long for them to learn that the button can be clicked to expand the accordian.

Potential solutions:

1. Change the use of button as accordions
2. Use color/visuals to enhance the indication of the accordions

Users are surprised that when they change restaurant, the previous selected dishes are cleared. (Learnability - Major)

Potential Solutions:

1. Show the menu page within the restaurant page when "view menu" button is clicked, so there is a stronger indication the system is restaurant specific

Users are unsure if on the restriction and preference page he was searching for his preference or restrictions (Learnability - Minor)
Contrary to our assumption that an search box would help the users to find the ingredients that they want more quickly, users often are not sure whether they should use it. 

Potential Solution: 

1. One time viewable alert shown per user to show what functionality is provided for by the search bar.

Users wanted all the accordions to stay open "to see what I've clicked on."(Efficiency, Minor)
User wanted to keep both the grains and dairy categories to both remain open so that he could scan them both to know all options were selected. 

Potential Solution: 

1. Correct our accordion behavior for our categories to keep items open once they have been activated once.

Users still unsure how to "go forward" (Efficiency, Minor)

One user wondered around on the pref/restriction page for a good while before clicking on "select restaurants".

Potential solutions:

1. Shape the "progression" button as arrows to strongly indicate progress.
2. Make the button animate slightly when the system thinks sufficient pref/restriction is being added to notify the user he can progress.

Users are disappointed when not a lot of menu items show up on menu page due to over-restriction (Efficiency, Minor)

One user restricted a lot of items, and was surprised some of the restaurants has no menu left for him.

Potential solutions:

1. Able to rank restaurants by number of safe dishes
2. Display on the menu page the hidden items due to unsafe ingredients

Users unsure of what 'plus' and 'minus' icons mean (Learnability, Minor)

One user believed that the green plus would add an item to their restrictions and was confused when it instead added it to the restrictions.  This is even after we had attached tooltip explanations to the buttons.

Potential solutions:

1. Colorize preference and restriction 'wells' red/green accordingly.
2. Explicitly label buttons 'prefer'/'restrict'.

Users liked how polished the UI is (good)

One user said "this is nice, so professional!"

Users chose to select preference ingredients first before filling out restrictions

This reinforces our decision to include preferences into our design because people's natural tendencies are to pick items that they want before what they cannot have.

Reflection -

Our design explanation lists our thought process from start to finish with our implementation.  The guiding factor for our designs was primarily feedback from GR1-GR5.  With extra time we would have most likely continued using our design and refining it, rather than start a fresh, all-new implementation.  With that said, we have discussed further areas of improvement that we would have liked to incorporate into our design.

• Incorporate a server profile and restaurant side page so that restaurants would be able to upload their menus easily to our website information format.
• Make a tutorial integrated into user accounts that is one time visible to show the different ways our application could be used.
• Further extend the system of ordering to allow users to purchase from restaurants online or by taking the user to the actual restaurant website to order selected items.
• Our ingredient grouping categories are long; we would like to include ingredient groups into our search bar functionality.