A word from the Programmer

[MUSKOKA FLORA] [Species] [Common Names] [Authorities] [Herbaria] [Townships] [SEARCH]

My work in laying out the Flora of Muskoka Web Database could neatly be divided into two clearly-defined components: work on establishing an efficient, easily-updated structure for the database, including filenames, directories, hypertext links, and the Update utility; and work (in collaboration with Sian Meikle) on the layout of the pages themselves, the user interface, the header graphics, and the overall appearance and "feel" of the system.

Database Structure

The database consists entirely of a collection of HTML documents interconnected via hypertext links. One of the design features of the muskoka_flora directory is that it is only one "level" deep, i.e. the /GROUPS, /FAMILIES, /SPECIES etc. subdirectories all branch off directly from it, and have no subdirectories of their own. This greatly simplifies searching for a particular web page, since they are grouped according to type. Any web page in any subdirectory could use the same relative address to find, say, a group page: It was for this reason that our alternate model, one with species pages in a subdirectory belonging to genus pages in a subdirectory belonging to family pages etc. (which would in fact more closely resemble taxonomic hierarchy) was rejected.

To make the database readily updatable with new pages, family, genus, species, sketch, map, accession number and authority pages are all assigned a four-digit number in their filenames (e.g. "fa0001.htm" for the Orchidaceae family page), along with a two-letter prefix identifying their type. This makes it possible for the Updater program to add a new genus page, for example, simply by checking the directory to see how many genus pages exist, and then creating a new genus page with a name corresponding to one greater than that number. While Unix allows filenames long enough to consider using the family, genus, or species names themselves as filenames, using these file "numbers" makes the system transportable to MS-DOS systems (indeed, the entire web database is backed up on an MS-DOS machine, where all updates are tested before implementation), since the filenames never exceed the 8-character limit (note also that the extension ".htm" instead of ".html" is used throughout for this same reason). In addition, using numbers in this way inherently "dates" a new page with respect to the others (to give some indication of how recently a particular page was added to the database), as well as circumventing any possible typographical problems (what if the species "hymale" exists under two distinct genera?).

Finally, it was decided that all large graphics (images, distribution maps) would have their own web pages, linked from the species page, so that only users that want to see them need trouble themselves with waiting for the bulky files to load. Users content with habitat and database information, then, get speedier service by default.

Page Layout

The layout of every page has some things in common. The "button bar" was placed at the top of EVERY page throughout the document, and while some of the links might be more useful on some pages than others, it was decided to keep ALL the buttons there on ALL pages, so that a user who had learned to use the button bar intuitively would not have to repeatedly read the buttons to see where they go.

Because of its uniformity, and because of the highlighted "MUSKOKA FLORA" label on the first button, this button bar doubles as a "title bar" for every page, to remind the user that they are still within the database. This was particularly more convenient than having a dedicated title bar, since it takes up much less vertical space on the page.

Near the bottom of each species page is a hierarchical list of the index page and relevant group, family, and genus pages:

Muskoka Flora - Index : Orchid Group : Orchidaceae : Aplectrum hyemale

This list represents a logical hierarchy of web pages through which one travelled to get to this web page, and is actually presented in some form at the bottom of every page in the database. Note that while it represents a logical hierarchy of files, often mirroring taxonomy itself, it is NOT an accurate representation of the directory tree, which is always only one "level" deep! Nevertheless, experimentation has shown that it is an intuitive and useful way of keeping track of one's position in the database.

Below this line, there is a small box at the bottom of each page, consisting of another link to the title page, an acknowledgement to the University of Toronto Library for providing the service, and a date-stamp indicating the day this particular page of the database was last updated. E-mail addresses for comments or suggestions are also provided in small print.

Below the box, in small print, is the copyright and the specific URL address for the page (as opposed to the entire database). This is a particularly useful aid for someone who prints out the page, and later wants to know how to find it in the system.

After hours of personally navigating through the system in search of bugs, I've found the sheer uniformity of all the web pages to be an invaluable aid to developing an intuitive "feel" for searching and navigating, sure to be quickly appreciated by the user.

Andrew Pavacic, August 1995.


Muskoka Flora - Index : The Muskoka Checklist : A word from the Programmer

This Information System is provided by the University of Toronto Library.
Please send comments to: timd@rom.on.ca, sian@vax.library.utoronto.ca, pavacic@ecf.utoronto.ca, or batthis@ecf.utoronto.ca.
Last revision: 10 July 1996
[Help]

© 1996 Royal Ontario Museum. All rights reserved.
URL = http://WWW.LIBRARY.UTORONTO.CA/www/muskoka_flora/misc/wordfrom.htm