> 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