ROADS Logo

Introduction and contents | Previous | Next

Day 2 - 11:00 Configuring the Search Interfaces


The default search screen that comes with ROADS 'out of the box' is designed not so much as an example you can work with straight away, but more as a showcase of all the search features you might want to include in your interface.

Default ROADS search screen

Default ROADS search screen

The idea is that you design your own.

The files for all of the HTML interfaces are contained in the /roads-v2.1/config/multilingual/UK-English directory:

Tip: It is possible to create several different views of your gateway perhaps in different languages or targeted at different users by creating duplicates of the UK-English directory, renaming them and then creating your separate interfaces in each. See the manual for further details.

I decided that I want a simple search screen (default) and an advanced one with a variety of options. The files that need to be changed are in the /roads-v2.1/config/multilingual/UK-English/search sub directory.

There are two options here. If I call the search.pl script without any arguments from the Web then the file it parses and returns is search.html. Alternatively I could create an entirely new file (ie. paul.html) in this directory and call the script thus:

http://fish.ilrt.bris.ac.uk/ROADS/cgi-bin/search.pl?form=paul

The simple.html and wired.html files are provided as examples of this.

Both of these options mean that you can use ROADS pseudo-HTML tags to avoid hard coding server URLs etc. For more information about these tags see the manual.

I decided not to take either of these approaches however primarily because having the search form generated by a CGI script creates greater load on the Web server. Instead I placed my form in the /roads-v2.1/htdocs/ directory as a static HTML document. I also find this approach much faster and allows the use of whatever HTML authoring tools I like.

I decided to design an extremely basic search form. The only option I decided to include other than the search box was a radio button element to allow the user to choose between a brief results display and a full. I designed the form to allow for 'graceful degradation', ie., simple enough that it looked good even in the earliest browsers.

For my advanced form I included field specific searching, a case sensitivity switch and a range of stemming options.

Tip: If you intend your gateway to contain records in languages other than English, do not include the 'stemming' option in your forms. Use the 'substring' and 'exact' options. The 'stemming' option uses the Porter Stemming Algorithm which is specific to the English language.

Simple search form screen shot  Advanced search form screen shot

Simple and advanced search forms

Tip: A quick aside about style:

You'll note that I've been fairly minimalist with my HTML. I have tried to keep things as simple as possible to allow my look and feel to 'degrade gracefully.' I have avoided using tables too much and I always give frames a wide berth as they can cause no end of trouble for navigation on older browsers and I hate not being able to get to a site using my PDA because it is framed. I have included a little navigation bar at the top and bottom of every page and kept plenty of white space in the interface to avoid clutter and emphasize the important elements. I have also only included those form elements I think the user will want and no more.

I have tested my interfaces on a number of different browsers including Lynx. For further information about interface design check out the W3C's Web Accessibility Initiative pages.


Introduction and contents | Previous | Next

Last updated: January 1999 - paul.hollands@bris.ac.uk