How to show parent topics

Original proposal

This is a small UI detail I would like to solve for the new release. Currently the view template has the parent topics shown just after the topic header. This is functional but does not fit into the design.

One possible way is to remove the parent line from the template and move it into the WebTopicEditTemplate instead. That way users have control of where (and if) to show the parent topic links. Example WebTopicEditTemplate:

-- %WIKIUSERNAME% - %DATE% <br />

<br /> %META{"parent" prefix="__Back to:__ "}%

The other idea is to expand the "bread crumb" line on the top. So, instead of showing:
[LOGO] TWiki . Codev . HowToShowParentTopics

you would show the parents embedded: (here just one)
[LOGO] TWiki . Codev . FeatureEnhancementRequest . HowToShowParentTopics

The question here is how to handle parents in a different web; we probably need a switch to start the parent list after WebHome and after entering the current web. Another question is the length of the line; it can get long if there are several nested parents.

Comments?

-- PeterThoeny - 26 Aug 2001

Why not show the parents below the revision information?

This automatic display of the parents could also be made optional with a setting in WebPreferences, example Set DISPLAYTOPICPARENT =

• Header; to show in the "bread crump"
• Footer; to show below the revision info
• None; no automatic display, should be included in the topic body

-- HansDonner - 26 Aug 2001

The idea of [LOGO] TWiki . Codev . FeatureEnhancementRequest . HowToShowParentTopics is just too confusing, is this link a subweb?, or a parent??.

• Precisely my point, a parent - child hierarchy is logically nothing else then a web hierarchy. Users do not need to make a distinction, and in fact, under the hood could be parenting instead of sub-webs. The bread crumb just starts from the TWiki home, goes to the web (e.g. web home) and decends to the given depth. -- PeterThoeny - 26 Aug 2001

I think that with the current templates the best solution would be to have it below the Topic name in the footer (probably separating the Ref by link to that same line).

I would not have it configurable through the preferences, as this would be an unnecesary complication of the code, such functionality can easily be had with templates, and if necessary, custom-defined variables.

I would also probably limit the display (and the storage) up to the great-grandparent, 3 levels should be more than enough for most applications.

-- EdgarBrown - 27 Aug 2001

The storage of parent information is not an issue as a topic only stores its parent. At present there is a recurse option for %META{"parent" ...}. Allowing this to be a number, as an alternative to on, makes sense. I was also thinking of adding suffix as an option. The suffix and prefix would only be displayed if there was a parent.

An update on that, unfortunately, there's a dontrecurse param rather than a recurse param. I suggest this is changed to recurse, defaulting to on, but that it can be set to a depth or off.

• Sounds good. In case it is a small change lets take it into the release. -- PeterThoeny - 26 Aug 2001

Additionally, I think putting the parent information with the revision information works fairly well, unless people say otherwise I'll make this change in CVS.

• For what would you need the rev info of the parent stored in the meta data? It will be outdated at the time of updating the parent... -- PeterThoeny - 26 Aug 2001
  • A confusion - this referred to the suggestion above to display below the revision information, i.e. doesn't refer to storage of information. - JohnTalintyre - 31 Aug 2001

-- JohnTalintyre - 28 Aug 2001

Implemented suffix="..." option, see PostfixArgToParentMeta.

Added also a new nowebhome="on" option which excludes the WebHome topic and stops the parenting chain at thatpoint. This is usefull to show the name of the web instead of WebHome, i.e. in a TWikiSkin that has a bread crumb like:

• TWiki >> Codev >> FeatureEnhancementRequest >> HowToShowParentTopics

-- PeterThoeny - 11 Jan 2002

I just created the RoundEdgeSkin for testing this out. Test ride the CreepingFeaturitis topic with this skin: https://twiki.org/cgi-bin/view/Codev/CreepingFeaturitis?skin=roundedge (a skin can be activated also site-wide in the TWikiPreferences, in a WebPreferences or as a user setting.)

See also RoundEdgeSkinExperiments

-- PeterThoeny - 11 Jan 2002

I like the RoundEdgeSkin approach, particularly showing the trail of parent topics. However, I'm not sure about how the coloured part 'dips below' the line to include the web... I'd rather just have the coloured bit all on the same level, as it is mainly there just to highlight the header part (IMO). In the current skin, the web name is not part of the coloured bar, so I'm not sure why it needs to be here.

