Q: Not *really* a C question...

[all]

Hi,

This isn't a C question more of a programming question, so I hope it's
ok to post here (I will be coding it in C!)

I've been racking my brains about this little problem and can't see
wood for the trees...

I have to write a c module that gives the user a menu interface to
various options. Dependant on the user, some/most/all menus can be
'turned off'. Rather than have a 'dead-end' if the user navigates to
an 'off' item they should only be able to see the menu options they
can alter.

Example:

FULL MENU
-------------

A-------------------------B
| |
a.1 - a.2 b.1 - b.2
| | | |
x a.2.1 - a.2.2 x x
| |
x x
ALLOWED MENU for user John
=============== ===

A.1----------------------B
| |
x b.1 - b.2
| |
x x

x = function, i.e. do something such as set screen orientation
A, a.1 = menu option eg A is "Screen", and a.1 is "Orientatio n"
So for Johns menu a.2 and subordinates are not allowed. To keep the
menu structure 'tidy' I have to promote the a.1 option to where A was
as this is only option available on this branch now.

Now the menu must not be 'hard-coded' to allow for
expansion/alteration, so I have created a link-list that points to the
items partner left and right and up and down. I *think* the best way
for me to handle menu items being on or off is to 'fix' the link list
to the full menu structure and have a option within each linked-list
to say if it's off or on.

Is this 'sensible'? I wonder because I can't see an 'easy' way of
dealing with menu items being promoted to higher levels within the
code.

Any help greatly appreciated.

[Mark Bluemel]

al*@sea.org wrote:

Hi,

This isn't a C question more of a programming question, so I hope it's
ok to post here (I will be coding it in C!)

[description of a design for a menu system which dynamically adjusts to
the user snipped]

"ok to post here"? Not really, IMHO.

This is a question about User Interface design and there are almost
certainly better places to look than a group about the C language.

As this is outside my sphere of expertise I'm unable to make a good
suggestion of online resources, but I'd probably start in a good
reference library as I expect your problem has a standard(ish) solution.
I very much doubt that you are the first person to have encountered it.

[all]

On Tue, 14 Aug 2007 10:43:53 +0100, Mark Bluemel
<ma**********@p obox.comwrote:

>al*@sea.org wrote:

>Hi,

This isn't a C question more of a programming question, so I hope it's
ok to post here (I will be coding it in C!)

[description of a design for a menu system which dynamically adjusts to
the user snipped]

"ok to post here"? Not really, IMHO.

Ok.

>This is a question about User Interface design and there are almost
certainly better places to look than a group about the C language.

Well the user interface is 'designed' I just need to work out how to
code it...

>As this is outside my sphere of expertise I'm unable to make a good
suggestion of online resources, but I'd probably start in a good
reference library as I expect your problem has a standard(ish) solution.
I very much doubt that you are the first person to have encountered it.

That's what I thought, not inventing the wheel here...but been unable
to find anything so far, hence the post.

Regards,
John.

[Richard Heathfield]

al*@sea.org said:

<snip>

Now the menu must not be 'hard-coded' to allow for
expansion/alteration, so I have created a link-list that points to the
items partner left and right and up and down. I *think* the best way
for me to handle menu items being on or off is to 'fix' the link list
to the full menu structure and have a option within each linked-list
to say if it's off or on.

Is this 'sensible'?

Yes. Another possibility is to maintain a "master" menu that contains
all the options, and create a copy of the menu that contains only the
items allowed for that user. That involves extra space, of course, and
a per-login time cost, but it means that your per-menu-display time
cost is lower.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Very.Little.Gravitas.Indeed]

On Aug 14, 11:31 am, [e-mail] wrote:
<snip>

I'd recommend you read more about User Interfaces and consider if the
decisions you are making are correct for the interface.

Consistancy is considered a good thing in user interfaces, so
magically dissapearing menus, would be a bad thing as far as
consistency goes.

Consider the annoying menus in Microsoft Office, or the way it deal
with the Start Menu, hiding items that are not used for some time.
Whether you like this or not its not good UI design.

