[Opendispense] UI design

Nick Bannon nick@ucc.gu.uwa.edu.au
Thu Aug 7 13:22:47 2003

On Wed, Aug 06, 2003 at 11:36:03PM +0800, Bernard Blackham wrote:
> Greetings,
> Here's a brain dump of my plans for the UI. Please rip it to pieces.  :)

Well, there is a risk that we're UI overloading the poor little keypad
and display... I wonder about a flexible keyboard, or capacitive
sensors behind the glass, or... Still, in the meantime what we've got
is what we've got. ::-)

> Main menu:
>   - Coins inserted:
>     - Take a selection number & act like a normal vending machine.
>       Drinks may be dispensed for $1.

Some drinks can be more, but I guess this price can be fetched like any
other (and rounded up to the nearest 5 cents).

Unused selection prefixes include 00, 22, 55, 88, 99. 00<slotnumber>
sounds good for drinks - 000, 001, 002, 003, 004, 005 and the quad slot
006. 007 as a synonym for the quad slot (coke!) sounds good.

(There's some potential inconsistency here. You could number the slots
1-7 which would make 007 come naturally and leave 000 free. The coke
brain firmware, and dispense, calls them 0-6. The sticker inside the
drink machine calls them 7-1. (ie 1 is the quad slot) Hmmm. )

>       The door may not be dispensed, no matter how much is put in :)
>   - 5-digit UID entered:
>     - Say "Welcome <username>. Enter PIN."
>       Verify PIN number.

Perhaps that needn't be necessary for adding money to an account.

>       - If a selection is entered, dispense it. A selection can be:
>          * row/column of vending machine item
>          * special numbers denoting door, drinks, or money (withdrawl)

We may not want to allow withdrawls, this should perhaps be a
deprecated, manual action by a cashbox keyholder in all cases. We have
given people credit on occasion that we'd prefer the didn't withdraw in
cash and there is of course the chance someone could find a bug or
vulnerability and fill up their account.

Still, it's a reasonable request for people to make...

> And return to the main menu after any of these operations (so people
> with have to authenticate several times to do multiple
> transactions) - bad thing?

"Press 1 to follow-on . . . <timeout>"?

The rest of the interface should have a (longer) timeout, too, of

I think a flowchart for documentation and a foolproof, bug-free, state
machine is called for. Naturally, you shouldn't listen to anyone (e.g.
me ::-) ) who seems to want to make it _more_ complex.


   Nick Bannon   | "I made this letter longer than usual because
nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal