Sit Down to Eat!

Hemant Chakravarthi

Michael Raupp

mikeyg@wam.umd.edu

John Roop

jroop@wam.umd.edu

April 29, 2002

Abstract:

Sit Down to Eat! uses the power of the internet to provide restaurants with speedier customer service. Below is the summary of a semester long project at the University of Maryland at College Park. In this project, we invented Sit Down to Eat! and designed, developed, and tested an interface for it. The following is an explanation of our system, and a walkthrough of the process in which we took an idea, and made it a realization.

Credits:

Hemant, Michael……………………...(low-fidelity prototype designers)

John, Michael ………………………..(high-fidelity prototype designers)

Hemant, Michael, John……………… (programming and implementation)

John ………………………………….(lead technical writer)

Hemant, Michael…………………….. (technical writers)

1 Introduction

When you arrive at a restaurant, you often have to sit and wait for a table to become available, sit and wait for your server to take your order, and sit and wait for the food to arrive at your table. These waits can sum up to more than an hour on a busy night. No doubt you were hungry before you arrived at the restaurant. After an hour’s wait you must be famished – and irritable. Dining out should be a pleasant event, not a stressful one. Making a reservation is often beneficial in eliminating or limiting the wait for a table but you must still wait for your order to be taken and the food prepared. Wouldn’t it be preferable to reserve a table and order your food before you arrived at the restaurant – so when you arrive you are seated immediately and your food arrives only a few moments thereafter?

Such a system is not only possible but also practical. In many existing restaurants the servers place the customers’ orders into a computer that informs the kitchen what meals to prepare. This existing system can be modified and a new interface created that allows the customers to place their own orders, not just in the restaurant, but at home or even on the way to the restaurant. Central to this system is to create an Internet interface that allows to the customer to make reservations, peruse the menu, make selections, and place their order – all before entering the restaurant. We call our vision of such a system Sit Down to Eat!

Many restaurants allow customers to call ahead for reservations or to place carry out orders. Few combine these aspects to allow the customer to place a reservation and place their order. Sit Down to Eat! does this and more. Instead of placing one’s order with a server over the phone, Sit Down to Eat! allows the customers to make their selection over the Internet. This would not be limited to traditional home PC access but would also be available to portable computing devices with Internet access (e.g. web-enabled Palm Pilots).

Sit Down to Eat! should not be limited to being merely an electronic menu. The technology allows us to expand the information given to the diner. As an example, they can be provided with easy access to nutritional information about the available dishes. This would be especially useful for those diners with special dietary needs (e.g. diabetics). The system would allow the diner to make alterations to their selections just as they can with a regular server (e.g. replacing a side of broccoli with rice). This latter aspect would not be limited to those with dietary concerns, of course.

The benefits of this system grow as the diners become better acquainted with it. That is, the repeat customer will be able to make better use of it. We envision that Sit Down to Eat! can even keep previous orders stored so the customer can recall and repeat the same order that he or she found to their liking on a previous visit. Workers who are stepping out for lunch may find the extra minutes gained by preordering especially enjoyable. A return customer’s familiarity with the navigation and the options available will shorten the selection process on subsequent visits. Changes to the menu and specials of the day can be flagged and offered to the diner.

Preordering one’s food is not limited to those with Internet access. By placing terminals in the waiting area customers can peruse the menu and place orders while they are waiting for their tables. Some diners may be intimidated by the technology of Sit Down to Eat! and for them the traditional diner-server relationship is something they look forward to when dining out. The servers can be provided with handheld devices with which to access the menu items and place orders in a more conventional manner (at least from the customers’ vantage point). The servers’ interface can be more utilitarian since the servers will be trained in the use of the device.

1.1 System Requirements:

To improve upon an existing restaurant system, customers must be able to get their food more expediently. Our goal with designing Sit Down To Eat! is to shorten the amount of time between when a user chooses a restaurant, and when the user eats their food. A system such as Sit Down To Eat! will have some concrete must-include requirements, as well as some optional, fun extras for the user.

1.1.1 What Must Be Included

The Internet gains users everyday. After a user has made the choice to come to our restaurant, we want them to be able to access our menu. Having an interface via the Internet is important to the time saving aspect of Sit Down To Eat! Using the Internet, a user can go to the website of the restaurant and Sit Down To Eat! will take over from there. So Sit Down To Eat! must include a network server connected to the Internet that runs software allowing users to perform the functions and tasks listed in the previous section.

Not all users will be familiar with the Internet; furthermore not all users know what restaurant they want to eat at before leaving the house. Users may also change their minds when arriving at the restaurant. An important feature of Sit Down To Eat! will be terminals in the waiting area for customer use. These terminals will run the same interface as the one on the web site.

On the other side of the interface will be the restaurant staff, who play a critical role in the operation of Sit Down To Eat! There will be server/host terminals where the employees will put people on the waiting list. Five minutes before the customer’s table becomes available the order will be electronically submitted to the cooks. There will be grill line (the cooks and chefs) and kitchen preparation displays, where the cooks can view upcoming orders, as well as orders that have become active. The servers will also have access to terminals with an interface similar to the customer interface where they can add and subtract menu items from the bill as well as assist customers in ordering their food.

The web site and the terminals need to access a database that has a wide variety of information. Sample types of information on the database will be: customer information, menu information, waiting list information, waiting times, paid/unpaid orders, cooked/uncooked orders, and so forth. All the data will have subclasses of information, and all this information will be contained in a centralized database.

So far, the system has many pieces, but nothing tying it together. The glue for all the components of Sit Down To Eat! is a network. The restaurant, depending on the volume of customers, amount of staff, etc. will require one or more servers running Sit Down To Eat!

The basic design would include a high-speed network server that hosts a LAN (local area network) within the restaurant. This contains the database and processes transactions at the restaurant. The website may be hosted on an outside server that has access to the restaurant server, or can be hosted by a server in the restaurant.

1.1.2 What Should Be Included

A helpful and important piece of hardware is the touch-screen. Sticky fingers, bad typers, and people with poor muscle control, are only some of the reasons to have touch screen monitors at the restaurant’s terminals. A touch screen monitor is a computer monitor that is sensitive to the touch of a user’s finger. So a user can peruse the menu by touching the screen. Alternatives to touch screens are such interfaces as a keyboard/mouse, or possibly voice recognition. The most practical for Sit Down To Eat! is the touch screen, and probably should be included at every terminal outside of the kitchen.

Many network servers should be included in Sit Down To Eat! Speed is always a factor in any network. Therefore, a fast system will require multiple servers. An alternative to many servers could be a single server system or a central system, but the multiple-server method will be the most practical.

1.1.3 What Could Be Included

Relaxation, entertainment, excitement are just some of the things a user might enjoy when going out to dinner. Form follows function is something every designer keeps in mind, but having a few extras in the Sit Down To Eat! might make a return trip more likely for a customer.

o Provide additional terminals for customer use. Terminals in the bar would allow customers to order their food and place drink orders while watching the game.

o Each customer could get a pocket device from the hosts in the lobby to place their order on. This device would take the place of the terminal. Then after the customer’s order is placed, the device could provide news, games, etc. This would be a more expensive option of course.

o The Network in the restaurant could be wireless. Servers, hosts, and customers alike could walk around with small devices to perform functions on Sit Down To Eat! A wireless network would allow simpler infrastructure changes (e.g. if the lobby was remodeled) to be made. Although somewhat more expensive than a hardwired network, the cost savings in avoiding structural changes during installation may counter balance much of this cost. In addition, future changes to the system (e.g. adding more terminals, upgrading hardware) would be easier.

2 Presentation of Design

2.1 Design Overview

When designing Sit Down To Eat! our aim was to develop an application that has a web-like interface. Users would logon to our system via their home computer or terminals in the lobby of the restaurant. From there they could order their food. We wanted to adopt a design that would be easy to learn and use. By modeling our design on current internet forms our hope was that the interface would seem familiar and, thus, achieve our goal of ease of use.

