RGA Project Part 2

Design Space Overview

Essentially, the design space for our potential interfaces demands that solutions be mobile ones. Our problem is to find an effective manner for users to search for restaurants in a familiar and possible unfamiliar mobile environment. The design space of our interfaces could be a user walking down the street, a user driving in an unfamiliar or familiar area, or in any number of situations where the user finds himself away from conventional computer-based or paper-based methods of finding a restaurant. However, some requirements for such a system may prove to be difficult. For example, having the appropriate amount of information on hand in a mobile situation could prove problematic. Where and how would this information be stored and how would it be presented? Luckily, the user is likely to find a few tradeoffs in this dilemma. One such tradeoff would be the quick and easy solution to his or her problem: Mobile search of a restaurant in an unfamiliar or familiar area. The user searching for restaurants might not need to know a vast quantity of information about the restaurant in question. They would likely be satisfied with a few basic points about the restaurant in question to aid in the quick decision of where to go for their meal.

We considered a total of six design solutions to attempt to solve this problem. First, the three we discard will be discussed followed by the three we chose to explore. We considered a system based on a cell-phone to solve this problem. However, this system was rejected due to the limited nature of the display on a cell phone. We desire a much richer display for the interaction between device and human. We also considered a freestanding kiosk that would be located in certain locations around a city. We rejected this design because it did not meet our criteria of mobility and would not allow the user to search for a restaurant at any desired location and at any desired time. Third, we considered wearable computer technology to be the basis of this solution. However, this alternative was rejected because of the fact that wearable computer technology is still in a developmental state and not nearly prevalent enough to support our desired function.

The three designs that we chose to explore follow. First is the voice-recognition multi-modal design that would be primarily looked at in the design space of a car. Voice activation technology is being looked at so that the user does not have to use hands or even visual attention to interact with the system. We found that a fair number of users would like to perform this task in the car. This system would allow them to do that without having to visually fixate on a screen or use their hands. The limitations of voice-recognition technology are being considered in the exploration of this design. Second, we are exploring a hand-held PDA interface that will search by categories within the information that is offered about a restaurant (e.g. cuisine, price, location, payment type, etc.). This system is being considered for its ease of use and because of the fact that it is the prototype that would offer the user the most features. This prototype would give the user the most information as well. All of the important information about a restaurant could be presented to the user in compact format that would not stress storage capabilities of the technology being used. Finally, we wish to explore an interface in a portable device that would be designed to consider the choices of multiple users. The system would take into account choices of several users in a party and search for a restaurant that could accommodate all of the tastes listed by the multiple users. This system has the potential to solve the problem of finding a restaurant but also the problem of deciding on a restaurant when a party cannot agree on a selection.

Interface Design A: Voice System Design Alternative

Design Description

One design for finding restaurants while mobile is multi-modal and has voice recognition technology. It will not require the user’s hands and will be located in a user’s vehicle. This system will utilize voice recognition technology, auditory prompts, will have an interface layout tailored towards a quick, less attention demanding visual scan, and will also provide information in an auditory modality. This system will allow the user to select relevant criteria upon which to base a search for a restaurant and after a search is performed information about the restaurants will be presented to the user, one restaurant at a time. The user will hear an auditory prompt that provides them with acceptable choices for search criteria and the user will then speak one of these choices. After narrowing the search to his or her preferred criteria and limiting the ranges of these criteria, results will be presented in both an auditory and a visual manner. These results will include information such as cuisine offered by the restaurant, general prices of items, hours of the restaurant, methods of payment accepted, and directions in map format. As mentioned, the visual presentation will be limited in amount of text to allow for a quick visual scan. For example, a screen of information will contain minimal written information and this information will be of appropriate size and spacing to promote visualization when the device is more than a couple of feet away from the user. This same information will be spoken by the system.

Design Rationale

