Restaurant Order Selection System (ROSS)

Date completed: May 7, 2002

ABSTRACT

Our group designed a restaurant interface for hand held devices that allows servers to enter in food and drink orders of their customers. Having knowledge of an inefficient, existing system that wastes a lot of the server’s time when entering restaurant orders, it was our hope to design a better interface which has quick and easy access to menu information. One of our major motivation was to create an interface that is easy to learn and convenient to navigate. The selections made on the interface by servers would be seen by cooks in order to make the food and by the customer in the form of a bill. This interface is designed for a hand held device that has an attached card reader to accommodate a credit card billing and a wireless network communication capability.

CREDITS

Kate and Estelle performed the usability testing. Vince and Alex implemented the high fidelity prototype using the Microsoft Access. All other portions of the project were a cooperative effort, and major interface design decisions were made during our weekly group meetings.

INTRODUCTION

Overview

The system we are designing will facilitate restaurant employees as they manage customers, take orders and run the restaurant. With our system, we hope to improve and combine features of several existing systems that we intend to evaluate. We have experience using a few of these systems. One such system allowed for most of the tasks ours will handle but was difficult to learn because of a poor interface and inconsistent organization. Most systems we have seen are also run from a few computers placed around the restaurant. The server has to write down or remember customer’s orders and then enter them into the system at a later time. Our system will be hand held and will be involved in several restaurant operations, including recording who is working, how many customers are in the store, which tables have customers at them, what each customer orders and the status of the food. Hosts, hostesses, waiters, waitresses, servers and bus boys would use this system.

The hosts and hostesses in our restaurant are in charge of greeting customers. When someone enters the restaurant, the host or hostess brings the customer to a table and provides them with a menu. With our system the host or hostess would indicate at which table he or she seated the customers. The host or hostess would then assign a server to the table based on whose turn it was to take a table. The system would keep track of how many tables each server had. Using this, the system would determine which server needed more customers.

The waiters, waitresses and servers in our restaurant are in charge of all dealings with the customer after they have been brought to a table. This person is an expert on the menu and features and can assist the customer in selecting items. He or she will take the orders of all customers and bring their food. The server handles the customer’s bill, both the printing of it and taking payment from the customer. With our system, the server would see which tables were assigned to him or her as the customers were placed at tables. He or she would take food and drink orders from each customer and enter it directly into the hand-held computer. Our system would eliminate the need for paper and pen or for the server to remember what each customer ordered. The server would be able to preview the entire order to ensure that he or she did not make any mistakes. The server could then send the order to the cooks to prepare. Our system would notify the server when the food is ready so he or she could deliver it to the table. When the customer completes his or her meal, the server could then print the customer’s bill and accept payment.

The bus boy in our restaurant clears and resets the tables. When a customer finishes his or her meal and leaves the restaurant, the bus boy removes the dishes and prepares the table for the next customer. The servers would notify the bus boys that a table needed to be cleared by marking it in their computers as needing service. The bus boy would then mark the table as cleared in his or her computer so that the host and hostesses would know that that table was prepared for more guests.

Previous Work

Commercial systems

1. Restaurant Computer Services -- http://handheldpos.com/

This is a company specializing in the production of hand held ordering systems. They sell systems similar to what we intend to design. Their products need to be studied further to see what kind of improvements we can make on what they have already developed.

2. Ameranth Wireless, Inc. -- http://www.ameranth.com/default.asp

This is another company advertising the production of hand held ordering systems. The news article announcing the development of the system is dated January 29, 2002, so this is a relatively new system that also needs further study.

Magazine articles

1. “Going out for a quick byte.”

This article talks about a food tracking computer system, which tracks ingredients from when they enter a restaurant until they leave a restaurant on customer dishes. This computer system keeps track of the price of each ingredient. These ingredient prices can be used to calculate the cost of each dish sold. Also, the computer system includes hand-held keypads, which servers can use to enter in customer orders at a customers' table. These orders can be printed out in a kitchen to be prepared by cooks. When a customer is done eating, the computer system can print a bill.

2. “McDonald's Made For You program: Quieter, sometimes slower.”

McDonalds has a computer system that communicates information from a customer to the McDonalds kitchen. At the customer ordering counter, the server enters a customer's order into the computer system. Then the order is relayed to cooks via monitors in the kitchen.

3. “Voice Recognition System Takes Pizza Orders Down Under.”