One UI issue, having just set the parent on some topics, is that it would be useful to be able to change the parent of a topic without having to go to the More page, hit the Edit button, and then Preview and Save. This is really the same issue as MakeCategoryAndTopicDropdowns, i.e. the ability to quickly change metadata (loosely speaking), so I've put this page into the InterfaceProject.

-- RichardDonkin - 14 Jan 2002

As an experiment I changed the template here at TWiki.org to show the topic parent lik this:

• TWiki > Codev > FeatureEnhancementRequest > HowToShowParentTopics

The bread crumb code in twiki.tmpl looks like this: (Needs latest Alpha code)

   <a href="%SCRIPTURL%/view%SCRIPTSUFFIX%/%MAINWEB%/%HOMETOPIC%">%WIKITOOLNAME%</a>
   &gt; <a href="%SCRIPTURL%/view%SCRIPTSUFFIX%/%WEB%/%HOMETOPIC%">%WEB%</a>
   &gt; %META{"parent" nowebhome="on" suffix=" &gt;"}%
   <font size="+1"><b>%TOPIC%</b> %TMPL:P{"titleaction"}%</font>

This really improves the navigation experience because you see where you are and you can go back to any parent topic quickly.

At work we have a skin in the corporate look and I added this bread crumb about two month ago. People like it and began to reparent older topics (new topics are already parented). Most of the topics here in the Codev web are free floating, e.g. do not have a parent. So the bread crumb feature is not as useful here as it is when creating new topics to conventional Wiki way.

-- PeterThoeny - 12 Feb 2002

I don't mean to be a stick in the mud, because I'm a big fan of bread crumbs, but the free form linking behaviour of Wiki may foil you here. Bread crumbs are mean't to show you a way back out from 'here' following the path you took to get 'here'. In a wiki however you may visit

TWiki - some web - some page - 'here'

only to find the bread crumbs say

TWiki - some web - some page you never heard of that is really the parent of 'here' - 'here'

Which is inconsistant user feedback. And since one link to a topic looks the same which ever page it's on, there's no indication which is a hierarchical link (parent-child) and which is a cross hierarchy link, there's also no clue to the behaviour to be expected from the breadcrumbs. E.g. sometimes it'll make sense to the user if they have followed the path indicated by the breadcrumbs and sometimes is wont. I guess you have to think: what is this parent-child link actually for in a wiki system?

OpenWiki has a bread crumbs systems that follows the actual path you take (I guess they use cookies or something). I'm all for the above example just wanted to raise this point.

As it turns out the OpenWiki link will illustrate what I mean. The breadcrumbs for that page are:

TWiki > Codev > WikiRssExtension > OpenWiki

It doesn't really make sense that the action of going from this page to that page produces those breadcrumbs. They are merely an artifact of the fact that the first OpenWiki link was made from the WikiRssExtension page and as such are meaningless in the context of your current site browsing experience.

-- AndrewTetlaw - 13 Feb 2002

My experience might be different, we are just starting with TWiki, but here it goes:

My users want extremely simple templates. Simple menu. They feel confused with too many options they do not know how to use. My simplest skin has only 4 words after topic name ( Intro, Index, Search, and far away in right corner: Dev (which will view page using another skin, still simpler than TWiki's classic one). Simplest skin does not have even Web name - I have different logos for different webs (program project icon). It's fine if parents are shown in footer, but one single parent might be assigned by chance: i.e. parent of this page, HowToShowParentTopics, is FeatureEnhancementRequest. It doesn't make sense, does it?

Maybe later, when my users get used to TWiki, they might appreciate displaying Parent Topic. For now, simple Ref-By will I guess satisfy all they needs, and more. And IMHO Ref-By is even more powerfull: it shows all pages pointing to this one, not only the one used to create it.

-- PeterMasiar - 15 Feb 2002

In the KoalaSkin I chose to present parents in a separate left margin panel, under the search panel and the "important topics for this web" panel, trying to mimic what users have become accustomed to in modern webs. You can see an exemple at: http://koala.ilog.fr/wiki/bin/view/Test/TestTopic3 (Parents bar to the lower left)

-- ColasNahaboo - 25 Feb 2002

Colas, I find your parents panel to be a little confusing, perhaps if you indented each child it would be easier to understand (at least for slow folks like myself).

Personally I prefer the parentage across the top of the page, but include ref-by and ref-to on a side panel. Having the "one degree of separation" in the panels on the side would be pretty cool.

Hmm. Maybe the following combined panel would be even better. Forgive the ascii art. Where all the xxx items are topics that refer to Currentpage (with some type of graphical representation that they flow into Currentpage) and all the yyy items are topics that are links out of the Currentpage.

 |<- xxx1
 |<- xxx2
 |<- xxx2
 v
  -> Currentpage -> 
                   |
             yy1 <-|
             yy2 <-|
             yy3 <-|
                   v

-- JohnCavanaugh - 28 Feb 2002

Yes, I tried to put the parents under the navigation bar at the top. But one design principe I was trying to stick to was "no flashing": elemenst at the top should always be of the same size to avoid seeing the page elemenst move around when going from page to page. Having the optional parent field on top was difficult to set right

-- ColasNahaboo - 28 Feb 2002

I encountered a problem with the way META{"parent"} renders a list when the topic has no parent. Apparently somewhere along the road an empty entry is created with a newline, that is converted to a paragraph code <P />. In my skin I have a menu at the left side of the content, with table cells for each link. A part of the menu is generated dynamically, it is a block with:
- the current topic's parent
- the current topic
- the topic's direct children

At the homepage, there is no parent, so a <P /> is inserted in the middle of the table, resulting in an emty line at the top of the table. Very bad looking.

I found a way: pass an "alttext" to META{"parent"} in case there is no parent. So I pass: alttext = "<tr><td style='height: 0px;'></td></tr>". I changed renderParent in TWiki.pm (release of 1 Jan 2003):

• _renderParent.diff: Diff file for passing alttext to renderParent. Diffed against TWiki20021230beta.

This works fine.

-- ArthurClemens - 23 Jan 2003

I just notice the same goes for the output of METASEARCH: it also renders a <P /> when no children are found. So I used the same solution with handleMetaSearch in TWiki.pm.

-- ArthurClemens - 23 Jan 2003

At least for the AthensRelease, I could fix this in the template. It looked like this:

foo bar
% META{"parent"}%
foo bar

foo bar
% META{"parent"}% foo bar

HTH -- PeterKlausner - 03 Feb 2003

Actually, here's a neat trick the TablePlugin does to avoid paragraphization on empty lines: insert a random <nop>, like this:

foo bar
<nop> %META{"parent"}%
foo bar

Then, whether or not the variable contains anything, TWiki regards the line as "non-empty" and therefore part of the paragraph.

-- WalterMundt - 03 Feb 2003

Just to bring it up again here: <p /> is invalid markup regardless of whether it's emitted at the correct time. A blank paragraph is correctly marked up as: <p></p>

And, don't repeat the argument that the former passes the W3C validator. They don't catch everything. If you don't believe me, try setting an attribute on a tag to width="fred flintstone" and they'll validate it, too.

-- TomKagan - 05 Feb 2003

Back to the original topic:

Whenever there will be SimplerDefaultTemplates, I suggest to move the parent list up to the top banner and include the web name as part of this path.

This matches RuleOne to follow the most common behaviour, e.g.:

• http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/HTML_Editors/Wikis/
• http://directory.google.com/Top/Computers/Software/Groupware/Wiki
• See http://www.useit.com/alertbox/991114.html for another example
  plus discussion of breadcrumb trails
  plus the recommendation on the separators to use, which is not '.' as in TWiki.

-- PeterKlausner - 17 Feb 2003

Factoring out BreadCrumbs to reference this feature easier.

-- PeterThoeny - 16 May 2003

See also PatternSkinCodeChanges for a patch for showing (and formatting) parent-children in a navigation menu.

-- ArthurClemens - 19 Aug 2003

New proposal: add format to META{"parent"}

Moved to AddFormatParamToMetaParent

New proposal: add $formfield to META{"parent"}

Moved to AddFormfieldParamToMetaParent

Category: TWikiPatches