Warning: Can't find topic Codev.InterfaceThread

This topic started in MultiLevelWikiWebs. The goal is to improve the navigation within a web.

Idea: Parenting Mechanism

The idea is to have a logical hierarchy of topics that could be shown at the top of a page, i.e.:

• WebHome >> FeatureBrainstorming >> NavigationByTopicContext.

The question is how to create this hierarchy. There is a Wiki clone (ZWiki?) that has a parenting feature: If you create a page by clicking the "?" link it will be a child of the originating page. In addition, a page can be "re-parented" if needed, e.g. it is possible to say "change the parent of this page from page Foo to page Bar". (FWIW, I don't like the idea to burden users with parenting issues)

The parenting mechanism should be done automatically in the background, the user should not be ware of that. It could be based on the frequency and order of topic visits.

Idea: 2D Topic Context

The parenting mechanism could be extended to two or more dimensions. A nice example is the Link2Go web site, they show related topics in a natural way using lines (bitmaps) and text, see for example http://www.l2g.com/more/www.mindspring.com/~peterthoeny/twiki/ .

this could be further extended with a zoop in / zoom out feature. Zoom out shows the topic in a bigger picture, zoom in shows the closer neighborhood.

-- PeterThoeny - 29 Aug 2000

A simple way of parenting would be to allow a "foreign" character in the name of pages, say NavigationByTopicContext_SecondPart (although for real parenting MultiLevelWikiWebs seems more logical to me).

For weaker connessions bewteen pages one could think to meta-informations, for instance the following fields (I'm thinking to scientific and technical informations):

• require: list of required concepts

• provide: list of provided concepts

• level: the level of the text

then it is quite easy (well, possible) to build up a path from one concept to another one (possibly at a certain level).

-- FrancoBagnoli - 30 Aug 2000

At work I got this related feedback:

First, it helps to know that the organization [of topics] is a tree. Currently you can see the part of the tree above you but not what's below you. I think it would be useful to have a 'down' button that lets you see, as a list, what's 'below' the current page. I find myself poking around a lot because I know a particular piece of information is on a web, but not the path down. For some reason, I haven't gotten 'search' to produce anything I want yet.

This points to some parenting mechanism we talked about earlier. Or a simple n-level deep tree could be dynamically built of topic links of the current topic. For this topic a 2-level deep tree is something like:

• NavigationByTopicContext     <--- You are here
  • MultiLevelWikiWebs
    • HierarchicallyNestedTwikiWebs
    • WebPreferences
    • GetAWebAddOn
    • TWikiPluginAPI
    • FeatureBrainstorming
    • FeatureAddOn
    • UserAuthorizationSchemes
    • WorkFlow
    • UserAuthorizationSchemes
    • AuthenticationBasedOnGroups
    • WebTeach
    • ExtendingTableSyntax
    • TopicFrames
    • CvsWebClient
  • FeatureBrainstorming
    • WebHome
    • FeatureEnhancementRequests
    • FeatureToDo
    • FeatureUnderConstruction
    • FeatureDone
    • FeatureNotSuitable
  • HierarchicalNavigation
    • RenderingWikiWordsToIncludeContext
  • WebMap
    • TWikiDrawImageMaps

Above tree could be created dynamically when the users follows a Relatives link.

The tree could include also the parent and siblings of the current topic. The question is how to find out who the parent is. May be recorded at topic creation time? Example tree:

• MultiLevelWikiWebs
  • NavigationByTopicContext     <--- You are here
    • FeatureBrainstorming
      • WebHome
      • FeatureEnhancementRequests
      • FeatureToDo
      • FeatureUnderConstruction
      • FeatureDone
      • FeatureNotSuitable
    • HierarchicalNavigation
      • RenderingWikiWordsToIncludeContext
    • WebMap
      • TWikiDrawImageMaps
  • HierarchicallyNestedTwikiWebs
  • WebPreferences
  • GetAWebAddOn
  • TWikiPluginAPI
  • FeatureBrainstorming
  • FeatureAddOn
  • UserAuthorizationSchemes
  • WorkFlow
  • UserAuthorizationSchemes
  • AuthenticationBasedOnGroups
  • WebTeach
  • ExtendingTableSyntax
  • TopicFrames
  • CvsWebClient

-- PeterThoeny - 05 Apr 2001

Yes! Yes!! Yes!!! That's what I'm missing most from TWiki. I was also thinking about a simple parenting mechanism: Any page can have a link to its parent page, ah - topic. Could be an invisible TWiki Variable, category, whatever; the originating page would make a good default.

At rendering time follow this trail to build the classical "You are here> ..." line. Should not cost much: even with a large documentation set, I would not expect more then 3/4 parent levels. This means, picking out the parent information from 3/4 other pages.

Creating "down" or "subtopics" links is not as easy. Without caching the hierarchical information in a file/DB/hash, you basically have to search all topics for a matching parent. Runtime would be like creating a full index page. Still, this might be useful for a cached sitemap page or so.

Same goes for "previous" or "next" links in the same level.

And, yes: in theory hierarchical webs might be the thing. But:

• Currently, the overhead involved in setting up and managing (sub-) webs is prohibitive.
• Linking is more complicated in a hierarchy of webs. If you keep it in a flat web, rearranging whole sets of trees could be a matter of switching a few parent links, without breaking any links.

-- PeterKlausner - 06 Apr 2001

Agree, the depth of a navigation tree within a web is probably not very deep.

A good hierarchical navigation within a web probably does satisfy most of the needs of MultiLevelWikiWebs, and therefore avoids the complexity of implementing multi-level webs. To me it makes more sense to store topics in a flat manner in a web are to organize them in a hierarchical way. Of corse we have a hyper-text structure of topics, but simplifing this into a navigation tree is most of the times a "good enough" mapping of the hyper-text structure. KISS!

We need to keep track of the parent in order to move up the tree. This raises the question if we should implement a GenericMetaDataStoreForTopics.

To move down the tree we simply need to recursively read topics and follow links. Performance should be fine if we limit the depth to, say, two levels deep. I don't think that we need to cache the tree, thus simplifying the design.

We could also offer a link on each node to re-center the map, an easy way to move around in the hierarchy without going to a topic (any better word for re-center?). Example:

• MultiLevelWikiWebs (re-center)
  • NavigationByTopicContext     <--- You are here
    • FeatureBrainstorming (re-center)
      • WebHome (re-center)
      • FeatureEnhancementRequests (re-center)
      • FeatureToDo (re-center)
        ...snip...

Another question is if to include topics located in other webs or not. I am inclined to exclude them since most relevant content is supposed to be in the same web anyway. Including other webs would bloat the tree without much gain.

-- PeterThoeny - 05 Apr 2001

One big plus of wiki is the ease of linking. You loose this, if you create deep hierarchies of webs. You'd have to follow the complete path to any target very carefully and changing the structure would affect all pages linking in. (Although I'd still maintain, that for bigger webs >>1000 pages a hierarchy seems the most natural thing to do.)

Regarding performance:
if we put the parent information on top of the page, the price to extract it wouldn't be too high. For every parent page:

• open
• read + check a max of ~5 lines
• if found parent, repeat

Practically, I wouldn't expect more than 3 or 4 of these iterations within a web. I strongly disagree to limit this to 2 parents. I want a complete "You are here: ... " path in any case. To protect from circular parent references, compare each found parent topic with the existing list. If there's a duplicate, insert an error page like CircularReferenceError as parent.

Searching for all children is far more expensive. You have to retrieve the parent information from all topics in the web. Obviously, this cannot be done for every page view.

---

Regarding up and down:
it took me a moment to realize, that Peter uses these terms just the other way round as I do. My thinking was [is]:

• up = hierarchically higher = parent = closer to WebHome / home page
• down = hierarchically lower = child = sup-topic = deeper into the site

Clearly, it doesn't matter how you name the beast, as long everybody understands the same. Obviously, that's not the case here. Is my thinking completely odd? Anybody else any idea how to name it?

-- PeterKlausner 10.4.01

Up and down the hierarchy? We are on the same line if you read carefully. Up is closer to WebHome, down is the direction of children.

• Moving up the tree should be done complete, e.g. until WebHome is reached or until it stops at a free floating (orphaned) topic. In the latter case we could simple "stick" the orphaned topic to WebHome.
• Moving down the tree should be limited to - say - two levels to show the tree in a manageable size.

-- PeterThoeny - 26 Apr 2001

Obviously, this is along the lines of TheBrainVsTwiki. My gravest concernt about this kind of navigation is imposing hierarchy. This is the thing I liked about http://www.TheBrain.com (and, believe me, it's the ONLY thing), was the visual generation of navigation. The presentation was ordered like this:

   Parent(s) -----  Topic  ----- Children

Each side (right and left) could show about 7 topics, with a "scroll" feature at the top and bottom if there were more. Each navigation regenerated the image (quite quickly, I might add! Probably because it's in an LDAP structure, which is VERY fast for reading). This would be nice, but as I personal preference, I value the vertical space on my laptop more than the horizontal space, so it would be nice (emphasis: my opinion) if you could have a left-side navigation that does something like:

Parent(s)
>Current Topic
Children

(Organized on a manner that is pleasing to most users)

We have to remember that a world like TWiki only imposes structure according to the collective will of the users. The benefit is that things are quickly related in a non-hierarchical way. The drawback is that we're not always bright enough to remember to relate things in topics (even in the Wiki world!).

-- DavidWeller - 10 Jun 2001

I like the idea of a vertical 'context' bar - however, the ZWiki approach is quite handy as well, and doesn't take up too much space. Just as long as we don't use frames, I'll be fine

-- RichardDonkin - 10 Jun 2001

If you like the concept of TheBrain perhaps a Link To... / Link From... tool would be handy. Selecting Link To would make the current page a parent of the page selected and Link From would make the current page a child of the slected page. The select the page you could have a list of choices or simply let the user type in the name of the page.

From any page then you could display the page's parent and child links.

That's the thing I really liked about TheBrain was that a 'thought' could be a parent and a child to as many other thoughts as you liked. You could also add a 'Jump To' link. which was neither a parent or child link but a realted link. This avoids creating an inflexible hierachy and instead offers more of a mind map.

Related: TheBrainVsTwiki -- MattWilkie - 09 Nov 2001

-- AndrewTetlaw - 09 Nov 2001