The Australians have devised a voice recognition ordering service for Pizza Hut. Their computer system will take calls from a central location in the U.S. A customer tells the computer system what they want to purchase. Then the computer system sends the order to a Pizza Hut in the town of the calling customer. Finally, the order is cooked and delivered to the customer.

PRESENTATION OF DESIGN

Overview of Approach and Solution

Our initial approach was to have the server select the table and seat of the customer and then enter in his or her order by selecting menu items. Each menu item would bring up sub-menus where the server would enter additional information, such as cooking instructions. The interface would then send the order to the cook, perhaps flagging food that requires longer preparation time. This problem was not addressed in our solution because this was not relevant to tasks assigned to servers, host/hostess, and busboy. The server would also be capable of signaling a printer via wireless network to print a customer’s bill from the interface. We planned to involve servers in the developing process to help us determine how the interface should appear and function.

Transition Diagram

High Fidelity Prototype

Figure 1: Employee Sign In [1]

From this screen, the user can go to [2], [14] and [15].

This is the initial screen.

Figure 2: Server Table Selection [2]

From this screen, the user can go to [3], [13] and [17].

The user can get to this screen from [1], [3], [7], [9], [10], [13] and [17].

Figure 3: Seat Selection [3]

From this screen, the user can go to [2], [5] and [9].

The user can get to this screen from [2] and [5].

Figure 4: Menu [5]

From this screen, the user can go to [3] and [7].

The user can get to this screen from [3] and [7].

Figure 5: Table Order [7]

From this screen, the user can go to [2], [5], [8] and [9].

The user can get to this screen from [5].

Figure 6: Order Confirmation [8]

From this screen, the user can go to [2].

The user can get to this screen from [7].

Figure 7: Bill Payment [9]

From this screen, the user can go to [2] and [10].

The user can get to this screen from [3], [7] and [10].

Figure 8: Credit Card Payment [10]

From this screen, the user can go to [2] and [9].

The user can get to this screen from [9].

Figure 9: Break Information [13]

From this screen, the user can go to [2], [14] and [15].

The user can get to this screen from [2], [14] and [15].

Figure 10: Busboy Table Clearing [14]

From this screen, the user can go to [13] and [17].

The user can get to this screen from [1], [17] and [13].

Figure 11: Host Table Selection [15]

From this screen, the user can go to [13], [16] and [17].

The user can get to this screen from [1], [13], [16] and [17].

Figure 12: Server Assignment [16]

From this screen, the user can go to [15].

The user can get to this screen from [15].

Figure 13: Sign Out [17]

From this screen, the user can go to [1], [2], [14] and [15].

The user can get to this screen from [2], [14] and [15].

Tutorial/Help

The Restaurant Order Selection System start up screen is labeled “Employee Sign In” [1]. On this screen there is a name field, a duty selection and several command buttons. At the bottom of the screen the current date and time are displayed. To begin work on the system, enter a name in the Name field (the user may also use the drop down arrow and select a name). This is a combination box, so by typing the first few characters of the name of the employee who is logging in, the system will pull the appropriate name. Some users may have to enter more letters depending on the number of employee names that begin with those letters. After entering the appropriate name, choose the appropriate duty by selecting the option button next to Bus Person, Host or Hostess, or Server. To sign in, press the “Sign In” button. If at any time, additional information is needed, press the “Help” button. This button will be located at the bottom right corner of all screens in the system.

Host

All functions to be completed by the host are contained in the host module of the system. At the top of all screens in this module, the word “Host” appears indicating the system is in host mode. The name of the host logged in to the system also appears in the top right hand corner of each screen. The bottom right hand corner of each screen has a command button, labeled “Help,” which provides additional information about that screen if needed.

Host Table Selection [15]: After logging onto the system as a host from the logon screen [1], this screen appears. The screen prompts “Select Table to Assign Server to.” By pressing a table, the server selection screen [16] is loaded. At the bottom of the screen are command buttons, labeled “Break,” and “Sign Out.” Pressing “Break” will take the system to screen [13]. Pressing “Sign Out” will take the system to screen [17].

Server Assignment [16]: This screen is loaded after the host selects a table from the host table selection screen [15]. At the top of the screen below the word “Host,” the system displays the table number that is currently being assigned a server. The system then displays a list of servers on duty appears. This list is in priority order as determined by the system. The host highlights the server they wish to assign the table to and presses “Assign.” If they have entered the wrong table number, they can press the “Table Map” button at the bottom left corner of the screen. After pressing either of these buttons, “Table Map,” or “Assign,” the system will return to the host table selection screen [15].

