Wrote an extension for OddMuse suggested by Moof: A trail of pages visited. ¹
JakobNielsen talks about a similar feature called “breadcrumb trail” in one of his AlertBox articles: *When Bad Design Elements Become the Standard.* ²
In the section *Breadcrumb Trail* he writes:
Many websites are starting to supply a breadcrumb trail across the top of the page to situate the current page relative to its parent nodes and to allow users to jump up several levels in a single click.
Breadcrumbs only work for sites with a hierarchical information architecture, but they do facilitate navigation in such sites. They would help even more if they were available on more sites so that users could get used to relying on them.
This is not quite the same, as this “trail” doesn’t indicate the trail the user took through the site; instead, it tells you how to reach this page from the “top node” (usually the front page).
Why didn’t I add such a feature to OddMuse?
Wikis are rarely hierarchical; if they are, they are rarely *trees* (each page has only one “parent”) – usually they form a *semi-lattice* (each page belongs to several “categories”); the existing hierarchy is usually very shallow, no deeper than three levels. In such an environment, hierarchical navigation is better served by a ForwardIndex on the category pages. A breadcrumb trail to show you where the current page *is* in the hierarchy is of little benefit.
Visitors know how to use the “Back” button on their browser. Modern browsers even allow you to choose *which* page in the history you want to jump back to. The trail of visited pages merely duplicates this information. It is of little benefit.
Why did I write it as an extension?
Several people have asked for similar features. I just don’t think it makes much sense to have these features. But rather than argue the point again and again, I just wrote it up; let people experiment with it. Maybe I am wrong, who knows. ;)
I wrote a similar critique on the Oddmuse site. ³ Maybe I should move it to CommunityWiki.
(Please contact me if you want to remove your comment.)
⁂
Making OddMuse more modular is the way to go. You can make minimalists like me happy by purging the main file of exotic features, probably getting it way below 4000 lines, and make others happy by offering lots of modules to play with. You will be happy because you can play around with new stuff without blowing your 4K-lines target. I’d like to see how small you could make the core. I’d like to see the stylesheet cookies feature squeezed out into a module, but I’m not sure the core would shrink much.
– GregScott 2004-01-28 07:57 UTC
---
Heh. Well at the moment I’m trying to put the existing extensions into a nice modular framework.
The CSS cookie is about three lines of code, and if you don’t tell your users about it, nobody will notice, since you still specify the default stylesheet using an option.
Unfortunately for you, therefore, I’m not going to see how small I could make the core... ;)
– Alex Schroeder 2004-01-28 11:35 UTC
---
No it’s not unfortunate for me, since i was only mildly curious about how small the core could get.
i like the modularity you’ve introduced because it allows you to innovate and make others happy with new features, while preserving the monolithic core. Although i like lean software, i hate to stifle innovation. the modularity supports minimalism and innovation, so i was happy to see this development. i know you understand the importance of the monolithic core for ease of installation and upgrading, since when i first stumbled upon OddMuse i read some statements of yours to that effect. i had played with smaller wiki engines, but they were just not impressive. OddMuse size/performance balance appeals to me, as do many of your scattered remarks about its design intent. finally, the appearance of modularity promises innovation without bloat. OddMuse is going great. Thank you Alex.
– GregScott 2004-01-30 03:50 UTC