We wanted the main screen to give the user as much information as possible without overloading their sense. We strived to make our design as intuitive as possible to avoid excessive help function use or the use of a lengthy tutorial. We also wanted a broad, shallow tree design, so that the user could navigate through the tasks quickly. We did not want the user to have to do more than they absolutely had to. Examination of other online menu systems made it clear that we should show the menu and a visualization of what the user has ordered (a.k.a. a shopping cart) on the main screen simultaneously.

We designed our interface so when a user visits it, they can begin selecting items and putting them in their shopping cart without entering any information about themselves. This idea appealed to us because the first thing we thought of when ordering online food, is what we want to order, not all the information we have to enter. So we decided it would be nice to offer users a choice to enter information at first or after they have ordered. This also allows someone to browse the menu and experiment with various order combinations without having to ‘sign up’ for the service.

Making form fill in as easy and painless as possible was our task. We used the guidelines of form fill-in (Shneiderman 264) for the design of our form. We did not want users to have to fill in information that they have already entered elsewhere. For example, after creating a new user profile (username and password), the user information is saved in a central user database and the new user is logged into the system. We felt that no user would bother to create an account unless they were going to attempt to do something. Thus, it behooved us to log them in automatically.

One of our goals was to retain previous orders so that a user can retrieve them in the future. We implemented a limited version of this feature in our prototype. While our intention is to allow users to maintain a number of previous order that they can ‘re-submit’ to the restaurant, our prototype limits this to a single order. By using their username and password, users can view their previous order and their reservation list. They can also modify these. Since persistence of this data required a username and password we included a facility to handle users who have forgotten these. The prototype facility is simplistic and certainly not security-minded, but it allows for future improvement.

The ability to make reservations is an important feature of our system. There are numerous examples of internet menus available. By combining the menu with the ability to make reservations we were offering users more functionality. The reservation interface proved more difficult than expected since it required that users had to enter more than one piece of data to complete the task. They have to indicate what day, what hour, and how many people the reservation is for. In an effort to streamline the process we arranged the fields so that the user would drop through them one after the other. We employed a click-able calendar for the data selection as we felt this was a familiar interface for the user. The date defaults to the current date and limits the user from selecting dates before the current date. Deciding on a default time was more difficult since restaurants can have different hours. We chose to adopt a single reasonable time but allowed for modification of this. The selection of number of seats uses a drop-down combo-box and defaults to a value of two seats. We felt that these settings were reasonable and we enabled users to confirm their reservations as they are made, just in case they missed a field. Canceling a reservation is extremely easy and requires that the user identify the reservation in their list and then select its unique number from another drop-down combo-box.

Space limitations on the main page kept us to providing abbreviated descriptions of the various items on the menu. Additional details are provided on the Food Item screen. This screen provides the user with nutritional information of the particular item selected as well as the ability to modify that item. Naturally, certain items do not need modification (e.g. drinks) and there are no options displayed for these items. Those items that can be modified will have their various potential modifications listed. Users can check the options that they wish by checking boxes on the screen. The Food Item screen can be used to order more than one item at a time, though they must share the same modifications. However, if a user wishes to have two items of the same type but different toppings, they still have to order them as separate items.

Once the user has prepared their order they can place that order with the restaurant. This process forced us to struggle with the issues of terminology and button placement on our main page. Although it may yet prove possible to implement the placing of the order on the main screen, we implemented our order placement facility as a separate screen. On this screen we sum the user’s order and calculate the total cost. The user is given the option of placing the order or returning to modify that order. At this point, the user also determines whether they are placing the order for carry-out or to eat in the restaurant.

The process of designing our interface proved to take immense care at each stage. From the creation of several low fidelity prototypes to the implementation of the final prototype we have found ourselves continuously honing our design. Although we have made great strides towards our goal we realized that our initial goals were beyond the limited time available and we were forced to refine the project. Although we pared out certain features, we continued to consider them in design decisions in an effort to maintain the flexibility to expand the functionality in the future.

Throughout the process of designing and implementing our prototype we have always strived to make using the interface easy for the user. We believe that we have created a system that quick to learn, easy to use, and visually appealing to the user.

2.2 Screen Transition Diagram

transition diagram

2.3 Screen Commentaries

2.3.1 Main Screen

final prototype main screen

The prototype was implemented using Visual Basic but our goal was to create an interface that resembles a web site. This is why the white background was selected. The only image that we added was a simple picture of a pizza. The program title to its left would most likely be replaced with the name of the restaurant employing the system.

The main page depicted above is designed to make a lot of information readily available to the customer. In the upper left corner, a simple text message indicates whether the user is currently logged in or not. This is useful for repeat customers who know that they must be logged in to order but do not always remember to log in right away. When they are logged in, this message changes to a simple ‘Hello, <username>’ text.

Below this is a small frame that lists the current wait time for a table if the customer were to walk into the restaurant at this moment. This feature assumes that the restaurant’s program maintains this value and can update this dynamically.

Below the wait time frame is a series of clickable text labels. Their color differs from the plain black text occurring elsewhere in an effort to emphasize that this text is clickable. This would be switched to clickable images on a true webpage – allowing modification of the color and font.

To the right of these labels is the menu. The menu is a simple list box that contains a brief description of the item and its price. The subtitle of the menu informs the user to double-click on an item to view the item or add it to the order. Although we feared that some users would struggle with this concept, the usability tests did not show this to be a problem.

The bottom half of the page contains the user’s current order and a series of buttons for handling the order. The choice of buttons instead of text was not deliberate. However, it does bring up the question of whether buttons are preferable to text labels for action initiation. Computer programs tend to use buttons while internet pages tend towards clickable text (even if these are actually images of text).

2.3.2 Login Screen

final prototype login screen In order to place an order or make a reservation the user must be logged into the system. The login screen shown at left allows the user to type their user name and password and then click the Login button. New users would click on the first text labels and those users who have forgotten their password or username can click on the second text field. In either case, a separate window opens to handle the action.

A common shortcut for navigating this kind of form is to allow the user to use the ‘Tab’ key to cycle through the fields that they need to fill so that their fingers do not have to leave the keyboard. We included this. In addition, after filling in the text fields, hitting the ‘Tab’ key again will move the control to the ‘Login’ button. Alternatively, the user can simply hit the ‘Enter’ key after filling in the text fields rather than actually clicking on the button.

2.3.3 New User Screen

final prototype new user screen The New User screen (left) is very simple and plain. This screen appears when a user has clicked on the ‘New Users Click’ on the Login Screen (see above). There is no differentiation between required and optional fields in this prototype. In a working version of this system, some fields may not be required and would have to be noted as such.

The layout of the buttons is unusual. It leads the user directly towards the ‘Create My Account’ button, which is the most likely action that a user would take on this screen. However, the arrangement of buttons as an ‘inverted T’ may be disconcerting to some users. This suspicion was not borne out in the usability study as no users made mention of this.

2.3.4 Forgot Password or Username Screen

final prototype forgot password screen With the numerous user identities that many internet users have it is common to forget one’s password or username on any given website. A forgotten password/username facility is imperative on any website that employs user-created unique identifiers.

This screen allows the user to enter their first name and last name to find their username and password. This is not a good choice for a secure key, but the system can be easily modified to create a special key in the creation of a user profile (e.g. favorite pet or mother’s maiden name).

If the user is found in system then their username and password are loaded into the Result fields and the user may click the ‘Log Me In’ button to log in. If a user remembers their password in the brief period between asking for help and this screen loading, they can click the ‘I Remembered’ button to close this facility.

2.3.5 Reservations Screen

final prototype reservations screen One of our goals was to allow a user to make an order and make a reservation on the same system. The handling of reservations is done through the screen at left. Reservations can be made or cancelled from this screen.