Individuals often have the desire to complete the task of finding a restaurant while operating or traveling in a moving vehicle. However, this task is somewhat complicated in this environment by the fact that driving requires motor capabilities in terms of using the hands to operate the steering wheel, to potentially change gears in an automobile with manual transmission, and to operate additional features such as turn indicators and windshield wipers. It is also beneficial for the eyes to remain on the road while driving to determine direction and the actions of other drivers. With these limitations, it would be difficult to manually select and view all desired information regarding nearby restaurants, especially in the conventional methods discussed in part one of this project. Thus, we propose a multi-modal voice recognition system with an interface requiring little visual attention. This system would allow the user to select search criteria after receiving an auditory prompt by speaking this choice, thus allowing the user to use his or her hands for the tasks associated with driving. These search criteria are based upon user input for part one, and are the criteria that they considered to be most important in finding a restaurant. Additionally, an interface with auditory interpretations of search results and directions to restaurants that do not have much text requires less divided attention on the part of the user. The user can perceive this information without looking away from the road. This decrease in divided attention is important because in theory it should improve performance on the task of driving and on the task of finding a restaurant.

Design Illustration

Display	System Voice	User Voice
Restaurant Search Criteria - Cuisine Type - Location - Payment Methods - Price	“Please select a search criteria from the following: Cuisine type, location, payment methods, and price.”	{Selects criteria} “Location.”
Current criteria: Location - 2 miles - 5 miles - 10 miles - 15 miles	“Please select a location criteria from the following: 2 miles, 5 miles, 10 miles, 15 miles.”	"Two Miles"
Criteria: Location- 2 miles -Perform search -Narrow with more criteria	"To perform a search now say ‘search.’ To narrow the search with more criteria, say ‘criteria.’”	“Criteria.”
Criteria One- Location- 2 miles Criteria Two -Cuisine Type -Location -Payment Methods -Price	“Please select a search criteria from the following: Cuisine type, location, payment methods, and price"	“Cuisine Type.”
Current criteria: Cuisine Type -American -Chinese -Fast Food -Italian -Mexican -Other	“Please select a search criteria from the following: American, Chinese, Fast Food, Italian, Mexican, Other.”	“Italian.”
Criteria One: Location- 2 miles Criteria Two: Cuisine Type- Italian -Perform search -Narrow with more criteria	“To perform a search now say ‘search.’ To narrow the search with more criteria, say ‘criteria.’”	"Search"
Search Results Location- 2 miles Cuisine Type- Italian -Anthony’s -Show additional info. -Show directions -Show next restaurant	“Anthony’s meets search criteria. For more information say ‘information.’ For directions, say ‘directions.’ For another restaurant, say ‘next.’”	"Directions"
Cuisine Type- Italian Anthony’s Map	“A map is on the display. To drive to Anthony’s from the present location: Turn left at Main Street. Travel 2 miles. Turn right on Oak Lane. Anthony’s is on the right.”	{User turns left} {Travels 2 miles} {Turns right}

Design Scenario

Scenario One: The Smith family in an unfamiliar location
The Smith family is traveling in their vehicle, in an unfamiliar location and they decide to stop at a restaurant for lunch. However, they have no idea what kind of restaurants are in the area or where they are located. The mother is driving while the two children are in the backseat. Thus, the mother is busy looking at road signs and navigating the unfamiliar roads and does not have the luxury of looking away from the road for extended durations of time. However, her children are cranky and it is imperative to find food before there is a mutiny in the backseat. She does not have the luxury of time; she cannot pull over or haphazardly drive around searching for suitable dining locations.

Instead, she presses a clearly labeled button, activating her voice restaurant search system. A voice prompt offers her acceptable search criteria: cuisine type, location, payment options, and price. Mrs. Smith’s main goal at this point is location, because the closer the restaurant, the sooner her children stop screaming! She says “location” and then a voice prompts her to identify the acceptable limits for this particular criterion. It presents several distance options and Mrs. Smith says “two miles.” The system then prompts her to either perform the search or to select another criterion upon which to narrow her search. Since she has incredibly picky children and knows that she must consider more than just location, she says “criteria.” The voice-activated system again lists the acceptable input criteria and Mrs. Smith says “cuisine type.” The system prompts her to limit this criterion. As the system is listing the available cuisine types, however, the children begin shouting their preferences and Mrs. Smith does not hear several cuisine types. After the system finishes listing the cuisine types, she says, “repeat” and the system again lists the cuisine types. Having to listen to all of the options again, even the ones that she missed the first time, is frustrating to Mrs. Smith. However, this time she hears an acceptable cuisine type, but as she is saying “fast food” her children again begin screaming their choices as well. The system does not recognize the cacophony of sounds produced by everyone in the car speaking at once so it produces no results. Mrs. Smith has to again say, “repeat” and listen to the choices. This time the system recognizes her when she says “fast food.” The system, which is synchronized with a GPS device lists the fast food option closest to the Smith’s present location and gives auditory directions. It also displays a map outlining the route along which they should travel. Mrs. Smith is able to follow the auditory directions with an occasional glance at the map and find the fast food restaurant.

Scenario Two: The Smith family in a familiar location
The Smith family is out running errands in their hometown when the two children in the backseat of the car tell their mom, the driver, that they are hungry. Although she knows most of the restaurant choices in her hometown, she would like to know which restaurants meet certain criteria that she is interested in and the most direct way to arrive at these restaurants. Thus, she decides to use the multi-modal voice recognition device mounted in her vehicle. The system prompts her to speak the criteria upon which she would like to base her search. She just fed her children fast food on the previous day and would like for them to have a more healthy meal so she says “cuisine type.” However, the radio is playing in her car and the system misinterprets the radio for voice input and advances to the Location menu. Mrs. Smith does not know how to return to the previous criteria menu so she turns the system off and then turns it back on again. This time she turns off the radio before she is prompted to select from the criteria listed. This time the system correctly interprets her “cuisine type” choice. When prompted to limit this criterion, Mrs. Smith says “American.” The system then prompts her to either perform the search or to limit the search with another criterion. She remembers that she just spent her last cash on toys for her two children at the mall so she needs a restaurant that will accept credit cards so she decides to select the criteria of “payment option.” The system then prompts her to limit this criteria and she says “credit card.” She is then prompted to either that which she is really concerned with so she indicates that she would like the system to perform the search. The system then provides her with restaurants that fit these criteria, one at a time, allowing her to obtain more information about each restaurant as it is presented. Mrs. Smith really had a certain restaurant in mind when she selected these criteria and she becomes frustrated when she must go through most of the restaurant choices presented to determine if this particular restaurant takes credit cards. When she discovers it on the list presented by the system, she then obtains directions to the restaurant from her present location. However, these directions are problematic in that they do not account for the closing of several roads in town due to maintenance, and thus, they do not indicate the appropriate detour that must be taken to arrive at the restaurant. Mrs. Smith has to discover this information on her own.

Design Assessment

The description, illustrations, and scenarios regarding this design alternative were presented to potential users to obtain their feedback on the system. This feedback is essential for an accurate assessment of the multi-modal voice recognition restaurant finder. It is also important to assess this design alternative with the usability criteria specified in part one. These criteria are familiarity, customizability, and recoverability. In terms of the familiarity criteria, several potential users commented that the concept of talking “to their car” was both new and uncomfortable. As an unfamiliar activity several users, mostly older professionals, mentioned that they did not like the idea of being given auditory prompts and that they would want to speak their choice immediately, without waiting for the appropriate time to respond. Most of the users had little or no experience with voice recognition technology. Thus, they had problems giving input in the appropriate manner. For example, instead of saying the prompted words that the system could understand, they would use words more familiar to them. Instead of “criteria” to present the criteria again, they thought that “narrow” would be a more acceptable choice since it was the first word presented. Additionally, they are accustomed to using vision when given information. Thus, they wanted to look at the display screen instead of just listening to the auditory information.

In terms of the customizability criterion, the users all commented that they did not like the idea of having to listen to all menu options each time and suggested that they be allowed to exclude options that they would never use. They did not like having to listen to the same menus repeatedly. For example, when trying to narrow a search with a second criterion, the user has to listen to all criteria again, even though they have already been exposed to all of them. Additionally, users mentioned that if the system were used frequently, they would remember most of the choices and would become frustrated having to wait for all of the voice prompts to finish before they could speak. Some users suggested having different settings, where more experienced users would not have to listen to all of the menu options.

