Searching \ for 'Menu system' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=menu+system
Search entire site for: 'Menu system'.

Truncated match.
PICList Thread
'Menu system'
1998\11\05@090245 by Mark Birks

flavicon
face
Hi listers,

Anybody got any advice/examples on implemeting a menu system using 4 push
buttons and a 24x2 character LCD.

Is there a 'standard' way to present menu and submenu options and confirm
cancel etc ?

Please mail me direct as I can only get the digest at present due to IT
limitations.....

1998\11\05@113200 by David Blain

picon face
I am also in the process of writing my own menu system and would be
interested in any feedback.

I am still in design mode, but this is what I was thinking:

My project has need for a Serial EEProm (and has extra room), so I was
thinking of storing the menu data in it.

I am trying to design a layout for the data that will store the menu
hierarchy, what the action of the four buttons represent, and a function
indicator(s) of what should be executed on entry and exit of the menu
choice.

The actions/Function indicators could be as simple as a index into a jump
table for the appropriate code.

Once I have a design of the data layout, I will most likely create a windows
application that will build/simulate the menu, as well as provide a way to
download it into the EEProm.

If anyone has any better suggestions, please let me know.

David.



{Original Message removed}

1998\11\05@131707 by Peter L. Peres

picon face
On Thu, 5 Nov 1998, Mark Birks wrote:

> Anybody got any advice/examples on implemeting a menu system using 4 push
> buttons and a 24x2 character LCD.
>
> Is there a 'standard' way to present menu and submenu options and confirm
> cancel etc ?

There is no such thing, but imho, there are two interesting sources:

1. A book called 'User friendly GUI design' that is not connected to any
OS maker in particular (I think it is from Prentice-Hall but don't take my
word for it).

2. The most commonly used device that has such a menu - e.g. a cellular
phone for example.

Peter

1998\11\05@152336 by Mark Willis

