RSS
 

Final Proposal for Redial: Hermes

09 Apr

My Redial class is awesome.  We’ve set up Rackspace servers with Asterisk telephony software and now we’re executing shell/ruby/php scripts through phonecalls which are now interacting with node.js servers to execute web site interfaces, Arduino RC car controls, etc.

I really want to focus on using node.js and socket.io with Asterisk/phonecalls for my final project.  So here’s what I propose:

Hermes

Hermes is an ordering interface for bars and restaurants.  When you sit down and order food, or when you’re standing at the bar trying to get a drink, you dial in with your phone to the establishment’s screen/s to place an order.

Say you sit down at a table and the table either has a built-in screen (like those old Pizza Hut arcade games where you could play Pac-Man using a joystick and buttons underneath the table surface), or it has a monitor or projection on the wall.  It will have a phone number for you to dial.  When you call in, it begins to interact in real-time with you both by voice and with on-screen instructions.  By pressing phone keys, you can place simple orders from simplified menus displayed on-screen.

Multiple people can dial in to the same line at the same table.  The screen will split depending on the number of people, allowing people to tie their orders to their phone number and to order independently of each other.

At the bar, when it’s packed, a projection above the bartender area will have a number to place calls.  The bartender can then cue drinks in the order they’re received in a fair way.  People can auto-order favorites or have drinks set to order every x minutes.  Complex group orders are handled digitally.

Multiple screens can be installed around the establishment so people don’t have to wander too far to place an order.

The screens can also be used for entertainment, as people could play phone trivia or mini-games via their phones, browse the news, change TV/music stations (handled via weak FM signal?), etc.

YouTube Preview Image

Why Hermes?

Hermes was recognized as the God of commerce and social interaction, and patron god to diplomats, messengers, and heralds:

Due to his constant mobility, he was considered the god of commerce and social intercourse, the wealth brought in business, especially sudden or unexpected enrichment, travel, roads and crossroads, borders and boundary conditions or transient, the changes from the threshold, agreements and contracts, friendship, hospitality, sexual intercourse, games, data, the draw, good luck, the sacrifices and the sacrificial animals, flocks and shepherds and the fertility of land and cattle. [Wikipedia]

Problems of a Hermes-Less World

  • Ordering food and drink is still a primitive process.  McDonalds has figured out how to move a lot of customers through quickly and efficiently with minimal job training.  But most restaurants and bars suffer from bad image and service because overworked waiters, waitresses, and bartenders can’t keep up with everyone’s needs 100% of the time, particularly when customers are fickle, intentionally hard to please at times, etc.  Streamlining the ordering process so that people can order as much food and drink as they would like, without inconveniencing themselves or waiting for some attention from an employee would increase business and increase consumer satisfaction.  There’s a problem when people discuss strategies to elbow their way into a bar just to maybe get a drink in 15 minutes, 15 minutes spent away from the party they came to attend.

Problems of a Hermes World

Hermes is not without its limitations.

  • Screen readability is limited by the size of the monitor, the customer’s ability to see clearly, the design of the interface, and how much text can be displayed at once.
  • There is also a problem linking orders to phones.  While something like Google Wallet, where one could pay via phone, would be preferable, at this point the phone number would only be an identity link to the customer and his order, and for reaching the customer afterwards for non-payment.  There are most likely large security/spoofing vulnerabilities in this approach unless a credit card number is somehow associated with the phone number.
  • Why would one find that dialing on a phone is a superior interface to asking a person, or using a touchscreen, or even using a custom web-app or mobile site to order?

Benefits

  • Tests with digital ordering systems seem to indicate people will order more food and drink if they can do it quickly, digitally, and without pause.  The systems seem to increase efficiency and overcome social shyness.
  • People strongly and affectionately associate with any actions involving their own phones, so using their phones as an ordering device empowers them.  It also is a potential bridge to have “preferences” that people can set and save with their “account”, linked through their phone number as identity.
  • Digital ordering produces a digital record, which is better for book-keeping and for validation of records in the event of disagreement between employees, customers, and management later.
  • Projections could be expanded upon — when people aren’t ordering food, they could be consuming news, shows, art installations, using Kinect-ish hands-free interfaces, messaging other tables, etc.  There is an exciting potential for linking different tables and screens with each other, via competition, flirting, or just networking or social lubrication.
  • Client interface consists of normal 1-0/*/# phone pad, can work with installed phones or smartphones or even simple cellphones, while all the customized, complex work can be handled server-side

Technology

  • Flowroute number linked to an Asterisk server installed on Rackspace
  • Asterisk dialplan forwarding to a ruby-agi script that sends data to a node.js instance
  • Node.js instance that takes incoming phone commands and passes instructions via socket.io (real-time, no polling) to the client that is installed on the projection/screen
  • jQuery/UI/AJAX/node.js client interface that handles order entry and routing, and can run multiple instances via the node.js cluster module, and can also forward to other instances for video, news, chat, etc. while keeping order entry instance CPU/memory load available just for order entry/processing

Long-Term

  • Tie-in to payment system/gateway?
  • Data saved into MongoDB
  • Employee and management interfaces to see stats on sales, database analysis, modify orders on the fly

Research Links

 
1 Comment

Posted in Design, Food, ITP, Redial