Break [13]: This screen is reached by pressing “Break” from the host table selection screen [15]. On this screen the host selects the amount of time that he or she will be unavailable and presses “Take Break.” When he or she returns from a break, they select “I’m Back” and the system returns to the table map [15]. At the bottom of the screen, the current time is displayed.

Sign Out [17]: This screen is reached by pressing the “Sign Out” button on the table selection screen [15]. It displays information about the host’s time on duty such as the amount of hours worked. A text box with number keypad will be used for entering tips earned during the user’s shift. The system then prompts “Are you sure you want to sign out?” By choosing “Yes,” the system proceeds to screen [1]. By choosing “No,” the system returns to the table selection screen [15] and allows the host to continue working. At the bottom of this screen, the current time is displayed.

Server

All functions to be completed by the server are contained in the server module of the system. At the top of all screens in this module, the word “Server” appears indicating the system is in server mode. The name of the server logged in to the system also appears in the top right hand corner of each screen. The bottom right hand corner of each screen has a command button, labeled “Help,” which provides additional information about that screen if needed.

Table Selection [2]: After signing in to system, a map of the restaurant [2] will appear on the screen. By clicking on any table in this screen or the table navigation bar at the top of the screen, the system will go to a seat map of the selected table [3]. On the bottom line of the screen are several command buttons. The first, labeled “Sign Out,” allows the server to log off of the system. It activates screen 17. The second, labeled “Break,” allows the server to notify the restaurant that he or she is unavailable for a given period of time. When pressed, this command button activates screen 13.

Seat Selection [3]: By choosing a table on the table map [2], this screen appears. At the top of the screen, below the word “Server” the table that is currently being modified is highlighted on the table navigation line. The seat that is currently active is also marked on the seat navigation line. The screen provides a picture of the table with the seats numbered. By selecting a seat, the system will proceed to the ordering screen [5]. At the bottom left hand corner of the screen is a command button, labeled “Table Map,” which will return to the previous screen, the table map. Next to the table map button, there is a command button, labeled “Bill,” which activates the bill payment screen [9].

Menu [5]: By choosing a seat on the seat map [3], this screen appears. At the top of the screen, below the word “Server” the table that is currently being modified is highlighted on the table navigation line. Below that, the seat that is currently being modified is marked on the seat navigation line. The upper right hand corner displays what food has already been added to the order for that seat. The main portion of the ordering screen contains a drop down box with six options labeled with different courses of a meal, “Beverage,” “Appetizer,” “Entrée,” “Side Order,” “Dessert,” and “Kids Menu.” Selecting one of these options will load that type of food into the option buttons. Above each list of food items, there are two buttons labeled with triangles pointing in opposite directions. These two buttons can be pressed to scroll up and down the list of items on the menu. Below these buttons are several command buttons. The first, “Next Person,” allows the user to move through each seats order in sequence. The second, “Add Item,” adds the food selected to the order for this seat. The last, “Clear,” clears all food orders for this particular seat only. Below these buttons, there is a button, labeled “Seat Map” which will return to the seat map screen. Next to that button is a button labeled “Table Order.” Pressing this button will take the user to screen [7], which display the food selections for the particular table selected.

Table Order [7]: Selecting “Table Order” from the order selection screen [5] loads this screen. At the top of the screen, below the word “Server” the table that is currently being modified is highlighted on the table navigation line. Below that, the seat that is currently being modified is marked on the seat navigation line. Below this text, the order for this particular table is displayed. Beneath the order display are three command buttons. The first button, “Send,” sends the order to the kitchen for the cooks to prepare. The next, “Bill,” sends the system to the bill payment screen [9]. The last, “Cancel,” clears the entire order, erasing it from the system. At the bottom left hand corner of the screen is a command button, labeled “Table Map,” which will return to the table map screen. Next to that button is one labeled “Menu” which will return to the order selection screen for the selected seat. This allows the user to modify the order for that seat.

Order Confirmation [8]: After selecting “Send Order” from the order preview for table screen [7], this screen appears. The text states “Order Confirmation: An order for table <table number> was received at <time>.” There is only one command button “OK.” This screen is used only to notify the server that his or her previous actions were completed. By selecting “OK,” the system returns to the table map [2] where the server can begin the process again.