The whole code to hide menus sounds like extra work, extra code that
needs to be debugged and maintained, if there is a good enough reason
you can't just have the menu options listed but unavailable, then you
probably have a good enough reason to create separate clients for each
user level. It'd be much more secure only to include the code each
user level requires in a client. It may sound paranoid but I figure if
you can't show unavailable items in a menu you must be into secret
service application programming, in which case the extra work is
justified by the extra security.

[all]

On Tue, 14 Aug 2007 10:04:52 -0000, "Very.Little.Gr avitas.Indeed"
<Ve************ *************@g mail.comwrote:

>On Aug 14, 11:31 am, [e-mail] wrote:
<snip>

I'd recommend you read more about User Interfaces and consider if the
decisions you are making are correct for the interface.

Consistancy is considered a good thing in user interfaces, so
magically dissapearing menus, would be a bad thing as far as
consistency goes.

Consider the annoying menus in Microsoft Office, or the way it deal
with the Start Menu, hiding items that are not used for some time.
Whether you like this or not its not good UI design.

The whole code to hide menus sounds like extra work, extra code that
needs to be debugged and maintained, if there is a good enough reason
you can't just have the menu options listed but unavailable, then you
probably have a good enough reason to create separate clients for each
user level. It'd be much more secure only to include the code each
user level requires in a client. It may sound paranoid but I figure if
you can't show unavailable items in a menu you must be into secret
service application programming, in which case the extra work is
justified by the extra security.

The requirements for interface states that the menus must be
selectable (on/off) by an 'admin' and that 'off' menus are hidden from
the user. Not so they don't know that there are things to alter but
that they don't have to 'trudge' through things they cannot alter.
Also there won't be a light-mid-high level user that I can create
templates for - it *must* allow zero to full access and anywhere
in-between.

Maybe I mislead people in my question...

It is not a design of the UI that I query, that is 'set-in-stone' for
me, but I just can't see any way to code the requirement (without lots
of switch statements and if else's)! The other 'set-in-stone'
requirement is that the code needs to be oblivious to the menu
structure (as I said the menu structure is planned to be a
linked-list, and that list is the only place where the menu is
defined/hard-coded). So my switch/if routines will/may not be
permissible as they will need to be hard-coded against a set menu
structure.

Kind regards.

[Bart.van.Ingen.Schenau]

On 14 aug, 11:31, [e-mail] wrote:

Hi,

This isn't a C question more of a programming question, so I hope it's
ok to post here (I will be coding it in C!)

I've been racking my brains about this little problem and can't see
wood for the trees...

I have to write a c module that gives the user a menu interface to
various options. Dependant on the user, some/most/all menus can be
'turned off'. Rather than have a 'dead-end' if the user navigates to
an 'off' item they should only be able to see the menu options they
can alter.

<snip>

So for Johns menu a.2 and subordinates are not allowed. To keep the
menu structure 'tidy' I have to promote the a.1 option to where A was
as this is only option available on this branch now.

Now the menu must not be 'hard-coded' to allow for
expansion/alteration, so I have created a link-list that points to the
items partner left and right and up and down. I *think* the best way
for me to handle menu items being on or off is to 'fix' the link list
to the full menu structure and have a option within each linked-list
to say if it's off or on.

Is this 'sensible'? I wonder because I can't see an 'easy' way of
dealing with menu items being promoted to higher levels within the
code.

The requirement that lone items in a sub-menu must be promoted is not
sensible at all, IMHO.
I would try very hard to put that requirement under discussion. If
necessary, with a prototype that shows the surprising effects of
enabling/disabling an option some levels deep.

If that requirement can be dropped, then you can test ion the display
routine if a menu entry is enabled (and for sub-menu's if they have
any enabled items).
If that requirement has to be fulfilled, I would go with the
suggestion from Richard Heathfield to use a master menu containing all
elements and for each user a (dynamically created) shadow menu that
reflects the visible tree for that user.

>
Any help greatly appreciated.

Bart v Ingen Schenau