It is a Sunday evening, and Anand is tired and hungry, after a long weekend of partying. Anand is a sophomore at MIT. He is burdened by his homework in 6.813, and needs to start PS2 soon. He lazily contemplates doing it, until he remembers that he can't think really straight unless he is full, so he decides to go to his favorite restaurant, Cinderella’s. He is really craving some Italian food today. When he arrives at the restaurant, he is seated by the host. The sign at Cindrella's says that the restaurant is newly enrolled in menu.io, and beta-testers can open up it up on their phone. Glad he signed up to be a beta-tester a month ago, Anand does not take the traditional menu from the containers available at the side of his table and opens up menu.io on his phone as he gets ready to decide what to order.

Design 1 was primarily meant to excel in simplicity. Taking design patterns that users were sure to have seen across varied platforms, Design 1 is the most learnable of the 3 designs. Entering text and filtering checkboxes are tasks that mobile and desktop users alike are familiar with. We also felt the grid approach was appropriate in this case because users have often seen it used on the mobile platform (either Android or iPhone), and it will make intuitive sense to use in the menu as to make it extremely learnable, and approachable in viewing the menu.

Design Selection: Search Bar

Scenario Part 1

Anand goes to menu.io and sees the search bar to find restaurants. He types in “Cinderella” because he does not feel like searching for the apostrophe on his mobile keyboard. Once he types in Cinderella, he is presented with a list of options. Because he is at Cindrella’s he picks it and not the other option of Cindrella Louveaunt, the French restaurant in Dorchester, MA. He is then presented with Cinderella’s main page with the menu attached to the bottom of page with several categories.

Learnability: The search bar is a learnable interface since it is a common part of the web. Most users are familiar with search options like Google to search terms that they want to.

Efficiency: This design is not particularly efficient because it requires the user to type the restaurant in. It does not automatically detect the restaurant, nor does it store selected particular restaurants. Every time a user arrives at a restaurant, he or she has to type the title of the restaurant in the search bar.

Safety: This design is safe in that errors are recoverable. However, it is not guaranteed that errors are few. If the user does not realize or know the title of restaurants (the exact spellings - usually), the user can be prone to errors. However, overall if the user is attentive, the system can be safe.

Design Selection: Checkbox approach

Scenario Part 2

Anand wants to try some new food at Cinderalla's.  Today, he's in the mood for pasta. He scrolls down to the menu, and sees the filter button. He clicks on the filter button and is presented with a standard checkbox filter. The checkbox filter has two different kinds of filters to be applied: ingredient-specific and item-specific. Because he wants be presented with vegetarian options (since he is vegetarian), he checks the vegetarian box. Next, he wants only pastas to appear. Currently, the item-specific box is checked All so all items appear. He unchecks All, and then checks Pasta-only, so only pasta’s appear. Then, he hits the back button, and returns to the menu.

 

Learnability: The filter is learnable because most people are familiar with the checkbox affordance. They know the checkbox represents a choice, and can use it to turn certain features on and off. Some users might find it hard at first to understand the item-specific approach. With some iterations, however, they will get it right.

Efficiency: This design is efficient in some ways because it is very easy to apply large, common filters such as vegetarian or vegan within 2 steps. This design is not particularly efficient because it requires the user to select the particular filter every time and perhaps not design custom filters. It also does not remember common filter selections.

Safety: This design is safe in that errors are recoverable. If the user applies the wrong filter, the user can return, and fix the filter. Errors are also few because the checkboxes are clearly specified. However, it can be hard to the user to check what filters he has applied, if he applies the wrong filter. It may be hard for the user to distinguish between filters such as vegetarian or vegan, if the user applies one or the other by mistake.

Design selection: Standard grid approach

Scenario Part 3

The menu is laid out in a grid. After filtering, the pastas are the only option left on the menu. Anand selects pastas, and is presented with a selection of vegetarian pastas. He selects mushroom raviolli, checks the description, spicy and salty factors and is content. He feels the $5.49 price is reasonable, and the ingredients seem to look good. He had a slight cold a week ago, so perhaps some ginger will do him some good in the pasta as well. He then calls the waiter over to order mushroom ravioli.

Learnability: This approach is extremely common for mobile apps and most people know the depth and usability associated with the grid item for viewing new item.

Efficiency: This design is efficient in that people are free to explore the depth of new options. They can go back and forth in the menu by navigating through the view tree. Their specifics can be realized easily according to their preferences. 

Safety: This design is safe in that errors are recoverable. If the user selects the wrong item, he or she can close the window. The users are also few since most of the time the user knows exactly what he or she is picking because it is specified in the picture and text.