Bill Payment [9]: Selecting “Bill” from the seat map [3] or the Order Preview [7] loads this screen. At the top of the screen, below the word “Server” the table number that is currently being viewed appears. The first button on the screen, “Print,” prints the customer’s bill. Below this there is a prompt to select payment type. The server then chooses the option button next to the form of payment the customer intends to use. There is a box for the server to enter a tip if applicable. Below the tip box, the sum of the bill and the tip is displayed. At the bottom left hand corner of the screen is a command button, labeled “Table Map,” which will return to the table map screen without recording the payment. Next to that button is one labeled “Pay.” If cash or check is selected and this button is pressed, the system returns to the table map [2]. If credit is selected and this button is pressed, the system loads the credit card signature page [10]. The pay button cannot be selected unless the customer bill has already been printed.

Credit Card Payment [10]: Selecting the credit option on the bill payment screen [9] and pressing “Pay” loads this page. At the top of the screen, below the word “Server” the table number that is currently being viewed appears. Below this, the amount of the bill is displayed. There is a text box where the customer can enter the tip he or she wishes to leave the server to the left of a number keypad that the customer can use to enter in the amount. The “private” button can be used by the customer to keep the tip information hidden from the server to avoid potential awkwardness. Then the system prompts “Please sign within the box.” The screen displays a box and the customer signs the screen. At the bottom left corner of the screen is a command button, “Cancel,” which will return the system to the bill payment screen [9] without a signature, canceling the payment. The next button, “Accept,” returns the system to the table map [2].

Break Information [13]: This screen is reached by pressing “Break” from table map [2]. On this screen the server selects the amount of time that he or she will be unavailable and presses “Take Break.” When he or she returns from a break, they select “I’m Back” and the system returns to the table map [2]. At the bottom of the screen, the current time is displayed.

Sign Out [17]: This screen is reached by pressing the “Sign Out” button on the table selection screen [15]. It displays information about the host’s time on duty such as the amount of hours worked. A text box with number keypad will be used for entering tips earned during the user’s shift. The system then prompts “Are you sure you want to sign out?” By choosing “Yes,” the system proceeds to screen [1]. By choosing “No,” the system returns to the table selection screen [15] and allows the host to continue working. At the bottom of this screen, the current time is displayed.

Bus Boy

All functions to be completed by the bus boy are contained in the bus boy module of the system. At the top of all screens in this module, the word “Bus Boy” appears indicating the system is in bus boy mode. The name of the bus boy logged in to the system also appears in the top right hand corner of each screen. The bottom right hand corner of each screen has a command button, labeled “Help,” which provides additional information about that screen if needed.

Bus Boy Table Clearing [14]: After logging on to the system as a bus boy on screen 1, the bus boy table selection screen [14] appears. The screen prompts “Select table to clear,” and a table map is shown. Tables that need clearing say “Dirty”; tables that do not need clearing have no text. When a bus boy presses one of the dirty tables, the dirty label is removed indicating the table has been cleared. When a clean table is pressed, the word “Dirty” appears, indicating that it needs clearing. At the bottom of the screen are command buttons, labeled “Break,” and “Sign Out.” Pressing “Break” will take the system to screen [13]. Pressing “Sign Out” will take the system to screen [17].

Break [13]: This screen is reached by pressing “Break” from the bus boy table selection screen [14]. On this screen the bus boy selects the amount of time that he or she will be unavailable and presses “Take Break.” When he or she returns from a break, they select “I’m Back” and the system returns to the table map [14]. At the bottom of the screen, the current time is displayed.

DEVELOPMENT PROCESS

Low Fidelity Prototype

Process of Arriving at High Fidelity Prototype

The low fidelity prototype showed many details and was structured well. In a sense, it was more than a low fidelity prototype. We preserved the general structure and many details when we implemented the high fidelity prototype.

The most prominent change was to allow the server change the current table and sometimes also the current seat by direct manipulation, that is, by a click of mouse. In the low fidelity prototype, we had a field where the server had to enter the table number, probably using a keyboard and pressing a button.

A more realistic picture that contains the table surrounded by the seats themselves where the server clicks on the seat s/he wants to select has replaced the table map in the low fidelity prototype.

The two menu forms in the low fidelity prototype (Form 4 and Form 5) have been combined into one Form, namely the Menu Form (Form 5) to allow the server to choose one food item and many selections at a time preventing him/her to go back and forth between two forms to complete an entire order.

