Warning! Dull geek stuff coming at you.
This week I are mostly been deleting things. It’s weird but one of the best feelings as a developer is when you work out how to do the same thing with less code. This means you get to throw out loads of code, code that you wrote, code that you sweated over, yet it feel good to throw it away? wierd.
I suppose it’s a kind of Zen thing, it’s about achieving your goal with a simplicity and minimality of movement. Its the same thing that appeals to me in Japanese Woodcuts or Haiku and, when I had the time for such things, was one of the pleasures I gained from long and middle distance running.
It’s just a general feeling of the code being ‘right’ when it takes 3 steps to get from ‘A’ to ‘B’ rather than 7. So this week I took another look at the navigation elements and site architecture concepts of the Rapidsite project (see I warned you about the Geek stuff). Previously the project had 3 fundamental content types: Categories, Pages and Page Objects. But I was thinking about Jakob Nielsen’s ideas on site architecture, and realised that of the 3 content types, only one was actually valid and that was the page.
The category is an artificial accumulation of associated content. Pages are only in a category because we say they are, it is only a navigational construct not an actual subdivision of the site. It’s role is to aid browsing and to steer visitors through the site in a manner which will aid both their search for information and our attempt to move them to the site goal. It is similar to species in terms of it’s artificiality and therefore should not be used as a data structure.
The Page Object is a fundamental unit but within the page. It has no role within the site as a whole, it’s role is to differentiate functionality within the page object, not to reinforce site architecture. The Page Object differs from the Category in that it can carry meaningful data that is better expressed within the object rather than anywhere else. So the Page and Page Object will survive my Big Brother purges, but the category will be vaporised (sorry reading 1984 at the moment).
Put simply there is no site architecture information that cannot be carried better in a Page than a Category. Each Page needs to know one thing, who it’s parent is. If it knows this then it will be able to group itself with sibling pages, which together will de facto form a category with a parent page which will be the category index. If each Page also carries one artificial extra piece of data, a Page Rank, then it can also know where about it sits within the category menu. So with 2 pieces of data, one of which (Page Rank) we were using already, we can now drop a whole data unit and database table. Hooray!
Next… How to model a hierarchical data set with a flat database structure. Bet you can’t wait?