Grupo Naidy Final Post

Group Name: Grupo Naidy

Group Number: 1

Group Members: Kuni Nagakura, Avneesh Sarwate, John Subosits, Joe Turchiano, Yaared Al-Mehairi

Project Summary: Our project is a serv­ing sys­tem for restau­rants, called Ser­vice­Center, that allows wait­ers to effi­ciently man­age orders and tasks by dis­play­ing infor­ma­tion about their tables.

All Previous Posts:








Our System :

Meet Joe. He’s a server at a restaurant, who takes orders from patrons. Using ServiceCenter, he can input orders into the system and can check cup statuses at his tables. When orders are ready, the members of the kitchen staff indicate that the orders need to be delivered. Joe must deliver orders to the table when they turn red on the motherboard.

Written Explanation:

Our prototype in the video above consists of a set of pressure-sensing coasters, a laptop, an HDMI cable, and a projector. Our pressure-sensing coasters are made out of plexiglass and aluminum sheets with FSRs attached, all hooked up to an arduino. The laptop is the central part of our system–it acts as both an interface for order input and a data collector for the Motherboard. We communicate data from the coasters (level of drinks) to the central part of our system via py.serial (creating a channel between the arduino and laptop) and OSC (for interdevice communication). We communicate the order inputs to the central part of our system via wifi to better simulate the interaction between the order device and central part of our system (i.e., we send information input to the laptop back to its online self because in the final prototype we envision having two pieces of hardware).  We communicate order status to the central part of our system similarly via wifi for identical reasons – order status is updated by the kitchen staff when an order is done and ready to be served. We communicate all table information from the laptop to the projector via HDMI cable. The projector, our Motherboard, displays a restaurant layout divided into sections and tables. Each table is a visual model that tells information about the levels of drinks and status of orders. The Motherboard centralizes any information required by a server and displays it in an intuitive format. Therefore servers need not worry about management of tasks, and only about completion of tasks, thus streamlining the service process.


Changes Since P6:

  • Include table number in Motherboard – This acts as a unique ID so all servers know which tables to looks at on the visual display when completing tasks.
  • Change colors to better reflect statuses and keep things consistent – Red alerts the server that a task needs attention immediately; yellow suggests that a task will require attention soon; green tells the server that a task does not require attention (it is less confusing to have the color coding be consistent across kinds of tasks).
  • Remove help button – We found in testing that the help button was not actually so useful; in particular, test users felt that in times of real need, verbal communication would be the easiest and most efficient means of server communication.
  • Turn input interface into a button + text box instead of just text box – Before, we had servers type in an order and command, but it is easier and more intuitive for a server to type in an order and just press a button (which simulates the effect of typing in the command)

 Evolution of goals:

Over the course of the semester the design and goals of our system has evolved and changed to a certain degree. In our initial brainstorming sessions, we first approached the problem as improving the experience of customers waiting for refills at bars/restaurants. However, as we began the design process, we quickly shifted towards aiding the actual servers in the restaurants (and through them, the customers). At first, we wanted our ServiceCenter system to consist of many different hardware devices. We wanted to have touch screen interfaces for both the servers to input orders and the kitchen staff to update order statuses that talked to a central computer feeding our Motherboard (just a large screen) table information to display. Early into the design, we realized that rather than worrying about obtaining the necessary hardware for such a plan, it would make much more sense to simulate the communication between these various hardware devices on as little hardware as possible, so as to ensure the functionality of our system (so that we could test the right aspects), but also at the same time guarantee the possible future step of bringing in newer and slicker hardware devices (which is easier with a working prototype).

Furthermore, initially we had planned for servers to have access to a simple ServiceCenter mobile app. The mobile app would allow logged-in servers to request help from other servers on the team at the click of a button. This would then appear as a universal notification on the Motherboard, alerting servers in the waiting area of their colleague’s request. This app we hoped would help servers at peak hours when work becomes more high-stressed due to the number of tasks to manage and complete. What we found in our testing was that in times of high stress like these, servers typically prefer to verbally communicate and pass messages along through colleagues. When asked, test users felt it was both inefficient and unnatural to ask for help using this app. One thing we may say is given that our tests were conducted in environments only similar to restaurants like dining halls/eating clubs, but not in actual eatery businesses, it could be the case that in real, busy restaurants an app to call for assistance could be useful. However, another thing to note is that in our field research, it was made clear to us that it is not necessarily appealing to customers to see their waiters using cellphones while serving them. So, this was another point we took into consideration. Thus, what began as a project to improve customer experience quickly changed into a system that helps servers/kitchen staff manage their tasks. As our project evolved, we decided to cut out certain features that we had originally thought would be useful, but upon testing found to be unnecessary.


Critical Evaluation of Project: 

The interface could certainly be made to be cleaner and easier to initialize. Currently, tables are positioned through center coordinates — a GUI that would let users set up their own table configuration. We also want to design a better way to sense the cup levels, since many restaurants don’t use coasters. However, in implementing and testing the basic functionality of our idea (a motherboard that conveys the status of orders and cups and an input system that lets you enter your table’s orders), we feel that with further refinement, it is very likely that this system would be useful in the real world.   Our usability testing and the feedback we received from it as well as the responses we have received when describing the project in casual conversation both indicate that people think that this system could improve the restaurant experience.

Our system was designed to address concerns and difficulties elicited during contextual interviews from people who work as servers in restaurants.  All three of our usability testers believed that they could complete their jobs with this new system more effectively than traditional ordering methods given that they had time to practice with it.  The tester who pointed out the most shortcomings to be improved, ended his review with “Great idea and beginning though! My dad owns a restaurant and his employees often are not highly skilled/trained and could benefit greatly from a system like this.” Upon hearing a description of the system, a friend remarked “So, it keeps waiters from coming over to your table and interrupting your meal.” Another colleague responded, “That’s pretty neat.  I could actually see that being used.”  While it is more difficult to predict profitability or how widely adopted the technology would be, it seems likely this system would be useful to some, if not many, restaurants.

We have learned a little bit about the application space of assistance hardware and software for restaurants.  Servers that we talked to said that the tasks that must be done as a waiter are not particularly difficult.  However, during busy rush times, the workload can become overwhelming.  In addition, prioritizing the different tasks that need to be accomplished can be difficult although this gets easier with experience.  Our system aims to mitigate this by presenting all the relevant information in one place.  While errors in delivering orders are rare, they do occur and can be bad for customer satisfaction, so our system helps to reduce their occurrence by making communication between servers and cooks permanent and reminding servers which table ordered each dish.  We also learned that the existing software for restaurants are clunky to use and have outdated appearances.  Potentially there is an opportunity for someone to improve the quality of available products by taking advantage of relatively inexpensive widely used technology such as the iPad instead of using lower resolution, proprietary displays.


Future Steps: 

There is plenty of room for improvement from the current version of our system. First, the display screen could be made more customizable. Currently it is possible to draw rectangular tables of any size in any place on the screen, but the way to do so is through directly programming the client to the display screen’s code. The display screen could be updated into an interactive GUI that allows for the creation of new tables of any shape, with the ability to drag them to any place on the screen.

The interface used for adding and deleting orders (on the server side) and updating orders (on the kitchen side) could also be improved. Currently all functionality is in place, but we might want to make it look more sleek and user-friendly. In addition, it only supports the three standard tables at the moment, but it could be easily updated to have a variable amount of tables.

Finally the actual hardware (and its casing) could be improved. The fidelity of the sensors are actually pretty reliable – and flexible according to the weight and size of the glass. The “coasters” that they fit in could be made to look as if they actually belong in a restaurant, though, and there may be some waterproofing issues that would need to be addressed for an object whose purpose is seemingly to keep the table from getting wet. Eventually we might want to replace the Arduino altogether with a dedicated device specifically made for the coasters; this would also presumably make it more compact.

We were also unable to test in the most ideal environment for our system–an actual restaurant. Based on our testing procedures, it seemed that the help button was not particularly useful to our users–we noticed that most people relied on verbal communication if they wanted assistance of any sort. If verbal communication is, indeed, sufficient for help requests even in a larger restaurant setting, then the help button unnecessary. Furthermore, having servers pull out a cell phone to call for help may not be the most ideal form of customer service–patrons are more used to verbal communication/signaling between servers. Thus, testing in a real restaurant environment would definitely help us further assess our design and functionality.

A Zip file of All Source Code is here.

Third Party Code:

  • PyGame–All of our graphics for the Motherboard were rendered using PyGame, an open source python videogame library:
  •  Portions of Kuni’s Fall Independent Work Code were used on top of PyGame to make the rendering process easier.
  •  WxPython: Used to render the input system:
  • pyOSC: Used to communicate between python modules:
  • Arduino: Arduinos and FSRs were used for the hardware:
  • pySerial–used to communicate between the Arduino and the python modules:

Printed Materials for Demo Session:

Here is our Poster.

P6 Grupo Naidy

Group Number: 1

Group Members: Kuni Nagakura, Avneesh Sarwate, John Subosits, Joe Turchiano, Yaared Al-Mehairi

Project Summary: Our project is a serv­ing sys­tem for restau­rants, called Ser­vice­Center, that allows wait­ers to effi­ciently man­age orders and tasks by dis­play­ing infor­ma­tion about their tables.


Here, we describe the methods and rationale behind a user study geared to aid us in the design of our serving system. The goal of our system is to present  pertinent information to servers in restaurants that allow them to task manage more efficiently. The prototype being evaluated is a single laptop connected to a display projector, which serves as the motherboard. The laptop acts as both an order input interface for the servers and a kitchen-side order status interface for the kitchen staff (this task  was performed by a group member). We chose to use a laptop as the basis of our hardware because the primary purpose of our testing was for functionality and usability, and any interaction with a device in our system is a mouse-screen interaction, which a laptop provides well. Furthermore, the laptop allowed us to display customer information on a large screen, which is how we envision our motherboard should look like in our final design. As we have discussed, the purpose of our user testing was to gain insight in future design improvements. This being the case, our user study consisted of three tasks, ranging from easy to hard that covered the main actions that a server would perform  using our system, described in the sections below.

Implementation and Improvements:

Our P5 post can be found here:

We do not have any new changes to our implementation, as we were preparing for P6.


The participants in our research and testing were all members of the university community. They were selected purely on a volunteer basis without any specific requirements; we did give them a quick demographic survey in order to gain a deeper perspective on who we were working with and how they would relate to our target audience. All of our test subjects were familiar with computers and used them regularly; one of our test subjects had some prior experience working at a restaurant. Overall, we found our participants to be related only tangentially to the target user group, but since the primary purpose of our testing was for functionality and the tasks were relatively simple, we found this was sufficient. In particular, we had one user who had experience in the service industry–his post-testing interviews were incredibly helpful. Otherwise, our subjects did not have waiting experience.


The testing was conducted in the dining room of one of Princeton’s eating clubs, at times when meals were not being served. We found this setting to be ideal, since it nearly replicated the environment of a restaurant and provided the necessary equipment (plates, glasses, a pitcher) without having to impose on any third party. A laptop computer was used to run the prototype system, and it was connected to a projector to show the order display on a large, highly visible screen – more or less how we imagine the final product to be used. The computer ran both the order display interface, into which the test subject entered new orders, as well as the “kitchen staff” interface, which was used to update the orders. The kitchen interface’s data was sent over a simulated wireless connection to better replicated intended use circumstances.


