create new tag
, view all tags
The basics of a wiki (with regards to UseModWiki), insofar as it works for me and the people I work with are:

  • Dead simple markup that anyone can learn quickly
  • Dead simple page creation and linking
  • RecentChanges and full text searching

Otherwise, the system gets out of our way and lets us work as fast as we can think of things to populate it with. As we get into working with the thing, we start to wish for more. ie. Versioning, in-browser diagram editing (like TWikiDrawPlugin), more topic structure, etc...

But, the thing is with TWiki, I'd like to see an easy introduction to these further features. The experience with my users has been "Oh, that's all there is to it?" And then a week or two later "Oh, and if I go further in, it does these things too?"

I showed TWiki to a more technical coworker, and his immediate response was "Yikes, what the heck do all those links do? That'll scare the heck out of the project manager. Clutter hell!"

So, while it's nice to have the TWiki and Know and Test webs out of the box to play with, it'd be very nice to have a super-simple distro of TWiki that comes with almost nothing, and hides the advanced features by at least one link away from immediate view. It might be anathema to the PowerUser, but I doubt an of my intranet users will ever be a PowerUser.

Anyway, I'll probably be playing with this...

-- LesOrchard - 27 Jan 2002

I agree. I spent quite a lot of time researching TWiki main site before installing TWiki on our server, so I got used to all this colored areas and links in it. And I am by nature curious person, and even tend to read software documentation wink

I read somewhere that 90% of the people prefer not to read documentation. Majority prefers to wait if some evangelizer/early adopter will learn new tool and show them pieces when they need them, Only 10% users are willing to invest time to research, if tool what they are using has some new features they are not aware, try and learn them. But software developers will never get response fron these "non-curious user", because these are also part of the "silent majority" which newer writes "letters to the editor" in newspapers.

When I showed TWiki page to my less curious colleague, she immediately complained that there are way too many links and she was pleased by skin=plain. Complete WabiSabi!

Also article in Unix Review noticed that TWiki is more time-consuming to install than other Wikis. And that after first install you may spend a lot of time configuring TWiki.