In terms of the recoverability criterion, the users thought that the system allowed for easy correction if the voice recognition did not detect any input. The user could simply get the system to repeat the menu options and then speak their choice again. They only had problems in that the functions such as “repeat” were not explicitly in the interface. Thus, if the system detected input, but did not recognize the input the user could say, “repeat” to hear the previous menu again. The users had to ask about this feature since it was not obvious in the interface and they commented that they did not know if they would be able to remember all hidden functions such as that one. However, if the system interpreted the input incorrectly, the users thought that there was no easy way to access the information that they actually desired. For example, if a user wanted to search by price, but the system interpreted the user saying “price” as “payment” for some reason, there would be no way for the user to stop the search on payment and do the search that they actually would like, one concerning restaurant pricing.
The users also made many comments that did not necessarily fall into any of the above criteria. However, these comments are also important to the assessment of this design alternative. The users generally thought having their hands free to drive, while also finding a restaurant was safer and more effective than having to take their hands and eyes away from the road to perform the task of finding a restaurant. However, several users noted that people can use just voice and hearing to talk on hands-free cell phones in cars, and that despite the fact that their hands and eyes are free to drive, they perceived these people as unsafe drivers as well. After explaining the problem of finding a restaurant while mobile, some users noted that this system would limit them to finding a restaurant while in their car. They also wanted a system that they would be able to use while not in their vehicle. Potential users also made several comments about the time required to use this system. They mentioned that they wanted to find a restaurant as quickly as possible and that they wanted to obtain as much information as possible about this restaurant, but that presenting this information in an auditory manner would take more time than just reading the information. They seemed to think that there would be a trade-off between the amounts of information presented and the time required to search for a restaurant (due to having to listen to all of this information). They also noted that they did not like that they could not search by multiple criteria at one time, but that instead they had to specify one criteria, place the limits on that criteria, and then choose and limit another criteria. They thought that this process wasted time and that they could, as one user put it “pass twenty perfectly good restaurants” before the system gave them any one of them as an acceptable choice.

In addition to the user’s comments, there are also technological limitations that must be considered in the assessment of this design alternative. First, voice recognition technology does not perform perfectly; there are several complicating factors and recognition errors that can occur. Voice input may not be recognized because of interfering background noise, which can distort what the user says. Additionally, there are differences in voices between individuals (inflection, dialects, accents, languages) and a system will not perform accurately on a new voice to which it is not attuned. Also, users do not always concisely give appropriate input. Instead, they often repeat themselves, pause, or perform nonsensical noises. They might also give the input at an inappropriate time, when the system is not primed for recognition. Due to these complicating factors several errors in recognition can occur. Substitution is possible, in which the system interprets the input as a different word. Rejection is possible, in which the system detects input, but does not recognize this input. Insertion is possible, in which the system falsely detects input and deletion is possible in which the system does not detect input.

In addition to problems with voice recognition, there are also problems with a multi-modal system, specifically with speech output provided by the system. This output cannot be easily browsed, results in an increase in noise in the environment, competes with background noise, and often must be completely repeated if parts of it are misunderstood.

Due to the comments of users and the knowledge concerning technological limitations of voice technology, it is apparent that while this design alternative would offer mobile performance in a moving vehicle, there are clearly large obstacles to the implementation and user satisfaction with this system.

Interface Design B: Intelligent Agent Alternative

Design Description

The process of finding a restaurant with all currently available systems and the two we discussed above is presented in a single user environment. In this environment one user operates a device that provides them with a list of options. If more than one person desires food then either they will both look at the device and discuss the options or one person will provide a small list of choices to the fellow diners. In order to facilitate this process, this prototype will request several types of cuisine from each person and then, based upon the current location and the selections made, it will intelligently provide a selection that will attempt to satisfy the majority of the users.

Design Rationale

This design places more of the selection process in the hands of the device when it is used within larger groups. This can be very beneficial to the end users. The task of deciding what to have for dinner becomes much more complicated when it is a group that has to decide together.

This design is attempting to leverage upon the existing systems of menu selection and go beyond just providing them in a new environment or in a method that is easier to use. It is trying to help solve some of the problems in the decision making process by providing a list of restaurant options that will satisfy as many users’ requests as possible. It will do this in a mobile setting since this appeared to be the most desired place to have this functionality, according to discussions had with several potential users of the system.

Design Illustrations

This system will be based upon a single handheld device, which each of the several users will enter their preferences into in order. The reason for a single device is to simplify and lower the cost of entry into the system. Since this would be a group activity it lends itself to being used in areas where there are likely to be multiple people. Common places would be in a car driving looking for food, or in a hotel room in an unknown city where the user is not familiar with their surroundings.

