Tags:
create new tag
, view all tags

Feature Proposal: What TWiki needs to be a real structured wiki

Motivation

We claim to be a structured wiki. But we bury a lot of potential, that lies in TWiki in the software. I want the navigation and overview of users of the software to be improved.

Description and Documentation

We need a box, that helps me to understand, where I am and where I can go from the point that I am at. It is very important for the confidence of each user to be in control of website navigation.

TWiki has an important navigation tool already: the breadcrumb navigation. Jakob Nielsen teached us in April 2007 in his post "Breadcrumb Navigation Increasingly Useful" why this is a good thing.

But why don't we show additional information, that helps our users to navigate for example in a box in the upper right?

Examples

Navigation for this page
Mother of this Page: FeatureRequest
Children of this Page: FeatureProposal4711, FeatureProposal4712
Pages, that link here: WebHome, WebStatistics, WebChanges, ... (see all)
Tags of this website: Structured Wiki, Features, Wishlist, ... (see all, change)
Pages with the same tags: WikiFeatures, Tagging, Semantic Web
Internal links on this page: PersonalRoadmapForMartinSeibert, MartinSeibert, ... (see all)
External links on this page: google.com, seibert-media.net, ... (see all)

  • The box and the font should be smaller.
  • The box could be enabled and disabled with a Variable or command in the Wiki-Code.
  • The box should be placed in the upper right corner within the Wiki-document. It is usally not taken and still provides a reliable point for users to refer to.

Impact

WhatDoesItAffect: Skins, UI, Usability

Implementation

  • It could be implemented as a standard feature of TWiki in the core. That is what I would suggest.
  • It could be implemented as a plugin.

-- MartinSeibert - Aug 2008

Discussion

Navigation is just one aspect. Moreover, structuredness refers to the ability to structure your information (1) per topic as well as (2) for large sets of topics. For now TWiki has only addressed (1) but not (2) besides having more and more webs. "Structuring your knowledge" is all about information architecture and taxonomy work. That's where standard TWiki scores comparably low. Actually most wikis don't support taxonomy work out of the box. That's why wikis may generate lost of costs to refactor them when things got one big spaghetti ball.

-- MichaelDaum - 07 Aug 2008

I also forgot to mention, that the whole breadcrumb structure is not visualized yet. It would be cool, if we could also generate a sitemap. I will file another feature request for this eventually.

-- MartinSeibert - 07 Aug 2008

That's a cool idea!

IMHO this could be implemented as a plugin (the current plugins infra-structure are enough. no need to change core).

It's worth to mention that this box would be very expensive, specially the backlinks row (try the backlinks and measure how long it takes), so this feature depends on heavy performance improvements.

-- GilmarSantosJr - 07 Aug 2008

in TWiki 5.x this should become a much less expensive thing - ResultSets will lend themselves to caching, and using a DatabaseStore will make most of it a fast query. That said, yes this is Plugin stuff - even Widget stuff, from which the core will probably be inspired to improve in its lookups.

-- SvenDowideit - 08 Aug 2008

This box could be cached during a time, that wiki is not used heavily.

-- MartinSeibert - 08 Aug 2008

Caching is not a real solution to performance issues - as the cache update still hits hard. Fixing the root cause is important.

-- SvenDowideit - 09 Aug 2008

But if you cache during a time, that has literally no usage, that is a first step, right?

-- MartinSeibert - 09 Aug 2008

Only in trivial and boring (for twiki) cases where queried information is not dependant on which user is logged in. Once you have permissions, user specific states and the like - the things that make TWiki more interesting than a static site, caching is less important than making the internals efficient.

Caching is about eeking out the last 10% efficiency from your site, the 90% is much more significant in bringing a responsive tool for the value add that an Enterprise wiki brings..

-- SvenDowideit - 10 Aug 2008

Sven: What is then the next steps for the realization of this feature? How much effort does it take? Would you complete it (for funds)? What would it cost? Maybe we will find enough people to raise the money.

-- MartinSeibert - 10 Aug 2008

It depends entirely on your focus.

If you need just the navigation box at the top of this topic, then you (or any of us) should be able to create a TWikiApp that works in very little time.

If you mean to build the TWiki 5.0 feature set that would make the above navigation box a trivial and natural part of TWiki's core function - I would love to find some financial help to make the (DatabaseStore / ResultSets / ExtractFormatting / SearchEngineSearchBackends) features for TWiki 5.0 a reality.

I see that TWiki5 functionality an important next step in overcoming TWiki's linear text file based history - and by unrolling the deeply recursive nature of TWiki's Application rendering philosophy, we should get something that will go a long way to reducing the 90%.