In the high fidelity prototype, the signing out procedure for all types of workers (busboys, host/hostesses and servers) was made uniform. Another procedure that is taken care to make uniform was to take breaks. There, the two buttons named “Take break” and “I’m back” have been collapsed to one button, which changes its title according to the situation.

The high fidelity prototype is simpler in various aspects than the low fidelity prototype. For instance, the number of tables has been reduced to 4 from 9, and the number of seats in each table has been reduced to 4 from 8. In addition, the “modify further” button for an item in a seat order has been left for future implementations.

Much attention has been given to preventing the user from making errors. Disabling and enabling of controls has been extensively used. For instance, on the Bill Payment Form the task of printing the bill enables further actions such as entering the tip, selecting the type of payment and paying the bill. Those actions are not allowed until the server prints the bill. A direction for printing the bill has been added to the Bill Payment Form, which changes to a confirmation message after the bill gets printed. Another example of preventing user errors is when a server tries to select a table that is already handled by another server.

Information showing the current status of things, such as who serves which table, and which tables are dirty and therefore need bussing has been made available. Such information relieves the user by lowering his/her short-term memory load.

Finally, help messages have been made in uniform format each showing a number of steps that is expected to facilitate the user to understand what to do in what order upon pressing the help button. The help button has the same appearance and location in every screen, however, provides information relevant to the current screen the user is in.

Usability Test for the High Fidelity Prototype

Brief process of the usability test method

The Restaurant Ordering Selection System interface was shown to each user on a PC at the beginning of the usability test. The layout was briefly explained concerning the content of each screen. I took about 2 minutes explaining the entire system addressing issues concerning the fact that this is a palm pilot like display, touch screen, and that user is to ignore the data that appear on the display box when adding items to the ordering list because the list is static.

Seven users with no prior experience as a server and five users with 1 day to 3-month experience were invited to try our system.

Then the users were asked to do following tasks on the task list.

Task List

Host:

1. Log on as a host.

2. Four customers enter the restaurant. Assign them to table #2 and select their server.

3. Take a five-minute break.

4. Return from your break.

5. Log off the system.

Server:

1. Log on as a server.

2. The user is assigned table #3 with 4 customers.

3. Order a coke for customer A, milk for customer B, lemonade for customer C and milk for customer D.

4. Order food for the table. Customer A wants a Hamburger with catsup. Customer B wants a steak, side salad, and mashed potato. Customer C wants pizza and side salad. Customer D wants milk, turkey, white rice and side salad.

5. Preview the table’s order.

6. Send food order to the cooks.

7. Take a 10-minute break while the food is cooking.

8. Return from your break.

9. Print a bill for the table.

10. Customer pays with cash.

11. Log off the system.

Bus boy:

1. Log on as a bus boy.

2. Clean all tables that are shown as needing it.

3. Notify the system that the tables are cleared.

4. Take a 2-minute break.

5. Return from your break.

6. Log off the system.

Usability Test Report

Four selected usability test results are shown below.

§ User #1

The high-fidelity model of our interface for the Restaurant Ordering Selection System (ROSS) was shown to Tracy Calvin, a professional with a degree in Biology who feels comfortable using computers. She has several years of experience as a server in various restaurants, including Uno’s, Lone Star and Romano’s Macaroni Grill. She has experience using computer systems to take orders.

Host

Possible design change: No design change for the interface required.

Observation and feedback: Next, the user was asked to assign table #3 to the server, John. The user had no difficulties choosing the table and selecting a server. She wanted to know how to tell how many people were at each table. She also wondered if she could “unassign” a table.

Possible design change: It may be useful to allow the host to indicate how many guests are at a table. The system also should be capable of freeing a table from server assignments.

Observation and feedback: Next, the user was asked to take a five-minute break. The user had no difficulties taking a break, but wanted to know what she should do if she wanted to take a 10.5 minute break or a 4.5 minute break, since the time spans were not all-inclusive. The user also was curious if the manager had any say in taking breaks or if the host could take a break at any time. The user also noticed that once on the break screen, a user was forced to take a break, she could not un-do the action that brought her to this screen.

Possible design change: We may want to adjust the time spans of the break options. We also may want to require manager approval for breaks. We should also have a cancel button on the break screen.

Observation and feedback: Next, the user was asked to sign out. The user found this task easy to use.

Possible design change: No design changes necessary.

Server