This intelligent restaurant locator could be taken anywhere the users wished to have assistance in the restaurant decision making process. It would consist of a fairly simple user interface since its main purpose is to request a preference choice from each user and to then try to make a selection that fits all of their tastes. The first screen of this system would present the user with a choice of how many users to ask for info and what the current location is as presented below. The current location field could be automatically filled in if a positioning system such as GPS was present. This would be a benefit in locations where the user was unfamiliar with the surroundings.

Uploaded Image: design2s1.gif

Each user would then be asked to enter a first and second choice regarding what they would like for dinner, most likely by cuisine but there could be other options as well. The user would also be required to enter a choice priority level which would allow for that user’s choices to be weighted differently in comparison to the others. This would provide a way for a family to allow the parents choices to weigh more heavily in the decision making process. Also, it would facilitate those who are going out for a special occasion to allow the guest of honor to have more say in the decision.

Uploaded Image: design2s2.gif

After each user entered his/her preferences the agent would go off and come up with a list of choices that was ranked according to its likelihood of satisfying everyone’s preferences. This would be based upon the current location or the planned location at which time dinner would be desired.

Uploaded Image: design2s3.gif

Design Scenarios

Scenario One: The Smith family in an unfamiliar location
The Smith family is on vacation in a city that they never have been to before. So its time for dinner and they need to pick a place to eat. The daughter is a fairly picky eater and so her suggestions always carry more weight than the mother and the son. Fortunately they brought along their handheld intelligent restaurant locator to assist them in finding a suitable restaurant in this city. They set the system to a party of 3 in the city they are in. In this situation having a position location system (either GPS or a wireless internet connection) becomes very handy in that it can fill in the current location automatically which is especially useful in an unknown city. Perhaps in this situation, though, the GPS device entered an incorrect location. The users could recover from this by going back to the search form and manually entering their location in the GPS is inaccurate. Next each of them goes in turn and enters their top two cuisine choices and their priority. The daughter sets her priority to 1 and the other two set theirs to 2. This way the system will take suggestions from all involved but will weight those that are most selective, higher. After everyone has entered in their information, the system will display a list of possible choices, and from this they may look at each of the restaurants in detail including parts of the standard dinner menu.

Scenario Two: The Smith family in a familiar location
The Smith family is on their way to dinner in the city in which they live. This family consists of a mother and two children, all of whom want different things to eat. Since they are in a familiar location, they know where they might want to go to eat. They are also more likely to wish to dine in a location that is different from their starting position since they know the area. In this situation with the mother driving, one of the two children will enter the mother’s preferences into the program. To start they specify where they wish to each, either where they currently are (if they have GPS or some other positioning system) or a place of their choosing. They must also enter the number of users whose choices the system will attempt to satisfy so they enter 3. One of the children then enters the mother’s cuisine choice and her choice priority which we will say is 1 that way the mother’s choice can at least equal that of the two children’s. Each of the children will then enter their cuisine preference and a priority choice of 2 so that their priorities will be less than the mother’s. This way the system will take suggestions from all involved but will weight those that are most selective, higher. After everyone has entered in their information, the system will display a list of possible choices. Perhaps then, the system returns several restaurant choices that no one in the party is satisfied with. At this point the child operating the system would simply return to their previous search field and make different selections that might yield different restaurant choices. After this recovery process takes place they finally are given an acceptable list of restaurants. From this they may look at each of the restaurants in detail including parts of the standard dinner menu. In this situation this system could be used just to find an agreeable restaurant or to find something new but the most important point is that it will be in the area in which the user lives so they will have more information at their disposal.

Design Assessment

One of the biggest issues with a system of this nature is how well it can satisfy the preferences of several different individuals. Its use would only exist if it could perform this job well and effectively, without causing circumstances that would have certain individuals upset with how the restaurant choice turned out. Due to the variety of individual preferences and the fact that only certain ones can be met in any one place, this system would have to try and adapt its responses so that if their was nothing that everyone would like that it would make this known otherwise the system will be blamed for what could ensue.

