Re: additional HTML+ FORM types (Long)

waterbug@epims1.gsfc.nasa.gov (Steve Waterbury)
Date: Mon, 11 Oct 93 00:22:09 EDT
From: waterbug@epims1.gsfc.nasa.gov (Steve Waterbury)
Message-id: <9310110422.AA06358@epims1.gsfc.nasa.gov>
To: www-talk@nxoc01.cern.ch
Subject: Re: additional HTML+ FORM types (Long)
Cc: waterbug@epims1.gsfc.nasa.gov, mclay@eeel.nist.gov,
        shab@trek.eeel.nist.gov

Kevin Altis writes:

> We have checkboxes, radio buttons, and rudimentary fields. What other types
> would people like to see for FORMs? How about sliders (vertical,
> horizontal, knobs)? Selection lists? Should the user be able to queue
> clicks in an ISMAP area to go along with some other checkbox and field
> selections before being sent off as a single query?

I think what we have includes "toggle buttons" rather than radio buttons -- 
the distinction as I understand it is the on/off state of each toggle in 
as set of toggle buttons is independent, whereas in a set of radio buttons 
there can only be one on at a time (hence the "radio" metaphor) ... when 
you select one, the one that was on turns off, etc.  

Having said that, the two highest priority widgets for my apps 
are (ta-da!) RADIO BUTTONS and (perhaps even more important) 
SELECTION LISTS (see further discussion below).  

Pei Y. Wei writes (about the new ViolaWWW [!]):  

> Not sure we have the same thing in mind, but I've got an <OPTIONS> 
> tag (gonna change that name before release...) that is mapped to a 
> pull-down menu.

Pull-down menus seem to have about the same semantics as selections lists, 
except that selection lists can be scrollable (in our applications, we 
tend to use pull-downs unless they get too long, in which case we have to 
go to a scrollable selection list).  So I guess SELECTION LISTS have a 
higher priority for me, since they are slightly more versatile ... but if 
we can have both -- oh goody goody!

Joel Richardson writes:

> Yes, all of these! (What else?) We are planning to provide as much of
> a database front end through WWW as we can. 

I am of a mind with Joel on using WWW and Mosaic as a database front-end.  
We (the NASA Parts Project Office) have a database application called 
EPIMS (see the CERN WWW Virtual Library subject catalog under 
Engineering) of which at least the public parts I would very much like 
to "Web-ize".  To make the front-end ergonomic, it is essential to have 
"pick-lists" (or selection lists) to assist in composing a query -- i.e., 
the pick-list is actually created by executing a "mini-query" to show what 
is available in the database to include in the principal query.  

Joel continues:

> Right now, we are concentrating
> on querying. But adding things like selection lists to forms would make it
> feasible to do the editorial interfaces as well. Would it make sense to 
> keep the list in a separate document and have a form's input field specify
> the URL? The usual document caching mechanisms would then save a lot of
> unnecessary traffic in many situations.

As it happens, I was just today thinking (in the shower of course) of how 
one might have a viewer to call for presenting pick-lists.  I guess that 
is still possible, but I like this idea of the list coming back in a 
separate "document" very much for several reasons:  

1)  it avoids gratuitously adding another widget (or viewer for that 
matter) for lists (although if it's easy to do, the pull-down menu and 
scrollable list widgets might still be nice ... at least for small 
lists)

2)  selection lists could work fine as hypertexted lists in the same way 
directories are presented now (he said glibly) if they could pass a 
selection from the list as a parameter back to the main query form 
(hmmm ... seems doable ... maybe another remote-control from the config 
file type thing)

3)  would work nicely with the idea of doing a "mini-query" from a 
button ("Select foo-bar from list") in your main form that would 
return a hypertexted list in a separate window, from which your 
selection would be sent back to the window with your main form.  
This could be nice and flexible:  the "mini-query" could a) access 
an existing HTML list (hard-coded), b) access the database server 
that your main query will go to, or c) access a specialty server 
that maintains that particular data item.  

E.g., in the case of our application, we let users select parts by 
classification (Federal Supply Class) and manufacturer (as encoded 
by Defense Logistics Supply Center into the "Commercial And 
Government Entity" codes).  We give them the option of popping up 
lists of FSC's and CAGE codes to include in their query.  The ideal 
situation (I think!) would be to have some national-scale server on 
which FSC's and CAGE codes are maintained, and when your app needs 
one, you just do a query against one of those servers.  Of course 
most sites would cache either the whole database or large parts of 
it if it's used frequently, but the servers should still be there 
to keep your cache up to date.  (Actually, in the case of CAGE 
codes, another level of query is needed, since there are about 
90,000 active ones and you _probably_ don't want a pick-list 
that long!)  

This points to one of my pet ideas (not that it is mine alone!), 
whose time for discussion (or at least reality checking!!) perhaps 
has come:  while it's great to be able to hyperlink around the Web 
discovering things by serendipity, I for one would like to see 
some servers dedicated to systematic indexes of what is out there.  
In my concept, this involves a couple of things:  

*  A consensual set of logical tags (in database parlance, "data 
elements") that would *not* be part of HTML, but could be used to 
logically tag info in an HTML document -- invisible to Mosaic, 
but visible to the indexing engine that is looking for it and that 
would maintain an index of all occurrances of that tag, with the 
corresponding URL (and perhaps position in the doc. somehow) 
and the value tagged in each instance.  

*  A (hopefully simple) indexing server that would accept queries 
on the particular data it supports.  This would probably need at 
least one level of indirection:  a hierarchy of servers of which 
the top level ones would be meta-data servers (knowing all the 
data elements/tags and the data servers for each -- sort of a 
Web-ized "active data dictionary").  

*  A way of agreeing on and "registering" data elements/tags, 
their names and definitions.  Here we go with the urban renewal 
project for the Tower of Babel (which is what we have right now, 
in case you hadn't noticed!).  I am working with Michael McLay 
of NIST on the idea of setting up a server to do this sort of 
registration (a big part of the concept we are working on is 
"object registration", but that's whole nother can of worms!).  

You will notice this scheme needs a bit of bootstrapping:  
it would be great to have at least the meta-data servers set up 
before one starts logically tagging things, so you can see what 
logical tags are "registered" and being indexed.  

I guess this would get us closer (in my view) to the "concept of 
a universal information database" that Kevin Hughes mentions in 
his Guide to Cyberspace.  

This promises to become quite an active and elaborate thread, 
judging by the initial responses.  I think the forms capability 
and the associated database access functionality are features 
that will raise Mosaic to ... uh, what status comes after 
"Killer App"?  "Psychokiller App"??  (naah)  Anyway, onward 
in fulfilling its destiny to be the "Mother of All Clients".  
(But enough vicarious megalomania!)  

Steve Waterbury
NASA/GSFC