DOC PREVIEW
Berkeley COMPSCI 160 - Low-fi Prototyping and Usability Testing

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Low-fi Prototyping and Usability TestingIntroduction and Mission StatementResultsDiscussionFigure 1Group 1: WAITer (Waiter Assistant Information Technology)http://ratbert.bmrc.berkeley.edu/courseware/cs160/fall01/Projects/Group1/Andrei Boutyline (role: PDA Programming)Neetin Gulati (role: Testing)Ha Nguyen (role: Documentation)Randy Shoopman (role: Web Programming)Low-fi Prototyping and Usability TestingIntroduction and Mission StatementBrief Project Summary:WAITer (Waiter Assistant Information Technology) is a graphical application for PDAs that will increase the efficiency of the processes in the life cycle of a restaurant order, which begins with a server taking an order and ends when a customer pays for the bill. Our application will achieve this goal by automating specific tasks and providing real-time status of orders, a wireless messaging utility for efficient employee communication,and billing capabilities. Purpose and Rationale of Usability Testing:In the low-fi prototyping and usability testing phase of our project, our purpose is to evaluate the quality of our preliminary graphical interface, which we have modeled using paper cut-outs. To achieve our objective, we will select three restaurant servers to represent our target audience and have them each work through three tasks. These tasks have been carefully selected to be representative of our system functionality. By taking notes and encouraging our subjects to verbalize their thoughts, our team will be able to identify some of the weaknesses and strengths of our interface. At the conclusion of this project phase, we will be prepared to make interface improvements and eventually begin developing a hi-fidelity prototype. Project Mission Statement:Although the purpose of this project does not includedeveloping a fully-functional WAITer application, ourteam is dedicated to learning the skills involved indesigning a successful graphical user interface for thisapplication. In doing so, we acknowledge the value ofuser-feedback and are committed to integrating user-feedback in our design decisions. Prototype DescriptionPrototype Construction:Our paper prototype was designed usingprimarily note card stock in various colors (specifically,purple, blue, and red). We used the colors todistinguish between the three interview tasks, whichproved to be very helpful in making the ‘computer’ runFigure 2Figure 3Figure 4smoothly. We cut our screens so that they were the same size as standard PDA screens. The main screen is the exact size of the screen of the HP Jornada. It consists of the global toolbar and a clickable diagram ofall the tables in the restaurant (see figure 1). Since the global toolbar is standard, the other screens are overlaid over the table area of the main screen, reducing redundancy and improving the overall visual experiencesince less screen area is changed when navigating the prototype. Tables are an important top level object in WAITer. Many actions are preformed in the context of a specific table. Therefore the user needs to be constantly aware of which table they are operating on. In order to make this clear, each overlay screen has a transparent tab on the left which highlights the correct table on the global toolbar screen. This is illustrated on the Table Home screen (see figure 2) which has two vertical black marks on the transparent tab that overlay table 1 on the global toolbar thatshow the user that he is dealing with the first table. We used peel-away stacks of post-it notes forinput fields so that the user could write directly on theprototype without us having to erase the input anddamage the prototype. This also had the addedadvantage of making input fields easier to distinguishfrom the non-input areas. One such screen that uses thistechnique is the messenger screen (see figure 3), wherepost-its are used in the message entry area. Small message boxes, drop-down menus, andsome screen updates were also done using transparencyoverlays. We wrote the dialogs/values on small piecesof card stock which we taped to transparencies that canbe placed over the card stock screens. Thetransparencies helped keep these small card stock piecesformatted and lined up properly. For example, in the messaging system, when a user clicks “Send”, the system notifies the user with a green “Message Sent” box (see figure 4) that is implemented in this fashion. One last technique we used for one line updates was card stock attached to transparent fingers. Using the fingers we could fairly easily insert the correct values into the correct location on the screen. An example of one of our fingers is shown in figure 5. Also, some of our screens use text highlighting and blinking to alert or focus the users attention. This was achieved using a laser pen.Figure 5Figure 6Figure 7Architecture Considerations:WAITer is an application that is assumed to bepart of suite of applications for restaurant automation. Itis the server’s interface to the system. The full systemwould probably include interfaces for configuration, thekitchen/cooks, managers, bus boys/girls, host/hostess,and possibly even the customers. In order to limit the scope of this project, we have purposely focused our attention to only the waiter’s point of view. At the same time, though, we have considered the most likely interaction between the various systems and tried to design with that in mind. Another point is that WAITer should be considered a client application. It is assumed that there is a data server in the back of the restaurant somewhere or hostedoff-site that stores the real time data. For example, the menu is stored centrally on this server and is pulled overthe wireless network into the client PDAs. This assumption is reasonable, because storing redundant copies of the menu would lead to consistency and update problems, to say the least. So, in general, WAITer only provides the client interface to the data on the restaurant server. Prototype Function:The global toolbar (see figure 1) provides top level navigation and access to the most important areas of the application. The vertical part, from top to bottom, contains the current system time, a link back to the main screen (home icon), a link to the waiters personal information (person icon), a scrollable, clickable listing of the tables, and a backlink (left arrow icon). The horizontal part, from left to right (excludingthe left arrow),


View Full Document

Berkeley COMPSCI 160 - Low-fi Prototyping and Usability Testing

Documents in this Course
E-LEAGUE

E-LEAGUE

15 pages

iCurator

iCurator

10 pages

Project

Project

14 pages

E-Drink

E-Drink

10 pages

Load more
Download Low-fi Prototyping and Usability Testing
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Low-fi Prototyping and Usability Testing and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Low-fi Prototyping and Usability Testing 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?