In discussions with potential users of the system as outlined in part one of our project, we learned that of our two potential user groups the college students would find this more useful. From the business user standpoint, while they do need to make decisions regarding dinner choices many times it is just a single businessman who makes this decision, usually the one who is paying for the meal. So while they would like the functionality they are not sure how much they will use it. College students on the other hand tend to run into this problem very frequently as they have many group events/meetings in which they go out to eat and since they are all paying for the dinner they all wish to have a say in the decision making process. One serious advantage to this system is presented with people who do not wish to necessarily say what they think and as a result they don’t get their preference voiced. In this way this system would allow for each user to have an equal say in the decision making process.

This system is most relevant in a mobile environment. In this type of setting the decision needs to be made quickly and the information needs to be at the users fingertips. In more conventional settings the users would have more time to think about their choices and are more likely to be able to agree upon a choice without the system’s intervention. In regards to the usability criteria that we specified in part one as being important to a successful system, these all still apply. This system is still based around the current means of finding restaurant options, in that we use standard selection criteria such as cuisine type and location. Recoverability is very important in this type of system. One would not want all the users to enter their preferences in and then have to do it again. In this way we will provide for the system to constantly store the choices so that may be restored at any point with little inconvenience. In this system customizability is addressed through the use of selection priorities which allow the system to assign different weights for each of the users, which could correspond more directly to their place in society. This is shown in our scenarios where the mother gets a higher priority than the children since most likely she wishes to have a higher say in the decision making process.

Interface Design C: Personal Digital Assistant Alternative

Design Description

The task of searching, ordering, and making reservations for restaurants can be simplified by using a personal digital assistant (PDA). The system will run on a PDA using the Palm operating system. The system will allow the user to search by restaurant name, cuisine, price range, operating, hours, payments accepted, and location. The user will be presented results based on his or her chosen criteria. The user will also be able to select to view the menu for a restaurant, view textual and visual driving directions, make reservations, order food, and view waiting time.

Design Rationale

The personal digital assistant allows users to access restaurant information easily while in local and remote locations. The program can be easily accessed using the same device that one might use to organize dates, memos, and other information, eliminating the need for the user to carry an additional device.

The interface design capitalizes on familiarity, since it uses layouts that the user will be familiar with in conventional searches for restaurants. The search page that is provided resembles a traditional web search interface. If the user selects the option to view a restaurant menu, then the menu will be formatted in a way that is similar to a menu one would use at a restaurant. The user will have the ability to search by restaurant name, cuisine, price range, operating, hours, payments accepted, and location. The user must specify one or more of these search criteria to obtain search results. Location is specified by a city name and state. If GPS capabilities are available to the portable device, then the default location will be set to the location of the user computed by the GPS coordinates. Otherwise, the user must explicitly input a city and state. For users unfamiliar with the area, the application will have the ability to display a map showing the route to a selected restaurant and will also give proper driving directions to the restaurant. Users will easily be able to interpret the visual map, which will be quite similar to a road atlas, with the driving directions highlighted. If the user requires more detail, the textual directions will give a more accurate description of how to find the restaurant.

This application also gives the user a great amount of customizability. The user also has the ability to choose which criteria to use while searching. Restaurants can also be added to the user's favorites list, allowing the user to perform searches specifically on the favorites list.

Recoverability is also considered in this device. The application will allow the user to correct mistakes in a search form by pressing "Back." The values from the previous search will remain in the text boxes, allowing the user to correct the error without reentering all of their search criteria. If the user is ordering from a menu, the application will display the ordered items and force the user to confirm the selections and total price. If there is an error in the list, the user will be able to go back and easily make revisions to the order list.

This application is superior to those already available, since it gives increased search capabilities to obtain more accurate search results. The ability to display complete menu listings, wait times, and order are all functions that are not available to current portable restaurant locators. If the portable device has wireless Internet capabilities, then restaurant information can be dynamically downloaded from the Internet during a search to give the most accurate results. Current devices require location data files to be downloaded and installed before the user can perform a search on a particular area. This task usually requires the data file to be downloaded first to a desktop and then synchronized with the PDA, which can be hassling to the user if restaurant data is needed immediately. The application will also allow the user to make reservations and order at participating restaurants, which is a feature not offered by any other device.

Design Scenarios

