brainstorming1Add my vote for this tag customer_focus1Add my vote for this tag marketing1Add my vote for this tag usability2Add my vote for this tag user_interface2Add my vote for this tag web_design2Add my vote for this tag create new tag
, view all tags

TWiki for Normal Users

Discussion, brainstorming and examples about how an end-user focused TWiki may look like...


My very first TWiki Experience was a bit shocking. After arriving on http://twiki.org I felt overwhelmed by the amount of information presented to the user. I thought how can a product with such a website be any good ? This becomes even more scary when considering that website and product are exactly the same thing.

The reason why I came to www.twiki.org was that my former company, a usability consultancy, was in need of some kind of knowledge management system. The topic TWikiUsabilityTestingAtSirValUse describes some of the issues we ecountered when starting to use TWiki for the very first time. However, quiet some time passed tll I understood and realized what a brilliant product TWiki is.

Because of our jobs as usability consultants we were almost entirely focused on all the interface shortcomings. Many of my colleagues felt like this isn't really the product that we need. The main complaint was "I never know where I'm at". A top-level navigation menu with highlighting was something missed by most who where part of this evaluation stage.

As a result of this I put some efforts in reducing the noise in TWiki's user interface. After having a highlighted top level navigation bar, color coding and stuff like that their was almost no opposition left. Now, the reaction was like "wow, looks good. when do we start using it?".

What I find interest about these reactions is that the only thing that changed was the look. So one might say that functionality and power is important when searching for potentiol tools to solve a problem but tends to get ignored or not noticed if the people who use this powerful tool feel uncomfortable with it.

Lessons learned

The main finding, which of course isn't a new one, is that some people are able to ignore noisy interfaces because they know how to muddle through all this or because they have build it. But some aren't. Either because they are not able to understand it or not willing to invest the time to do so. The result is the same - they wont use it.

This is exactly what happend on my current job at IBM where we have a wiki for our department that nearly no one is using. And why? Mostly because of interface/design shortcomings! People aren't able to orientate, don't know where to go.

Design decisions and considerations

...based on my and my former colleagues findings on using TWiki with NatSkin at SirValUse and with PatternSkin here on twiki.org.

  • separate tools from webs (which are used for navigation in this design)
  • top bar with the ability to highlight the web you are currently in
    • I know this solution does not work in an environment with lets say 30 or even 700 webs but I feel like having such a high number of webs is not the way to go.
  • reduce the noise where ever possible
    • this was a big task wink
  • Use icons to ease unterstanding of the given options
  • remove all those geeky links like "more", "raw view", "manage", "More topic actions"
  • avoid the more screen
    • parenting is done in edit
    • delete / rename / move is an option on it's own
    • restoring is done via the footer

Design Examples


  • Never underestimate the importance of images. It gives your site a "human touch" and makes it more appealing for the eye.

tool bar

  • The idea is to separate the navigation menu from tools. The standard twiki distro has a imho unhealthy mixture. You got your webs which are in fact a navigation aid underneath things like changes, index, preferences and so on. The result is that the purpose of the sidebar is not entirely clear.

  • Well, I got this part titled "navigation" as well. But I think it's a different story here. Any ideas for a better wording are welcome.

user page

  • I never understood why the user home pages on twiki.org are so god damn ugly. Although I was never able to install Arthur's PersonalInfoAddOn (due to problems with either my twiki version or because I use NatSkin) this AddOn should be used here on twiki.org (or the simpler UserHomepageHeader).

  • These user pages are not a good marketing thing wink


  • See this Bolg entry for more info and ideas regarding the creation of site maps.

search results

  • Since nearly everyone is using google users don't need to get used to a new search interface when it looks similar to google.

attachment table

  • hmm, what is manage about? What can I manage? With these icons it should be easier to unterstand your options.

attach screen

  • Slightly different styling.

  • BatchUploadPlugin installed to allow upload of multiple files at once (you need to zip them befor the upload and the plugin autmatically extrats the files afterwards).


  • See Bugs:Item5543 for some background information explaining the motivation behind this solution.

rename / move / delete

  • big, big icons so that reading is not so important anymore.

  • not 100% sure if the icon for rename / move fits in here