The idea behind Design 2 was to use technology to drive a more efficient platform. This design takes advantage of both mobile technologies, and UI patterns that appear clean and quick, mimicking the style of Apple's interfaces. Specifically, we leverage technology in detecting location - to take a slight risk in safety, but allow for efficient detection of the restaurant. We also take a risk from the menu and filtering angle to use affordances such as tags and touch-based sliders (perhaps slightly new arrivals in the mobile and web 2.0 space), to create a more efficient and understandable interface. The leap might be a bit higher in terms of learnability, but it allows us to be creative with the design approach.

Design Selection: GPS

Scenario Part 1

As soon as Anand opens up menu.io, the app presents him with 3 different options: Cinderella’s, Toscanini’s, and Desi Dhaba. These options are found through the GPS feature of Anand’s phone. These are the closest restaurants that use menu.io, based on Anand’s current location. Anand sees that if he wanted to explore another restaurant's menu, he could press the "Choose another restaurant" button.  Anand selects Cinderella’s, and sits down to view the menu that the app has generated for him.

Learnability: GPS is very learnable. The app does most of the heavy lifting for the user, and the user only has to choose the restaurant of his/her choice when it shows up.

Efficiency: This design is efficient because it makes sure the user only has to take 1 action: choosing the restaurant. Nothing has to be typed up or searched, and GPS can be selected immediately. The only efficiency issue arises when the wanted restaurant is not shown in the list to the user, which will be discussed in the Safety section.

Safety: This design is not very safe, especially if there are GPS issues with the phone. This requires users to type in the restaurant that they are eating at, which causes an efficiency issue.

Design Selection: Icons on top with details in the center.

Scenario Part 2

The app presents Anand with a row of icons at the top of the screen. He can scroll back and forth between items and the center item is reflected in a larger detail view in the center of the screen. He is able to see a picture of the item along with price, details, and ingredients. Anand really likes that he is able to see up close what he wants to eat, because he is feeling hungry so he skips over all of the options which look like a small portion. Presented with all this information, Anand is able to make a much more educated choice about what he wants to eat. 

Learnability: This design is fairly learnable because of the scrolling elements of the icon bar. Most of the features of these menus will be made obvious to users, so there is no learning necessary here.

Efficiency: It is easy to move from dish to dish on the menu, but there is no natural sorting to make it easy to move to a dish of one’s choice quickly. This is where filters (Task 3) come in. 

Safety: There is not very much room for error here. If a user scrolls past an item of his/her choice, it is very easy for the user to scroll back to the desired item, making this design safe.

Design Section: Drag filters to menu

Scenario Part 3

Anand is a vegetarian, and is usually frustrated that he has to scroll through all of the pastas to find the vegetarian ones.  He decides to use the filters provided by menu.io. The filters are shown on the bottom of the screen, and he drags the vegetarian filter onto his menu view, and all of the non-vegetarian dishes disappear. He also knows he wants to eat pasta, so he drags the pasta filter onto his menu. If Anand ever wishes to remove one of the filters he has placed on his menu, he could click the corresponding filter on a new dialog that has opened on the top of the screen. He checks out the mushroom ravioli and sees that the description is ravishing. $5.49 is a good enough price for him, since he is on a tight budget. He decides that is his choice today, and calls the waiter over to order.

Learnability: The drag-to-filter design might pose a learnability issue for new users. It is not made obvious that filters are meant to be dragged to the menu, and users might consider interacting with them in other ways (clicking, for example) to add them to the menu. This can be remedied by having multiple methods of applying a filter with the same design.

Efficiency: This is a very efficient method of applying filters. It requires a simple click or drag, and the filter is applied immediately.

Safety: This design is fairly safe. If a wrong filter is applied, it is made obvious how to remove it, and removal of said filter is done almost instantaneously.

Design 3 is driven by exploring various metaphors for the menu interface. This design has the most potential for innovation, experimenting with interesting user models. This feature-driven design, however, has potential for losing out on learnability. We use the metaphor of grocery shopping and dining the most. The QR code scanning is somewhat like a grocery shopping metaphor, since most people scan an item to really recognize what it is. Similarly, users scan the restaurant code to select the restaurant. The Lazy Susan metaphor appears, as they view the menu, just like they see all the plates at a dining table - allowing the user the freedom to explore choices. Finally, users are able to pick what they want to compare easily, by dragging it to a basket - where they can make their final choice (this metaphor perhaps requires a higher leap), however, it also allows us to a take a more risky approach.

