Serving multiple selections
Selections
When a W3 server offers the user a choice of options, typically it
will do this with a hypertext page with pointers to virtual pages
whos addresses contain a coded version of the option that the user
has selected. (See making a server for existing data)
So, for example the page /calendar may ask "which page do you want?"
and have several anchors to point to pages /calendar/monday, calendar
tuesday, etc. (see example)
Multiple selections
This can be extended to multiple selections. (See Example case). In
this case, the address fo a document may contain a serious of options
separated for example by "plus" signs.
Suppose that in Gary's example, we represent the particle types by
short acronymous:
> GH _ GAUGE AND HIGGS BOSONS
> LU _ LIGHT UNFLAVORED MESONS
...
> BB _ BOTTOM (BEAUTY) BARYON
> ET _ SEARCHES FOR FREE QUARKS, ..., COMPOSITENESS, ETC.
and then suppose that the initial page is called /query. Query itself
is not an index because there is not enough information for the search.
The user is given a list of choices pointing to nodes named /query/GH
etc.
This is a straightforward selection. Once he has selected GH, for
example, he can now be given BOTH the option of searching at that
poin, and ALSO links to modified searches:
- /query/GH+LU
- Also search LU. An almost identical will be displayed,
but instead of the links to "Also serach LU" there will be one to
"Don't search LU", a link back to /query/GH
- /query/GH+OL
- Also search OL. As above but for LU read OL. And so on.
There ar e19 of these links, which basically allow him to toggle on
or off the 19 groups in the list. If 19 is too many, you could route
him through a single option "Add/remove groups" called say /query/GH+LU/CHANGE
but that would make the selection process slower. With direct links,
the result will look very much like pressing radio buttons, in that
clicking on an option should immediately present him with a page with
that one option toggled.
There are also links to select at the next level down. leading to
pages:
- /query/GH/Omega
- Specify a search for Omega.
- /query/GH/Omega2250
- Specify a search for Omega(2250). (etc)
Suppose the user follows GH first, then BB and end up in /query/GH+BB.
He then follows Omega and then lambda to end up at /query/GH+BB/Omega+Lambda.
He still has 19 links to toggle particle classes, 4 links to toggle
particles, but he now has also 6 links to select what sort of data
he wants returned. he ends up with a node looking like
/query/GH+BB/Omega+Lambda/H+D
Which means that he wants all all header and decay data for the Omega
and Lambda particles. That document could be just a menu, with a
(prominent) link to the data itself, or it could contain the data
itself.
Holding back the data
If your search is fast, then you might want to do it every time. If
it is slow, you might want to make sure the user has the query absolutely
right, and then follows a link to the actual data. If you can mention
how many lines of data he will get, then that might be useful information
to include in the link:
Review Results (12367 lines)
will make him pause and save some network traffic! (The link there
is dummy).
Line mode and the text input altrenative
It is true that with the line mode browser you have to type in a lot
of numbers. To ease that, you could set the ISINDEX flag on your documents,
and allow some sort of text to be typed in by users who know the ropes
and want to get there fast. You have to pick a syntax which is simple,
but just toggling any recognizable keywords in the user input would
work OK in this case. It would allow the person to say
FIND OMEGA ALL
and immediately get something back. This would allow him to make
a command line alias forthe PDG data so that if very command-line
oriented he could type
alias pdg www http://etce.etc.etc/query
pdg omega all
which would really appeal to a certain set of people (which includes
me!). Keep this low-profile in parallel with the hypertext method.
Put a link to the doc on how to use a text search in at least the
entry page.
Tim BL