In our work­ing pro­to­type, we have cho­sen to sup­port an easy, medium, and hard task. For the easy task, users are sim­ply asked to request help if they ever feel over­whelmed or need any assis­tance. This task is impor­tant to our sys­tem, because one of our func­tion­al­i­ties is the abil­ity to request assis­tance from wait­ers who may have a minute to spare and are watch­ing the motherboard.

For our medium task, we ask users to input order infor­ma­tion into the sys­tem for their table. Once users input orders, the moth­er­board will be pop­u­lated with orders and the kitchen will also be noti­fied of the orders. This is a medium task since this is sim­ply inputting information.

Finally, for our hard task, we ask our users to uti­lize cus­tomer sta­tuses (ie. cup sta­tuses, food orders) to deter­min­ing task orders. This task cov­ers both ensur­ing that cups are always full and that the pre­pared food is not left out for too long. The motherboard’s main func­tion­al­ity is to gather all this infor­ma­tion in an easy to read man­ner, allow­ing wait­ers to sim­ply glance at the cus­tomer sta­tus to deter­mine what order they should do things.


The testing procedure was designed to place the test subject in as accurate a simulated restaurant environment as was possible.  The tasks that can be accomplished with the system were required to be performed interspersed with each other, as they would be in a real restaurant, rather than completely divorced from each other.  Three of the group members sat at different tables and each played the part of 3 to 4 customers.  The tester acted as the waiter for about 15 minutes while the customers ordered a standard, prescribed combination of appetizers, entrees, and deserts.  The tester was responsible for entering the orders into the system and for bringing the “food” (actually paper labels) to the table after it had been prepared and plated.  Each dish took a specific length of time before it was ready.  Periodically, generally about twice a test, the tester would have to fill the water glasses at each table since the motherboard indicated that they were empty.  Participants generally did a good job of announcing both what they were doing, ex. “I am refilling the water glasses,” and what they were thinking, ex. “It’s confusing that red means the water glasses need to be refilled but that the food isn’t ready yet, so I don’t have to do anything.”

Test Measures: 

“Turn around time’” – time between dish being put out by kitchen and being delivered. This was measured by hand – electronic measurements were dependent on users correctly using the system, making the metric interdependent on other variable factors (discussed later)

Post-Test ratings by users (Self reported Likert scale 1-5. The results of these questionnaires are provided in the Appendix):

  • “Recoverability” – Whether the system made it easy to recover from mistakes. We felt that this was important because in a system where “online” decisions are being made, the system must be especially robust to user error.
  • “Easiness to Learn” – Since this system would be deployed in existing restaurants, the restaurants would want to minimize the time that users (waiters) would take to adapt to the new system and start working at their maximum efficiency. Thus, we felt this an important metric to measure.

Results and Discussion: 

Testers had some trouble interpreting the graphical display on the motherboard.  In particular, they suggested that the color coding of various events could be made more intuitive and that the presence of empty water glasses could be indicated in a more obvious way than the number of full or half-empty ones.  Basically, the display of things that need to be urgently addressed should grab the user’s attention and colors should be consistent. If red is to indicate attention for cups, it should not indicate “not ready” (and thus requiring no attention) for orders.  Perhaps in the future, the red circle that contains the number of empty water glasses can be made to flash.  On the bright side, users seemed to have a fairly easy time entering orders into the terminal for the kitchen to prepare. One thing that we were interested in seeing was whether or not order input would be a hinderance to servers.

Overall, the testers were fairly efficient in the use of the system. We had wanted to put a “heavy load” on the testers to see how they would respond to a lot of activity, and we did this by scheduling what we thought was a high number of orders (9 “orders” comprising of about 25 dishes) over the course of 10-12 minutes. The average “turn around time” of the users was quite low. We decided to split the data into instances where the waiter was in the “kitchen” area when the dish came out and when the waiter was not. Unsurprisingly, when the waiter was around, the average turn around time was negligible. When the user was not in the kitchen, the average across users was about 30 seconds per order.

However, we realized after the fact that we did not have a “control set” of  turnover times, which would ideally be turnover times from waiters working in a real restaurant environment. We noticed that waiters had the most trouble when sets of orders from different tables came out at the same time, and in a real restaurant setting, there could be more tables, and thus more of these challenging situations. Our setup used only 3 “tables” of guests placing orders, but it may have been more accurate to have a larger number of tables placing orders with a lower frequency. We also noticed that none of the users decided to call for help in this trial. This is most likely because we used paper plates during the trial, which allowed users to pick up as many plates as needed when delivering orders. The physical space we were using to test was also quite small, allowing users to move back and forth between patrons and the “kitchen” very quickly, allowing them to deliver a large amount of plates quickly without too much delay. Since this system is meant to help with actions whose durations are very short, environmental influence on action time can be proportionally very significant, and care must be taken to recreate an accurate environment to get meaningful data.

Users seemed to figure out very quickly how to enter the data into the interface for a new order, and by the time they were entering their second or third full order they had become quite efficient with the system. However, we noticed that several test subjects seemed to forget about the requirement to delete the orders after they were ready and delivered. Since there are a limited amount of order slots for each table, any order input on a full table would not go through. This resulted in at least one mistake where an order was lost in translation from paper to prototype when the user did not look up at the screen immediately to check that the data had been entered successfully. We have also considered making the ready orders disappear automatically to avoid this problem, but this raises the additional problem of the system needing to know when the plate has been taken out. In this case, at the very least a warning to tell the user that a table is full of orders would be a good addition to the prototype.