flavicon
face
Mark Birks wrote:
>
> Hi listers,
>
> Anybody got any advice/examples on implemeting a menu system using 4 push
> buttons and a 24x2 character LCD.
>
> Is there a 'standard' way to present menu and submenu options and confirm
> cancel etc ?
>
> Please mail me direct as I can only get the digest at present due to IT
> limitations.....

 Up, Down, Select {Or Choose}, Escape would be MY choices (Escape moves
up a menu, Select moves down the hierarchical menu tree or picks
something to toggle, up and down scroll the selections (aka Next and
Previous selection in this menu)

 That makes the most sense to me, seems to work pretty well on consumer
devices (Laser Printers, etc.)

 Another alternative would be Yes, No, Up, Down but then you need neat,
short, clear, concise, yes/no questions <G>  "We engineers aren't always
good at those" <Heh!>

 Spend some time on your menu texts getting them clear & understandable
- for a totally hypothetical printer, for example, this is clear:  (I
show some various thoughts, any are pretty clear, current settings
"should" always pop up first as if they're right the user then can hit
Escape!)  And it's not a bad idea to use line 1 as the "current
setting", and scroll line 2 so the user can see they've changed the
setting...

 Paper Size
   Is Letter
   -> Legal
   -> A4
   -> Envelope
 Form Type
   Is Pinfeed
   -> Sheet Feed/Envelopes
   -> Lower Hopper
 Default Font
   Is Set to Courier
   Change to Pica
 Default Mode
   Mode Is Quiet
   Make It Regular
   Make It Fast
 Interface
   == Parallel {SPP}
   -> Serial {RS-232}
   -> Infrared {IRDA}

 But this would be a nightmare:  (I've seen something FAR worse than
this.  Didn't buy it!)

 Paper Size        <No way to tell what it's set to now!>
   Ltr             <Too many abbrvs.  Unclr.>
   Lgl
   A4
   Env
 Form
   Cont.           <Huh??>
   Single          <Single WHAT?!>
   Lower           <Lower WHAT!?>
 Def.
   Fix             <Def Fixed WHAT?!?>
   Prop
 Defs              <Too similar to Def.>
   Qt.             <Enough to give you a headache, nu?>
   Reg.
   Qk.
 Intfc.            <Tech Support Calls: "What's an Intfc.?">
   Par.
   RS232.          <Many consumers dunno what that is!>
   IRDA

 Mark, spam_OUTmwillisTakeThisOuTspamnwlink.com

1998\11\19@150959 by Mark Willis

flavicon
face
Mark Birks wrote:
>
> Hi listers,
>
> Anybody got any advice/examples on implemeting a menu system using 4 push
> buttons and a 24x2 character LCD.
>
> Is there a 'standard' way to present menu and submenu options and confirm
> cancel etc ?
>
> Please mail me direct as I can only get the digest at present due to IT
> limitations.....

 Up, Down, Select {Or Choose}, Escape would be MY choices (Escape moves
up a menu, Select moves down the hierarchical menu tree or picks
something to toggle, up and down scroll the selections (aka Next and
Previous selection in this menu)

 That makes the most sense to me, seems to work pretty well on consumer
devices (Laser Printers, etc.)

 Another alternative would be Yes, No, Up, Down but then you need neat,
short, clear, concise, yes/no questions <G>  "We engineers aren't always
good at those" <Heh!>

 Spend some time on your menu texts getting them clear & understandable
- for a totally hypothetical printer, for example, this is clear:  (I
show some various thoughts, any are pretty clear, current settings
"should" always pop up first as if they're right the user then can hit
Escape!)  And it's not a bad idea to use line 1 as the "current
setting", and scroll line 2 so the user can see they've changed the
setting...

 Paper Size
   Is Letter
   -> Legal
   -> A4
   -> Envelope
 Form Type
   Is Pinfeed
   -> Sheet Feed/Envelopes
   -> Lower Hopper
 Default Font
   Is Set to Courier
   Change to Pica
 Default Mode
   Mode Is Quiet
   Make It Regular
   Make It Fast
 Interface
   == Parallel {SPP}
   -> Serial {RS-232}
   -> Infrared {IRDA}

 But this would be a nightmare:  (I've seen something FAR worse than
this.  Didn't buy it!)

 Paper Size        <No way to tell what it's set to now!>
   Ltr             <Too many abbrvs.  Unclr.>
   Lgl
   A4
   Env
 Form
   Cont.           <Huh??>
   Single          <Single WHAT?!>
   Lower           <Lower WHAT!?>
 Def.
   Fix             <Def Fixed WHAT?!?>
   Prop
 Defs              <Too similar to Def.>
   Qt.             <Enough to give you a headache, nu?>
   Reg.
   Qk.
 Intfc.            <Tech Support Calls: "What's an Intfc.?">
   Par.
   RS232.          <Many consumers dunno what that is!>
   IRDA

 Mark, .....mwillisKILLspamspam@spam@nwlink.com

1998\11\19@151825 by Dave VanHorn

flavicon
face
acter LCD.
> >
> > Is there a 'standard' way to present menu and submenu options and confirm
> > cancel etc ?


If nothing else, make sure that the "I didn't mean it, get me out of
here without changing anything" key is always the same one!

1998\11\20@072737 by Peter L. Peres

picon face
On Thu, 5 Nov 1998, Mark Birks wrote:

> Anybody got any advice/examples on implemeting a menu system using 4 push
> buttons and a 24x2 character LCD.
>
> Is there a 'standard' way to present menu and submenu options and confirm
> cancel etc ?

There is no such thing, but imho, there are two interesting sources:

1. A book called 'User friendly GUI design' that is not connected to any
OS maker in particular (I think it is from Prentice-Hall but don't take my
word for it).

2. The most commonly used device that has such a menu - e.g. a cellular
phone for example.

Peter

1998\11\20@075554 by David Blain

picon face
I am also in the process of writing my own menu system and would be
interested in any feedback.

I am still in design mode, but this is what I was thinking:

My project has need for a Serial EEProm (and has extra room), so I was
thinking of storing the menu data in it.

I am trying to design a layout for the data that will store the menu
hierarchy, what the action of the four buttons represent, and a function
indicator(s) of what should be executed on entry and exit of the menu
choice.

The actions/Function indicators could be as simple as a index into a jump
table for the appropriate code.

Once I have a design of the data layout, I will most likely create a windows
application that will build/simulate the menu, as well as provide a way to
download it into the EEProm.

If anyone has any better suggestions, please let me know.

David.



{Original Message removed}

1998\11\20@165326 by Martin McCormick

flavicon
face
       One question to ask in a user interface is "Can you do it in
the dark (without seeing the screen)?"  If the answer is no, then
there is a problem, simple as that.  Now, I did not say that it has to
be easy and require no thought or planning by the user of the
interface, but it is a no-go if there is not some way to start from a
known state and step through to the desired state.

       People who are blind or for what ever reason can not see the
screen of the device should still be able to have a fall-back method.

       One could build a snow-capped mountain in Death Valley with
the junk that is made today that might be usable by people who are
blind, but is totally useless because there isn't any way to begin at
the beginning or know where the end is.

       There was a lecture recently given on our campus about the Y2K
problem and how it is actually a manifestation of a much more serious
flaw in human logic which basically says that we tend to believe that
something always will be true because it has been true up to now.

       We all tend to think in this way if we aren't careful because
it is impossible to try every possible logical scenario to see what
will ultimately render our wonderful design useless.  The real killing
blow is to assume that this is the way it should be and that nobody
should need anything else.  That turns a simple oversite in to a _BIG_
mistake like Microsoft Windows or like most of the digital heat and
air controllers out there or the control units for microwave ovens
just to skim the surface.

       What we need is not to try to anticipate every possible
situation, but to make the user interface with a port in to and out of
its little mind so that things the designer never even dreamed of can
be interfaced with the device without major destruction.  To me,
information is sacred and should be preserved in electronic form right
to the bitter end.  That way, everybody can bring what they need to
make the device work for them.

       My idea of the ultimate menu design would be to build an
interface that works for most people but with an optical I/O port
similar to the IR ports on day planners and other devices which can
allow electronic communication as well as the traditional "see the
screen and push the button" kind of thing.

Martin McCormick WB5AGZ  Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group

1998\11\20@172613 by Reginald Neale

flavicon
face
Martin said:

(big snip)
>        We all tend to think in this way if we aren't careful because
>it is impossible to try every possible logical scenario to see what
>will ultimately render our wonderful design useless.  The real killing
>blow is to assume that this is the way it should be and that nobody
>should need anything else.  That turns a simple oversite in to a _BIG_
>mistake like Microsoft Windows or like most of the digital heat and
>air controllers out there or the control units for microwave ovens
>just to skim the surface.
>
>        What we need is not to try to anticipate every possible
>situation, but to make the user interface with a port in to and out of
>its little mind so that things the designer never even dreamed of can
>be interfaced with the device without major destruction.  To me,
>information is sacred and should be preserved in electronic form right
>to the bitter end.  That way, everybody can bring what they need to
>make the device work for them.

The whole question of optimizing human interfaces is best explained in a
book called "The Psychology of Everyday Things," by Donald Norman.

Well worth reading for anyone who is a designer.

Reg Neale

1998\11\24@120724 by John Payson

flavicon
face
|        My idea of the ultimate menu design would be to build an
|interface that works for most people but with an optical I/O port
|similar to the IR ports on day planners and other devices which can
|allow electronic communication as well as the traditional "see the
|screen and push the button" kind of thing.

One thing I'd like to see along the same principle would be for
devices that use remote controls to have defined controls that
operate to put the device into a certain state.  For example, while
it's often useful to have things like "power" and "mute" function
as toggles, there are times (esp. when using external devices to
control the equipment) when it would be much more useful to have
seperate "power on" and "power off" functions, and a "mute" function
which didn't toggle (volume up should cancel mute, so there probably
isn't a need for a special "cancel mute" code).

Given that only a fraction of the possible remote codes are actually
used, it add nothing to the per-unit cost to incorporate such functions
into a television or VCR, but it would be quite handy to the end user.
The maker of the product could then publish a list of all the codes (even
those never sent by its own remotes) on a web or ftp site.

How does that sound for an idea?

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...