extract_idea1Add my vote for this tag usability1Add my vote for this tag create new tag
, view all tags
Scenario 1: I am explaining the wiki wiki concept to a geek and he admires the possibilities of this technology. We talk about twiki appearing to be the most powerful, flexible and complete wiki engine

Scenario 2: I am showing twiki to a Muggle and explain how it lets multiple users edit content online. The first thing he or she points out to me is how ugly it looks.

The point I am trying to make here is, right now twiki is more of a technology than a solution. The current design is a great hindrance to have it accepted as a tool work with on a day by day basis.

-- MartinKuhne - 05 Nov 2002

Hi Martin. Have you tried the skins? Some of them are very nice indeed, and some even have Javascript tricks to increase usability (they usually don't work in every browser, though). For more information, please see WebHome#TWiki_SkinPackages, and, in particular, TigerSkin and KoalaSkin. See also MegaTWiki.

-- EstebanManchado - 05 Nov 2002

Yes, let's hear it for TigerSkin! We introduced TWiki at my workplace a few months ago, and the crucial thing was not technology, but people. And for people to use TWiki, it needs to be friendy. TigerSkin is the friendliest skin I've ever come across, and with a few modifications (such as making the IEJS formatting toolbar work in the edit view) it makes for a very, very useful interface.

There are lots of other improvements on our WishList, like a whole handful of plugins (why were these not preinstalled with TWiki itself?), that I hope the admins will find time to do soon.

I vote for a friendlier interface and a more useful out-of-the-box experience.

-- TorbenGB - 05 Nov 2002

Could you please explain what aspect of TigerSkin it is that you find user friendly. I am not questioning your comment, but trying to learn the specifics. It would also be good to see your whole wish list as well as the suggested list of base plugins.

-- ThomasWeigert - 05 Nov 2002

A userfriendly interface is key to get initial buy-in. As Martin points out, different target groups have different needs.

EnhancedSkinHandling with a bunch of pre-packaged skins was a goal for BeijingRelease. This will be deferred to the CairoRelease.

-- PeterThoeny - 06 Nov 2002

In response to ThomasWeigert's good point, I'll try to give a few comments. Since I'm not at work right now I can't be very accurate, but I could try to come back with more points later.

  • Iconified Edit/Attach buttons at the top of the page. Easy to access and easy to find.
  • Advanced features hidden in a More> dropdown menu
  • Configurable, collapsible-outline left-menu system
  • A less cluttered page top: only main features are kept while hiding or removing advanced features (raw mode, diffs, etc.).
  • No preview on save; just edit and view.
  • More to be added as I think of it.

  • I manually merged the IEJS skin into TigerSkin, so we have a formatting toolbar in the edit mode. Very useful and very friendly for newbies. No need to remember formatting rules, more MS Word-like. The toolbar also includes a dropdown list of web topics; when used, the selected topic name is pasted into the edit pane at the cursor - good when you didn't happen to memorize each and every topic name!
  • I also modified the skin to support per-web background colors. The WEBBGCOLOR feature was deliberately removed from the TigerSkin to make it more uniform, but we found that per-web colors help identifying the different webs. It also supports the notion that topics in other webs have to be prefixed -- because they're obviously not the same (color).
  • I also changed the default font everywhere to a serif font instead. [ added 08 Nov, TGB ]
  • I also changed the edit template so that the check boxes and their labels are once clickable area - it annoys me when I can't click on a check box label to toggle the box, but it's such a simple thing to implement. This would also go for the preview template if we'd use it. [ added 08 Nov, TGB ]

As for the WishList (which we are linking to from our WebHome to encourage user feedback), items I can recall right now include:

  • TablePlugin - to make tables sortable by heading on-the-fly
  • SmiliesPlugin - just a neat detail, completely irrelevant (and perhaps counterproductive?)
  • FindElsewherePlugin - absolutely vital to good integration and newbie users, especially because you can skip the Web. prefix and it still works. Avoids double entries for same concepts.
  • TWikiDrawPlugin - a major argument against TWiki is that we can't use images easily; we still need a lot of Visio and PowerPoint to illustrate simple things, but we don't want to have to attach clumsy GIFs all the time.
  • Timestamps must be printed in local timezone, and not GMT time. (GMT timestamps are very annoying when you only have one office and it's in Tokyo. Nobody can figure out when a page was last changed when there's a nine-hour time difference. Sounds simple, but human's just aren't built to think that way intuitively.)
  • We want the Last changed on ... by ... to be printed under the topic name as well (keep the one in the bottom too). Makes it easier to determine if there's been changes.
  • Repeat the Edit button on the bottom of the page. It's handy and we don't want to force users to have to go to the top/bottom/whatever of the page; for the sake of usability, let users edit the page when they feel like it.
  • More to be added as I think of it.

I realize there's no universally perfect skin for all companies, users, implementations. But there seems to be a general need for a nicer out-of-the-box skin than the default one. It's not that difficult to install non-default skins and add non-default plugins, though, but it's a selling point.

-- TorbenGB - 07 Nov 2002

I agree completely with Torben's comments, they all make a lot of sense - I have intranet users here who absolutely refuse to use TWiki because it looks so complicated, even though I have made it use the intranet standard font (Arial/Helvetica).

I would like to propose the following:

  • The community chooses one additional skin to be bundled with TWiki - should be relatively straightforward, providing simple features in main view (like TigerSkin ) with access to all other features via 'More' type links.
    • We should bite the bullet and make this skin depend on JavaScript, since I believe the collapsible menus will need this, and so that the IEJS feature can be used easily. Although I am not a fan of JavaScript, many intranet sites already require it anyway. The standard skin will remain available for those who don't like JavaScript.
    • It should target web standards used by modern browsers, such as IE5 or higher, Mozilla 1.x, Netscape 6.x, Opera 6.x. Again, the standard skin will be available for those using Lynx and so on (see http://www.webstandards.org/).
  • The selected skin is updated as required, and documented for ease of configuration - it should be very easy to make the standard TWiki distribution use this skin.
  • In the BeijingRelease, this is included, along with a list of RecommendedPlugins - the idea is that people who want a smoothly working intranet site should use the new skin along with the recommended plugins, though these would not be bundled with the main TWiki distribution.
  • In the CairoRelease, assuming the new skin is working well, it could become the default skin, keeping the current one as a 'TWiki classic skin'.

I really do think that the look and feel of TWiki puts a lot of people off - compared to typical WebLogs and intranet sites, it is complex and the use of serif typeface is old fashioned, reminiscent of web sites before the <FONT> tag was invented, let alone CSS.

-- RichardDonkin - 08 Nov 2002

What a wonderful proposal! I really like the idea of voting for a single skin to replace or bundle with the "classic" TWiki skin. I would vote for replacing rather than merely bundling because I think there's a usability benefit for newbies, but I have a feeling that long-time fans would prefer just bundling.

I second the opinion that JS-based features should be included, as long as they are reasonably cross-browser compatible. I know it's tough to achieve that completely, so 'reasonably' is the keyword here. But it's definitely a must-have.

A shortlist of recommended plugins is a very good idea. But, if they're recommended, why aren't they included by default? That would be even better.

I like the concept of letting one upcoming release be a test (bundled, and with recommended plugins) and the following one be for real (replaced, and with the plugins included), based on user feedback. That requires that there will be some user feedback though...

ALERT! I only have one major objection to Richard's notes: Serif fonts aren't bad, they're good. Courier is downright terrible, but other serif fonts are a lot easier to read than sans-serif fonts. There's a reason newspapers and books are printed in serifs; if sans-serif would be easier to read, the publishers would use that instead. Typography professionals know that sans-serif is good for headings/buttons/menus/etc., while serif is good for long texts such as topic contents. I should note that the implementation of TigerSkin at my workplace features serif fonts instead of the default Arial. But Courier should be exorcised.

-- TorbenGB - 08 Nov 2002

Richard, excellent proposal! There is a ton of excellent patches around which IMHO should be standard features. I would like to have them, but I am not experienced enough (or too afraid) to apply them without much studying. Also, I feel time for changes is coming, and I hate to go non-standard way.

The only issue is, how to get approval of CoreTeam? We can vote and vote again (and then recount wink ) and nothing will happen, if no developer able to make changes in main codebase is willing to do so. Do we have one with us?

What we might want now is regime change (I always was a radical smile ): IMHO, for Twiki community to thrive we need to develop "Twiki Best practices" for newbie users/admins and make out-of-the-box Twiki easy. And yes I know that old installations will have slightly more work to do when unpacking new Twiki distro to make changes back to old defaults which they are used to have for years.

But make no mistake about it, this mean that we ask CoreTeam to do additional work (for free) which will not benefit them, but others. In terms of Raymond's "Cathedral and the Bazaar", to scratch somebody's else's itch. So we should be very polite - and gratefull for excellent job they are doing, even if they decide not to do what we ask for.

-- PeterMasiar - 08 Nov 2002

Well, I am on the CoreTeam, and JohnTalintyre (TigerSkin author) is on it too smile ...

However, including an additional skin is a fairly major enhancement to the core, so I would like to see some consensus on the CoreTeam that this is the way to go. I don't have a huge amount of time to spend on this, but if good-quality patches can be produced by others I should be able to help get them in the core, assuming the rest of the CoreTeam is OK with this. As long as the new skin is additional to the current 'classic' skin, I imagine this would be OK with most people.

As for the 'ton of excellent patches' - have a look at TWikiPatches, there are a lot of patches but I'm not convinced all of them are good enough to go in the core. Even simple-looking bug fixes like RefreshEditPage and BackFromPreviewLosesText can easily take a long time to refine to the point where they work well in various situations. A skin is different of course, in that it is already quite modular.

Re serif vs. sans-serif fonts - I know that serif fonts are shown by many studies to be more legible, but fashion is quite important in the 'cool factor' of websites as well - if you look at a lot of modern websites, particularly WebLogs which are competing with TWiki to some degree, they often use sans-serif to some degree, or at least use more interesting serif fonts than Times Roman - e.g. http://news.com and http://www.webstandards.org, as well as PikiePikie etc. Of course, with a CSS-based skin this would be quite easy to change globally in a single place. On looking at a few sites, I realise it's actually not so much serif vs. sans-serif that's the issue - it's more a matter of whether the site has an interesting and clean looking design and doesn't just use default browser fonts.

-- RichardDonkin - 08 Nov 2002

I'd be a bit reluctant to introduce heavy dependency on Javascript. We use all kinds of browsers and operating systems, and one of the reasons we picked TWiki is that it worked perfectly on all of them. TigerSkin is optimized for IE according to TigerSkinPlugin. We tried using it, but too many of our browsers did not work properly. We settled on a different skin which does not have a Javascript dependency. I'm not trying to start a skin flamewar, just suggest that the default TWiki install should be as portable as possible, with a better-looking default skin that will still work equally well on all browsers/platforms. Extras that are optimized for particular browsers are no problem, as long as they are not part of the default install.

And I totally agree that a better looking default skin would make a huge difference in overcoming resistance when introducing TWiki.

-- MartinWatt - 08 Nov 2002

I agree with Martin. The default skin should not have any features that would cause it not to work on key browsers. The drop down menus on TigerSkin are nice, but last time I checked they did not work on Netscape. That would not be acceptable in the default installation.

I personally am less concerned with how slick the default skin looks, but how easy it is to customize. And also with not having things in the default installation that are not necessary to run the system.

-- ThomasWeigert - 08 Nov 2002

I also agree that it would be very important to replace the current skin with a nicer, "weblog-like" skin. I make the KoalaSkin for this reason. Misc points:

  • In europe, newspapers and magazines are traditionally written in sans-serif. Serif is easier to read for low-quality print processes, but on modern papers there is no need for it. So for an european, serif is ugly ... (well, serif is still used on some newspapers with small fonts to aid reliability). The Macintosh was the first computer system to consciously promote sans-serif to appear more "user-friendly".
  • I would also make Javascript optional. It should be possible to have "More" pop a menu or bring to a menu page depending of a variable.
  • I would suggest we move to more things decided at "compile time". e.g. in KoalaSkin, all templates are generated offline via a script. This saves a lot of runtime CPU, and allows for a much more sophisticated customisation. It can be made transparent with the new possibility to hook code on the save.
  • I think there should be only one skin, otherwise maintenance will be too hard for the core team. What would be nice is that this skin should be customizable enough so that Tiger, Koala, Gnu, ... Skins be expressible in this scheme. Note that the current documentation is too dependent on the skin to have multiple skins. In my site, users reading the tutorials and docs are a bit lost when they try to apply it to what they see.
  • I would push for more use of CSS. Note that Wired.com just decided to go for full CSS2, and that it is thus displays quite strangely on netscape 4.x. For Javascript, we should check that the skin stays functional without it, and that JS used works on modern versions of IE, Mozilla, Opera, Konqueror. For Netscape 4, there will be companies that will be locked it still using it (the one having developed complex intranet apps that only work on NS4 - Yep I know, it is ugly). However, trying to have JS working also with NS4 may be hell, better just check that the skin works without JS, even it is less convenient.
  • There are too many config variables: TWiki sites can be installed in too many different ways, this makes designing automatic upgrade schemes too hard (as well as a complex install for first-timers)
On a unrelated topic, I think that we need:
  • better upgradability: I should be able to unzip a new version into a running TWiki without problems (maybe just running an install script afterwards)
  • thus we could have closer releases, even without too much new functionalities, just to fix bugs. I find that a monthly release of KoalaSkin is nice, so that I can issue bug fixes immediately, and avoid code forks, but it is possible because upgrading the KoalaSkin is dead easy.

-- ColasNahaboo - 09 Nov 2002

I have been working on skin which relies on CSS completely, I just started adjusting it to work out of the box on the august twiki beta and should have something ready for upload on tuesday or wednesday.

The "what font should twiki use?" really is (should be) a non issue. One single line in a stylesheet controls that: body {font-family: [your favourite fonts here];} .

I would like to emphasize the easier upgradability wish mentioned by Colas.

I don't think it is necessary to require javascript in order to have a nicer twiki out of the box experience.

It is great that there are so many different skins for twiki becoming available, however I wish it were easier to split/share the functionality of them. I wonder if the specs should say that a skin shall only change the look and feel and not create files other than *.tmpl (e.g. no code), while added functions are in separate modules (something between a plugin and a patch).

This way an administrator could grab KoalaSkin SavemultiCgiScript, PhotonSearch, the TigerSkinPlugin collapsible menus, and the MegaTWiki editable menus and wrap them all in the skin of their choice with a minimum of hassle.

-- MattWilkie - 10 Nov 2002

The latter suggestion would certainly be great. Almost every skin ends up being a combination of modifications to look and feel and to functionality...

-- ThomasWeigert - 10 Nov 2002

Matt, I've been thinking about that lately, too, but haven't found a way to separate functionality and style/look. Have you got any idea?

I think, like you, that skins should be only appearance, and functionality should be added easily.... but how? If you have any idea, we could create a new topic for that and start working on it...

-- EstebanManchado - 11 Nov 2002

It's very good news that better default skin is coming. I recall reading somewhere here, that (PeterThoeny?) prefer default skin to be without tables in main body text completely. IIRC, he was concerned that malformed HTML table in page body will blow off whole skin, among other things. Did this concern go away? Are we ready to force our will against Peter's? (I do not dare wink ).

But there are more in good out-of-the-box install version of Twiki than skins. Question is, which kind of admin is our audience: Expert admin, or just newbie admin? I know we do not have resources to provide slick GUI interface to install Twiki, and it's OK. I know that when Twiki started, more important issues has to be taken care of. But now? TWikiMission says:

  • Design for a good "out of box experience"; advanced features are OK as long as they do not distract

I know what newbie Twiki admins are looking for - I am one of them wink . It is easier to delete, than add IMHO. I.e. it is easy to set up your users into User web and set up parameter, but new admin has bigger problems to worry about - until is too late. Maybe on hosted account it is not easy to install plugins like smilies, and doing it in a bunch will hurt less.

I suggest to agree on some BestDefaultSettings. I understand that many of these settings will not have sense for existing Twikis, based on current default. Old-timers even might have change their defaults when upgrading. But think how generations of new inexperienced Twiki admins will be grateful for that wink

There are many cool stable mature plugins available, which might just become part of the standard. Multiple skins might be bundled in, so admin can enable different ones and see them in action. Many system variables (like colors and graphic icons) might be pre-set, so Twiki will be pretty right out-of-the box. We have HighResolutionLogos available, but not present.

TWikiAdminCookBook and TWiki/InstantEnhancements pages has many suggestions for new admins. Recently I noticed that link to it was removed from TWiki.WebHome page, so it is not easy (for new admin) to find and use. And some tips require decision Before install. Too late if you found them 6 months late.

I might sound ungrateful - I am not. Maybe I am not smart enough to contribute by adding code right now, but I do care about success of best wiki - Twiki. To stop whining and start doing something about it: Maybe we should start AdminFriendlyTWiki page about what features are stable and worth be in default. Or should we revive died-out discussion in SimplerTWikiDistribution? RichardDonkin, you are the man now - where to go, what to do? How can I help this to happen?

-- PeterMasiar - 11 Nov 2002

I have uploaded the latest revision of SeeSkin. This is a major overhaul of my previous approach and should be much cleaner (no code, just templates and stylesheets). What is the process for getting a skin installed on TWiki.org? in CVS? Is there some test I have to pass?

-- MattWilkie - 13 Nov 2002

I think the difficulty with skins is picking just one as the 'official alternative skin' - there are reasons to have plugins with or without JavaScript, with or without use of CSS, and so on. Also, people have strong opinions about look and feel, making it hard to just pick one. So it may be necessary to do a new skin, borrowing from existing ones, to avoid choosing just one existing skin (which would annoy some people who use other skins).

I was suggesting getting a good alternative skin included in the default TWiki distribution, which implies it would be in CVS. This means that someone on the CoreTeam has to put this in, and the rest of the CoreTeam has to agree - ultimately, PeterThoeny is the final arbiter.

You could also put your skin into the CVS repository for the Plugins web, see there for details (not sure if anyone is using CVS there but they probably should!), but that's probably not what you meant.

  • I did not know there was a separate cvs repository for plugins. I'll go check it out. But no, that is not what I meant. My ultimate aim is for SeeSkin or something like it to be considered for inclusion in the core -MW

TWiki.org would normally have whatever skins are in the default distribution - however, changing the default skin is a big step, particularly since some TWiki.org webs are aimed at TWiki experts (e.g. Codev) where the current skin is a good fit. Also, per-user skin setups are hard unless you make everyone authenticate even to view pages, or use cookies (e.g. SessionPlugin) to carry a persistent 'use this skin' setting. Not everyone likes cookies, of course, so I'm sure introducing cookies to TWiki.org could generate some complaints unless it was optional (i.e. go to a special page to select a skin, which generates a cookie only for users who want them). See EnhancedSkinHandling, which is going to be in CairoRelease.

-- RichardDonkin - 14 Nov 2002, -- MattWilkie - 14 Nov 2002

For TWiki.org, any skin would be good as long as they would have the "direct save without preview" button in edit mode smile This is definitely something typically needed for expert TWikiers (and made the default to release the lock).

  • My most desired improvement to TWiki is direct save, combined with AccessKeys. --MW 19 Nov 2002

-- ColasNahaboo - 15 Nov 2002

I work at Lost Boys/IconMediaLab, Amsterdam as senior interaction designer. For the last couple of weeks I've been tweaking and reprogramming TWiki (in my free time) to be able to use it as a knowledge base on Interaction Design.
As interaction designer I am standing right in between the view of the designer and the view of the programmer, as I need both skills and point of views to create logical and pleasant web sites. So I have both the geek and the 'Muggle' inside of me :-). Let me give my two cents...

I agree with previous comments that the default TWiki design is not attractive for most people, and that packaged skins are a way to make a better TWiki experience. But I think the above discussion is too much focussed on 'futile' design issues (serif font, an icon with Edit). Probably my reaction should be placed elsewhere (UsabilityIdeas) but I felt urged to react to this.

I have tried out some skins and dislike most (I have started to create my own) because they do little to improve the interaction. Worst, the best looking skins don't look so editable anymore - the pages look like an ordinary (static and visually neat) web site. I think the most important issue with the Wiki concept is that everybody can edit the page. So it must look inviting, open and probably not too polished. That does not mean it should be ugly.

Look at Wikipedia to see that a plain interface can work too. It looks editable. And it is navigable. The way you can navigate through these topic categories is hardly seen on TWiki sites. Also note that WikiWords are not recognizable as such (too geeky) - one thing I have copied in my own TWiki (I use underscores to create Wiki_words and single Wikiwords_ - and they are rendered with spaces in between).

  • I don't find Wikipedia all that more attractive than out of the box TWiki. I can't comment on navigability because Wikipedia seems to under really heavy load for the last couple of days and page requests keep timing out. A simple way of getting a Wikipedia style look in TWiki is to set the background colour of each web to white. --MW
    • What I was trying to say is that a lot of skins are beautifying TWiki to an extend that it loses it most prominent feature: editability. Wikipedia is bare - nothing beautiful there, but it looks editable. This 'affordance' is something that should be kept in any skin - unless the skinned TWiki wants to look like an inaccessable site. --AC

Some more comments and possible improvements from my own experience:

  • The list of TWiki Webs at the top is not primary information on smaller sites or on sites, so the placing of these links could be reconsidered. Currently it is very hard (impossible?) to remove the other webs, as site preferences are stored in TWiki:TWiki and users in TWiki:Main. The sudden switches the user must make between webs is not desirable. And he must know from what Web he came from. I would rather call it sites than Webs.
    • Also see RenameWebToZone --MW
    • The 'correct' naming will depend on the context where the TWiki is deployed. Some intranets are divided in 'Areas', others in 'Rooms'. The naming should be so that new users don't have to learn a new terminology. So to have this as a site preference would be nice. --AC
    • If you have a small TWiki site, about one subject, it is really overkill to have the TWiki and Main and Sandbox webs. They should be removed or hidden for the average user, but this is not possible without changing the setup completely. -- AC 21 Nov 2002
    • If you have one Web, calling this Zone (or Room or Area or Project) does not solve any problem: you will get ZonePreferences, ZoneStatistics, ZoneChanges. It doesn't make sense. The one most common terminology that all users will understand is Site. You can have one site about one subject, or many sites about many subjects. Of course configuring the naming terminology within TWiki is a nice option, but I don't know if it is even feasible. -- AC 21 Nov 2002
  • The naming of the links at the bottom of the page are not very helpful. "Edit" ( = "Edit this page" ) and "Printable" ( = "Printable version" ) should be placed at the top (and repeated at the bottom). Also "Ref-By" should be named something like "Pages that link to this page". "More" to "More edit options". "Diffs" to "Version history".
  • Thought should be put into using different names, but using phrases instead of single words takes up too much room. My approach is to use title attributes to show tool tips on hovering over the links. I've renamed 'Diffs' to 'History'. The only alternative to 'Ref-By' I've come up with so far is 'Back-links' but I'm not sure that is any better. As for placement at the top or bottom or side, that should be a preference (relatively easy to do with CSS). --MW
    • Phrases take up too much room in the current horizontal format. I have put them in 3 rows at the bottom, that works fine - it is a small block of links that you use less often. At the top I have repeated the most important two: Edit this page and Printable version. --AC

  • WebForm is a too general name, should be renamed to Classification Form.
  • So naming is very important. To be able to use single words and lower case words as WikiWords make it possible to have "Homepage" instead of "WebHome", "Recent changes" instead of "WebChanges" and "Notify me" instead of "WebNotify". Of course you can name topics using the
    notation, but that does not prevent the topic names as being listed with their normal names in the Topic list.
  • The navigation could be improved. Wikipedia does this with both fixed links at the left and more dynamic links in the content frame with lists of category names and topic links. I am using a leftbar navigation with fixed links to the most important entry points, combined with a block of dynamically generated links of the topic's parent and its children. Of course the choice depends on the size of the site. But to be able to have my dynamic links I had to hack away in various .pm files.
  • There is a difference between Go and Search, but in the default design this is not clear. To provide 2 search fields works better: "Go to topic", and "Search text" (= simple search) combined with a link "Advanced search" (was: "WebSearch").
    • there shouldn't be, or at least there shouldn't be as much of a difference as there is currently. See GoIsSearch. --MW
      • I have skimmed GoIsSearch. There are a lot of suggestions, and even ready ones, but they seem to target 'power users' in that they have a function that you must know about before you can use it. For instance: "If the contents of the box begin with /, it performs a standard full text search". No new user could ever figure this out by himself. Look at Google: they use two buttons for two functions. The logic is visible, can be read and does not depend on the syntax entered in the text box.
        To assume a certain search strategy would be dangerous, for instance: "do any of: (topics) exist in the current web? If only one yes, open page immediately". Perhaps I DO want to see search results instead of going directly to the page itself. Of course I could click "Ref-by" when I am in the topic, but that would be an extra step and I would miss all nops. (this is another point, but I use "nop" to make my pages more readable - a lot of links slow down reading of the essential text, and you can give these links at the bottom under "See also:"). --AC

  • The creation of a new topic is hidden under "Go", and new users should enter a wrong topic name to find out about this function. They could be helped with a link "Create new topic".
    • a good idea --MW
    • At my workplace, we've "solved" this by teaching that the only way to make new pages is to edit an existing one first with the name of the page you want to create. This is pretty easy to understand, it does not require any special features because it relies on the usual page-editing, and best of all, it prevents orphaned pages. IMHO, Create new topic would almost certainly produce a large amount of orphan pages. [ Main.TGB 20 Nov 2002 ]
    • Of course you would need the situation where you can teach this to your users, as also this approach is not obvious from the interface, too. -- AC - 20 Nov 2002
    • To prevent orphaned pages, it could be an idea to set the new topic's parent at the edit page, like Matt suggested. Or even to force a topic parent (I'm not sure if this is desirable). With a tool like the TreePlugin (see below) you can get a quick overview of where each topic's children are located, and where weeding and regrouping is necessary. -- AC 21 Nov 2002

  • A lot of times feedback could be offered. For instance, the link "More" leads to a page (template oopsmore) where you can set the topic's parent, but you don't see the currently set parent. Better yet: the parent is preselected in the dropdown list.
    • Better still, the parent should be changed from the Edit page instead of More. --MW
      • Agree. But in the way the dropdown is created now there is no way to have the current selected item as the default. In my own template I have put: The current set parent is: %PARAM3% - where PARAM3 is a third parameter given with the link "more" from the view template. --AC

  • On the page Move/Delete/Rename (template rename) the feedback is currently placed at the bottom of the page, while it could be distributed to where it is needed. For instance with Move:

Move or delete this topic

Note! To delete the topic, select the Trash Web. More help on moving topics
  • I very much like the TreePlugin with the Colored nested tables as output. A visual sitemap serves as an enhancement (but no replacement) to a topic list and an indented list. Should be packaged with TWiki.
  • I have created some variables to improve text formatting, basically divs that are styled with CSS: intro paragraph: %STARTINTRO% .. %ENDINTRO%, comment: %STARTCOMMENT% .. %ENDCOMMENT%, related box: %STARTRELATED% .. %ENDRELATED%, relations table: %STARTRELATIONSTABLE% .. %ENDRELATIONSTABLE%, left image: %STARTLEFTIMAGE% .. %ENDLEFTIMAGE%, right image: %STARTRIGHTIMAGE% .. %ENDRIGHTIMAGE% . Not very neat and definitely steps more complicated than the TWiki Text formatting rules, but these variations bring the pages to life. The most important and useful is the comment block (light sand color), to visually distinguish the flow of the text with remarks and help texts. For instance, "Create new topic" has a help text labeled "Starter's info" with info how to name Wiki words. Once you know this, you don't have to read it again. The colored block makes visually clear you have seen it before and don't need this info to proceed.

Well, I notice I am starting to dig more and more into details, so I better leave it to here. But I hope this is food to some more discussion!

