A couple of times lately, I've brought up the notion that clients should
handle highlights (the terms that match a search query) better. It's
rather inefficient to force the search server to proxy documents just so
that it can add highlights. Worse, it takes the decision about *how* to
highlight (bold? underline? surround with asterisks?) out of the user's
hands (barring some sort of ugly protocol for telling the server).
We'd like to suggest a very simple approach -- a highlight tag. This way,
our server could add the highlight tag in the appropriate places, but it
would be up to the browser (under the user's control, presumably) to decide
how to identify highlights in the text (turn them red, underline,
whatever). An appropriate UI enhancement would be the addition of a "next
highlight" button or menu item and optionally a "previous highlight"
button.
I agree with Nick that clients should be able to highlight search
results, but I suggest a simpler approach - when a server sends a
response to a search (and only the server *really* knows when this
is), it should send a keyword attribute in the HTML header, containing
the terms it thinks are relevant to the results (which may not be all
the terms specified.) Then the browser can (or not) implement a simple
way to find and highlight the terms. Most (all?) browsers can already
search on text, so this is a very simple extension for them. It
relieves the server of having to muck with the actual HTML text it
sends, and uses existing mechanisms.
Cheers!
--
wa | Wayne Allen, EINet - [email protected]
| MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759
| http://galaxy.einet.net/EINet/staff/wayne/wayne.html