All surveys, forms, and scripts are located in this dropbox folder. All the collected raw data is also located in this folder.

P5 Grupo Naidy

Group Number: 1

Group Members:

Avneesh Sarwate, John Subosits, Yaared Al-Mehairi, Joe Turchiano, Kuni Nagakura

Project Summary:

Our project is a serving system for restaurants, called Ser­vice­Center, that allows wait­ers to effi­ciently man­age orders and tasks by displaying information about their tables.

Description of tasks we chose to support:

In our working prototype, we have chosen to support an easy, medium, and hard task. For the easy task, users are simply asked to request help if they ever feel overwhelmed or need any assistance. This task is important to our system, because one of our functionalities is the ability to request assistance from waiters who may have a minute to spare and are watching the motherboard.

For our medium task, we ask users to input order information into the system for their table. Once users input orders, the motherboard will be populated with orders and the kitchen will also be notified of the orders. This is a medium task since this is simply inputting information.

Finally, for our hard task, we ask our users to utilize customer statuses (ie. cup statuses, food orders) to determining task orders. This task covers both ensuring that cups are always full and that the prepared food is not left out for too long. The motherboard’s main functionality is to gather all this information in an easy to read manner, allowing waiters to simply glance at the customer status to determine what order they should do things.

How our tasks have changed since P3 and P4:

We didn’t end up changing our tasks too much, since we thought it covered the functionality of the system pretty well. Based on user testing, testing, our easy task was performed as needed, and our other two tasks were performed regularly throughout the testing process. We decided to combine the medium and hard task into a hard task and add a new task that requires users to input customer orders into the system. This last task was added so that we could test the full functionality of our system. We also didn’t test the input interface in P4, so we really wanted to add this as a new task.

Discussion of revised Interface Design:

Initially, we had designated a dedicated person to take the order-slips of the waiters and then input them into the system. However, during our paper-prototype test, we saw that this designated inputter was by far the slowest element of the system. We decided, then, that it may be easier to have the waiters enter their own orders. Even though there is a lag involved in typing out items twice, there could be more of a lag if a single person manning the input screens becomes overwhelmed, as then that worker could make mistakes that lead to errors that cause problems for other waiters. By having each waiter responsible for their own input, we could reduce the volatility of our system.

Our initial design for the order-input interface was fairly involved, and displayed the restaurant menu as a clickable menu with a list and checkboxes, but after seeing how long basic tasks took on the paper prototype, we thought we should strip down to make it more efficient. We decided, for the purposes of this prototype, to have a simple text entry box and button for each table. Having a physical menu next to the entry station could also save screen space, and allow the input interface to be displayable on much smaller screens (cheap tablets, old portable TVs, smartphones). We decided to move to a typing interface because we had a very minimal amount of information that needed entering, and typing seemed faster for this limited interaction.

Easy Task 

Medium Task

Hard Task

Overview and Discussion of New Prototype 

The table-end side of the system has been fairly extensively prototyped although the interface between it and the rest of the system has not been implemented.  The current system for each restaurant table consists of three coasters for the patrons’ drinks which incorporate FSR’s to estimate the fullness of the glass based on its weight.  The coasters were manufactured from clear Plexiglas.  An Arduino monitors the sensors on the table and sends their states to a laptop computer via a serial connection.  The status of each of the glasses then prints to a serial monitor window on the laptop.  For the purpose of this prototype, a wizard-of-oz technique used a person at this computer communicating via a chat application with another person at the computer controlling the motherboard which displays the status of the various tables.  The wireless communication between the Arduino and the motherboard via a laptop was not implemented for this prototype because of the ease with which wizard-of-oz techniques could be used to simulate it and the relative difficulty of this part of the project.  The code for monitoring the FSR’s with the Arduino was loosely based on the Adafruit FSR tutorial code, available at, although the code was used primarily as inspiration.  Little was retained from the code expect the variable names and setup routine.

We implemented the changes to the interface design for the order input system. The minimal language that the users would enter into the box of each table would be “DishName Command.”  DishName could be any string (so users could use their own shorthand), while Command would be either “add,” “done,” or “del.” Add would add the item to the list for that table, done would mark that item as delivered, and delete would delete them from the order list. Pressing the button would “send” the information to the motherboard.

We chose to implement the Motherboard (the actual display screen for the app) using Python, with the Pygame module and a “Standard Draw”-like module included for ease of creating the actual screen. We chose Python since it is a simple, easy-to-use and debug language which fully supports object-oriented programming. Each “Table” on the screen is implemented as an object, which contains a variable number of “Order” objects and a single “Cup Display” object (which displays the current number of empty, medium, and full cups). We deemed it important to implement these objects to allow for modularity in the display screen to adjust to different restaurant floor plans. With the current implementation, it is possible (and fairly simple) to draw a rectangular table of any size at any position on the screen along with all of the table status features. In the final implementation, we plan to include support for circular tables as well. The screen updates itself whenever it receives new information to display it in real time.

We decided to leave out implementing the communication between different parts in our working prototype. Our system currently is made up of independent components with a set API. We have defined an API for each system so that cup statuses and order inputs/statuses can be easily changed through these functions once the communication channel has been implemented. In testing our prototype, we will use a Wizard of Oz technique for the communication between devices, and have our group members relay the information from each sytem. We chose this functionality to leave out of the working prototype, because we wanted to focus primarily on the layout of the motherboard and input system, and the functionality of our coasters. The help button is still a paper prototype, since in our ultimate system, this will simply be a button that alerts the motherboard. We decided that having a paper prototype and an observer to keep track of when the button is pressed (an easy task as P4 showed) were enough for user testing.