- ArthurClemens - 16 Nov 2002

Arthur, you've made many good points and I'll defer comment on most until I think about them a bit more. In the meantime I've interspersed a couple within yours.

And, not that it helps us solve anything, but I bumped into this interesting essay related to the discussion at hand: Why Free Software usability tends to suck

-- MattWilkie - 19 Nov 2002

I added my two cents to the "The creation of a new topic" bullet above.

-- TorbenGB - 20 Nov 2002

Additions from 20 and 21 Nov inbetween: Go/Search, different TWiki webs (removing/renaming), creation of new topic, feedback, naming of edit links.

-- ArthurClemens - 21 Nov 2002

Good discussion here. The main answers to this break down into A. technology and B. information design. Technologically the answer is to build new skins, right? That's what Joachim did at the HurdWiki:Main/HurdGnuFansOrg with I think some great results. I have ideas for a new skin as well I'm mulling over.

Information design is less clear cut by far.

-- GrantBow - 14 Jan 2003

(Maybe this should go to BetterDefaults... So check discussion there, too. But ArthurClemens comments era here ).

There is a strange thing. If programmer (perl guru hacker) tries to design graphics, s/he usualy fails miserably, can see and acknowledge it, asks a pro (graphic designer) for help, and uses the much improved design (sort of - we still are waiting for HighDefinitionLogos ).