What to do with this? Next steps, Brainstorming...

-- CarloSchulz - 20 May 2008

First of all: thanks for posting your insights. We need these discussions to show what is wrong with certain decisions that we have made. What you describe is very similar to my experience: TWiki is so bare bones that it takes a lot of efforts to make it attractive, in appearance and in functionality.

On the other hand it is quite normal to have to customize a tool to the needs of an organization. But the effort may be too high now.

A lot of your additions require plugins that are not automatically installed with TWiki. This discussion can make a difference for BatchUploadPlugin, TreeBrowserPlugin, a personal home addon. Then ImagePlugin is too difficult to install with some computers so cannot be relied upon.

  • Yes, it is a pain to install Image::Magick on OSX, as is the case for a lot of other plugins on OSX for similar reasons. However, Image::Magick is shipped with most unix distros out of the box. - MD

On the default interface: the past years we have had very narrow time windows to make any changes, so the default interface has been practically frozen for a long time. We need to bring it one step further now.

Also good to define problem areas: web homepages, personal pages, the more screen. I would add a couple of others:

  • the registration procedure
  • error feedback messages (oops)
  • the button row on the edit screen
  • the separation between attach and edit
  • the lack of handling of multiple attachments
  • the lack of handling multiple topics with form field values when a form definition changes
  • the lack of titles for topics, form fields, page types (current *Templates)
  • the notion of "advanced search" while there is no easy way to filter a search result set
  • the lack of navigating parent/children (HierarchicalNavigation) without an extreme speed penalty
  • the existence of a jump box

Some suggestions don't scale, so an alternative must be provided:

  • horizontal navigation on webs (some TWiki installations have hundreds of webs, and we can't do anything about that fact)
    • true, but a horizontal navigation does not necessarily need to represent webs. Basically I did this with webs because that's the it works with NatSkin. Maybe anotherway of doing this is possible but I lack the skills to implement something with a similar result but not based on webs. CS
  • your example with the page revisions (some pages have hundreds of revisions)
    • it is limited to the ten latest revisions, but you're right by now there's no easy option to access the revisions not shown in the table - CS

I do like the ease to manage attachments directly. This cannot really be difficult to bring to the default skins. The meaning of the icons is not that obvious though. I would prefer a folding out nav thing like on flickr.

  • sure, not everything is 100% perfect in this design in particular the icons do not fit everywhere as they should - CS

Some ideas need more work:

  • The list of changes at the bottom do not allow to compare revisions
    • I was thinking of a way to allow this from the changes table at the bottom but I haven't finished thinking about this - CS
    • Is there any other place to compare revisions?
      • Not yet as I rarely compare revisions - CS
  • The prominent position of the page tools in the left bar means that more relevant items are pushed down. On the other hand, you have used only tool links, in that case it won't matter.
    • Where would you place personalized ("my") links?
      • I haven't seen an intuitive way of addding personal links with twiki so far, that's why I removed them. CS
    • It is not that bad to mix navigation and tools. But the distinction between the items must be clear(er).
  • The batch upload option on the attach screen promises it will extract existing zip files. I believe it only works when uploading a new file. But it would be a welcome plugin enhancement.
  • FamFamFam icons use transparency, but that is not supported on explorer 6. So we need to use GIF files for a while yet.

Our company has different needs than IBM. Showing user activity and updates of documents are key. So this is our example, the homepage of the Lost Boys intranet (using TWikiNetSkin):


-- ArthurClemens - 20 May 2008

Thanks a lot for your great feedback.

The Lost Boys homepage is a very good example of a well thought over home page. Good work. And as you say, different needs require different designs.

Please note that this is in no way an IBM wide TWiki installation. Compared to IBMs overall size it is just used in very small department. More a team wiki than a company wiki.

-- CarloSchulz - 21 May 2008

Carlo, you created a great design. I am sure that a lot of clients will prefer to get a TWiki that looks like this out of the box. So there is definitely a market to create a TWikiForNormalUsers distro.

What yours and Arthur's work also shows is the importance to create a proper frontpage. If the frontpage sucks, any other gem is ... well just some page buried in your wiki.

And let me know on how you plan to release your stuff. We should work together on it to make sure it survives the next plugin updates and things don't diverge too much.

Another idea would be to create a twiki-theming.org site to increase the momentum for a twiki theming community.

-- MichaelDaum - 21 May 2008

I would love to get our TWiki to look like Carlo's. The site is a huge improvement for an (non-developers') intranet. Unless it's packaged somehow though, I wouldn't stand a chance of implementing something like this. I agree with Arthur that ". . . it is quite normal to have to customize a tool to the needs of an organization. But the effort may be too high now." It's way too difficult for mere mortals (i.e., non-developers) to make the kinds of changes you see here.