Scenario One: The Smith family in an unfamiliar location
On a sunny summer afternoon, the Smith family is traveling to Panama City Beach in Florida for a weekend vacation. As they pass through Tallahassee, the whole family is hungry after being in the car for two hours. They decide that it is time to stop to get something to eat, but none of them are familiar with the area and they do not have any idea what restaurants are in the area. That is when little Billy starts the restaurant finder application on his Palm device. The family agrees that they want Mexican food at an affordable price. Billy selects "Mexican" as the cuisine choice, enters "Tallahassee, FL" for the location, and 0 to 15 dollars as the price range. However, the device fails to recognize the pen properly and instead of restaurants in Tallahassee, it provides restaurants in Tampa!! Thus, Billy has to restart the restaurant search to correctly identify the location as Tallahassee. The search brings back two results, "Taco Bell" and "Los Compadres." The family's decision is split between the two establishments, so Billy selects "Wait Time" for both restaurants, and finds that Taco Bell's wait time is ten minutes less. Since the Smith family is very anxious to get to the beach, they decide to dine at Taco Bell. Billy selects "Directions" for Taco Bell, and proceeds to give his mother the proper driving directions to the restaurant.

Scenario Two: The Smith family in a familiar location
The Smith children, Billy and Suzy, come home from school after their extra curricular activities. The mother has had a long hard day at work and does not have the energy to prepare dinner that night. The children are adamant in wanting Pasta for dinner. The mother gets her Palm device and searches for "Fazoli's," the local pasta parlor. Billy tells his mother that he wants spaghetti and Suzy tells her that she wants lasagna. The mother then selects the "Order" button for Fazoli's and selects two orders of spaghetti (one for herself), and an order of lasagna. However, her wireless connection is not working that well since Billy dropped the device in a sink full of water. Thus, it takes several tries before she can successfully order. She chooses to pay by credit card and enters her credit card information. The mother and children proceed to Fazoli's, and when they arrive, their food is already prepared.

Scenario Three: Bill and Ted
Bill finishes his first day of work as a Palm software developer at Wild Stallions Incorporated. Bill moved to the area two days ago from Atlanta, which is over 2000 miles away. Ted, one of Bill's co-workers, stops by Bill's office as he is shutting down his desktop computer for the day. Ted asks Bill if he and his wife would like to join him and his wife for dinner that evening. Bill agrees, and suggests that they get seafood. Ted likes the idea, and tells Bill to meet him and his wife at Red Lobster in San Dimas at 8pm.

While Bill is out picking up a few things at the grocery store for his wife, he realizes that he has no idea where the Red Lobster is located in his new community. He powers on the trusty portable Palm device and starts the restaurant finder application. Bill enters "Red Lobster" in the search screen, and specifies "San Dimas, CA" as the location. The search returns two locations for a Red Lobster restaurant and Bill is not sure which one Ted intended. He thinks it is the Red Lobster on Main Street so he selects this particular Red Lobster and then selects "Directions" to obtain driving directions. He then clicks "Map" to give a visual idea of the location of the restaurant. Before shutting off the PDA, he selects "Wait Time" for the Red Lobster restaurant, and notices that there will be at least a one-hour wait. Bill uses his portable device to make reservations at 8:30pm, to ensure that they will have a table at that time.

Design Illustrations

	Application Icon in Palm device
	The restaurant search screen that allows the user to enter the name of the restaurant, price range, location of the restaurant, hours of operation, and cuisine.
	Search results displayed after the user presses the "Search" button on the search screen. The user has the ability to select to view the menu, get directions, view wait time, or order from the restaurant.
	The menu display for a selected restaurant. Pressing the "Back" button returns the user to the search results page.
	Wait time information display. The user can choose to make reservations by clicking the "Make Reservations" button, or return to the search results page by clicking the "Back" button.
	The order items display. The user can check the items that are to be ordered. The user will be able to scroll through the list of all items on the restaurant's menu. Pressing "Order" takes the user to a confirmation screen, which is followed by a screen to request payment type and information.

Design Assessment

