You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Design Selection: Search Bar

Anand arrives at Cinderella’s. 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

Anand wants to pick pastas that are vegetarian. 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, 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 return 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

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 ingredients, description, spicy and salty factors and is content. He then calls the waiter over to order.

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.

Design Selection: GPS

Anand arrives at Cinderella’s and opens up menu.io in order to see the menu. 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. He 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.

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

Anand wants to filter the menu to only show vegetarian dishes, because he is vegetarian. 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.

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.

  • No labels