|Home||Original Proposal||Assignments||Group Members|
Human Factors and Interface Design
Dan Bathgate, Eddie Byun, Dan Grieneisen, Ryan Mitchell
September 11, 2010
Drink Discovery and Ordering System for Bar Patrons
Problem StatementThere is a huge amount of information at bars and restaurants that is largely inaccessible by patrons. A software-mediated interface to facilitate the transmission of this information to help patrons make drink purchasing decisions could be of tremendous help and has not, to the best of our knowledge, been attempted before. Currently, inventory systems, purchasing systems, and menus are separate entities. As a result, there are many common unpleasant scenarios: - A man wants to impress his date with a bottle of wine, deciding between the $20, $35, and $60 chardonnay. Having only a vague idea of what "chardonnay," is, and not wanting to seem too spendy or too thrifty, they simply order the $35 bottle.
- A woman wants a cocktail she heard her friend talking about the other day, but she doesn't know if the bartender knows how to make it, or if they have the ingredients. Not wanting to cause a scene, she orders a rum and coke.
- A bored patron sits alone, wondering what the girl at the table across from him is drinking because it looks delicious. She's with someone else though, so he goes back to watching the game that he's not really interested in. We would like to make a software interface to allow patrons to discover interesting options on the menu in a fun and engaging way. We would also like to integrate a purchasing system.
User Characteristics and Goals:As mentioned above, our users are bar patrons who would like to be able to order either new drinks that they have never tried before or drinks that they do not know if the bartender knows how to make.
Initial Design Ideas:By expanding the idea of a traditional menu to incorporate an appropriate software interface, we can solve many of the problems mentioned above. A possible scenario: A patron walks into a bar and selects a spot. They are greeted by their menu that asks if they would like, wine, beer, liquor, non-alcoholic beverage, food, or would like to browse by some other criteria (such as most popular drinks for that establishment, or bartender recommendations). The user selects one and is presented with a list of drinks, and a search interface for exploring all the available choices.
When a selection is made, a tab is automatically started for that user, and a bartender is alerted through the purchasing system screen on their side of the bar.
Logistics of this project:Bars were chosen for this project, rather than restaurants, because they are largely a social environment where patrons interact with bartenders and each other, and are often very interested in what they are drinking. We believe that a greater flow of information and communication will enhance this experience. There is also a much smaller scope to the problem of dealing with drinks (which do not rot, go out of season, or change dramatically in price, and they are relatively standard and well-known from establishment to establishment) than dealing with food. There is the problem, of course, that this project will be related to alcohol. Although 3 of our 4 group members are 21+, no alcohol will be involved in this project. Most Massachusetts restaurants containing bars are open to all ages and we've found that bartenders are more than happy to chat about their industry regardless of what you're purchasing. In addition, all these bars serve food and non-alcoholic beverages. Ryan is friends with several bartenders, waiters, and restaurant industry people in Massachusetts, and knows one person in particular who has contacts in many restaurants and bars in Boston that could facilitate our research. Although the scope of this project is large (some sort of information transmission system between everything at a bar), if the scope becomes too large, we would like to focus on menus in particular, and the problem of getting accurate, timely, and plentiful information to patrons. Patrons in particular, are very easy subjects to talk to in bars. That's the point :)
Team Roles and CompetenciesEvaluation Manager: Ryan Mitchell
Technical Lead: Danny Bathgate
Group and Write-up Manager: Dan Grieneisen
Design Lead: Eddie Byun Danny and Ryan have significant web development experience. Dan is an organizational machine, and Eddie has some experience with the Adobe tools. The amount of domain knowledge varies significantly across team members.