[Opendispense] UI design
Thu Aug 7 13:22:47 2003
On Wed, Aug 06, 2003 at 11:36:03PM +0800, Bernard Blackham wrote:
> 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
email@example.com | I lack the time to make it shorter." - Pascal