To make a reservation the user selects a date, time and the number of people in the party and then clicks the ‘Add Reservation’ button. A message box pops up to confirm the details before adding the reservation to the user’s reservation list.

To remove a reservation the user selects the number of the reservation from the combobox below the reservation list and then clicks the ‘Remove’ button. Although not yet implemented, the user should be able to select the reservation by clicking on it in the reservation list.

2.3.6 Food Item Screen

final prototype food item screen The food item screen is a very important part of Sit Down to Eat! This screen is opened when the user clicks on a menu item. It allows the user to view the nutritional information for a particular item and to add toppings to the item if appropriate. Multiple items can be selected by changing the quantity value at the bottom of the screen.

The nutritional information is loaded dynamically. That is, when a user adds or removes toppings, the information is updated to indicate the effect of the change. These effects are shown in the Nutritional Information box and in the totals listed below it.

The ‘Toppings’ frame only shows up for items that can have toppings. Thus, the user will not be given the option of adding sausage to their soda. Since this screen can appear when the user double-clicks an item in either the menu or order area of the main page, the back button will return the user to that screen. However, if this screen was loaded by clicking on an order item, the ‘Add To My Order’ button will not be visible to the user. A potential improvement would be to replace the ‘Add To..’ button with a ‘Remove From..’ button in this instance.

2.3.7 Place Order Screen

final prototype place order screen Once a user has completed their order they will place the order with the restaurant. This screen totals the price of the order and calculates the tax. The user has the option of modifying the order if they notice something that they wish to change.

The user can also select to place the order for eat-in or carry out.

2.4 Description of Help/Tutorial System

final prototype help screen - general

The screens above show two instances of the Help screen. The user clicks on the available help topics that are listed on the left hand side. The help text will show up on the right hand side. The default is the ‘General’ text (left). The screen on the right shows the help text displayed after clicking on the ‘Making or Canceling a Reservation’ text label. The prototype Help screen has a very limited amount of help available. Still, the usability tests implied that this was adequate. This can partly be attributed to the limited number of activities that are available, and more importantly, that a user would want to attempt on a restaurant website.

A number of screens have their own help functionality that uses Visual Basic message boxes to provide the help. This is not a good method as it lacks consistency, but we implemented the help in this manner out of expediency. A full implementation should lead all help to a single help screen. Any interim prototype should also be moving towards a goal of a central help system. This would make testing and updating the help system easier as well as enforce consistency across the system.

3 Report on Development Process

3.1 Low-Fidelity Prototype Refinement

The development of Sit Down To Eat! was a process of continuous change. Our initial design was very complicated and included thirteen separate screens. By selectively combining the functionality of these screens we were able to refine the original design and reduce the screen count to seven. In addition, by providing more information on each screen we were able to reduce the amount of switching between screens.

The evolution of the main menu screen was to combine the main menu screen with a series of other screens, to enable our interface to maintain a broad-shallow tree design. We wanted our users to be able to obtain as much information at once visually without burdening the user with a cluttered display. We realized that the menu did not have to be separate from the main screen. We were able to combine the current order and the menu onto the main screen by implementing each as a list from which the user could select items. We also found that a separate screen for displaying the current wait time was unnecessary as this was easily displayed in a small area on the main screen.

low fidelity prototype main screen low fidelity prototype current wait time low fidelity prototype menu

(four screens that were combined to make the main screen)

final prototype main screen combining features of above low fidelity screens

(main screen of latest prototype)

Displaying a list of items that the customer has added to their order was essential to the system. Having a virtual shopping cart (simply called ‘Your Order’) on the same screen as the menu seemed like a good idea. This allowed the user to simply glance between the displayed menu and order while adding items to their order. This gives the user a better impression of the size and content of their order than requiring them to examine their order on a separate form.

Refining the food-information screen was another big achievement for us. We were able to squeeze all three of the screens below into one form we called food-information. Each of these elements did not have to have it’s own screen.

We implemented a dynamic form, that, when the user selects a food item off of the menu on the main screen, the detailed information for it is displayed on this form. As the user modifies the food item, the nutritional information changes with each modification. Combining these three screens made a more compact and refined solution to the problem.

low fidelity prototype food item low fidelity prototype modify food item

(three screens that were combined to make the food-information form)

final prototype food information combining features of the three low fidelity prototype screens above

(Food Information Screen from final prototype)

We were not able to combine some screens with any others. We decided that the three screens below would have to be their own separate entities. The check out screen was modified slightly from this to include a list of what is on the customer’s order, but it was very similar to the screen below.

The new user screen was a form fill-in, we decided not to change this, because it was a necessary evil of any online ordering system. A restaurant could require more or less fields than the ones in our final implementation, but we included the most common fields that we found in our research.

The reservation screen was modified visually from this to include a clickable calendar, but the reservation form below sums up the information taken from the user. We omitted the ‘check current wait time’ link because the current wait time is obtainable from the main menu screen.

low fidelity prototype check out low fidelity prototype new user low fidelity prototype reservations

(three screens that were changed minimally)

Some screens we felt were either redundant, or perhaps unnecessary we intentionally left out of the final implementation. These screens to the left are examples of what we did not keep in our final implementation. The personal list, although we thought might be appealing to frequent users, we decided would be duplicating information that would be obtainable via the main screen. We also felt that most users would place a single order, rather than making multiple orders for multiple days. The place order screen seemed to be unnecessary because its functionality would be handled by the new main menu screen. So the place order screen became obsolete in our final implementation.

low fidelity prototype personal list low fidelity prototype place order

(obsolete screens)

3.2 Usability Testing

3.2.1 Observation Reports

We conducted usability tests on five users. Each user took a pre-test survey, a post-test survey, and was given four tasks to complete. The tasks we gave the users to do are as follows:

Task One:

Users are to order 2 pizzas.

Task Two:

Users are to make a reservation at the restaurant.

Task Three:

Users are to modify the 2 pizzas to pepperoni.

Task Four:

Users are to cancel all orders and reservations made.

Subject: Rebecca

Task One:

Most time was spent creating user account. Subject created user account before attempting to create or place order. When attempting to add item to an order, she initially single-clicked on the menu entry but quickly realized that a double-click was required.

Task Two:

Subject navigated steps quickly and easily.

Task Three:

Subject removed the cheese pizza and replaced with pepperoni pizzas quickly. When checking the calorie count of the pepperoni pizza, the subject clicked on an entry in the order area first. When this did not produce the desired information she clicked in the menu area, which produced the information. After acquiring this information, the subject hesitated, seemingly unsure of how to get rid of the food information form.

Task Four:

The subject performed the steps fluidly. Most clicks were confirmation clicks. We should endeavor to reduce the number of clicks related to feedback that doesn’t require confirmation.

Subject: Stephanie

Task One:

Subject started out by opening the reservation screen. While thinking aloud she said, “Do I need to make a reservation to place an order?” After debating this for a bit, she decided she did not. The adding of items to the menu went quick with the subject. She flew through the food Information screen. The subject did not find the place order button quickly, she had a lot of trouble placing the order. After some thinking, the subject clicked on the checkout button.

Task Two:

Subject went very quickly through this task.

Task Three:

The subject cleared the order before she retrieved it. Maybe we could have the order load upon the user logging in. Again the subject complained there was no Place Order button. This task took the subject a great deal of time, because she could not bring up her old order successfully.

Task Four:

The subject was able to cancel the reservation well. Again the subject struggled with the cancel order operation. It said she did not have a previous order. Then she clicked on cancel order again, and it said order cancelled without ever showing the order on the screen.

Comments:

Subject found it kind of unclear that you don’t know how to log in at first. Subject found it annoying that you have to go to checkout to place order. Subject found that cancel order doesn’t always remove it from the screen.

Subject: Greg

Task One:

Subject logged in first thing. Subject completed the subtasks quickly, but did not understand how to place order. After some thinking, the subject clicked on the checkout button. Subject was confused when a null value appeared in the goodbye user screen.