As for plugins, I not afraid to install any plugin that makes something easier to do or adds functionality my users consider important. I'm not even afraid for the installation to be difficult. The real challenge is just when there is no real supporting documentation for what might be difficult installs (i.e., Image::Magick on OS X--which, in fact I have installed, but still can't get plugins that depend on it to work).

If this IBM "theme"/"skin"/whatever were packaged and available right now, I would jump at the opportunity to use it.

-- DavidWolfe - 21 May 2008

Thanks you very much for sharing this Carlo, it looks very clean. FWIW, at TWikiDotNet we identified usability and out of box experience the critical factor in getting acceptance outside engineering. Usable/presentable wiki homepage and user homepages are crucial.

-- PeterThoeny - 22 May 2008

I've taken over your google-like search result page for standard NatSkin.


-- MichaelDaum - 22 May 2008

Nice smile . We should meet soon to coordinate further development

-- CarloSchulz - 22 May 2008

Hi Carlo, thank you very much for sharing these layouts and comments with the community. We have an implementation for a customer running also, that is much lighter. I will ask the customer, if this can be posted here for discussion and input. As soon as I have approval, I will enter the discussion with examples. I like your work a lot. Congratulations for these results!

-- MartinSeibert - 22 May 2008

Here's another twist on attachments:


I've moved the "Actions" column to the end and added a separate row for the comments. Tables tend to get squeezed if the comments are longer so I've added an extra row for them. I renamed the column headers also to be more readable, e.g. "Attached by ..."

-- MichaelDaum - 22 May 2008

Overall I think, too many icons hurt more than they help.

-- MichaelDaum - 22 May 2008

Michael: I agree. The TWiki-standard-layout has too much buttons and links with only little value. For example: "Index".

-- MartinSeibert - 23 May 2008

Links: wikis make it easy to link topics to each other. Unfortunately, pages show much too many links on wikis, i.e. on twiki.org. While "link-rich pages" are a concept of its own value (learned that from Carlo), wiki pages become "link-rich" by accident. Users simply don't know which link to choose being overwhelmed by this range of choice. TWiki.org's frontpages and webhomes are unfortunately a good negative example how not to do it. But so is http://en.wikipedia.org as well. It is like trying to eat an icecream with too many flavors.

-- MichaelDaum - 23 May 2008

Range of choice is not the problem. See a successful linkrich homepage that we made: http://hema.nl

Lack of perceived relevance is the problem. That can be caused because this user does not need the links, or because the used wording does not match the personal domain, or because of bad visual design (lack of organizational structure).

-- ArthurClemens - 23 May 2008

Yea, but that's a site presenting a catalog of its products. That's where it totally makes sense. I agree. It's a linkrich page by purpose.

-- MichaelDaum - 23 May 2008

There is an interesting similarity between your hema site and my example homepage - no underlined links! Too many underlined words and you see nothing... just lines

-- CarloSchulz - 23 May 2008

No underline links is suitable for some situations, but I don't think that will work in a wiki topic text. Places where underlines are superfluous are menus, links lists, Table of Contents and so on, where the list gives a 'clickable context' to the items. See this principle at work at http://www.amazon.com/ - the left menu without underlines and the content items with underlines.

-- ArthurClemens - 24 May 2008

I have an approval from our customer ReiseBank for showing their layouts here. I will prepare a document like this in the next days / weeks ...

-- MartinSeibert - 25 May 2008

That's great news Martin. I'd love to see more delicious screenies smile

-- MichaelDaum - 25 May 2008

I am slowly catching up with my mails and rss feeds. I will do my very best not to let you wait too long. smile

-- MartinSeibert - 31 May 2008

A blog post at Humanized: Ten Ways to Make More Humane Open Source Software. Good read with examples of OSS projects. Number one rule: Get a Benevolent Dictator. Someone who has a vision for the UI. Someone who can and will say “no” to features that don’t fit the vision.

-- ArthurClemens - 29 Aug 2008

Benevolent Dictatorship is the one (extreme) side of a wide range of various ways to govern an (open source) project, putting aside that not every BD is a blessing for the project (see GCC - EGCS - GCC story).

-- MichaelDaum - 31 Aug 2008

I don't think the people at Humanized were referring how to organize a OSS project in general, but instead wanted to emphasize the role of the user experience.

-- ArthurClemens - 31 Aug 2008

OIC, maybe I am a bit allergic when someone is calling for the BD. I am all for "let the experts do their expert job."

-- MichaelDaum - 31 Aug 2008

Arthur, thanks for the link. Very good read. Made me think about a couple of issues we have with TWiki.

Actually, the number one rule arthur quoted does not refer to a main BDFL of the entire project (in TWiki's case Peter) but to a BD (or a team of) for the job of creating a great user experience. Which is equal to "let the experts do their expert job."

I think it is about to write down a vision and develpoment process for twikis UI. See TWikiUserInterfaceStrategy

-- CarloSchulz - 01 Sep 2008

I think the interesting observation is that some love the current pattern skin (me), some want additional features added and some want less.

I guess the truth is that there is no "normal" user. The UI depends on both purpose (wiki vs CMS vs blog), scope (single purpose or multiple departments with different needs) and the user background (Duh computer?? vs geek). I think the best we can do for TWiki is to enable and develop multiple skins of very different appearence. I recently thought of having a PDA/Smartphone type of skin with very simple UI and no left/top bars at all.

With a stable skin API and just 3 or 4 supported skins we may also see more contributing skins again.

An overall strategy could be diversity with respect to skins.

-- KennethLavrsen - 01 Sep 2008

Inspired by this topic and encouraged by my users frustrated with the UI experienced I created a new PatternSkin overlay for our installation that I have now packaged up as the NuSkin (for normal users wink ). I still want to do search, attach and edit templates as demonstrated above, but for now I think the view template is a stable v1.

-- DavidPatterson - 03 Sep 2008

nice effort David smile

-- CarloSchulz - 03 Sep 2008

A similar design like the one shown above will be either part of a future NatSkin release or available as an add on package to the NatSkin. Can't predict any release date.

-- CarloSchulz - 03 Sep 2008

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Attachments.png r1 manage 15.1 K 2008-05-22 - 20:31 UnknownUser  
JPEGjpg NatSearchSnap1.jpg r1 manage 106.6 K 2008-05-22 - 13:13 UnknownUser  
PNGpng attach.png r1 manage 36.1 K 2008-05-20 - 16:01 CarloSchulz the attach screen
PNGpng attachment_table.png r1 manage 36.0 K 2008-05-20 - 16:06 CarloSchulz the attachment table - using icons to access manage functions
PNGpng footer.png r1 manage 44.6 K 2008-05-20 - 16:02 CarloSchulz the footer - designed for easy access to prvious versions
PNGpng home.png r1 manage 190.9 K 2008-05-20 - 16:25 CarloSchulz our homepage
PNGpng homepage.png r1 manage 710.6 K 2008-05-20 - 21:00 ArthurClemens Homepage at Lost Boys, May 2008
PNGpng rename_move_delete.png r1 manage 132.8 K 2008-05-20 - 16:02 CarloSchulz  
PNGpng search_results.png r1 manage 55.8 K 2008-05-20 - 16:03 CarloSchulz  
PNGpng sitemap.png r1 manage 16.6 K 2008-05-20 - 16:05 CarloSchulz index turned into a sitemap
PNGpng toolbar.png r1 manage 35.5 K 2008-05-20 - 16:04 CarloSchulz the lefbar aka the toolbar
PNGpng userpage.png r1 manage 98.9 K 2008-05-20 - 16:04 CarloSchulz a user page
Edit | Attach | Watch | Print version | History: r36 < r35 < r34 < r33 < r32 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r36 - 2008-09-03 - CarloSchulz
  • 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.