I basically see the complete ResultSet ++ work as taking over 3 months hard slog - but I've obviously avoided costing it in detail.

-- SvenDowideit - 10 Aug 2008

This is a key roadmap discussion. I'm 100% behind Sven on this, BTW, and will also be putting my work where my mouth is.

-- CrawfordCurrie - 10 Aug 2008

I understand, that the box itself would create less server stress with a database in the backend. I understand, that for a reasonable installation, we will probably have to wait on TWiki 5.0.

But that TWiki 5.0 - discussion is one, that should be discussed elsewhere. Is there a topic for that already? I would especially like to discuss possibilities of funding or at least supporting the needed work.

-- MartinSeibert - 10 Aug 2008

Actually, the (internal) backlinks feature could be done without a search over all of the content, be it a file-based grep search or an sql search. TWiki knows best where it links to when it generates them. So a backlinks index could be maintained on each save/move/rename. You'd only need to build it up once to get the initial index of all content, and then let it run. Doable as a plugin even for a 4.1.2 engine.

-- MichaelDaum - 10 Aug 2008

It would be great, if the plugin could integrate the tagging feature. I added the corresponding lines in the box above.

-- MartinSeibert - 10 Aug 2008

Here's what I think: this navigation box is probably not that useful and usable. I'd provide part of that information in different places. For instance, parent-child relations, or more general top-sub-categories of the current topic are probably best visualised as a virtual folder- or tree-structure placed into the sidebar navigation. Instead of showing all topics that have the same set of tags, all tags of the current topic should be clickable linking to page listing topics using the same tag. There are probably only a few topics that use exactly the same tags as the current one. Others, that use a subset of tags like the current one might be "related" already. The more tags it shares - the more "related" it is. What is left is a list of pages "that link here", internal links being more useful on corporate intranets than external links. External backlinks are better known as TalkBack or PinkBack. (I once started to write a PingBackPlugin but never finished it.) Well, and the links on the current page, well I don't see why they should be duplicated. They are on this page already, most probably more usable as having them all in a big list.

-- MichaelDaum - 10 Aug 2008

To reduce visual clutter, it should be in a twisty. And so it doesn't slow the initial page load, it would be very nice to use AJAX to load the content in the background.
On second thought, AJAX could/should be used for all twisty content that is initially hidden, not just this one.

-- SeanCMorgan - 12 Aug 2008

Bottom line is that this box is useful only in some context, and useless in others. This belongs more to a Skin than to the Core.

-- RafaelAlvarez - 12 Aug 2008

yes, but there's another bottom line - the core should support this kind of functionality better. None of the queries that someone might make (and these are just examples) should be difficult, nor be performance issues.

-- SvenDowideit - 12 Aug 2008

I think this topic's name is misleading; since it's only a few days old, I gather it's OK to change it. How about "NavigationContext"?

-- SeanCMorgan - 13 Aug 2008

Actually, I think this is often found in a menu / page of "Page Infos" or "Page properties" on wikis, blogs, or CMSes. See for instance the "Page Info" of confluence: http://confluence.atlassian.com/pages/viewinfo.action?pageId=8161

If you look at the current pattern skin (on this page foir instance), you can see we have wikipedia like tabs on the top right "Edit" "Wysiwyg" "Attach" "Printable" to show different aspects / facets of the topic. We could just add an "Info" one, and I guess also "Talk" and "History" ones, like wikipedia. This has the advantage of being implementable immediately, as then it is not a (big) problem is this Info page is slow, as it is not shown in normal mode. We may even make an "Actions" or "Admin" tag for the "More" page?

-- ColasNahaboo - 13 Aug 2008

I did that for Talk in TalkContrib, which was demoed here in TalkTalk - but was booed down by the 'UI' guys.

I'm strongly tempted by the idea of adding a few more actions in that way - permissions and admin..

-- SvenDowideit - 13 Aug 2008

Erm, these are no tabs, these are click buttons.

-- MichaelDaum - 16 Aug 2008

I'm pretty sure that you are capable of making some css to make them look more like tabs for you.

-- SvenDowideit - 16 Aug 2008

That's not the problem. Tabs & Buttons are different concepts.

-- MichaelDaum - 16 Aug 2008

I might have lost you all in the course of this discussion. But I think to have read, that nobody objects, that this type of box would be a useful feature.

In my opinion we now need someone who is willing to create a first iteration, that can be judged and improved. It would be nice to see how much time will be needed to complete this action.

I fear, that we will have an endless discussion here. I would like it better to have a result. smile

-- MartinSeibert - 18 Aug 2008

Edit | Attach | Watch | Print version | History: r26 < r25 < r24 < r23 < r22 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r26 - 2008-08-18 - MartinSeibert
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.