Observation and feedback: Next, the user was asked to sign in to the system as a server. The user found it easy and clear to enter in her name, choose her duty, and to hit the button that says “Sign In.”

Possible design change: No design change for the interface required.

Observation and feedback: Then, the user was told that she was assigned to table #3 and that four customers will be sitting at the table. The user had no difficulty selecting table 3, or any other table on the page. The user did not like that she could access table #1 and #2 since they were already assigned to other servers.

Possible design change: We may want the system to lock other server’s tables so that only the server assigned to the table and the manager could access the table.

Observation and feedback: The user was asked to order a soda for customer #1 and lemonade for customer #2. The user found it easy to navigate from seat to seat using the next seat button. She did not like having to hit append after each item was entered. She was afraid she would forget. She also did not like that she could jump from table to table from the order entry screen. She was afraid she’d accidentally switch tables or switch without sending the order first.

Possible design change: We should eliminate the table navigation on the order selection screen or have a notification that tells the server that they are changing tables and whether or not they have already sent the current tables order. We should also consider changing append to remove item and have food automatically be added when selected and use the remove to fix errors.

Observation and feedback: The user was asked to order food for the table. She found the food on the list rather quickly, but was curious how much she could modify the selection. She did not see a way to specify cooking temperature or specialty food. She thought that the system should at least have an option to tell the cooks to wait for further instructions from the server.

Possible design change: We may want to include a see server option for all food entries.

Observation and feedback: When asked to preview the order for the table #3 and send it to the cook, Tracy wondered whether she would be seeing the entire order or just the food she had just added to the order. She also wondered how to tell which food order was being sent to the cook, the new food or all of the food.

Possible design change: We should consider displaying all of the food on the preview screen but highlighting food that has not been sent to the cook yet in a different color to indicate that that is the food being sent.

Observation and feedback: Next, the user was told that the customer wanted to pay the bill by credit card. She thought that the total should change when the customer entered the tip, that way they knew exactly how much they were paying.

Possible design change: The system should total the bill and tip on the credit card payment screen.

Observation and feedback: Next, the server was asked to sign out of the system. She found this task easy, but thought that the system should ask her how much money in tips she was claiming for tax purposes.

Possible design change: The system should allow the user to enter cash tips into the system.

Bus Boy

Observation and feedback: The user was asked to sign on as a bus boy. She had no difficulty with this task.

Possible design change: No change necessary.

Observation and feedback: The user was asked to clean table 3 and mark it when she was finished. She had no difficulty with this task. She thought the system should indicate if other areas of the restaurant needed cleaning, for example, spills on the floor could be marked for the bus boy.

Possible design change: The system could have a message board for the bus boy to receive information.

Observation and feedback: Finally, the bus boy was asked to sign out of the system. She found this task easy.

Possible design change: No change necessary

§ User #2

The high-fidelity model of our interface for the Restaurant Ordering Selection System (ROSS) was shown to Rebecca Hoffberg, a Mathematics and Government & Politics double major, with some computer experience. She has never worked as a server.

Host

Observation and feedback: Initially, the user was asked to sign in to the system as a host. The user found it easy and clear to enter in her name, choose her duty, and to hit the button that says “Sign In.” She was curious as to why the arrow next to the drop down box was not the same height as the box.

Possible design change: No design change for the interface required.

Observation and feedback: Next, the user was asked to assign table #3 to the server, John. The user had no difficulties choosing the table and selecting a server.

Possible design change: No design change for the interface required.

Observation and feedback: Next, the user was asked to take a five-minute break. The user had no difficulties taking a break.

Possible design change: No design change for the interface required.

Observation and feedback: Next, the user was asked to sign out. The user found this task easy to use.

Possible design change: No design changes necessary.

Server

Possible design change: No design change for the interface required.

Observation and feedback: Then, the user was told that she was assigned to table #3 and that four customers will be sitting at the table. The user asked whether she should click the table number at the top of the screen or the table itself. She liked the visual representation of the table.

Possible design change: We may want to either remove the table navigation at the top or clarify where to select the table.

Observation and feedback: The user was asked to order a soda for customer #1 and lemonade for customer #2. The user was not sure where she should click to change seats. She found the next seat button, but then wondered what would happen when she ran out of seats, would it loop back through and could she have more than four seats.

Possible design change: The system should allow the server or host to specify number of people at a table and then allow only those seats to have orders placed on them, rather than just a standard four seats per table.

