See also InformationArchitectureOfThisWiki

I didn't think too much about navigation in a wiki until I had to set one up as a defined project space.

Starting point

*Wikipedia navigation virtualises the A to Z of Britannica where the initial letter of the word dictates the jump-in point. It relies on Search, Homepage, Random Page and http://en.wikipedia.org/wiki/Special:Randompage and link chasing for navigation

User manuals built by wikis

follow that numbered

indented thing

I never go the hang of

Until the wiki made it easypeasy

||Thoughtstorms swirl, snowball and make short-circuits||

I just did a wiki which was a fillinable document. When a project moves between phases, the wiki acts as the container of the of information from the previous phase. Seems commonsense but so does all knowledge manangement and when a project goes from the suits in sales to the plodders in planning to the eggheads in engineering and then to the customer there's not a lot of cultural connection and little sharing or storing of tips and references. Anyway the wiki had to let anyone step in, drop their information and let others find it. It is a discrete knowledge container.

Connections and Navigation

The trick is in the boundaries probably and this wiki is something that will hold just a chapter of information, one project amongst a few others. However when connections are made that is when the sparks fly. If navigation is there then it should inspire that possibility for innovation.

No endpoint

I think, after all this, that navigation is only restrictive if it bounds knowledge rather than offering a space for incubation and if it somehow devalues interlinking or doesn't empower the full potential of a keyword search. A startpoint is useful, there is no need for an endpoint and if there is one it should be explicit.

– Rup3rt

Hey, thanks for joining us Rup3rt. Wanna start a page on yourself?

I understand you as wanting to have defined sub-areas within the wiki, which are protected in some way from too much permiation by links in and out. I understand that. It's another kind of DataHiding and is useful if you need to preserve a modularity. For example, if the chapter gets too dependent on and intertwingled with other pages on the wiki, it will never stand on it's own. I have a similar problem with PatternLanguageForTheSocialNetwork which was always conceived as being a separable document, hence I never link in to it from other pages, and initially only linked out on the grounds that it was temporary.

If I understand again, you are suggesting WikiNavigation (as in a more fixed structure to the site, maybe defined by standard menus etc.) can help the containment of modules? That's a fascinating question too.

(See also : OnModularity)

Or have I got totally the wrong end of the stick?

– PhilJones

I've been drupal-ing and used tikiwiki and now I'm finding it hard to separate navigation, menus and taxonomy. Here are three simple states of Wiki Navigation

*Brainstorming on a wiki develops its own navigation or taxonomy. Visualization is a useful add-on.

*Developing a project or theme should be guided by these categories to concentrate the interactions - Rudimetary wiki navigation by tags or popularity and time ranked menus (this is where CMS modules help)

*Recording parts of a project and acting as a rewritable space for notes, observations, shortcuts is where a wiki should have the strongest navigation system to maximise partipation and a great clustering search also helps.

I have probably described what a GUI specialist could tell you in 10 seconds but it clarifies what I said above. Not so much modularity but the evolution of a folksonomy & cleaning up jargon & descriptive subtitles. But this all comes from relatively small groups (+-20)

Rup3rt