The Motherboard section used the Pygame module for Python. Apart from this, all code was written by Kuni Nagakura and Joe Turchiano.

A Plexiglas coaster with protective covering still in place showing temporary FSR attachment.

A Plexiglas coaster with protective covering still in place showing temporary FSR attachment.

Circuitry showing three inputs and 10K resistors.

Circuitry showing three inputs and 10K resistors.

Simple Order Input Interface

Simple Order Input Interface


Screenshot of Motherboard

Screenshot of Motherboard

P4 Grupo Naidy

Group Number: 1

Names: Yaared, Kuni, Avneesh, Joe, John

Project Summary: Our project is a centralized serving system, called ServiceCenter, that allows waiters to efficiently manage orders and tasks.

Description of Test Method:

To obtain informed consent from the test subjects, we first asked if they would be interested in helping to test our system for a COS class.  Once they assented, we explained that they would be playing the role of a waiter in a restaurant and interacting with our system and that the testing itself would take about ten minutes plus set up time.  We then presented them with the consent form that can be accessed here, and they signed it. We also read the demo and task scripts to them in order to explain what they were going to be doing through the test. The demo and task script can be accessed here and here.

All three test subjects were affiliated with Terrace F. Club.  The first was a member of the kitchen staff, so he had experience serving food to others.  He was a relaxed and friendly waiter.  This subject expressed interest in our prototype system when he saw us setting up, and we were able to show him how it worked in detail by using him to test it.  The second subject was a student who has spent multiple summers working as a waitress in the restaurant at a country club.  Since she was used to demanding customers, her style was more professional and focused.  She was chosen based on her experience as a waitress who was used to working in a high pressure environment. The last subject was a male student.  He had a unique approach to customer service, but was an enthusiastic participant and waiter.  We chose him because we wanted to test the system on an inexperienced waiter/waitress.

We chose to run our low-fidelity prototype in the lower dining hall of Terrace F. Club. The lower dining hall is split into two sections: a solarium and a seated area. The solarium was where we set up our Motherboard – a screen that displays order information, order status, and cup status for all tables in the restaurant. For the actual board, we used a white board with the table floorplan for the restaurant drawn on. The customers sat in the seated area, where our test users took orders and served the food. When serving food, the waiter on duty served plates with labels on them, specifying what dish it was. We used cups, jugs, cutlery, and updated the Motherboard using dry-erase pens to simulate our system for this low-fidelity prototype.

For our low-fidelity prototype test, we divided roles amongst our group as follows. John, Yaared, and Joe acted as customers in charge of ordering for their respective tables, while at the same time making any test run observations from the viewpoint of the customer. Avneesh acted as our main test run observer and took notes. At the same time, he was available to help complete any tasks if the waiter/waitress requested help. Kuni managed the Motherboard and the “kitchen”. Given an order, Kuni would update the appropriate section of the Motherboard, put out completed orders to be served by the waiter on duty, and again update the Motherboard, thereby simulating the transfer of information between the kitchen and floor.

For our testing procedure, we decided to stagger 4 different groups of customers of varying size (i.e. 4 tables). The first group (i.e. John) enters and is served by the waiter. John orders for a large group of 7. Now, the second group (i.e. Joe) enters and is served by the waiter. Joe orders for a small group of 2. ‘5 minutes later’, the third group (i.e. Yaared) enters and is served by the waiter. Yaared orders for a medium-sized group of 4. The second group (i.e. Joe) then asks for the bill and leaves after paying. Now, the fourth group (i.e. Joe) enters and is served by the waiter. Joe orders for a medium-sized group of 3. The respective groups finish their meals, ask for checks, pay and then leave. We thought that staggering 4 groups of customers of varying size in quick succession would be a good way of simulating a situation in which servers may be hard pressed. Since our system is supposed to allows waiters to efficiently manage orders and tasks, we thought simulating a situation in which servers may be hard pressed, i.e. dealing with a lot of tables in peak hours, would best test the effectiveness of our system (after all this is the problem we are trying to solve!).

Summary of Results:

Our users understood and used the system well throughout our prototype test. All of our tasks were completed—calling for help was very simple and only happened when our users had to bring out multiple plates of food at once. Our other two tasks—checking customer status and determining task order—were performed regularly throughout the 10-minute period for every test run. An incident occurred where there was confusion over what a customer had ordered when two customers had placed similar orders. Another major incident was when our first subject was confused about which tables corresponded to the figures on the board. At times, Kuni, who was operating the Motherboard, had trouble keeping up with the speed of orders being placed and preparing the paltes. Otherwise, the user testing went very smoothly.

Users rarely (less than 5 times) looked at the motherboard for more than 10 seconds. Most of the time, they would glance in passing and quickly assess what their next task was. The only time they seemed to stop to look at the board was when there were multiple tables with ready plates. Throughout the test, there were times when the customer had to remind the waiter/waitress that their cup needed refilling. Overall, Kuni processing all the information and updating the board while also preparing the plates seemed to be the biggest bottleneck throughout the testing process.

Discussion of Results:

The most common “problem” faced by the test subjects seemed to be deciding how to order food deliveries to tables when multiple tables had food ready. One test subject volunteered the suggestion that orders should display an “estimated time left” that would show the rough time until each dish would be ready (the estimate could be determined in a variety of ways.) This could prove helpful in planning for future trips to tables when there is some down time. Also, it could be helpful to automatically sort the orders on the screen. All orders could be given a time value, positive for orders that have been sitting out (for how long they have been out), and negative for orders not yet ready (for how long until they will be ready). The orders could then be automatically sorted in ascending order by time. This would place them in priority order for the waiter/waitress.