Upon presenting the design to a sample user, the design was found to be effective in most ways. The user stated that the search fields on the search screen were clear and unambiguous. The action to begin a search was also easily located by the user. The user stated that all button labels were clear except for "Order." He felt that it should be changed to "Place Order." Order might have implied to the user that the button would order the list of results. The user commented that he did not fully understand the method for inputting data, due to his unfamiliarity with Palm devices. The Graffiti system was explained to the user, which he felt he could easily learn. The user was also told that a virtual keyboard could be used, which is displayed on the screen. The user felt that the virtual keyboard would be more efficient than using the Graffiti writing style. The user was also unsure of how to enter special keys on the keyboard, such as "tab" for moving between text fields and "backspace" to delete characters. At first, the user did not understand how to move between text fields without the "tab" key or the use of the mouse. After explaining how to perform these actions, the user felt he could easily adapt. The use of GPS to specify the default location of a restaurant was deemed unnecessary by the user, since he would frequently be searching for restaurants not near his current location. The restaurant menu listing was considered to be very useful by the user. The user also easily understood how to select menu items to be ordered. The user questioned whether or not taxes and gratuities were included in the total after ordering items on the menu. The user was told that that issue has not been addressed yet, but taxes are usually not applied to Internet sales, and it would be the customer's choice whether or not to leave a tip after they dine at the restaurant. Overall, the user felt that the system was a very helpful tool.

The user made comments specific to the considered usability criteria of familiarity, customizability, and recoverability. Concerning familiarity, the user stated that the system was fairly familiar. It presented a search similar screen to a traditional search engine, restaurant menus were displayed in a traditional format, and user interface components were similar to those on a Windows machine, such as buttons, text boxes, and select boxes.

The user felt that the system was customizable, since it contains all options that he could want to conduct a search. At first glance, the user thought he had to fill in all text fields to perform the search, but the user was glad to know that only the needed text fields had to be completed. A simple notice stating of the fact that only needed search criteria should be entered should be placed on the main search screen to prevent confusion.

When evaluating the system, the user quickly knew how to recover from mistakes by using the "Back" buttons. The user was told that when the "Back" button was pressed, previously entered values would be retained, which he found to be very helpful. Deleting characters in a text field due to a spelling mistake was unclear to the user. He felt that he could easily use the Graffiti method for deleting characters.!!Changes to requirements and Usability criteria
We made no major changes to our usability criteria as specified earlier in the project. We are still following the criteria of Familiarity, Recoverability and Customizability. Through discussions with users and further development of our design, these criteria continue to emerge as ones that are most relevant. We also added a requirement of the system being mobile. Without mobility, the problem will not be solved in a satisfactory manner.

Changes to requirements and Usability criteria

We made no major changes to our usability criteria as specified earlier in the project. We are still following the criteria of Familiarity, Recoverability and Customizability. Through discussions with users and further development of our design, these criteria continue to emerge as ones that are most relevant. We also added a requirement of the system being mobile. Without mobility, the problem will not be solved in a satisfactory manner.

Familiarity in this system is very important in that it aids in the learnability of the system. Users of this system are likely to be people who already use currently available system. These current systems include such things as internet pages. This design leverages off of users familiarity with these current systems in that most of the interfaces will be similar and the general method of information presentation will be similar. This being the case, users will not have to spend a great deal of time familiarizing themselves with details of the system. Customizability remains important in this system as well. The systems will allow the users to access selection profiles and weighting of specific choices in some instance. The recoverable nature of our designs was a welcome feature for users that gave their reactions. Mistakes do happen and computer often give back erroneous data. Therefore, being able to reverse actions without completely starting the entire process over is a feature that is quite valuable to our system. We will judge the value of our system based on its ability to meet or exceed these usability criteria.

In addition to these formal criteria, we added the requirement that our system be mobile. Each of the current prototypes is mobile to one degree or another. Without mobility our prototypes will not solve the problem we have outline for ourselves. Portable handheld devices seem to be a valid method of tackling this problem. Also, one of our prototypes exists in a car. Having this system restricted to the vehicle solves a portion of the need for mobility but perhaps it leaves out the notion of being outside of the car when performing the task of searching for a restaurant. In any case, mobility is one of the most important requirements that our system must meet. If our system does not meet this requirement, the fact that our system meets the usability criteria might not be as profound.

Link to this Page

Rationality Gone Awry last edited on 4 December 2001 at 10:31:50 pm by ACA4C188.ipt.aol.com