Provides a Thirstbuster registration website that allows venue owners to sign up and register their establishments.

The Main barperson UI is where most of the action is. Provide basic web-app functionality.:

• Allows at least four simultaneous orders open for processing. That is, orders are just all shown in open panels, ready for processing.
• Time-stamps when orders come in and provides some indication of priority based on this.
• Allows filling of drinks in each order, one by one. Updates status in shared data channel appropriately so mobile app can update.
• Tracks status of orders, preferably automatically, changing status as orders come in, are worked on, get picked up and are closed.
• Supports self-serve mode: provides some way of handling the "verification of drink receipt" problem discussed in the spec. when the client comes up to get the drink order.
• Provides way of viewing total orders and money taken in.

Reasonable quality UI --- clean, aesthetic, smooth function. Serious points here. The main barperson UI is implemented as "touch-screen", i.e., mouse-only, no keyboard. (Registration on website is okay for keyboard use).

Basic Test Harness. You have to be able to test this in at least simulated live action. Ideally, you will achieve basic communication with the Mobile-app half of your coupled team. Barring that, you need to implement some sort of bare-bones test harness (mobile, desktop app, terminal window, whatever), by which you can simulate events (like drink orders) coming in from the mobile app side.

Provide basic Thirstbuster client app functionality. Some things a basic system has to support include:

• Nice app icon, launches and opens smoothly
• Provides a way to enter a client's name and payment information at first run.
• Provides a way to browse the drinks menu for an establishment.
• Provides a way to start a drink order, and place drinks on the order, then submit
• Shows status of evolving orders, drawn from data posted in the shared data channel by the web-app side.
• Provides some way of handling the "verification of drink receipt" problem discussed in the spec.
• At least a way to handle the "self-serve" mode, meaning the client comes to the counter to get the order. This avoids implementation of the second, small "server-app" mentioned in the spec.

Reasonable quality UI --- clean, aesthetic, smooth function. Serious points here.

Basic Test Harness. You have to be able to test this in at least simulated live action. Ideally, you will achieve basic communication with the Web-app half of your coupled team. Barring that, you need to implement some sort of bare-bones test harness (web app, desktop app, terminal window, whatever), by which you can feed it events happening on the web-app side.

Provide full, realistic Thirstbuster web-app functionality. In addition to the preceding functions, you might like to provide some things like:

• Allow editing of the venue's profile information, e.g., update of address, settings, accounting info.
• Allows editing of drink order: barperson can delete a drink manually if requested.
• Easily handles longer orders, e.g., scrolling within orders.
• Data analysis: provides analysis of what drinks are most popular.
• Have an effective capacity for handling large number of simultaneous drink orders. Implies that you can't keep them all (wide) open all the time; need more clever UI that keeps an ordered list, shows how long orders waiting, and allows selecting/opening and filling orders efficiently.
• Data analysis: provides analysis of workflow: times that orders spent in each status.
• Data analysis: provides analysis of what drinks are most popular. Add-ons: graph by day of the week, time of night, different timespans (last week, last month, custom range).
• Anything else more polished that your user studies indicate that might be a hot seller.

Very clean and well thought-out interface design: Great looks, fast, smooth flow.

Scores on the A-range will have a nice, polished application that you could see using behind a busy drinks counter. Doesn't have to be perfect, just has to be an "excellent" effort.

Provide full, realistic Thirstbuster functionality. In addition to the preceding functions, you might like to provide some things like:

• Supports "table-service" mode by implementing the mini app used by servers. Either as separate app (recommended), or even as "hidden mode" in the main app.
• Provides a way to edit a drink order that has been submitted, i.e., delete drinks, add drinks.
• Only allows edits based on the rules given earlier, i.e., only while order incomplete, etc.
• Provides ways of marking/tracking who's drinks are whose within each order in a simple elegant way. Makes it easy to split a tab between friends...or notice which friends are being leaches.
• Provides some reporting functionality: how much you've spent (week, month), breakdown of what things you buy when you're out (beers, wines, liquor, soda), or whatever else you can think of and that resonates with users.
• Neat ways to speed item entry, e.g., "most common items", or spelling completion based on past history. It's a pain to search out "IPA" out of a huge list all the time! Recognize that everyone has their preferences...how can your GUI help here?
• A way to tip the server and/or barperson. (On every order, as you leave, whatever)
• Anything else more polished that your user studies indicate that might be a hot seller.

Very clean and well thought-out interface design: Great looks, fast, smooth flow.

Scores on the A-range will have a nice, polished application that works smoothly and feel like something you might actually like to use. Doesn't have to be perfect to the point of being app-store-ready, just has to be an "excellent" effort.

Advanced functionality, some random ideas:

• Advanced reporting and analysis functionality: graphical analysis tools like pie-charts, graphs etc. that show info of high value to owners.
• Supports multiple "stations" within a venue, and does load-balancing of incoming orders between them. Would have to communicate this to those (customers or servers) picking up orders.
• Smart load-balancing for table-service mode: weights which station incoming orders go to based on proximity of tables to each station. Could re-balance, moving unfilled orders between stations as new orders come in.

Advanced functionality, some random ideas:

• GPS-based integration: puts up a map with Thirstbuster-enabled venues showing.
• GPS-based integration: Switches context to the venue where you are automatically based on GPS location.
• GPS integration: Notices when you leave a venue. Sends you a reminder with the sum of the bill there, plus, if you haven't done so, an option to leave a tip at various percentages.