GPS detection
Before our paper prototype, we had three ideas for restaurant selection: GPS detection, QR code reader, or using a search bar. We decided to go with the GPS detector for several reasons. First of all, we felt it would be the most efficient for users. With a QR code reader the user has to exactly line up their camera with the code, and with a search bar the user has to manually enter the name of their restaurant. But since we use GPS, the user simply has to load our page on their browser and a list of restaurants is immediately pulled up, with the closest one listed at the top. The advantage to the search bar, though, was that you could search a restaurant’s menu from home. But we ultimately decided that the purpose of our application was not to serve as an online menu, removed from the restaurant, but rather to replace the paper menu in the restaurant. So, the user would only be using the app when they are actually at the restaurant, so GPS fit perfectly with our goals.
List of nearby restaurants
The reason we give multiple restaurant options rather than just one is in case multiple restaurants are close together and the GPS is glitchy--we didn’t want the app to accidentally load the wrong menu and confuse the user. | 
|
Checkbox filters
For our final iteration, we opted for the simple checkbox filters. Checkboxes are a familiar interface used for selecting a few things out of a larger list (i.e. filtering). This filtering technique is much more intuitive than our design for the heuristic evaluation, which consisted of a scrollbar at the bottom of the page where you would highlight the filters you wished to select. We had originally taken this risk because we felt it would be more interesting and innovative, but it ended up being difficult to implement and so it didn’t look very nice. Users didn’t realize they were supposed to click on the names of the filters (such as “vegetarian”), while when there are checkboxes users know exactly what to do.
Location of checkbox filters
We moved the filters from inside the gallery to outside the gallery. We believe that a user visiting a restaurant isn’t going to choose “vegetarian” for one dish and not for all of them. Before a user even decides whether they want a sandwich or a pizza, they decide that they want vegetarian. So, we moved the filters to the outside of the gallery, where this mental decision actually takes place. We justified this decision by knowing that the app is for the individual user, not a group, and the average individual user will be consistent in their dietary restrictions for all types of entrees.
Checkbox filters as an alert
We made the checkbox filters an alert message. Because we are using mobile, we quickly realized that screen space economizing is critical. So, we have a button “Filters” in the header which doesn’t take up any extra room, and when clicked it opens up the filter menu as a pop-up box. We decided that it wouldn’t matter that the filters pop-up would cover up the other menu items, because the filtering task and the entree selection task are independent. In other words, the user doesn’t need to know that a given restaurant has “Sandwiches”, “Pizza”, and “Pasta” to know that he wants “Nut-free”. We also discussed putting the checkboxes on a separate page entirely, which would be located between the restaurant selection page and the category selection page. But because mobile web pages are slow to load to begin with, we didn’t want to have the user to have to navigate through one extra page. An alert box would be much faster.
Apply button
We added an apply button to the bottom of our filters alert to make it explicit to the user how to apply filters. We also added an “x” at the top for safety reasons--a user who accidentally clicked something could just close the filters menu without having to undo all of their changes manually. |  |
List of names
We simply listed the names of the categories (“Sandwiches”, “Desserts”, etc.) in our final iteration. We felt this was much cleaner than any other option. In our iteration for the heuristic evaluation, we included example pictures of a sandwich or dessert. This was a poor use of screen space. The user was unable to see all of the categories at the same time because the pictures were so large, so he would have to scroll down. Also, the combination of pictures and category names in this original iteration was too hectic--it was difficult to visually group pictures with their corresponding name. We knew that we could add more white space between category names, but this would just take up more screen space. We decided to nix it and go with the simplest option. |  |
Swipe gallery
We opted for a menu-viewing tool which would have the look and feel of a gallery. We wanted large pictures so the user wouldn’t have to squint, so we quickly threw away the idea of smaller icons. Swiping would allow the user to see all of the pictures full screen without having to reload a new page every time. This would allow the user to quickly scan the whole menu and stop when he saw something that interested him.
Item details at the bottom page
We provided entree details (name, price, and description) at the bottom of the screen so the user wouldn’t have to search for more information about the item. In one of our paper prototypes, we had a full screen picture, and would only open an alert-box containing the item details when the user clicked on the picture. We realized that users wouldn’t realize how to access these details, or even that we provided them at all. We also realized that we could it wasn’t necessary to make the picture that large. So we combined the two tools and put the item details right beneath the picture.
Navigation
We used a navigation bar at the top with dots signifying how many entree items were in a given category, and which item the user was currently viewing. This gave the user a better sense of how many options they had for a given category. We originally had “+” and “-” buttons which the user could click to go to the next page, but we removed these. They didn’t add anything to the user’s experience, and served the same functionality as swiping (but ended up being much slower), so they were unnecessary.
Icons in header
We added icons in the header of the gallery pages to allow the user to move to different parts of the application without needing to use the browser buttons. These icons are all familiar, and were added to increase the user’s efficiency. |  |
Reasons for adding
We added this functionality for our final iteration. A shopping cart would allow a user to select a few items from a variety of different categories, look at them all at once, and narrow down his options to a final order. We had discussed having a shopping cart in our very first sketches, but had originally left it out. We had felt that it was a separate task from filtering and we wanted to focus on that because we had believed that a user’s ability to filter for “vegetarian” was most important. After repeated requests for a shopping cart feature, in both the paper prototype and the heuristic evaluation, we finally realized that a cart would be an equally important filtering tool. Our feature allows users to add to the shopping cart by pressing the “+” in the upper right-hand corner of the picture in the gallery. They can remove items from the shopping cart by pressing the “-” in the upper right-hand corner. Users are familiar with this method of adding and removing items. This feature allows for side-by-side comparisons, which makes the menu experience much more efficient. Even paper menus do not offer this type of direct side-by-side comparison. At a restaurant, users typically need to keep one finger on one choice and another finger on another choice when deciding what to order. The shopping cart effectually memorizes the user’s choices for him.
Feedback upon clicking “X” or “+”
When you add an item to the cart, the gallery automatically moves to the next page. We deliberated on this action for some time. We wanted to give the user feedback that they had successfully pressed the “+” icon. First, we used an alert, but we believed that having an alert pop up every time you added to the cart would be inefficient. We opted for moving to the next page because we felt this would both alert the user that they had successfully added to the cart, and save them the extra stroke of swiping to the next item. We realized that this is not typical feedback and so we were curious how users would react. When removing an item from inside the cart, the application moves to the previous item and updates the number of dots in the navigation. This is a more familiar response.
Extensibility
The shopping cart is an optional feature. It enhances the user experience by allowing him to compare multiple selections side-by-side, but in no way limits any other part of the experience or obligates the customer to use it. This was a critical design decision because we wanted to keep the app simple and didn’t want to confuse any users that might not be as tech-savvy, or otherwise might not want to use the cart. |  |