create new tag
, view all tags

Feature Proposal: Segregate Wikiness


Seeing wiki implementation specific topics listed with user topics produces clutter and distraction from the primary focus of a given wiki.

Description and Documentation

Filter wiki internal implementation details from users. Segregate wikiness from the primary subject.


Using the default index function produces a list of topics. see: WebTopicList, Many of those topics are either implementation details, see: BasicForm, or wiki specific topics, see: TWikiCommunity. Implementation details should be hidden from users, and wikiness aspects should stand out, and apart from, a wiki's primary subject. This allow users to stay focused on their current interest, while keeping the wikiness seperate, available and inviting, but without it being a distraction, or source of clutter.


WhatDoesItAffect: Usability


As an example solution, I promote the addition of two new categories, and refactoring of existing topics to take advantage of these new catagories. WikinessCatagory : to include wiki specific topics that we DO want the user to see and have access to, but segregated from other topics. WikiImplementationCatagory : to include all topics that are specific to the implementation of a specific instance of a wiki, but do not qualify as wikiness.

-- Contributors: RandyScales - 24 Jan 2008


Given a list of topics that are in and out, we should be able to make a TWikiContrib that you can 'install' that makes TWiki have one personality or the other. We've been working towards that kind of pluggability - in 4.2.0 the TWikiUserMapping code and topics are in a seperate Contrib - that is shipped in the default (and currently only) release bundle. But we have always wanted to be able to customise this.

Be warned though, this concept requires a lot of leadership - we've had several people attempt it, but not to the point where they brought it into the mainline development (to our shame).

-- SvenDowideit - 25 Jan 2008

Nice idea. Personnally I simply use a variable,

   * Set SYSTEMTOPICS = WebCharter,WebStatisticsDetailedBacklinks,WebStatisticsDetailed,WebAttachements,WebAttachments,WebChanges,WebChangesGroup,WebIndex,WebLeftBar,WebNotify,WebPreferences,WebRecent,WebRss,WebSearch,WebSearchAdvanced,WebStatistics,WebTopicList,WebTree,WebTreeBars,WebTreeTable,WebUnchangeds
That I use in %SEARCHes like
%SEARCH{search=".*" excludetopic="SomeLocalTopic,%SYSTEMTOPICS%" regex="on" order="modified" limit="32" casesensitive="on" nosummary="on" nosearch="on" reverse="on" noheader="on" nototal="on" format="$topic <br>" }%

This system works quite well. Perhaps a simple solution would be to insure that all TWiki functions would have an excludetopic= parameter if it is relevant for them. Note that you do not want WebHome in this variable, as WebHome most of the time contains user contents. And that this system is nice as it allows overriding and/or addition per web/topic.

A category solution would be much too slow I think, however, ...

-- ColasNahaboo - 25 Jan 2008

I would like for the relevant topics to be able to identify themselves, in the topic's subject. I do not know how this would be done directly with a variable.

Would it be advantages to use the category method for maintainability, and then have the category topic generate the variable for us?

-- RandyScales - 28 Jan 2008

Not quiet sure if I unterstood your proposal correctly... Do you just want to introduce two new categories or do you want some kind of split between static read only and dynamic wiki content?

-- CarloSchulz - 28 Jan 2008

I am not sure I like the idea of adding a basic form to all default topics in Main or to try and hide them from WebTopicList.

I like that WebTopicList lists everything. It is the only way to get the full picture of what is in a web. Otherwise I end up having to access the file system. I am generally not in favor of hiding things from users. Once a new TWiki is installed the first users are the users that will later be the power users. They need to get a good overview of how TWiki works and what components it consists of and the WebTopicList is a vital tool for this.

It is so relatively simple to change the WebTopicList to exclude a list of topic. Or better to replace the "Index" link in the WebLeftBar by your own topic that contains a search similar to the one that Colas suggests above.

I do not think it is possible to make a list of which topics people should see and which they should not see. For example in my view it is important that the users of a web can see WebLeftBar. How else will they learn that they can change the left bar? We all have very different use cases of TWiki. In my use case I have 20 webs and as the admin I cannot spend time maintaining left bars for all of them. Each team have their own web that they administrate to their needs and hiding the "implementation details" from them would put a damper to their innovation and creativity as TWiki users.

Maybe the search example that excludes system topics should be in an FAQ?

-- KennethLavrsen - 29 Jan 2008

the hardest thing will be making the list of topics, and updating all the docco so that the seperations make sense. The actual machanisim for showing and hiding topics is by far the easiest - I'm sure we can come with one that works for everyone in the time the rest of the needed work is done. (I still think seperate contribs - installed in the default twiki, but relocateable (or removeable) if you need a more cms-y approach will be the most reusable)

-- SvenDowideit - 29 Jan 2008