We also realized that the dedicated board updater could be a bottleneck in a real restaurant setting even in the workings of the real system. If there are a lot of orders with many modifications and many tables being served, then the input of all these orders will most likely be the most time consuming part. But we realize that this is a worse case no matter what the system is. If we dedicate a person to input, then this could alleviate the problem. The dedicated input person would take the task from waiters/waitresses and possibly become quicker at inputting the information. Users were overall enthusiastic about the system, and they didn’t need too much explaining beforehand to understand how the system worked. We were happy that users did not need to scrutinize the board to figure out what the status of each table was—the layout and concept seemed to be clear.

Future Test Plans:

There are several areas of our low-fidelity prototype that could use extra testing before we move on to the high-fidelity prototype; many of these were brought to light during this testing session. As it is, we have already tested the usage of the information screen both in terms of entering data and reading data. However, we did notice during the testing procedure that simulating the information screen without a computer created a major bottleneck – Kuni had as much work to do in each task procedure as the actual outside participant. In order to better simulate the actual speed of the system (since speed and efficiency are at the core of our goals), we might have to find a faster method of displaying the data without computerizing it, if we want to continue to test with low-fidelity. Finally, we would also want to incorporate the input interface in the next round of testing. Since in our system, we would have a dedicated worker inputting the orders into the system, in our test Kuni essentially played this role by directly writing the orders onto the board.  In the creation of the paper prototype for the input interface, we went through some brief pseudo testing, going through 2-3 iterations of the input interface. But for future testing, we would have another subject input the orders as the simulation runs.

There are other areas which we found difficult to test but which could have yielded useful information. For one, we were not actually able to do testing in an open restaurant setting with waiting staff, instead using the dining room of an eating club with students with waiting experience as an alternative. Testing in the real setting would yielded the ideal results, but we are unlikely to find a restaurant willing to participate. Another smaller area which was difficult to emulate in low fidelity was the entrée timer (i.e. the timer which counts down the time until the food in the kitchen is done being prepared). It was simply infeasible for the board manager to be constantly updating the time, and somewhat less useful anyway since we used wait times of 1-2 minutes instead of 15-30 minutes as is common in actual restaurants. Testing this aspect might be done with an actual timer or stopwatch in the future.



P2 Grupo Naidy

Group Number: 1

Group Mates: Kuni Nagakura, Avneesh Sarwate, Yaared Al-Maheiri, Joe Turchiano, John Subosits. All group members were involved with the interviews and design. Avneesh and John worked on the task analysis questions, Kuni worked on the sketches and storyboard, and Yaared and Joe answered the Contextual Inquiry.

Problem and Solution Overview:

Servers and restaurant staff tend to be over tasked at busy times, which leads to unhappy customers, overworked staff, and decrease in revenue. Our solution a system that passively gathers low-level information (ex. Status of food, drinks, etc.), and displays it in a way that allows the restaurant staff to make high level decisions more quickly and effectively.

Description of Users in Contextual Inquiry:

As our system affects both patrons and servers in restaurants, we decided to focus primarily on the servers for the majority of our interviews. We made this decision because putting more control in the hands of the patrons may exacerbate the issue of overworked waiters. Focusing on the servers, we concluded, would not only decrease their workload and reduce any inefficiency, but it would also improve the quality of service for the patrons. Thus, our target user group for our system is servers and restaurant staff (waiters, bus boys, managers, etc.). We observed and interviewed four different users from this target group. Our first user was a middle-aged waitress at Zorba’s Restaurant, who served us while we ate lunch. When we interviewed her, she had no major complaints and seemed satisfied with her job. Our second user was a young waiter at Zorba’s Restaurant, who had just gotten off his shift. He emphasized the teamwork that is necessary in an effective waiting staff and complained about large parties that demand all available staff. Our third user was a Princeton student who has waitressed for numerous summers at an upscale Country Club.  Our final user was a young manager at Triumph. As a manager, she focuses on efficiency and customer satisfaction of the whole restaurant, not simply specific sections or tables.

Contextual Inquiry Interview Descriptions:

We prepared a set of questions before each interview. The first set of interviews/observations was performed while our group sat down to eat lunch at Zorba’s Restaurant on Nassau St. We spent most of our meal observing and taking down notes on the movement/activities of the waiting staff. Afterwards, we interviewed two waiters—one that was directly serving us, and another who had just gotten off his shift. We asked them both about the range of tasks that they perform and how they perform it on a daily basis. The interview with the student was performed in an informal setting, and we asked her to recount her past summer experiences as a waitress. We met with a manager at Triumph at around 5:00 before the bar got too busy. She was still on her shift but was able to answer our questions for a couple minutes.

Most of the people we spoke to agreed that time management and balance, especially during busy hours, was the key to good service. Teamwork and covering for each other’s tasks also seemed to be a prominent component of making it work.  It seemed that the tasks themselves were not especially difficult, but during peak hours, the sheer number of simple tasks to be completed and the difficulty of organizing those tasks led to poor service. Most of our interviewees mentioned that a key part of the job was balancing the ability to provide for patrons as soon as possible but without being overbearing. We found that in all three settings, there was a clear division of labor in place between management, service, and bus boys, but there was usually some degree of overlap between the positions.