Design selection: QR code 

Scenario Part 1

When Anand opens up the app, he is greeted by the welcome screen to menu.io.  Confused as to where the QR code is, he calls a waiter over and asks. A waiter points him to the QR code at the center of his table.  Anand touches the “Scan QR Code” button and a QR reader appears.  He scans the QR code which immediately pulls up the main page for Cinderalla’s.  Anand touches the menu button to pull up the Cinderalla’s menu.


Learnability: The QR code scanner is a popular technology in many mobile applications, so many users would recognize it.  There would be a population of users who are not as tech-savvy and who might not know how to use a QR scanner.

Efficiency: The QR scanner would immediately pull up the restaurant’s menu so there would be fewer button presses for the user.  However, sometimes QR scanners take a while to scan the code, depending on the angle and proximity of the code.

Safety: Sometimes QR scanners cannot locate the code because the angle is bad or the code is too far away.  Assuming the restaurant places the codes in an appropriate location, the QR reader would be very safe because it would load the correct menu.

Design selection: Modified Lazy Susan/Scroll wheel

Scenario Part 2

The first page of the menu displays the different categories of food at Cinderalla’s: pasta, pizza, appetizers, drinks, salads, and more.  Sample pictures of these categories are displayed in a circular around the main stage. The main stage displays the highlighted picture at the very top.

Anand is in the mood for pasta, so he drags the circular icons around the stage until the pasta icon is displayed.  He touches the center stage (he could also touch the bottom label) to bring up the pasta sub-menu.  Anand uses the scroll wheel to scroll through the items until he reaches mushroom ravioli.  He thinks that sounds pretty good, so he drags the ravioli on the center stage to the basket in the upper right-hand corner.  Anand keeps looking through the pasta items, and also decides to drag the fettuccine alfredo to the basket to compare later.  He then clicks on the basket to compare his selections.


Learnability: The scroll wheel is not a common interface, but it is common enough that it would be recognizable. It also follows a modified-Lazy Susan metaphor which might help some users.  Users might not know that they are supposed to drag dishes into the basket; this is why we would include tooltips. However, the necessity of tooltips at all begs the question of whether this interface is learnable.

Efficiency: The scroll wheel is not always efficient to go through for each task. It presents an element of novelty; however, it can often be cumbersome when browsing for new dishes. Also, scrolling, dragging and then clicking can be a a time-consuming process.  The two step process is an organizational feature which prevents the user from being overwhelmed by all of the menu options at once.

Safety: The scroll wheel can be less safe if users go through the two-step process because of a lapse. However, the two-step process also remains a check that sometimes prevents errors because users can preview sub-categories before moving on.

Design selection: Comparison grid/table

Scenario Part 3

After clicking on the basket to compare his options, Anand is greeted by a screen with a large stage in the middle with three places to drop entrees.  His choices (mushroom ravioli and fettuccine alfredo) are sitting at the top of the stage.  He sees that if he decides he doesn’t want a dish he can always drag it into the trashcan in the upper right-hand corner to remove it from his basket.  He also sees that if he wants to keep searching the menu he can click the menu button in the upper left-hand corner.

Anand next drags his two dishes into the center stage.  He presses compare to pull up a table comparing the ingredients of his two selections.  He immediately sees that the fettuccine alfredo has chicken and that the mushroom ravioli does not.  Since Anand is a vegetarian, he immediately rules out the fettuccine alfredo, and waits for the waiter to take his order.


Learnability: The shopping cart metaphor is sometimes good for users to learn that they are in the final step of the decision process. It can also be hard to understand that the basket is for filtering initially, rather than just viewing.  Users would probably not know that they are meant to click on the shopping cart to reach this filtering stage.  Again, tooltips could solve this problem but tooltips are an inconvenient way to teach a user how to use the interface.

Efficiency: The filtering mechanism is not particularly efficient in that it can’t allow you to apply large filters, and makes only small comparisons. However, some users might like comparing individual items at a time if they are between particular choices - which makes it easier for people who are indecisive between 2-3 items.

Safety: This mechanism is safe in that it requires multiple steps to get to this stage, and people can still choose what items they want to compare. A comparison is usually going to be determined, and not random. If the wrong dish is there, it can be sent to the trash can easily. Users can add as many dishes they want, and also compare as many decisions they want, without having to worry about the number of items they might have dragged into the basket.

  • No labels

1 Comment

  1. Unknown User (juhokim@mit.edu)

    "Overall: Thanks for checking in with me for feedback. The ideas are well-communicated. Great work!
    "