...
In addition, during paper prototyping, users were having trouble figuring out when their friends were done ordering, and many often pushed the order before their friends had finished ordering. Therefore, we decided that we needed a means to make it very visible when someone is done ordering. Therefore, we added this bottom paned with icons for each person. Initially for the computer prototype, the bar was subtle and contained all of the Facebook photos of the people in the order and grayed out text that turned white when the person finished. However, users of this prototype pointed out that there was nothing to draw their eyes down to that part of the screen, and that the change was far too subtle. Therefore, we changed it to the current red X/green checkmark. Even this, though, seems not to be effective enough.
Implementation
Because of the large backend and the necessity to communicate between multiple computers, we decided to use Ruby on Rails as our back end. Though it took a long time to convert our computer prototype to Ruby on Rails (as we had not yet made a final back end decision regarding final implementation as of GR4), it was very worth it to implement the change. To communicate over multiple computers, we used a message system where the back front-end would post messages to our server, as well as look for updates every couple of seconds. That way, we could implement an entire message hierarchy that included chat messages, ordering food messages, restaurant selections messages, etc. , and react to them client- and server-side.
Unfortunately, we had many problems meeting our initial goals with our back end. First, we were counting on getting some sort of API from Campus Foods or Foodler. However, neither company responded to our e-mail with anything useful (we got a "I'll forward this on" sort of response from Foodler). This meant that there was no simple way to hook up our interface so that people could actually order food. Therefore, we had to spend extra time gathering menus from Campus Foods and didn't end up hacking our way into either site to send orders, as we felt that doing so would detract from the large amount of other work that we needed to get done.
In addition, we had problems synchronizing our system to handle multiple users. In the end, we got a lot of simple things working, but there were still some large visibility issues that arose. For example, there were times that messages would just get dropped. However, we had the most issues when it came to adding people to orders. Sometimes the already present users would have to refresh their screen to see the new person added. However, since we never got around to the process of storing data through refreshes, orders would be lost upon refreshing. In addition, for the same reason, when a user would join the order , they wouldn't see all any of the previous activity, as we only did the "live" portion of the backendfood orders placed by other users. Chat activity, though, was persisted through sessions.
Lastly, some things just didn't quite get finished the way we wanted. Voting never actually got counted, as we couldn't quite figure out how to trigger the proper handlers with multiple users. Also, though we made an affordance for users being done, we didn't quite finish that implementation to change the status to "not done" if the person were to try to change their order after they click done.
...