Re: SELECT structures with lots of OPTIONs (fwd)

Once upon a time Dave Raggett shaped the electrons to say...
>If the purpose of the example menu is just to select between 3
>versions of the OS (3.7.1, 3.7 and 3.5) it would be much simpler
>to ask for just that without introducing the superfluous Option
>groups for "Comm Servers", "PortMaster 2" and "PortMaster 3".

The thing is, that example is very shortened.  In real life there are over
30 code revisions in the list.  And five product lines.  And there is some
overlap between them.  I didn't want to make a long example, just show
enough to demonstrate the capability of simplifying navigation with grouping.

>If the selection of PortMaster 2 and 3 has a real meaning then
>the server script would like to know this. This suggests that

No meaning that is important to the server.  It just makes life easier for
the human since I'd rather see the 3 revisions for the PM-3 and not have to
find them in a list of 30+.  And I picked this example deliberately from
expeirence.  We've had users get confused with a long list.  And I have seen
many sites using select.  For example see
<URL:http://www.baynetworks.com/Products/nav/DA510-2742EC-B-nav.html#docs>
And hit the 'related documents' select list.  They have 3 sections, and 
embedded labels in the list.  This is a kludge that I have seen used many
times.

Why?  Because people are looking for the grouping abilities we're discussing
and making due as best they can.  But it is certainly not the best way to
do things.

>To avoid confusing people with "old" browsers who can't see the
>option groups, we need to make this distinction in the labels.
>At the same time we don't want to clutter up the labels for
>people who *can* see the option groups. How?

Good point.

>The most obvious solution is to add a label attribute to the
>OPTION elements for use with new browsers. When present, this
>attribute is used in preference to the element content. You
>can now design your menus to offer the clearest labels to
>users of both old and new browsers, e.g.
>
> <SELECT name="ComOS">
>   <OPTGROUP label="Comm Servers">
>     <OPTGROUP label="PortMaster 3">
>       <OPTION label="3.7.1"
>               value="pm3_3.7.1">PortMaster 3 with OS3.7.1
>       <OPTION label="3.7"
>               value="pm3_3.7">PortMaster 3 with OS3.7
>       <OPTION value="pm3_3..5">PortMaster 3 with OS3.5
>     </OPTGROUP>
>     <OPTGROUP label="PortMaster 2">
>       <OPTION label="3.7"
>               value="pm2_3.7">PortMaster 2 with OS3.7
>       <OPTION label="3.5"
>               value="pm2_3.5">PortMaster 2 with OS3.5
>     </OPTGROUP>
>   </OPTGROUP>
> </SELECT>

The problem I have with this is still the container issue.  What about
when, as in my case, it doesn't need differentiation.  In fact, we do not
want it.  Since any code that shares the same number shares the same 
features, we don't care what platform it is on.  The grouping is for
improving things on the user end.

We end up with duplicates again.

>This functionality is greater than Megazone's relatively complex
>proposal, and at the same time is much easier to understand.

Duplication when differentiation is undesirable is the only drawback I
can see to the container concept though.  What do other people think?
It is still better than no grouping, maybe I'm to hung up on that one point.
I'd love to hear some feedback.

Either way, I do like the label idea for being able to present different
content in the browsers that support it.  I think that would benefit the
proposal either way.

-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/> 
Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Received on Friday, 17 October 1997 19:47:07 UTC