customer_focus1Add my vote for this tag persona2Add my vote for this tag usability1Add my vote for this tag create new tag
, view all tags

An evaluation of KindsOfTwikiUsers and their doc needs

While obviously people may not fall neatly into just one of these categories, I've tried to take a first cut at describing the various kinds of users I can think of. Please feel free to edit as well as comment. (Of course.)

  • Users...
    • Absolute newbies and casual users:
      • new to wikis in general
      • new to TWiki, but who may have used other wikis (such as Wikipedia or Writeboard) as viewers only
      • new to TWiki who are at least familiar with the idea that wiki topics can be edited
      • who have done some text-editing topics, but are still nervous
    • Having some experience:
      • (also above) new to TWiki, but who may have used other wikis (such as Wikipedia) as viewers only
      • who have done enough editing to be interested in learning how to do a bit more more than just correcting spelling errors and adding comments
      • who need to accomplish something and don't know how to get it done using TWiki
    • Having a comfort level in using TWiki:
      • who are comfortable using the simple TWikiVariables (i.e., the ones that are variables
      • who are willing and able to try playing with the advanced TWikiVariables (i.e, the ones that are really functions) and whatever plugins are installed
    • Experts
      • who can write TWikiApplications
  • Installers:
    • trying to install TWiki for the first time
      • having not much experience in web servers
      • having experience in web servers
    • installing TWiki for the nth time
      • installing a new release version
      • installing on a different platform
    • who have installed other wikis such as MediaWiki and come to install TWiki with very different assumptions
    • who have been using Windows and are completely unfamilair with Apache and the UNIX assumptions that underly TWiki
  • Administrators: People tasked with administering one or more TWiki installs. One of these may well be the person who did the installation.
  • Developers
    • who write TWiki Applications
    • who write plugins
      • who know Perl
      • who code by copy-pasting
    • who fix bugs in TWiki

-- Contributors: MeredithLesly


It's pretty clear (to me) that the documentation topics that these various kinds of people need are often quite different. The different needs of installers and administrators vs ordinary users is pretty obvious. The various levels of users I've described essentially reflects a user's comfort level with wikis in general and TWiki in particular

Writing (and thinking about) this has helped me to clarify why I think a Doc web is important. For one thing, installation and administration information is irrelevant to users and belongs in the TWiki web, leaving the rest arguably belonging in a different Doc or Documentation web, with appopriate pointers there into the TWiki web.

It's important to help the lower end of the user continuum to use TWiki effectively and (probably) to gently allow them to become more and more sophisticated in their use as they become more comfortable. Too much information can be extremely intimidating. At the same time, we don't want to hide information that users at the upper end want.

This suggests leaving the installation and admin topics in the TWiki web, as I've stated above, while moving (or copying if necessary) user-oriented topics into a Doc web with appropriate entry points and the like as well as pointers into the TWiki web documentation as relevant. Adding recipes to the Doc web would also help users experiment without having to learn too much too soon.

-- MeredithLesly - 13 Apr 2006

I think this discussion is about twiki.org as well as about TWiki installations (from a download). Designing for usage patterns is indeed the correct approach.

If we have a Doc web besides a TWiki web, it should be clear which docs can be found in Docs and which ones in TWiki. I think Docs means (end) user documentation. Plugin topics are admin and go into TWiki. Cookbooks could potentially fall in either category (installers/TWiki or end users/Docs) but that is not a problem: each cookbook has its audience.

So from the first round it seems that Docs could be a valuable site section. But I still think that Showcases deserves its own section as well. It is mostly targeted to potential users and evaluators, and Docs would not be a good name for that section.

-- ArthurClemens - 14 Apr 2006

I agree with Arthur on both counts, except that a Showcases web needs a little more discussion. When I first discussed it with (mostly) Steffen, I was thinking of a topic that might more properly go into a Community web (as was suggested by someone in a different context later on).

What I imagine as a Community web would be for the larger community, although it would include those of us (probably all of us!) who are working on projects of one sort or another. A place where, for example, I could start out describing a project in (mostly) text, with links to the plugins, etc., that I'm using. As the project moves along. the page(s) could be fleshed out with screenshots or, depending on the privacy and accessibility of the project, links to the install.

A Showcase could go two different ways: a fairly-fleshed out version of what I just described, or actual demos. But most of this comment should probably be factored into a different topic, as the focus here is on Doc, not showcases.

-- MeredithLesly - 14 Apr 2006

Peter's resistance to creating webs has resulted in the "categorization" and use of SEARCH to build category lists from tagged topics.

This is fine if you are already in the know. However part of the power of TWiki is the webs (or if you want, call them Namespaces) to perform categorization.

Having a Documentation web make the function quite clear at a high level in way that having category topics scattered though Codev fails to achieve.

Once, there was a tool that pulled the documentation topics out of a new installed and put them in a documentation web. The problem is that maintianing such a tool is a headache. Maintaining a documetnation web wodl be much simpler.

-- AntonAylward - 15 Apr 2006

Part of a discussion today with Kenneth in #twiki saddened me. Not because I disagree with him -- in large part he was stating facts, not opinions -- but because of the implications of what he said.

"Even engineers are awfully stupid when it comes to new tools. It is only 5-10% of them that ever bothers learning anything advanced in TWiki... But the 5-10% are the ones that create cool TWiki Applications that the other 90-95% use and love."

It's great that 5-10% of his users are able to create new TWiki applications. But I find it very disheartening to hear that 90-95% of his users use nothing more than the text-formatting guide. Is this typical? Is this what we want? And, if we don't want it, then is there anything we can do?

If what he says is true in general and will remain true no matter what, then there's little point in spending time cleaning up and reorganising TWiki documentation, since those 5-10% will find what they need no matter what and the others won't care. It also means that many people thinking about installing a wiki should be steered elsewhere, because their needs are met out of the box with a number of other wiki engines.

Finally, if what he says is true in general, it's a waste of time and energy for those who can program to do anything at all about documentation, since fixing bugs and enhancing TWiki (including enhancing performance) will contribute far more than anything else we could do.

-- MeredithLesly - 15 Apr 2006

This is typical, and I wouldn't be bothered too much by it.

While 5-10% of the users will create programs, the other 90-95% do have wishes: "can we have a blog?", "can we have role based editing?", "why does this interface suck, can it be changed?". The 5-10% of the users will have to look it up efficiently. If those 5-10% say: "I really don't know, I cannot find a thing on their site" it is not good PR.

Still, making judgements about effectiveness of one's time is very useful. But if our enhancements cannot be found because they don't have good access points, we shouldn't have bothered to write them in the first place.

-- ArthurClemens - 15 Apr 2006

I've made points elsewhere about TWIki.org presenting bad PR and agree with you here as well. I did have this silly idea that documentation for ordinary users was a good idea and will write it up for my own users, so that they never have to go into the TWiki web until if and when they become power users. I will, however, leave any reorganisation of the TWiki and Codev webs to others. If a consensus is ever reached.

-- MeredithLesly - 15 Apr 2006

Look at it this way. If 5% of a user base makes nice TWiki apps it is still maybe 10 times more than what it is in a traditional group ware add where maybe 0.5% of the users have the training needed and the access rights granted to get things done.

In traditional web design corporations have tool staff that make the tools and for the users it is one long battle to fight for the little resources available.

With a tool like TWiki the only thing that prevents a user from becomming a TWiki App developer is interest and a little investment in time reading the advanced docs and experiment. And learn to pick ideas from others. "Source code" is right there - view raw.

And if we make some improvements in the TWiki documentation that will make the fraction of users that write simple TWiki Apps from 5% to 10% - it is a fantastic improvement. That is double up and 20 times more than the 0.5%.

And for the remaining 90% - it means getting more nice TWiki Apps that can make their life easier.

It should not be a goal that everyone using TWiki makes complicated topics and TWiki Apps. It is the goal that TWiki enhances collaborations. It is the goal that people work better together.

Where I work we make professionel radio communication equipment used by Police, Ambulance, fire fighters, train operators, airports, harbours etc etc. That is what we do. Our product is not TWiki pages and TWiki apps. We make radio systems. TWiki is a tool for the staff to work together more effectively and make better products for our customers. Just like for our customers our radios are a tool to save lifes and protect communities, etc etc.

I see a 5-10% of users making advanced stuff in TWiki a great success and not a problem at all.

What we need to make sure is that:

  • The 90% of the users have good documentation and hopefully a better and better Wysiwyg interface. We still have a long way to go on the latter but we are still much better now than 2 years ago.
  • We have documents at middle level and advanced level which are organised in a proper and intuitive way so that those that feel like learning more can advanced their skills through self study and experiments and good examples. And also here we are getting better and better. But maybe the left bar and TWiki web home could be organised better through incremental improvement. We probably need some newbies and intermediate users to give feedback. I know I am already too advanced to judge. I love having an index topic and left var with everything.

But do not panic when "only" 5 or 10 % of users become advanced. That is more than most tools can ever achieve and is actually a good track record for TWiki - and for Wikis in general.

-- KennethLavrsen - 15 Apr 2006

As I see it, the "Doc" web should be targeted to those power-users, with all the cookbooks and howtos that allow them to create wonderful TWikiApps, and the TWiki web mayfocus on Admin docs that allow them to customize and secure their installations.

-- RafaelAlvarez - 16 Apr 2006

I should stop posting comments at 3am. I forgot to add that I have seen in my users exactly the same behavior that Kenneth saw. Actually is worse because 90% of the users don't even care about Wiki formatting.

-- RafaelAlvarez - 17 Apr 2006

As a DocumentationFocusGroup effort, I would like to focus on the listed types of users above, and start out with Users. Just because we have the most of them, and the least amount of information for them. Looking at the links on TWiki.WebHome, NONE of the topics is suited for new users. For instance, even WelcomeGuest has too detailed information, and cryptic phrases ("communicating asynchronously"?). And there are many more topics. TWikiTutorial focusses on the "whats", not on the "whys" (and has quickly outdated information like "You can navigate the webs from the upper right corner of each web page").

Perhaps before creating new navigation or editing topics, let us first think about what these users need. To be continued...

-- ArthurClemens - 16 May 2006

I think that there are two issues here (why I always see to intermingled issues in nearly every discussion at t.o is beyond me):

  • The navigation and quality of the documentation in t.o. This includes reorganizing all the content scattered in Codev, TWiki, Main and Support web
  • The navigation and Quality of the "shipped" documentation.

I do this separation because "users" that come to TWiki.org are either evaluators or admins, which has different focus and needs than the "end users" that work with a TWiki installation. We should not treat them the same.

-- RafaelAlvarez - 16 May 2006

According to people like Kenneth and Harald, end users don't read doc and don't do anything but create simple topics or fill in forms. Whether that's because that's all they need to do, all they want to do, or all they can figure out how to do isn't clear to me. And, of course, we have no information about the broader picture.

-- MeredithLesly - 17 May 2006

And according to me, 90% of the people don't even care about TML if they are provided a good TWikiApplication that "relieves" them from learning it (for our ticket system and project tracking the users don't need to know TML, for our SCM only the header and list sintax is needed). These users needs good documentation for the TWikiApplications, not for TWiki.

