[whatwg] Select element suggestion

This does not really address what you're asking for, but rather what you're 
asking for reminds me of something else:

several years ago I used to ask my students to program, as exercises, 
various useful widgets in HTML/JavaScript (color pickers, alarm clocks, 
zoomers and panners and sliders and so forth) -- the sorts of things that 
were not really standardized yet but which might be useful in applications 
of all sorts running in some WWW-like network. Fortunately I now hold 
patents on all of these (just kidding! but I pleased that my prior art 
invalidates new patent claims that might arise).

One of the exercises was to develop a slider in which an ordinal discret 
entry k < n could be chosen as quickly as possible for large integer n. The 
familiar examples I gave were the digital timer on a stove (if you keep your 
finger down long enough it accelerates from 1 min/sec of change to 10 
min/sec of change. Can we make some sort of slider in which the movement of 
the mouse allows the construction of the numbers 162537, 2, or 791 quicker 
than it would take to type that number (or at least most) by hand. The 
detection of both duration of the mousedown event as well as subtle changes 
in its positioning, I argued, could be used to do just that. None of the 
students (all undergrads) ever accomplished quite what I had in mind, so 
I've de-elevated (or elevated) the thing to extra credit status. The problem 
is sort of similar, how best to enable a user to select from a large number 
of possibilities. In the case of certain objects, like magnitudes and 
numbers, there is a natural and intuitive ordering of options, such that 
some loglinear interface to an accelerometer allows (in theory) linear-time 
access to 2^n options. Likewise in the case of alphabetization of 
western-language style strings: relying on the mapping that people 
presumably internalize between the alphabet and the line, a slider (like a 
selection list) maps n options onto points on a line. The irregularities 
along that line posed by discontinuity of actual words, is arguably 
negligible. When it comes to semantically discrete categories, the prospect 
of speeding users' ability to choose from among N options, depends on either 
a) the division of those N options into logN intuitive categories (such was 
the goal of Dewey and L of Congress classifications) -- think of cascading 
submenus in which logN branches in a tree ultimately accesses any of the N 
leaves, or in the ability to somehow map those N options onto a linear (or 
multidimensional) manifold that intuitively maps the space. The problem in 
either case is in customizing our interface to people's intuition about the 
Semantic proximity (in the original sense of the term semantic in 
linguistics as differentiated from the newfangled spec-speak usage of the 
term) of the various options presented.

You've suggested an approach which could involve server side intervention: 
as options are more frequently chosen (across multiple users), those options 
eventually float closer to the top, and the spec, if responsive to your 
suggestion, would presumably allow the author to choreograph this 
client-server interaction. Assuming that frequency of choices tends to obey 
some sort of Zipf's law, then the top 4/n items would account for 
k(1/2+1/4+1/8+1/16) of the options chosen for some k, hence simplifying life 
for lots of people. I'm not sure Zipf's law though would actually apply to 
most things though. Population across geopolitical districts (states and 
countries) is probably distributed more like a Bell curve than like word 
frequencies ("the" "of" "a"), so the advantage may not be so pronounced as 
we might hope.

But as long as we're open to the kind of approach, that allows the author to 
choose some soft of server-optimized ordering then it seems like broader 
possibilities arise. Telling the server to perform a principle components 
analysis based on some lexico-semantic criterion and then to map the options 
in a 2D plot, or to find the most intuitive taxonomy (based on method A B or 
C) for our options would also become possible. Even in the simplest case: 
maximize users' selection speed for a large set of contiguous integers, the 
situation becomes rather fun. So fun, in fact, that it would be worth 
playing with.

Again, much of this is rather tangential to your idea, but the idea is just 
intriguing enough to provoke thought.

cheers,
David Dailey

----- Original Message ----- 
From: "Csaba Gabor" <csaba2000@yahoo.com>
To: <whatwg at whatwg.org>
Sent: Tuesday, July 15, 2008 8:14 AM
Subject: [whatwg] Select element suggestion


