...
Initially, the display shows four restaurants in their nearby surroundings with limited information about each restaurant - a name, general rating, distance, and a few menu options. From these choices, the one that seems least appealing can be swiped off, producing another query result. If at any point the user swipes two options off the screen at the same time, the resulting comparison will only look at the remaining two options. Another method is to slide two different restaurants into one other, announcing that the user wants to compare those particular two restaurants.
This step provides a more detailed comparison between the two remaining choices. Between these two options, the user can again use the same method before, and swipe off the eliminated options, thereby leaving the choice for dinner.
Once a choice has been made, the application displays a step by step directional map to guide the user to their designation. This page will be displayed with other information about the restaurant, such as phone number, the entire menu, as well as photos of the establishment.
Other Information
This application will contain simple to use back buttons to guard against mistakes and changed decisions. Another feature that will be involved a more traditional sort to limit the type of restaurants that are displayed such as type, price, and rating. This feature will be a part of the middle, MenuMe button.
Analysis
For example, out of the four displayed options, Subway seems the be the least attractive, I will just swipe it off the screen and see what else the application suggests. At any point in this process, the user may also click on the restaurant of their choice to see a more detailed report on the establishment.
After looking through a few different options, the user is please with his choice of four restaurants, and now has decided on two that he want to examine further. If at any point the user swipes two options off the screen at the same time, the resulting comparison will only look at the remaining two options. Another method is to slide two different restaurants into one other, announcing that the user wants to compare those particular two restaurants.
This step provides a more detailed comparison between the two remaining choices. Between these two options, the user can again use the same method before, and swipe off the eliminated options, thereby leaving the choice for dinner. Additional choices can also be to click on the selected choice, at which point that will application will interpret it as the user's choice.
Once a choice has been made, the application displays a step by step directional map to guide the user to their designation. This page will be displayed with other information about the restaurant, such as phone number, the entire menu, as well as photos of the establishment.
Other Information
This application will contain simple to use back buttons to guard against mistakes and changed decisions. Another feature that will be involved a more traditional sort to limit the type of restaurants that are displayed such as type, price, and rating. This feature will be a part of the middle, MenuMe button.
Analysis
Learnability: Elimination is a common technique for making choices. Given a certain set of decisions, a person initial instinct is to quickly get rid of choices that are not appealing. Learnability for Learnability: Elimination is a common technique for making choices. Given a certain set of decisions, a person initial instinct is to quickly get rid of choices that are not appealing. Learnability for this particular app follows the same idea. As a user eliminates choices for a restaurant, he can This design is based on a compass. When a user chooses to open our application, he can basically point the device in a direction and see what restaurants are in that direction. The motivation for this is that sometimes a user may have some notion of which way he is trying to go. In this application he can easily see what is in that direction. This application will eliminate the obnoxious "pins" that tend to show up in current restaurant map searches. Additionally, it doesn't require the user to read any sort of map to see what direction his desired restaurant is in. He can instead find restaurants in a more intuitive manner since the device is a part of the user's world, instead of simply showing a top view of the world. Finally, when we ultimately do show the user a map so that he can get there exactly, he is already oriented as to which direction he should begin walking. This will make the process of reading the map eventually much easier.just
Storyboard
IMAGE 1
1) Image 1 shows the first page a user sees when opening the application. It looks like a compass, showing that Wendy's and McDonald's are straight ahead, more or less. The user can also see the cardinal direction for orientation. If the user turns his device one direction or another, the restaurants being showed will rotate and new restaurants will appear. The restaurants always represent a few that would be found if the user headed in that direction. In our example, suppose the user is interested in sorting the restaurants that are shown in a different way. He touches the "sort" button.
IMAGE 2
2) Image 2 shows a simple menu of the different ways the application can choose to show restaurants. Since there are presumably many restaurants in a given direction, the user can choose which types he wants to see. Our user is very interested in getting cheap food, so he selects "cost". The menu disappears and the compass reappears as in Image 1. The user now finds two restaurants that interest him. He adds them to a list of restaurants he wants to compare by touching them. Once he has found two that he likes, he selects "compare".
IMAGE 3
3) Image 3 shows the two restaurants our user is interested in. If he changes his mind and wants to continue searching, he can simply press "back". Otherwise, he selects the restaurant he wants. In our case, the user wants to go to "Hsin Hsin".
IMAGE 4
4) Image 4 shows a map that the user can follow to his destination. Our user does so and enjoys his experience.
Further Information
The map in Image 4 is something that we are wrestling with a lot. It would be more consistent and very cool if after the user selected his restaurant, he was directed by a compass to the destination. In other words, he would be directed by an interface more like that shown in Image 1. We chose not to use that idea in this storyboard because we are concerned about the accuracy of the directions people would get, as well as the accuracy of the GPS knowing exactly where the user is. If we choose to implement this design, we will seriously consider implementing our design in this way.
Additionally, there is the concern of how we show multiple restaurants in the same direction. Since our expected user is not super picky about the place he eats, but instead is just trying to find some food, showing only a few restaurants in a given direction is acceptable. We are working out the best way to add some sort of scroll bar, though, to cycle through the various restaurants at various distances in a given direction. It is a minor detail at this point, but we are thinking about it.
Analysis:
Learnability: This should be very learnable, because the idea of pointing the device in the direction you want to find a restaurant seems very intuitive. A user should be able to pick up the app, and even if he doesn't know what it does, just by turning it and seeing various restaurant logos scrolling on the screen, a new user can learn what the app is doing. The subsequent screens are very self-explanatory and there are few controls. That means that a user will not have to learn very much functionality to fully use this application.
Efficiency: The main concern here is that a user will have to physically move the device to see all the restaurant options. This is a very slow process. This may be an acceptable tradeoff, though, if the user feels that the search is more intuitive and interactive. Once the user has chosen his restaurants, the rest of the process is very quick, as there are very few steps to take, and all can be completed with a simple touch. Another concern here is that the process of scrolling through the restaurants in a given direction may be time consuming and tedious for the user. We are designing this for a user who doesn't care too much, though, so we shouldn't find users who want to scroll through tons of restaurant options. In any case, efficiency is where we see a primary concern, because the user does have to physically move the device to select a restaurant.
Safety: We will have back buttons to easily return to previous screens. This will mitigate a lot of safety concerns. The largest safety concern is that after the user has chosen his restaurants, if he makes a mistake and wants to re select his restaurants, the nature of the compass interface is tricky. He will then have to point the device in the proper directions once again to find the restaurants he wants. This could be very annoying for many users as they are effectively forced to start over. This should be a solvable issue, though. We will continue developing solutions to this issue that mitigate the safety concerns while maintaining consistency with the design of the app.
"wipe" it off the screen. This motion is used throughout the entirety of the experience. As a result, the interaction with our interface is an intuitive way for users to eliminate choices consistant with the way they perform a similar task otherwise.
Efficiency: Presenting essential information at each particular stage of the elimination process is the key to the efficiency of this design. At our initial level of comparison, our application hopes to provide enough information for a user to eliminate a few of the choices. Later on, as choices are more limited, more information is provided for the user. In the entire searching process, the user rarely needs to navigate between screens to make a decision.
Safety: A center MenuMe button helps the user navigate through previously swiped options, thereby allowing the user to backtrack through previous choices. Furthermore, additional back buttons will also allow the user to retrace their steps as they look into the menu and location.
Design 2
...
can "wipe" it off the screen. This motion is used throughout the entirety of the experience. As a result, the interaction with our interface is an intuitive way for users to eliminate choices consistant with the way they perform a similar task otherwise.
Efficiency: Presenting essential information at each particular stage of the elimination process is the key to the efficiency of this design. At our initial level of comparison, our application hopes to provide enough information for a user to eliminate a few of the choices. Later on, as choices are more limited, more information is provided for the user. In the entire searching process, the user rarely needs to navigate between screens to make a decision.
Safety: A center MenuMe button helps the user navigate through previously swiped options, thereby allowing the user to backtrack through previous choices. Furthermore, additional back buttons will also allow the user to retrace their steps as they look into the menu and location.
Design 2:
This design is based on a compass. When a user chooses to open our application, he can basically point the device in a direction and see what restaurants are in that direction. The motivation for this is that sometimes a user may have some notion of which way he is trying to go. In this application he can easily see what is in that direction. This application will eliminate the obnoxious "pins" that tend to show up in current restaurant map searches. Additionally, it doesn't require the user to read any sort of map to see what direction his desired restaurant is in. He can instead find restaurants in a more intuitive manner since the device is a part of the user's world, instead of simply showing a top view of the world. Finally, when we ultimately do show the user a map so that he can get there exactly, he is already oriented as to which direction he should begin walking. This will make the process of reading the map eventually much easier.just
Storyboard
1) Image 1 shows the first page a user sees when opening the application. It looks like a compass, showing that Wendy's and McDonald's are straight ahead, more or less. The user can also see the cardinal direction for orientation. If the user turns his device one direction or another, the restaurants being showed will rotate and new restaurants will appear. The restaurants always represent a few that would be found if the user headed in that direction. In our example, suppose the user is interested in sorting the restaurants that are shown in a different way. He touches the "sort" button.
2) Image 2 shows a simple menu of the different ways the application can choose to show restaurants. Since there are presumably many restaurants in a given direction, the user can choose which types he wants to see. Our user is very interested in getting cheap food, so he selects "cost". The menu disappears and the compass reappears as in Image 1. The user now finds two restaurants that interest him. He adds them to a list of restaurants he wants to compare by touching them. Once he has found two that he likes, he selects "compare".
3) Image 3 shows the two restaurants our user is interested in. If he changes his mind and wants to continue searching, he can simply press "back". Otherwise, he selects the restaurant he wants. In our case, the user wants to go to "Hsin Hsin".
4) Image 4 shows a map that the user can follow to his destination. Our user does so and enjoys his experience.
Further Information
The map in Image 4 is something that we are wrestling with a lot. It would be more consistent and very cool if after the user selected his restaurant, he was directed by a compass to the destination. In other words, he would be directed by an interface more like that shown in Image 1. We chose not to use that idea in this storyboard because we are concerned about the accuracy of the directions people would get, as well as the accuracy of the GPS knowing exactly where the user is. If we choose to implement this design, we will seriously consider implementing our design in this way.
Additionally, there is the concern of how we show multiple restaurants in the same direction. Since our expected user is not super picky about the place he eats, but instead is just trying to find some food, showing only a few restaurants in a given direction is acceptable. We are working out the best way to add some sort of scroll bar, though, to cycle through the various restaurants at various distances in a given direction. It is a minor detail at this point, but we are thinking about it.
Analysis:
Learnability: This should be very learnable, because the idea of pointing the device in the direction you want to find a restaurant seems very intuitive. A user should be able to pick up the app, and even if he doesn't know what it does, just by turning it and seeing various restaurant logos scrolling on the screen, a new user can learn what the app is doing. The subsequent screens are very self-explanatory and there are few controls. That means that a user will not have to learn very much functionality to fully use this application.
Efficiency: The main concern here is that a user will have to physically move the device to see all the restaurant options. This is a very slow process. This may be an acceptable tradeoff, though, if the user feels that the search is more intuitive and interactive. Once the user has chosen his restaurants, the rest of the process is very quick, as there are very few steps to take, and all can be completed with a simple touch. Another concern here is that the process of scrolling through the restaurants in a given direction may be time consuming and tedious for the user. We are designing this for a user who doesn't care too much, though, so we shouldn't find users who want to scroll through tons of restaurant options. In any case, efficiency is where we see a primary concern, because the user does have to physically move the device to select a restaurant.
Safety: We will have back buttons to easily return to previous screens. This will mitigate a lot of safety concerns. The largest safety concern is that after the user has chosen his restaurants, if he makes a mistake and wants to re select his restaurants, the nature of the compass interface is tricky. He will then have to point the device in the proper directions once again to find the restaurants he wants. This could be very annoying for many users as they are effectively forced to start over. This should be a solvable issue, though. We will continue developing solutions to this issue that mitigate the safety concerns while maintaining consistency with the design of the app.
Design 3:
Design 3 is a radically different way of choosing a restaurant to eat at. As we have mentioned, the target market is the set of people who are hungry but want cheaper food, and are eating simply to satisfy the biological need, not necessarily to have the "ultimate restaurant experience." In this design, we allow users to view restaurants in the area, but in the context of a game. This medium makes a lot of sense for a variety of reasons. First, since the game can be thought of as "competitive", restaurants could potentially advertise in a new way by rewarding winners. This way, people would be excited to use the app and find a restaurant that they could get a coupon for. Second, if we make the game itself compelling enough, people may be excited to use the app just because they enjoy the game. In this way, we may be able to interest users. Finally, by giving the user a gaming experience, people could gain an emotional attachment to the restaurant search experience. That emotional attachment would make it more fun for the user.
...