If I understand the issue then the problem is not if the topic are there. If you use forms and left bars etc you need these topics. I understand from Randy that the need is to not show users the topics in the list you get when you hit the index link in the left bar.

-- KennethLavrsen - 29 Jan 2008

It is difficult to demonstrate examples on this wiki, because this wiki is about a wiki.

I am suggesting the creation of a method to create two types of searches, with both of those type being usable as excludes.

Consider the following usage examples. I install a new default wiki, and open it to the public, and advertise it as a wiki on recreation. I wish to create three indexes.

  • User submitted topics (having nothing to do with wikis)
  • Wiki related user tools (UserGroups, etc...)
  • Wiki internal topics (for users that are trying to maintain the wiki)
How do I create these three index, and how do these indexes maintain themselves. If a user adds a new topic, that is by intent designed to be a wiki internal topic, how do the identify that fact?
  • Do they add a keyword to the new topic that they created?
  • Do they have to go find and alter a list or variable setting in another topic?
What happens when I add a plugin to my wiki?
  • Does it have a way to identify all of it's topics as internals?
  • Do I then have to search down all of the plugins topics and go manually edit some variable?

I would like to see some automation put in place here, for people that maintain wikis, and for creators of plugins. When a user adds a new topic, they should not have to add any tags or keywords to identify it as a typical topic.

  • Every topic that comes with the wiki should already be appropriately categorized.
  • Every plugin should identify all of it's included topics.

The exact mechanics of how to accomplish these things may be subject to debate, but I would like to see these things accomplished by default on the standard distro.

-- RandyScales - 29 Jan 2008

Maybe you try to resolve a problem which is not really there.

First - people only see the list of topics if you make it available to them. If the Index in the left bar is disturbing then remove it.

I do not know what you mean with a user submitted topic which is not a wiki. TWiki is a wiki. All pages are wiki pages. If you do not want wiki pages then maybe TWiki is the wrong choice in the first place. Give TWiki a chance anyway wink

If you think the users will be able to consistently figure out to correctly put the right category on topics then I can tell you that experience says that you cannot. Not even here on TWiki.org where we are all TWiki geeks can we do that.

Plugins have all their topics in the TWiki web. You can make your own WebLeftBar topics and only show the webs that you want normal users to see.

You should perhaps try and sneak around on some of the public TWikis and see how we have implemented solutions where even very occasional users feel OK.

Take a look at my TWiki at http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

I recommend to use TWiki as a wiki and not as a content management system.

-- KennethLavrsen - 29 Jan 2008

A wiki can be divided into at least two abstract parts.

  • The subject.
  • The tool.
If I make a wiki about cars, then "cars" is the subject, and "wiki" is the tool. The point of this feature request is to separate the tool from the subject. The tool, wiki, is a separate and independent subject, all of it's very own. In a wiki about a wiki, like this one, where "wiki" is both the tool and the subject, it can be hard to know how to properly categorize topics. The "tool" and the "subject" are so intertwined that it is hard to see the dividing line. In a wiki about cars, I can let my users divide themselves into two primary groups:
  • Those that want to maintain only topics about cars.
  • Those that are willing to maintain more.
If the car people are going to ever have a comprehensive index that shows only cars, then someone will either have to categorize all the car topics, or categorize all the non-car topics. Since I want the car people to focus on cars, and not wikis, then I have to ask the wiki people to categorize the wiki related topics accordingly. Seriously, who should I expect to be better at categorizing their topics: People that create topics about cars, or people that create topics about wikis?

Look at the solution presented at the beginning of the discussion by ColasNahaboo. Not only did this solution require a lot of understanding of the structure of a given wiki, but it is difficult to maintain if you start adding wiki specific topics.

This is not about hiding anything from anyone. This is about giving users to most useful tools to find what they are looking for. If they are looking for topics about wiki, then there should be a mechanism to find those topics. That same mechanism can be used as an exclude for people that are looking for topics other than those related to wiki.

-- RandyScales - 29 Jan 2008

What you need to do Randy is the same as all the rest of us have done that have put TWiki in production.

You need to build some good TWiki applications and tailor the user interfaces that the normal users see. There is no generic solution to this.

If you want to make a TWiki installation about cars then you need to plant the seeds by making

  • A good WebHome that shows only the paths you want the users to take.
  • A web left bar that only show the items that make up your TWiki applications.
  • The right forms, submit pages to create new topics, topics with formatted searches etc.

Look at the Motion site I gave you. A person that wants to submit a bug report is not much exposed to any wikiness other than the fact that it is a wiki. There is an edit button. But he is guided to a page where he can see and submit bug reports. He fills out a web based form and submits to create the new bug report. Normal users have no use of looking at the index. As your TWiki grows the list gets too long to be useful anyway.

