Our final prototype takes users from the "I got the bill; how much should I pay?" stage to the "This is how much I owe; now how much should I pay?" stage. Usually, in a restaurant, payers have to think about several things when coming up with the payment amount, including:
- should we split the bill evenly?
- how much did each person get?
- how to account for tip/tax?
In the end, however, what they really are interested in is how much they should put on the table. What our prototype does is walk them through this process, record what information they can easily figure out (what percent do they want to tip, who should split what, etc) and calculate how much they should pay if they had exact change--the subsequent rounding and owing procedures are left up to the user.
A flow diagram for our prototype is provided below, and covers in detail what our prototype allows people to do. Because our prototype is functional enough to accurately show its attempted capability, we do not describe this in too much detail.
The full implementation of our final prototype was done in JavaScript and PHP. Each page (a block in the flowchart) was implemented as a seperate webpage, and communicated to other webpages using PHP POST and GET. The menu items were hard-coded in a JavaScript header file, which was included in all of the pages. The prototyping for this, in software, was done in two phases: first in PowerPoint, then in JavaScript. The advantage of using PowerPoint was that everyone in the group was familiar with it, and could easily manage the organization and creation of design features. The PowerPoint prototype also ended up being a very good layout device, in providing clear indication of the code structure needed before any JavaScript was written.
One of the most important aspects of our interaction, however, was drag-drop, and to implement that, we needed something more dynamic, and so the final prototype was implemented in JavaScript. This was mainly decided based on personal preference, resulting from previous experience, ease of finding tutorials, and general transparency of the language. Although the language itself didn't really afford too many disadvantages, the extent in which it was used turned out to be a bigger factor. The day after the first prototype was completed, it was discovered that a free JavaScript package existed for coding for iPhone webapps, affording several unimplemented features, such as:
- ability to be functional on an iphone
- standardized keyboards, buttons, and headers
The other main feature that JavaScript and PHP alone were insufficient to preform is the bill-loading system itself. Originally, we imaged that at many restaurants, bills, when loaded into their own financial system, can also be accessed and viewed from the iPhone, using the paycode found on the receipt. To simulate this, we provide the testers with two standardized receipt, whose items are hard-coded into the system. Overall, however, because of the little backend required in our prototype, we were able to provide a very close simulation in design to what we had intended to produce.
The final prototype can be found at:
All features have been implemented. However, this prototype currently only has one receipt which you can use to split the bill:
