Tue 18 Oct 2005
Last week, Shaun and I met with Robert Thombley to discuss website structure goals and best practices. Before this, Shaun and I had never had to explain our website structure to someone who was completely unfamiliar with it. This gave us a good chance to put into words the philosophies behind the structure of the various Ocean Informatics sites. Some of these ideas we have implemented more fully than others; below is a brief outline of the discussion and where I feel we stand on each point.
1) Website file system structure: We all agreed that the file system structure should mirror the site’s navigation. First, it makes the site more sensible to the designers, and easier to work with. Second, it obviates the need for a lot of absolute links or ‘..’-based relative links, which make sites less modular. Third, it allows you to cleanly automate navigation elements (such as the breadcrumbs on the Palmer site). The OI sites have stayed have stuck close to this design philosophy, with the exception of the inherited Palmer site, which is currently on the list for some file system restructuring.
2) Naming conventions: Strong naming conventions are worth the time to set and observe. If you need to sift through your site’s files - particularly useful for auto-generating content and navigation - good naming conventions will save a lot of time by making your actions scriptable. If you are auto-generating navigation elements based on the file system, it is also important to have easily readable filenames. You may know that 05aug_phmeet means ‘August 2005 Phytoplankton Meeting’, but your navigation-building script won’t know this unless it is explicitly told. The OI sites are fairly good in terms of naming conventions, but the conventions aren’t always consistent between subsections of a site. For example, files in different projects may use different date formats in their filenames. Also, some sites were set up without auto-generated navigation in mind, so user-unfriendly abbreviations are sometimes an issue.
3) Data storage: The main issue we talked about here is storing data in database software versus storing it in flat files. The pros and cons of each approach is a blog post of its own; I won’t go into detail on that here. The most important point that was raised was that, whichever approach you take, if you implement it cleanly migrating to a new approach should not be a difficult task. Well-formatted data is more important than the storage medium itself. On the Palmer site, where we are currently migrating from flat files to a database, we’re finding that individual data files are well structured and easily parsed. However, the data as whole lacks some coherency, because the datasets were not initially recorded with interoperability in mind.
4) Templating and inclusions: Templating is an area in which it is important to strike a balance. A rigid template can be frustrating from a design point of view, but a highly configurable template can become difficult to manage. The OI sites are currently lean more towards rigid designs, with little configuration on a per-page basis. We are implementing some PHP code, however, which allows us to override the default template for those few pages where the standard design is not workable.
5) Database-driven sites: We also discussed the merits of database-driven sites. For cases where being able to quickly and easily recreate the structure and navigation is more important than flexibility of design, DB-driven sites are very useful. Robert mentioned that the site he was designing would be re-implemented for each cruise - four sites a year, all using the same structure and navigation, just different content. In a case like this, the initial, higher overhead of setting up a DB-driven site pays off in the long run. Although we have DB-driven elements on most of our sites, none of the OI sites are fully database-driven (yet).
These five points constitute only a small fraction of the considerations one must make when setting up a website. As we continue to present our sites to others, more strengths, shortcomings, and goals will come to light.
Leave a Reply
You must be logged in to post a comment.