I do not see the point in adding a form to all the default topics in TWiki assuming that your users will add the same form to their new topics. There is no such thing as a wiki topic vs a non-wiki topic. If a user makes a TWiki topic with a formatted search - you don't want to see a silly form at the bottom. It will only disturb the usage.

-- KennethLavrsen - 30 Jan 2008

I think the point is being missed here. This isn't a conversation about wiki topics vs. non-wiki topics. It's a discussing about Topics that are about TWiki itself vs. Topics that are about whatever else. Even in a Web that's been created to discuss "Food," for example, there are some Topics that TWiki requires to function. When performing some searches, when viewing lists of recent changes, and when looking at the Index, these TWiki-specific Topics often confuse users who expect to see only Topics related to Food. You can't simply hide the Index from users, because it is an otherwise very useful tool--even when the Topic list gets extremely long.

-- DavidWolfe - 30 Jan 2008

Basically, you can't prevent users from seeing TWiki-specific topics (topics TWiki needs to function), as far as we are talking about those topics that come with a _default template web. However, and that's where you hit an issue, the normal TWikiApplications do come with a set of technical topics like form definitions etc that people tend to mix with net data. The only solution to this is to move all TWikiApplication specific topics into an Applications (sub) web. This has the advantage of not only moving those technical topics out of sight but also, that you can reuse these things in another web. This becomes a significant design issue for larger TWikiApplications that need care of their own, and which are important to those wiki users that care about the application itself. These need a helping hand also. That's one of the criteria that drove the development of the TWikiWorkbench framework.

-- MichaelDaum - 30 Jan 2008

KennethLavrsen, This problem is going to faced by every new installation. I could just solve it myself, on my own site, as you have done, or I could get it solved in the standard distro, saving a lot people a lot of time.

DavidWolfe, I do appear to be having trouble communication the point you have highlighted. Thank you for helping me clarify it.

MichaelDaum, Your idea of moving specific topics to a web is interesting. I participate in this discussion to discover ideas like this, so that we may evaluate our options. I do not yet agree that this is the only solution, and still hope to hear competing solutions from others.

-- RandyScales - 30 Jan 2008

KennethLavrsen, your concerns about reducing the functionality of specific functions is understandable, and I agree. In order to address your concerns, I am no longer proposing any change to the default index functionality, and I am instead promoting the addition of a feature to support the creation of new types of indexes. Specifically, indexes capable of including/excluding topics that contribute to the functionality of a wiki, but not to the primary subject of a wiki. Does this action properly address your concern?

-- RandyScales - 30 Jan 2008

Randy. The new types of indexes are simply topics with a SEARCH. But you still need a criteria. And here no one solution fits them all.

I have indexes that lists bug items. I have indexes that lists feature requests etc. In some cases I choose to use a topic naming convention. In some cases I choose to add a specific form to topics of a special kind and search for the form name. And sometimes I look for a specific form value.

Another option is to search for a meta data setting.

Excluding the default topics you find in any web is easy because that can be made as a fixed list like Colas shows above.

Your problem is to define a criteria for what else to exclude. Which topics contain information you want to find and which do not? It is possible to do that but it will always be different from TWiki to TWiki.

-- KennethLavrsen - 30 Jan 2008

Kenneth. You have listed the very problem that I am attempting to solve. While every administrator is free to implement their own method, many more might prefer that a default method be already in place. I am asking us to choose a method, and implement it.

The method listed by Colas is direct, but it is not automated. But how hard would it be to automate it? If we add a category to all of the relevant topics, then we would have a list of the criteria. As new topics are added in, by future releases, by hand, and by plugins, these topics can add themselves to that category, thus automatically updating the list. Then we can use Colas' method of using a variable, but instead of typing all the values in by hand, we have the variable pull the values from the list.

-- RandyScales - 30 Jan 2008

Adding a form gives a bad user interface for then the page you want to not list is used as part of a navigation page. So that is a bad solution.

Then we can add a TWikiVariable setting under "More topic actions" -> "Edit Settings". But this is geeky and not at all user friendly. And from a performance point of view the Index would mean opening all files to look at the content. Takes no time today. Takes forever when you have 1000 or more topics in a year or two.

Fastest way is using a naming convention. Except the webs TWiki and Main, all the default topics start with Web. I you decide to hide the defaults, the forms, the templates and any topic ending with Menu or Index then you can make a simple search.

%SEARCH{"*" excludetopic="Web*, *Form, *Template, *Menu, *Index" format=" * $topic"}%

As long as you create the few wiki application helper topics that keep this convention then the search should be fairly self maintained. And a SEARCH based only on filenames is very fast.

Hope this can give some inspiration.

-- KennethLavrsen - 31 Jan 2008

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2008-01-31 - KennethLavrsen
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.