Observation and feedback: The user was asked to order food for the table. She had no problem finding the food on the list, but wanted to know if there was a “back” button in case she messed up. She also found it hard to tell what she had already ordered for other seats. She wanted to be able to see the status of the whole table’s order while working with each individual seat.

Possible design change: We may want a back button on each page.

Observation and feedback: When asked to preview the order for the table #3 and send it to the cook, Rebecca had no problems.

Possible design change: No design change for the interface required.

Observation and feedback: Next, the user was told that the customer wanted to pay the bill. She did not find any problems with this, but wanted to know how she would know how much tip to enter with cash. She wondered if a server would be able to calculate the tip to enter if they found $25 on the table and the check was $18.75.

Possible design change: The system should possibly have a calculator feature or a place to enter the amount of money received rather than the amount of the tip.

Observation and feedback: Finally, the server was asked to sign out of the system. She found this task easy.

Possible design change: No design change for the interface required.

Other Observation and feedback: The user thought that she would prefer the pen and paper method to the computer because she wanted to be able to specify special cooking instructions. She also wanted the opportunity to see what she had already done and what was missing. She thought that if the computer method was used there should be more “Are you sure?” screens to double-check her actions. The user also commented that Microsoft had conditioned her to look for help at the top of the screen and that was a possible reason why she did not notice the help function while taking the test.

Possible design change: We could move the help button to the top of each screen.

§ User #3

Our interface for the Restaurant Ordering Selection System (ROSS) was implemented using VB. The high fidelity model was shown to Joanna Smith, a Natural Resources Management major who spends about 15 hours/wk using a computer. She has about 1 day to 3 months of experience as a server. She has used a computing tool to collect orders and to get alerted when food is ready.

Observations, encountered problems, and feedbacks: Initially, the user was asked to sign in to the system as a host. The user found it easy to choose the name given and to press the “Sign In” button. The user did not have any trouble assigning people to each table. The user easily found the “Break” button and the “Sign out” button. The user also did not have any trouble navigating the system to bus the individual tables. However the user wondered why there are so many screens and three buttons she needed to press to sign out as a hostess. She suggested that one question was enough to show her that she intended the correct action by pressing the “Sign out” button.

Possible design change: Cut down on the number of screen that comes up when signing out of the system as a hostess or as a bus person. Similar problem did not arise when logging out as a server because the screen that asks if the user is sure he/she wants to sign out was eliminated. This was one of our inconsistencies.

Observations, encountered problems, and feedbacks: When ordering food items for each customer, Joanna had a slight difficulty finding hamburger under the kid’s menu. She was looking for this item under the Entrée section. She also did not know what “Append” button meant and was puzzled as to if she should press this button after placing each item on the ordering list or to press the button after finish ordering the customer’s entire list. She found the fact that the display on this screen did not update to reflect the item she was adding. She suggested “Append” and “Clear” button should be pressed for the customer’s entire order to cut down on her hand movement going back and forth from marking the desired item to pressing the “Append” button after each item.

Possible design change: Add the item on the display as the user marks the item on the menu. This was not implemented on time to be used for the usability test. Our group should discuss more carefully defining the function of the append button and the clear button.

Additional suggestions: Joanna suggested that it would be nice to have a feature that alerts the server when the food is ready to be delivered to the customer at the table.

Our group had that function as ‘Could have’ feature when initially developing the interface. It was not implemented due to lack of time.

Overall, Joanna felt that the system was very easy to navigate and was confident that she can learn and be comfortable with the system on the first try. However, she prefers the traditional paper and pen approach to using a palm size device.

§ User #4

The high fidelity model was shown to Kirsten Hogan, a Kinesiology major who spends about 14 hours/wk using a computer. She has about 1 day to 3 months of experience as a server. She has not used a computing tool during her work as a waitress.

Observations, encountered problems, and feedbacks: She did not like the fact that she can’t choose more than one food item under one category. She also suggested a way to type in a special request to cook.

Possible design change: Allow the user to select more than one item on the menu list. Allow type in addition request option.

Observations, encountered problems, and feedbacks: Ordering coke with catsup seemed very strange to her.

Possible design change: The condiment list should dynamically update as the user chooses certain item from the list on the left.

Observations, encountered problems, and feedbacks: Accidental click of “Break” button got her to Break screen but she could not cancel her action. She clicked on “Help” button but the help was “useless” to her needs.

Possible design change: Back button or return to previous screen button should be present and a better help should be added.