So, I think that we all agree that we all have different requirements for documentation.

BUT, and this is a big but, I realized yesterday we need superb documentation for users: PR and to convince evaluators. When I evaluate a software, I usually check these things before trying it, in order:

  • Feature list/matrix/brochure
  • Requirements
  • Installation Guide
  • User Documentation
  • Developers Documentation (if applicable)
  • Support
  • Price

If I fail to easily found any of the item, I stop the evaluation. Special case is the user documentation: If I can't find it in the webpage of the product, I expect it to be bundled.

I expect other evaluators to have different orders, but I bet everyone check at least the features, requirements and price. TWiki don't have a "price tag", but then... what are the features and requirements of TWiki?

So, I think that evaluators are another kind of "Doc Users" with another set of needs, and that we will benefit if they get a good users documentation.

-- RafaelAlvarez - 17 May 2006

Great! We really need this kind of information to be able to construct personas and user scenarios. Perhaps Kenneth and Harald can add some of their experiences with end users: how they react, what questions they ask, what they need.

-- ArthurClemens - 17 May 2006

One of the things we need to evaluate are the KindsOfTWikiUsage. These three things: usage, users, and documentation are not the same but are deeply related. We need to get as much feedback from installations as we can!

-- MeredithLesly - 17 May 2006

Talked about this on IRC: the need to get info from our users: how TWiki is perceived, what can be improved upon, what are the weak and strong spots. And on twiki.org: what are people looking for, did they find what they needed, etc.

I think it would be useful to create two questionnaires, one here on twiki.org (at least in the Support web) and one sent to twiki admins.

Should be followed up in a dedicated topic.

-- ArthurClemens - 17 May 2006

That sounds like an excellent plan; but don't do it half-arsed. Someone needs to follow through, generate the questionnaire, liaise with Peter to get it sent to the mailing lists, collect, analyse and present the results. Quite a lot of work, but well worth doing with the right questionnaire.

-- CrawfordCurrie - 18 May 2006

/me pokes Arthur for this one.

-- MeredithLesly - 18 May 2006

A useful list is on WikisInTheWorkplaceBook#InterviewQuestions.

-- ArthurClemens - 21 May 2006

Edit | Attach | Watch | Print version | History: r24 < r23 < r22 < r21 < r20 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r24 - 2006-05-30 - MeredithLesly
  • 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.