Task Two:

Subject wanted to hit the enter key after logging in, but it had no function. Subject then made a reservation 5 years from the current date.

Task Three:

Subject was confused about how to retrieve and order. Subject was also confused about how to delete the pizzas.

Task Four:

Subject completed this task quickly.

Comments:

The main thing missing from this restaurant interface is a place order button on the bottom right of the screen. The lack of this button causes intense user frustration as they frantically try to figure out a way to place an order.

Subject: Chandra

Task One:

Subject entered info at log in screen before creating an account. Then she clicked on ‘forgot password’ and then ‘create new user.’

Task Two:

Subject entered wrong username. She didn’t have problem making a reservation.

Task Three:

Subject did not delete the cheese pizzas. She did not check out after ordering pizzas.

Task Four:

Subject made another reservation. After canceling reservation, didn’t know that it was cancelled. Subject logged out. Logged in again to delete pizzas. However, the list was empty since she failed to checkout her order in Task Three.

Subject: Jacob

Task One:

Subject entered username and password at log in screen before creating an account. This happened three times before he was told to create an account. Subject checked nutritional info. Back at the main screen, subject got info of all buttons. He figured out that he had to check out before logging out.

Task Two:

Subject entered wrong username. Clicked on ‘forgot password’ to log in. Took time to get info on all buttons at the reservation screen.

Task Three:

Subject entered wrong username again. He said he had entered the right info. After removing pizzas, subject ordered one pepperoni pizza. He had to go back and order another one.

Task Four:

Subject was able to log in. After canceling orders, he clicked on check out to place order for coke.

3.2.2 Data collected from usability tests

Table 1. User pre-test Survey statistics:

user pre-test survey statistics

Table 2. User post-test Survey statistics:

user post-test survey statistics

Table 3. User Statistics:

observed userstatistics

3.3 Identified Problems After Usability Testing

A number of programming bugs came to light during the usability testing for Sit Down to Eat! While it was important to repair these, that was not the purpose of the testing procedure. We identified a number of usability problems that need to be addressed. The list of problems that follows combined bugs and usability problems and assigned two scores to each. The list was in no particular order. The first score was the importance of repairing the problem, and the second score represented the relative amount of time we believed it would take to undertake the repairs.

Perhaps the most important problem was item 1. The choice of the text ‘Check Out’ did not make sense in our system, since the process of checking out generally referred to finalizing payment rather than an order. In addition, the positioning of the ‘Check Out’ option away from other buttons did not make sense. A change in terminology was necessary as well as a reorganization of the screen that placed this button in a logical place. The reorganization of the screen was of primary importance. The post-test surveys indicated poor to middling scores for logical arrangement of data on screen.

While we were trying to emulate a web interface, our project was built in Visual Basic. This caused some problems on how to lay out the screen. The use of list boxes, rather than HTML text, limited the visual representation. Also, Visual Basic’s lack of a scrollable form limited us to a form that fit on the screen. This led us to create a form that kept getting larger and wider.

Our usability studies did not show users complaining about redundant feedback but during the process it was noticeable that some dialogs were not necessary since the feedback was displayed on the form itself. This is not the case in all situations. A careful review of the dialog boxes that arose was in order.

Another important problem that had to be addressed, was, that the general procedure for ordering was not spelled out on the main form. Although it is available through the help functionality, we believed that the users would be able to navigate the website with ease if they are given clues to the operation. In general, users did not make great use of help screens and preferred to ‘feel’ their way around the product trying to figure out how to do things themselves. If we could build the help into screens themselves, the procedures would become self-evident.

(ranked on a scale of 1 to 5 for importance and time-consumption)

1) How an order is placed is not clear to all users. Some did not realize that they must click on ‘Check Out’ to place the order. Others found it frustrating that the ‘Check Out’ button was not with the other buttons on the right hand side of the screen. (5/2)

2) The ‘Cancel Order’ button does not always remove the order from the screen. Why? (4/2)

3) Sometimes when logging out, the logout confirmation message box lists the user name as ‘null’. Why? (3/2)