But when a programmer designs user interface, s/he is perfectly happy with the kludge it works for him, and often wants to solve user complaints by more user training, not by improving the design. Of course I am talking about my colleagues at work - any resemblace to Twiki community is pure coincidential wink

Then a pro, who does interface design for a living, comes over, explains what is wrong and how to improve it, even contributes code. And guess what? Hackers in true spirit of OpenSource, dissmiss this as a personal opinion. And insist in keeping old ways. Why it is so? Maybe because flaws in interface design are not as easy to spot as graphic flaws? Please visit Twiki-based site what ArthurClemens designed: http://www.visiblearea.com/patterns. You can see touch of a prefessional. Compare it with skin here. And decide who is the authority to decide good from wrong.

If this comparision will not persuade you, nothing will.

I rest my case.

-- PeterMasiar - 14 May 2003

Wow. Arthur the twiki design -- looks as well as function -- you have going there is stunning. Do you plan on releasing your skin? Do you mind if I borrow from it?

-- MattWilkie - 14 May 2003

Peter asked me that too. I promised to get back to him in a few days. In the meantime, please use whatever suits you. I learn from others all the time.

-- ArthurClemens - 14 May 2003

Another great improvement by Arthur in his skin and code patches is: WikiWords in links are separated by spaces - he uses NoBumpyCase.

-- PeterMasiar - 15 May 2003

I nominate and vote "yes" right away that ArthurClemens be immediately put in charge of the default skin for TWiki! smile

-- TomKagan - 15 May 2003

I just wanted to say that I'm 100% in agreement that TWiki's default skin is a barrier to its widespread acceptance. I'm still figuring out how to turn our TWiki into a skin, since we've made some minor coding changes, but I promise to do so eventually. Our TWiki uses mod_auth_mysql to authenticate off an existing web forum username/password database instead of .htaccess. The seperation of usernames from WikiNames was very unpopular at the old phpwiki, so I have made attempts to allow regular usernames. (heresy, I know...) Currently, the SpacedWikiWordPlugin is installed. Please feel free to take a poke around at what happens when a web designer (Tom) and an assembly programmer (Me) tackle a perl webapp (TWiki). smile See http://wiki.pgmfi.org

-- DavidBlundell - 17 Feb 2004

See also SimplerDefaultTemplates, HowToGetInternalBuyInForTWiki, SimplerTWikiDistribution, BetterDefaults, NoBumpyCase

Edit | Attach | Watch | Print version | History: r38 < r37 < r36 < r35 < r34 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r38 - 2004-02-17 - DavidBlundell
  • 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.