The purpose of McInterface is to automate the ordering process in McDonald's. We achieve this goal by providing the following four main functions in our design.

Menu Selection
There are twelve food categories in the menu: New Tastes, Extra Value Meals 1-5, Extra Value Meals 6-11, Mini Meal Deals, Happy Meals and Toys, Burgers, Sandwiches, French Fries/McNuggets, Salads, Beverages, and Desserts. Users can choose to view a category by touching on the corresponding button in the red navigation bar on the left of the Menu screen (below). The individual items in that category will be displayed with their names, pictures, and prices (for an item with various sizes, only price of the medium size is shown).

Item Details Selection
Users can choose an item by touching on the "Order" button next to the picture of the item. A pop-up window, the Options screen, will allow customers to specify the details of the item, such as size, quantity, special requests, drinks, and toys.

Order Summary
The system provides users with immediate feedback of their orders through Order Summary. Each item selected by users will be listed in the Order Summary on the right of the Menu Page. Feedback on chosen special requests are shown as small icons next to the item. Users can change the details of the item later by touching on the "Edit" button, which will bring users back to the Options page mentioned above. In addition, customers can remove an item from Order Summary by touching on the "Remove" button. (See the first picture)

Payment Selection
After finishing the ordering process, users can touch on the "Pay" button to proceed, which brings them to the Payment screen. On this page, users can choose whether they want eat in or to go. Then, they can choose from one of these three payment options: ATM, credit card, and cash. Selecting a payment option will lead the users to the corresponding payment processing screen.

Interaction Flow

Below is the flowchart illustrating the interaction flow of McInterface.

What Left Unimplemented

The implementation of McInterface was constrained by some technical issues and by the scope of the project itself. In order for McInterface to be put in a real use, there are some parts of the design that need to be implemented.

1. Use of a touch-screen. We always use a mouse to simulate the 'touch' on the screen.
2. Versions in other languages. The Start page having three language options is only to illustrate how the design can accommodate several language options. We do not have our the interface in other languages.
3. Pictures of the food items. Although we tried to find food images that resembled the real menu items as possible, the current pictures still do not reflect actual images of McDonald's food items.
4. Payment process. We cannot simulate the physical actions and interactive feedback for the payment activities. For example, we could not give feedback about the validity of an ATM card's PIN number that the customers enter nor the validity of a credit card. We cannot simulate the process of inserting dollar bills. Therefore, on the payment screens, we assume that users will give cash to the machine, swipe the cards, get the appropriate feedback, and get the receipt after they finish ordering.
5. Use of graphical control components that work better with a touch-screen. As a result of using Microsoft Access to implement the prototype, we are constrained to using Windows graphical components, giving many limitations that affect our design. Currently, we use plain images for our buttons because we could not change the color of the gray Windows buttons. These buttons (except buttons on the red navigation bar) do not give feedback to a touch (They do not appear like they are being touched when they are touched)
6. We did not add more special request options as suggested by one of our test subjects. These options were "no mayonaise" and "no cheese".

Tools

In the low-fi prototyping stage, we used paper printouts to prototype the design. We used Visio to create the printouts so that we could print out several copies of the prototype.

For later stages, we used We used Microsoft Access and Visual Basic for Applications (VBA) to implement McInterface. We selected Access to be our prototyping tool for the following reasons:

• Two of our team members have some experience with Access and VBA before.
• We first thought that we were likely to use Visual Basic to build our prototype later in the design stage, and using VBA should give us a quick start on the prototype, which can then easily be migrated to a full-blown version. However, we later decided to not implement the prototype using Visual Basic code due to the time constraint.
• We thought that using a Database Management System as the tool can help us conveniently manage the content used in the system.

After using the tool, we think that Access is a reasonable tool to use in our project given our prior knowledge of the tool although it also has some limitations that reduce the effectiveness of our design. (If we did not know Access and VBA, it might have been more effective learning and using other tools to implement this prototype) These are the list of pros and cons of our prototyping tool.

Pros:

• We could store the menu information in a database, which saved us some time in creating the menu display pages.
• We could use the same form for different groups of food and accommodated the differences between the groups using VBA code.

Cons:

• We were limited to using Microsoft's built-in graphical components, which impose some limitations that affect our design. For example, we cannot make radio buttons or drop-down list boxes large enough for fingertips.
• Programming by VBA was very much contrained by the structure of the parent application. Microsoft Access is a Database Management System, and therefore, has a quite complex data structure. Some functionality might have been implemented much more easily coding from scratch.
• Using Database Management System sometimes did not give us enough flexibility. For example, using Access forms to display data from the database left little room for us to be creative in designing the form layout. By default, a continuous form can only display record vertically. We could not easily tile the display of the records and had to create two continuous forms in order to display food items in two columns.
• Storing information in a database seriously reduced the performance of the prototype. Displaying each screen of food items means a query to the database, which makes the prototype run very slowly. Also, an Access database file's size is very big.
• The above problem is worsen when coupled with our need of using graphical images in the prototype. We chose to leave the form that contains a lot of pictures (the Menu screen) open all the time in order to improve the speed of the prototype.
• Having an application-dependent prototype puts some burden on those who want to try our prototype. The prototype cannot run via a web interface, and there are quite a number of requirements and steps needed to run our prototype.