>I know it is rather late in the game, but there is an attribute that would 
>be immensely useful for SELECT elements.  It is motivated by a desire to 
>make web page interaction more efficient.
>
> It is frequently the case that SELECT elements of size 1 (drop downs) are 
> quite long, requiring scrolling to reach most of the options.  For 
> example:
> Year a person was born in
> States of the US
> Countries of the world
> Height (in inches or cm)
>
> This necessitates a minimum of 4 actions for most of the options (click to 
> pull down the select, click on scroll bar, drag scroll bar, click desired 
> option) vs. 2 actions (the first and last) for those options near the top. 
> Clearly the time difference is significant, especially when the same 
> select element must be selected on repeated visits.  Furthermore, the 
> overwhelming liklihood is that only a few of the many options will ever be 
> of interest to any individual.
>
> Therefore, it makes sense to float those values to the top of the select 
> element in a reasonable way.  What's reasonable?  I would like to suggest:
> frequencyLimit=percent
>
>
> <SELECT name=states frequencyLimit=16>
> <option>Alabama</option>
> <option>Alaska</option>
> <option>Arizona</option>
> <option>Arkansas</option>
> ...
> <option>Wyoming</option>
> </select>
>
> This would say that if any element is selected 16% or more of the time, it 
> floats to the top part of the select element.  It would apply to any 
> select element of the same name and frequencyLimit at [for efficiency 
> reasons] the current page's directory level or lower.
>
> Specifically, a reasonable UA implementation would be:
> For each select element of a minimum size (say 9 elements) with 
> frequencyLimit set, compute a checksum of the select element (e.g. md5) 
> and if that matches the previous value, then frequency analysis should be 
> done (otherwise, start with a fresh slate).  The initial position (for 
> reinsertion purposes) of each option and frequency count of each option is 
> stored.
>
> If the frequency of an option being selected reaches the threshhold, it is 
> moved to the top portion of the select element.  If the frequency drops 
> below this threshhold, it is moved back to its original position.
>
> This is clean, backwards compatible, and offers a clear advantage in 
> usability, especially for impaired users.  It is something that could be 
> implemented by javascript on individual web pages, but it makes more sense 
> to have a uniform approach.
>
> A few comments/pitfalls:
> 1.  If frequencyLimit=p, this does not float the Math.floor(100/p) most 
> frequently selected options to the top.  At most that many will get 
> floated to the top.  For example, with frequencyLimit=33, if Oregon and 
> New York are both selected 40% of the time, while ILlinois and California 
> are selected 10% of the time, only Oregon and New York will float to the 
> top since only they exceed 33%.
>
>    To consider a second example in this light, frequencyLimit=5 might 
> seeem to mean that one can expect 20 elements to float to the top, but it 
> is extremely unlikely that there would be such uniform distribution of 
> selections.  It's far more likely that fewer than 10 elements float to the 
> top.
>
>    One could put lomething like frequencyLimit='.2', effectively floating 
> anything that is selected to the top.  However, this would create two 
> separate lists within the select, likely leading to confusion.  If M is 
> the maximum number of options that can be seen at any one time, probably 
> the frequencyLimit should ensure that no more than M options get floated 
> to the top.
>
> 2.  Of course this proposal represents a demand on the UA to cache the 
> information across sessions as with cookies, so it makes sense for the UA 
> to limit the number of such cached select elements under any particular 
> domain/directory.  In addition, there is some exposure of privacy, so 
> these saved values should perhaps live and die with corresponding cookie 
> information.
>
> 3.  As outlined above, the scheme does not work for dynamically populated 
> select elements.  However, in those situations, frequencyLimit should not 
> be set a priori (in the HTML); rather, it should be set after the select 
> element is populated.  At this point, the UA would then compare the select 
> element against any cached image (ie. checksum).  This also provides a 
> mechanism for the server to clear out cached information, by setting 
> frequencyLimit on an empty select element.
>
> 4.  Everything can apply just as well to multiselect elements and to 
> elements of size greater than 1.
>
> 5.  One could envision only using the last n selections (where n is say 
> 100) for analysis, but this puts an additional implementation burden on 
> the UA.
>
>
> Csaba Gabor from Vienna
>
>
>
>
>
>

Received on Tuesday, 15 July 2008 10:10:12 UTC