In each interview, we did pick up a few pieces of unique information that other interviews did not provide. Our first two interviews took place at Zorba’s Restaurant on Nassau Street, a small family restaurant. We interviewed both the waitress who served us and another waiter on staff at the time. These two emphasized the need to always be keeping an eye on every table they were staffing; in retrospect this sort of tactic is probably only possible at a smaller restaurant like Zorba’s. Otherwise, they seemed to have very little to complain about.  Next, we interviewed a student waitress in an informal setting. She, by virtue of having worked at a country club, had a different experience from the rest. The focus of her customers tended to be on alcoholic beverages (especially wine), and her major problems arose from trying to coordinate bringing out food for one table while having to refill drinks at another. She also mentioned that it was difficult to determine when to take food or drinks away when different people at the same table ate and drank at different paces. She also mentioned that, because the country club was divided into several segments, she was not always able to check on all tables as she moved around the floor. She also mentioned that not letting food get cold while refilling drinks was another big issues that she often faced. The final interview was with a manager at Triumph Bar, also on Nassau Street. Our questions for her were therefore more geared toward a management perspective rather than that of small-scale waiting. Since Triumph is a large establishment with multiple levels and a bar, the manager stressed that coordination and division of labor was especially important to her success. We found that the Triumph staff had been using a service called Digital Dining – which didn’t work especially well and actually turned into a bottleneck-point when waiters had to manually input orders to the service after first writing them up.

11 Task Analysis Questions:

1. Who is going to use system?

Servers, managers, and kitchen staff at large/busy sit down restaurants would be
the target users of our system. Servers would be the primary users, and would
benefit most using it during “rush” periods where many parties come in, or during
times where particularly large parties unexpectedly come in. The kitchen staff
would use the system to provide information to the servers to make their work
more efficient.
2. What tasks do they now perform?

Servers must (roughly in order of increasing difficulty) refill drinks, clear plates,
refill condiments/coffee/napkin dispensers, bring food from the kitchen in a
timely manner, take and send orders to the kitchen, bring the bill at the right time,
determine what order to perform the previous tasks.
3. What tasks are desired?

Waiters want an efficient way to transfer orders from waiter to kitchen and would
like to know when food is ready in the kitchen. They would also like to know when
tables are “antsy” and impatient. They would like a way that helps them minimize
mistakes in taking down and delivering orders. They’d also like to know when
customers’ drinks are low.
4. How are the tasks learned?

Waiters either learn tasks by serving as a busboy first, or shadowing another waiter
for a day. More experienced waiters are given more tables to handle, while less
experienced waiters are given fewer tables.
5. Where are the tasks performed?

The tasks occur mainly on the restaurant floor and the “waiter’s area” where the
waiters pick up food from the kitchen or congregate for other tasks.
6. What’s the relationship between user & data?

Users must be attentive in collecting data themselves and must make real time/
online decisions on how to act. There is a lack of quantitative data – the only well-
specified type of data is orders and check amounts; everything else must be guessed
or estimated. The sharing of data between servers and kitchen is fairly structured
(notes passed about what orders to cook), and there is some sharing of data
between servers to help each other out, but this is incidental and always verbal.
7. What other tools does the user have?

Paper and notepad are used to remember orders, which are often written in
shorthand. Some (very few) use mobile devices for this instead. There are
sometimes computer-scheduling systems, but not often. At Triumph, “Digital
Dining” is used, a system that supposedly helps waiters perform some of the
previously mentioned activities (but the waiters are dissatisfied with it).
8. How do users communicate with each other?

Servers communicate almost exclusively verbally, some body language/implicit
communication or inference occurs when a server tries to discern a customer’s
mood. Between the servers and the kitchen, communication is generally written,
maybe with verbal emphasis for some unusual aspect.
9. How often are the tasks performed?

Each waiter can be assigned up to 5-6 tables at the same time. Tasks in general are
being performed all the time, it depends on server how they are ordered/scheduled.
10. What are the time constraints on the tasks?

There are no explicit time limits on tasks, but in general all individual tasks are
completed as fast as possible and the “optimization” comes with deciding what
order to perform tasks in as to minimize “lateness” across the entire set of tasks.
11. What happens when things go wrong?

This depends on how wrong things go. For small delays, customers may simply
shrug it off, or become slightly grumpy. For larger delays customers may cut back
on the tip or complain to a manager. For meal mix-ups, users may again complain to
a manager or cutback tip. Depending on how angry customers are, they may refuse
payment. In some restaurants, servers are granted authority to make concessions to
customers (i.e, free deserts) to make up for mistakes.

Description of 3 tasks:

1. Checking customer status
This task involves checking to see what tables have drinks that need refilling, what
tables are waiting on orders, and what tables are requesting attention. Currently
this task is of medium difficulty, but can be quite difficult when things are busy.
Some information, such as how long tables have been waiting for food, are not at all
currently available. Using our system, this task should be very easy, as the server
would only have to look at a screen to see the status of all their tables.
2. Determine task order
This task involves deciding what to do first, for example, whether to make a
round of filling drinks before checking the kitchen to see if food is out. This task is
currently the hardest task for servers because of the lack of information available
in making the decision. Servers do not always know the status of all of their
tables and generally do not have data on whether their orders to the kitchen are
finished or not. Combined with the solution to task 1, incorporating kitchen data
into the system makes this task much easier, as with a single glance servers will
have customer data and kitchen data, which will help servers determine the most
“urgent” tasks to complete.
3. Signal for help
This task is generally easy, but during busy times it can become difficult. Servers
generally verbally ask other servers/busboys nearby for help if they need another
hand to bring food or quickly fill a glass. However, during really busy times it might
be the case that a server can’t immediately find a free hand for a task. In this case,
pressing a button or sending some signal to a central area could alert all servers that
a free hand is needed in a certain area.

Interface Design:

Our system works over two “layers” of interaction. The interaction between the waiters and the customers, and the interaction between the waiters and the kitchen. The central unit of the system is a set of screens in the waiter’s area that displays the floorplan of the restaurant and displays the status of each table. For each table, the screen lists the number of empty, half empty, and full cups, the list of dishes ordered by that table, and how long it has been since the table placed their order (if the table has their food delivered, the time display shows the text DELIVERED, if the table is not occupied, the time display shows EMPTY). Each screen represents a section of the restaurant that a waiter or small group of waiters is responsible for. On the table, there are pressure sensitive coasters that can detect how full a glass is. These send the information on the state of the glasses to the main screens. Waiters also have a “help” button on their belts. If a waiter cannot solicit help from a nearby waiter, they can press their help button, causing their section’s screen in the waiter’s area to flash, alerting any free waiters that assistance is required in a particular section.The screen displays the list of food items that have been ordered by each table. Each item in the list is displayed in red, and its color changes to green when it is finished by the kitchen. If a finished item has been sitting for some specified amount of time (which can be set for the user) the table that ordered it flashes red as a warning that an item at that table may be getting cold, and the table should be served.


Task 1: Checking customer status

Task 2: Determine task order

Task 3: Signal for help

Sketches of System:

L2 Loops I Did it Again

Group Number 1: Kuni (nagakura@), Yaared (kyal@), Avneesh (asarwate@), John (subosits@), Joe (jturchia@)

We built a sound looping system for our final result. The interface is three buttons and a potentiometer, where each button corresponds to a different pitch and the potentiometer determines the tempo. When the system starts, there is a constant stream of 16th notes on top of which the user builds the loop. Once the loop begins, the user can add different notes to the loop and it will keep playing it. Over a couple of loops, any user can make a beat! We built this, because we thought looping was cool and also accesible to non-musical users. We are very happy with our final result. The interface is intuitive and easy to use and pretty much anyone can make some sort of simple beat/rhythm using our system. For future improvements, we would add more buttons to provide more diversity in the looping sounds. We could also add a switch to change instruments.


Prototype 1:

For our first prototype, we made a simple button to chord mapping using ChucK and three buttons on the Arduino. Every combination of buttons creates a unique chord.

2013-03-06 22.38.11

Prototype 2:

We used a SoftPot and FSR for our second prototype and built a system where the amount of pressure on the FSR determines the volume of the note, and the SoftPot controls the pitch. The prototype plays the sound of a mandolin and the interface is intuitive even for non-musical users.

Movie on 2013-03-06 at 20.38

Prototype 3:

For the last prototype, made a sound looping system. We have three buttons and a constant stream of 16th notes, where each button corresponds to an instrument and the user can create samples and loops using the 3 buttons.

2013-03-06 22.45.27

Final System:

Avneesh makes beats, speeds up the tempo, and has a great time:

Final System Demo

Parts List:

  • Arduino
  • 3 buttons
  • Jumper wires
  • 3 resistors (10k pulldown)
  • Breadboard
  • Potentiometer

Instructions (image attached):

  1. Attach three buttons to breadboard, spaced comfortably apart.
  2. Attach a pulldown resistor between each of the buttons and ground.
  3. Connect ground to Arduino.
  4. Attach 5V line to the other side of the buttons.
  5. Attach signal lines between the resistors and buttons and run to digital pins 6, 8, and 10 on the Arduino.
  6. Attach potentiometer to Analog 0, ground, and 5V
2013-03-06 23.01.43

Reference Image for Circuitry

Source Code:


int b1 = 6;
int b2 = 8;
int b3 = 10;
int b1Reading;
int b2Reading;
int b3Reading;
int curReading;
int lastReading;
int potPin = 0;
int fixed;

void setup(void) {
  pinMode(b1, INPUT);
  pinMode(b2, INPUT);
  pinMode(b3, INPUT);

boolean b1Last = false;
boolean b1New = false;
boolean b2Last = false;
boolean b2New = false;
boolean b3Last = false;
boolean b3New = false;

void loop(void) {
curReading = analogRead(potPin);
if (abs(curReading - lastReading) > 2) {
  fixed = map(curReading, 0, 1023, 0, 250);
   Serial.println(" ");

lastReading = curReading;
b1Reading = digitalRead(b1);
if (b1Reading == HIGH) { 
  b1New = true;
else {b1New = false;}

b2Reading = digitalRead(b2);
if (b2Reading == HIGH) { 
  b2New = true;
else {b2New = false;}

b3Reading = digitalRead(b3);
if (b3Reading == HIGH) { 
  b3New = true;
else {b3New = false;}

if( !b1Last && b1New) {
  Serial.println("1 ");  
if( !b2Last && b2New) {
  Serial.println("2 ");  
if( !b3Last && b3New) {
  Serial.println("3 ");  
b1Last = b1New;
b2Last = b2New;
b3Last = b3New;


Shakers inst[16];
int filled[16];
0 => int count;
.125::second => dur step;
for(0 => int i;i  dac;
// create our OSC receiver
OscRecv recv;
// use port 6449
6449 => recv.port;
// start listening (launch thread)
recv.event( "set, i" ) @=> OscEvent set;
fun void play() {
        if(filled[count] == 1) {
            .9 => inst[count].energy;
            .8 => inst[count].noteOn;
        step => now;
        if(filled[count] == 1) {
            .8 => inst[count].noteOff;
        (count + 1) % 16 => count;
spork~ play();
while(true) {
    set => now;
    set.nextMsg();  //loop thing?
    1 => filled[count];
    set.getInt() => inst[count].preset;

import serial
import OSC
import time

ser = serial.Serial('/dev/tty.usbmodemfa141', 9600)

client = OSC.OSCClient()
client.connect( ('', 6449) )  
iset = OSC.OSCMessage()
knob = OSC.OSCMessage()

while 1:
    line = ser.readline()
    if " " in line:
        if("p" in line):
            s = line.replace("p", "")
            print int(s)
            print int(line)