[Javascript] Thoughts on building form elements/similar divs

Paul Novitski paul at novitskisoftware.com
Thu Jul 7 01:26:56 CDT 2005


At 07:06 PM 7/6/2005, Mike Dougherty wrote:
>I'm wary of presenting a user with a moving target (the select box) and 
>having to populate a text box with the contents of the selection then 
>moving again to another place to click [possibly I'm not envisioning your 
>proposed design]

I wasn't really thinking of anything "moving" from the perspective of the 
user, but rather a list containing the same options that drops down 
whenever you click on an input field, very much like a combo box.

When we right-click on a series of images on a page, the same context menu 
appears each time to give us the options to save, send, etc.  It's really 
the same menu each time, just appearing in different spots on the 
screen.  That's the kind of thing I was suggesting.

You're absolutely right that a 2300-option list seems totally 
unwieldy.  What a hassle to have to scroll down, and down, and down to find 
one particular item!  The number 2300 is a big red flag warning of bad 
design ahead, and I hope it gets split into a list tree for the users' sake.

Maybe I'm being overly conservative, but I'm still wary of xmlhttp because 
it's not cross-browser-friendly, and I prefer to stick with server-side 
calls when I can keep the page quite light, as in 
http://dandemutande.org/ResourceGuide/

Regards,
Paul


>What about using a single-valued drop-down select for category, and an 
>select list (say 8 lines) showing the options in that category (to help 
>manage a 2300 item list) Then have a "list mover" type control for putting 
>the selected options into a second 'chosen items' select list.  This would 
>help the user see their multiple-selection choices and manage multi-select 
>in a (thanks to many existing OS/user app dialogs) more obvious way.
>
>I also wonder if this application would be a good candidate for using 
>xmlhttp calls to build the picklist as a result of the category 
>select.  With some lazy cacheing, the page could be presented without the 
>weight of the 2300 items, and build up those items (in the DOM) as they 
>are requested. The usual caveat of AJAX pages not having a definate URL is 
>negligible because we're talking about the contents of an on-demand list 
>box rather than page layout.  The javascript gets more complicated, and it 
>would be helpful to understand the DOM - but an interface like that would 
>be pretty slick.  (and if you had a publically available page, would make 
>a nice technology showcase for your favorite "how to" site to link to)
>
>ok, now i'm wildly off topic for the original question  :)





More information about the Javascript mailing list