4) One user wanted to be able to simply hit the ‘enter’ key after filling in the login fields to log in. (1/2)

5) Upon logging in, the previous order should automatically be loaded. This could alleviate the need for a ‘retrieve order’ button, thus simplifying the interface. (4/1)

6) Calorie count for an item should have a total. (3/5)

7) The interface is very plain. (5/5)

8) Make all ‘click-able’ text boldface or another color. Some users hesitated before identifying ‘click-able’ text. (4/3)

9) Make order entries ‘click-able’ in the same fashion as menu-items. This will make the order easier to modify and allow the user to get item information from either list. (3/3)

10) Eliminate redundant feedback to user. For example, the confirmation of making a reservation via a message box is unnecessary since the item shows up in the reservation list. (3/2)

11) Users cannot always remember if they have logged in. Place a label somewhere that indicates if a user is logged in and, if so, who they are logged in as (see 10). (3/3)

12) Date field on reservations form should default to the current system date. Time field should default to a reasonable time (e.g. 8pm)?? (4/4)

13) When an order is cancelled, the order list should be cleared. (5/2)

14) Illuminate the procedure for placing an order. Give user a change to place order when logging out (if they have not already placed the order). (5/4)

15) Reduce font size in list boxes. (4/1)

16) Make items in order list have toppings shown. (5/1)

4 Conclusions

4.1 Status of Final Design

The final status of Sit Down to Eat! is a web-like interface implemented in Visual Basic 6.0. This interface allows users to engage in a simulation of what using Sit Down to Eat! would be like if it was used by a pizza restaurant with a very limited menu. We were able to trim most of the rough edges off of our initial design, but the interface will change depending on what type of restaurant uses it.

4.2 Future Work Possibilities

To be marketable, our system will need to be adaptable to any restaurant anywhere. Doing this will entail primarily database accessibility. Our system will require the ability to adapt to an ever-changing menu and user population.

When a company purchases Sit Down to Eat! they will have to have the ability to customize our system to their restaurants needs. So another interface for Sit Down to Eat! will be the system maintenance interface. This will include database setup modification and maintenance.

The current system does not allow users to place an order for a reservation. The idea of attaching an order to the reservation could benefit consumers as well as the restaurant. Consumers could plan business lunches and take some of the hassle out of what to order and where to go. Restaurants might find this helpful for big parties because they could know how much food to order in advance.

The nutritional information currently available is limited. Our system could leave this customizable to the restaurant. This way, the restaurant can show as little or as much food information as they wish. For example, if a restaurant serves very fatty foods, they may wish to leave the fat content out. Restaurants could choose to display the ingredients of certain dishes if they wished, as well as pictures of the food items they serve.

4.3 Recommendations to Future Developers

Future developers interested in furthering the development of Sit Down to Eat! can take notice of the future work possibilities listed above. The hardware requirements and system setup of Sit Down to Eat! could look something like what we have below:

· Server with SCI with a RAID operating no less than 8 160 Gig hard drives

· On the server we recommend running Apache or Tomcat

· We recommend for the database running the latest version of Oracle

· The in-restaurant LAN should also be connected to the server

· For the LAN terminals, we recommend economy PCs and touchscreens

The software side of Sit Down to Eat! could be developed in any language, but we recommend an Oracle friendly language such as C, C++, or Java. We recommend making the restaurant side operations extremely flexible and customizable to allow virtually any restaurant the utility of Sit Down to Eat!

5 Acknowledgements

We would like to thank the participants of our usability tests: Greg Hess, Stephanie Wagner, Chandra and Jacob Chakravarthi, and Rebecca Cowell. We would also like to thank Ben Shneiderman for his teaching in the classroom and his mentoring on this project evolution.

6 References

6.1 Pizza Delivery Rivals

Domino’s

http://www.dominos.com/default.cfm (2002).

Papa John’s

http://www.papajohns.com/ (2002).

Pizza Hut

http://www.pizzahut.com/ (2002).