So I am thinking how much effort will be to prepare TWiki distribution be "out-of-the-box" ready. I was thinking to implement directly in distribution package:

  • put users into UserWeb (so instead of Main.UserName we have more obvious User.UserName
  • I guess leave Main web for info related to new site, for info shared between webs - TWiki should not hog this important area. If TWiki needs system files, I guess they should reside in TWiki web. Or another web with customisable name, like System or Admin, so users will not be tempted stick pages into it.
  • templates and skins. Can we have much simpler view template as instalation default? And TWiki admin can place other more sophisticated template afted most users will grow to appreciate all added functionality later. What about having just links to [Edit] and [More] right after topic name, in top menu, and discarding bottom menu? All stuff from bottom menu ( Printable, Difs, Ref-by etc) will be in this [More] page? I know that templates are customizable, but admin of new Twiki site has other more pressing needs, like designing site, getting buy-in and not to customize default look. Default look should be as newbie-user-friendly as possible. Let advanced user set their skins to advanced look, not vice versa. Can we add some kind of TigerSkin as default?
  • Maybe even rename Test web to Sandbox. Again, Test area is rather meaningful area for intranet (espacially for a company developing software), and TWiki should not hog it for system purposes. I know it's changeable, but IMHO is more time-effective to change it in distribution, than dozens would-be admins have to change it right after instalation.
  • plan for even more effortless upgrading to next TWiki release: wouldn't it be nice if I can upgrade by replacing /bin and /lib directories, setting config? If customer-specific system-wide changes were gathered in some folder which is outside Main and Twiki webs? Something like System or Custom or so, which will contain only topics customized or recommended to be customized, like TWikiPreferences, User registration etc.

Whole point is: TWiki is cool and powerful and highly customizable. And Twiki core team can customize it in no time. But admin starting with Twiki (and as in my case, also with Apache, Linux and HTML) has bigger fish to fry: to design webs, create some contens, get site up and running! So s/he lacks time to research how to customize templates, might be scared to rename Main to User etc. If Twiki wants to increase user's appeal ist better to put "best foot forward", to hide advanced features (just one click away).

Or possibly we can create TWikiAdminCookBook with tips and tricks for newbie TWiki admins (or maybe it exists somewhere?). Easy customizations tips and tricks, useful includes, to avoid reinventing the wheel. I know I would like to have one!

-- PeterMasiar - 28 Jan 2002

These are very good suggestions. We will make TWiki more intuitive for a better out-of-the-box experience.

As a start:

Renaming the Main web need to be investiagted first, follow up in RenameMainWebToHome.

-- PeterThoeny - 28 Jan 2002

Having just installed TWiki recently, I noticed a few things that were, ah, annoying.

  • Having to relock all the rcs files. I ended up a with a few shell loops that did rcs -M -l (I was 'su'ed to the web server identity). Seems like the server should be able to do this pretty much automaticly (its already running as the correct identity). I wouldn't mind have a "fix locks" button. Of course then I'd want to have the stuff shipped locked as someImpossibleUserDoesNotExistSoThatYouCanNotClashWithARealUser. wink
  • Several places in the TWiki.cfg file that have the same path repeated over and over. S'Ok to do when you want them to be different, but for the default case the file should have you set one and let the others default if not set.
  • Adding a new web is doubly tedious. Doing the file system work, like relocking the rcs files, could be done with perl code, since it is just making directories and copying files. Updating the Webs Table page and the site config (for the upper right menu) is really aggravating. Luckily one doesn't add new webs that often, I hope!
  • Initial setup is way too clutterly. I'm going to have to rework the Main page and nuke the Knowledge web. I like making the plain skin the default, may try that too.

-- DougPhilips - 01 Feb 2002

For re-locking the RCS files, see the one-liner command (using Perl) at WindowsInstallCookbook. This will work on CygWin or Unix. If anyone's interested, I re-wrote perl -pi.bak for another script, and can post a pure Perl equivalent that can be included in a suitable CGI script.

I agree that TWiki installation could be much simpler - as well as the file re-locking, it would be simple to automatically edit the shebang lines on Windows (see WindowsInstallCookbook again).

Not sure about plain skin as default (how would you edit?) but KoalaSkin looks good. I agree with the need for a simpler TWiki distribution - a big part of usability is starting with a simple but powerful feature set, and making it easy to discover and enable/install enhanced features.

-- RichardDonkin - 25 Feb 2002

My suggestions:

  • for TWiki.cfg
    • use more "vars in vars", e.g:
      $defaultUrlHost   = "http://koala.ilog.fr";
      $wikiLocation  = "wiki";
      $serverPath    = "/var/www/htdocs";
      With this 3 vars above, you can deduce all the other paths below:
      $wikiHomeUrl      = "$defaultUrlHost/$wikiLocation";
      $pubDir           = "$serverPath/$wikiLocation/pub";
      Thus, people installing in the default location will only have one or two vars to edit. And people can still customize fully
    • If possible, put all variables that should be edited (host, rcs path, sendmail) first and the seldom modified second after a comment: "normal installation need not touch this"
  • Make the default "front page" not the Main web. The Main web should be kept hidden as it is a kind of "Settings" web.
  • Consider going to RCS unlocked mode. thus the owner of the lock wouldnt matter anymore.
  • Use the KoalaSkin as the default skin smile

-- ColasNahaboo - 02 Mar 2002

Looking at the TWiki20030201 distribution, I notice:

  • A lot of users seem to have topics in TWikiWeb (these topics are actually redirection pages), but this makes the purpose of each web (TWiki, Main) fuzzy.
    • Suggestion: change the topic TWiki.TWikiContributor so each name links to a Main.UserPage. Delete all redirection pages.
  • The prefix Main is not really appropiate. This is an old discussion, see also RenameTheMainWeb and RenameTheMainWeb, but I would like to discuss this now in the light of the distribution. Looking at the contents of data/Main, I only see user names and office locations, and one topic redirection page, Main.TWikiVariables. If the TWiki distro is also a how-to, it doesn't make clear what other functions Main could have besides user administration.
    • Suggestion: change Main to Users or People.
    • Is there a simple tool (Perl script) so admins can change this Web name according to the company's culture?

Related: KnownIssuesOfTWiki01Feb2003.

-- ArthurClemens - 01 Sep 2003

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2003-09-01 - ArthurClemens
  • 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.