Additional suggestions: Kirsten suggested that the bus person could just look at the restaurant instead of being alerted through the hand held device.

The bus person feature is optional and can be used if the restaurant is big with divided sections that do not allow the bus person to assess the condition of each table at a glance.

Overall, Kirsten felt that the Help button was easy to find and that she would use the system over the traditional paper and pen approach.

CONCLUSION

Implementation

The Restaurant Order Selection System (ROSS) includes features that enable the host/hostess, servers, busboys to login and logout when they start their shifts. We did not include a password box for logging in because it is assumed that the manager of the restaurant will clear each employee to login at the time the user checks out the palm pilot for work before each shift.

For host/hostess, the system allows the user to assign the servers to the table. For servers, this system will provide a more convenient way to place orders and bill the customer. For busboy, the system alerts which tables need to be cleaned. This interface requires a hand held device (palm pilot) with a stylus to input the data and to navigate the interface.

The interface’s displays are set with static data. Our database is not dynamic and therefore the same items are listed on the display no matter what items are being placed on the order (Menu [5]). The table order also does not change (Table order [7]). This is also static.

Use of the busboy feature is optional. This feature might be very useful if used by a big restaurant that has lot of divisions or walls that separate each section. Bus boy can then know which tables to clear. The system also does not allow more than four seats at a table and will not let the user to expand the numbers of the tables in the initial floor plan of the restaurant.

This interface is designed for a hand held device that has an attached card reader to accommodate a credit card billing. This hardware is also assumed to have a wireless network communication capability as well. The size of each screen designed using MSAccess is slightly larger than a palm-pilot display. We believe that our screen size scaled down to an actual palm-pilot display size would not affect the performance of our users or our system.

Future possibilities

The “modify further” function was not implemented due to lack of time and complications with database management. Cut and Paste feature for duplicate orders for customers were not implemented. To go along with the features listed above and with the “see server” option in the condiment selection section of our Menu screen, a special instruction box where the user can write or type in special requests/instructions could be implemented in the future. A text-messaging feature for all users to communicate with other users on the system was not implemented. The special instruction box and the text messaging should be done using graffiti or touch screen keypad. Also, voice recognition feature for the cook to access the orders and to send feedback to the server when the meal is ready is a possible feature that was not implemented. A split bill feature was considered in our initial development of the interface but was not implemented. Additionally, our system does not allow the restaurant management to change the list of food items available in the Menu form. The servers could use a scanning system to select tables and seats rather than using the palm pilot interface.

Recommendations to future developers

Performing an initial survey with potential users prior to design is highly recommended. Several of our users preferred paper and pen approach to our system; therefore, more insight into the working of the intended client is necessary to develop a successful system. Also, for the future research, the usability test should be done using an actual palm pilot or a hand held device with a stylus to simulate more realistic situation. Better use of margins and organization of buttons and information on more content oriented screens. Additionally, an implementation of screen movement (use of animation) that does not seem as abrupt when transitioning to and from each screen is needed to let the users know that they are not losing the content of the previous screen when going to the next screen. This can also be achieved using multiple windows or implementation of back and forward buttons similar to ones used for Web browsing.

ACKNOWLEDGEMENTS

Our group would like to thank Dr. Ben Shneiderman for his critics, encouragements, and time throughout the semester with our project. We would like to thank all our friends, classmates, and family members who participated in our usability tests and gave us feedback.

REFERENCES

Ameranth Wireless, Inc. -- http://www.ameranth.com/default.asp

Browning, D. J., Cain, G. M. , Gouldstone, F. G., McEntegart, J. The Interactive Process Scheduler Applications: Simplified User Interfaces Proceedings of the HCI'85 Conference on People and Computers: Designing the Interface 1985 p.230-238

Creed, Adam. “Voice Recognition System Takes Pizza Orders Down Under.” Newsbytes 24 Jan. 2002: pNWSB02024001

Dudman, Jane. “Going out for a quick byte.” Computer Weekly 11 Apr. 1996: 38

Nash, Kim S. “McDonald's Made For You program: Quieter, sometimes slower.” Computerworld 14 Dec. 1998: 24

Restaurant Computer Services -- http://handheldpos.com/

Rowe, Christopher J. Introducing a Sales Order Processing System: The Importance of Human, Organizational and Ergonomic Factors. Behaviour and Information Technology 1987 v.6 n.4 p.455-465