Basic Mode

See also: SimplerTWiki

From IRC, 11 Nov 2006:

Lynnwood	"packaged nicely" is the key piece there. we need so much to simplify twiki for basic use. i was just looking at the wiki on the site i mentioned above (MoinMoin) and noticing the comparative simplisity of basic interface. TWiki could easily do most of this.	[05:55]
PeterThoeny	agreed we can do a lot more in terms of usability	[05:56]
Lynnwood	But we're fixed on a more "robustly utilitarian" (i.e. geeky) interface	[05:57]
PeterThoeny	i think there is room for both	[05:58]
Lynnwood	oh totally!	[05:58]
PeterThoeny	out of the box i'd prefer a simpler interface	[05:59]
Lynnwood	i think twiki's interface is excellent for a pretty serious work tool but, yes, out of the box, it's a bit intimidating	[05:59]
PeterThoeny	i think we should have two skin modes, a basic one, and an advanced one the advanced one is the current patternskin	[06:00]
***	SergioSouza has joined #twiki	[06:08]
Lynnwood	yes, i agree

1. areas for simplification
2. a way to distinguish basic and advanced modes

For me this is not only about interface but about the total interaction with TWiki.

-- Contributors: ArthurClemens - 11 Nov 2006

Where can the TWiki interaction be simplified?

• Edit and Preview screen, the buttons Quiet save, Checkpoint are for advanced usage
  • Why would the preview screen be simple? Just another step to go through. Save and cancel is all that is needed for "simple" interaction. -- TW
    • Actually I agree that Preview is extraneous for most cases. Yet I wonder if people wouldn't miss this if it wasn't provided at all. -- AC
• Configure interaction, especially at first view (nothing installed yet)
• Web namespaces
• WebNotify has fairly complicated instructions. This could do with a simple 'add my name to the list' form.
• Topic action buttons:
  • Backlinks: for web and for all webs. Why not simply "Backlinks"?
  • History: one history button and a number of revisions and changes between revisions. Why not 'History' plus 'Last changes'?

Plugins that support simplification

• FindElsewherePlugin

Discussion

I saw this discussion in IRC, and it prompted me to create a simple but awesome TWiki skin demo using Css Zen Garden . This skin is a modification of the default skin, and supports all the css designs that were uploaded.

-- SvenDowideit - 13 Nov 2006

For configure

• Clear separation between basic and advance options; e.g. bin/configure?advance=on - Not all need to see all options. The more there is, the more confusing it can be.
• A global entry for all paths. e.g. DefaultPath = "/path/to/twiki/" would coincide with TemplateDir = 'templates' - one simple change in DefaultPath would change everything else.

For UI, since menubars are in list form, would be great if it has the whole hide/show feature. Something like...

• Sliding Tab Menu
• A vertical sliding menu maybe?
• Vertical flyout IE compatible - No javascript
• Vertical flyout 2

On content, maybe it's just me, but I find the lack of hierachy structure, or whatever form of categorised structure quite intimidating on what I want to find. Sure there are tags, but they aren't enough. Sure there are big topic headers, but they aren't good enough to justify. This would go easy on the overall UI (e.g. think breadcrumbs). I think MichaelDaum was working on something IIRC, on clear separation between Topics and Subjects, with tags.

• Is there any chance to combine Main and TWiki into one TWiki?
• Scrap unnecessary documents on the release copy, i.e. docs that can be found on twiki.org shouldn't be on release, for users. We can always come back to twiki.org to refer, and its usually something rare. And additional package called DocAddOn is do-able. But I guess there's alot of work involve in this?

-- KwangErnLiew - 13 Nov 2006

Blog post http://blog.dcinteract.com/?p=71 : "So there’s now, what, six potential ways to save a page? Three save buttons, plus a force new revision toggle that can be applied to each? Plus preview, _plus _cancel? Aren’t wikis supposed to be simple?"

-- PeterThoeny - 09 Dec 2006

We do tend to support edge cases, making it more difficult for all users; each time we think up of something handy to support our case we create a barrier as well.

We need to be more stringent on the impact of these decisions.

TWiki is a toolbox that can be customized. Extraneous buttons can be removed with a custom template. But the number of settings to change is growing with each release, so are the number of options for customizing templates.

We do server power users with our features. Question is: who is the TWIki user? Who do we support most? WikisInTheWorkplace could provide some answers to that. But shouldn't the defaults be simpler, with the power options hidden to be switched on by the twiki administrator?

This doesn't have to be a switch or setting in configure. What defines "power user interface". But we can provide easy to implement examples, or even cover templates.

I have updated the simplify list above.

-- ArthurClemens - 09 Dec 2006

In the last release meeting we have decided to remove the Twisty from the attachment table because quite some people (clients as well) reported problems in finding the attachments. The Wikipedia:KISS_principle principle has been mentioned.

The idea is to remove the default Twisty and provide a manual to add it back. My idea: leave a working but commented out version of the Twisty.

Now I would like to use this space to put forward a more serious proposal of simpler user interface for action links/buttons.

Proposal 1: Edit screen:

• Only show the buttons Cancel Preview and Save (TW has even proposed to remove Preview as well)
  • Leave the current buttons commented out so they are easy to put back
  • Write a cookbook entry to tell how to put these back
• Move the Add form button to the More screen

Proposal 2: View (topic) screen:

• One Backlinks link that points to the search results page of all webs
  • Write a cookbook entry how to change this to the current web only, and how to put the 2 links
• One Last changes link plus one History link instead of the numbers and arrows we have now
• Remove Printable from the bottom actions

-- ArthurClemens - 13 Feb 2007

On proposal 1 for edit:

• Agreed for all.

On proposal 2 for view:

• I think the Backlinks should point to the current web only. And, like in a search result page, there should be a link to "search more" at the top and at the bottom, aka links with "search backlinks in all webs" functionality. (There are many large sites where a default to "search backlinks in all webs" would be (1) to slow, and (2) too unwieldy (I know of three companies that have 700-1000 webs each.))
• On replacing the r9 < r8 < r7 < r6 < r5 with Last changes: The most common use case is to find out what changed recently on the topic, that is, we could actually remove all the r9 < r8 < r7 < r6 < r5 links and keep just a History link. That History link would show the diff between the latest 5 revs only (or whatever configure defines). It would also have a link to "show all diffs" at the top and bottom of the page. Instead of the "show all diffs" link we could place two selectors for top and bottom rev to compare.

-- PeterThoeny - 16 Feb 2007

The only silly button we have in the edit view is Quiet Save. Noone understands what this is about unless they know the very deep insides of how TWiki works. And if you do not have webnotify turned on then it has no function at all.

Please don't destroy a good user interface just because someone who thinks his users are idiots write a blog.

We need Save and we need checkpoint and all users with more than 30 minutes TWiki experience need them. There are no stupid users who do not need to save a large topic and stay in edit mode. We all need this.

And in view. Why remove the great feature that allows me to click directly to earlier versions? There are not at all confusing. It works very very well.

Please do not destroy a good user interface. Please do not introduce more mouse clicking to do a simple thing.

I will throw a core veto on any proposal removing direct access to viewing the previous versions, and see backlinks to current and all webs or removing the checkpoint button in edit. These are brilliant features that users learn to use very quickly.

It is funny that this comes up after the Attachment twisty decision where we decided NOT TO HIDE a feature. And then BANG everyone wants to hide features - again thinking all our users are idiots that cannot use anything. Remember who the target group is for TWiki. TWiki will 99.9% of the time be used by users that have used TWiki before. Wikipedia as a wiki targert audience that very rarely touch the wiki. You cannot compare the two. And we should not be like Wikipedia.

The only thing my users ever complain about in TWiki is learning TML. They still want a Wysiwyg that works. And the one we have now is a Wysiwyd (d = destroy).

It is not the first time I react this way. Last time I added a long song on my TWiki.org homepage. See KennethLavrsen

-- KennethLavrsen - 16 Feb 2007

I see we are running too fast. We have not yet envisioned how to make 'hidden' features quickly accessible.

Our goals should be:

1. make TWiki look accessible (not daunting)
2. make it easy for beginning and intermediate users to become expert users

-- ArthurClemens - 16 Feb 2007

The crux of the problem here is that we have to acknowledge that the UI needs/desires of a beginner and an advanced user are distinctly different and attempting a compromise betweeen these will satisfy neither.

I had an interesting experience recently with trying out NatSkin on a couple of clients. In both cases, they immediately liked it better than the default PatternSkin. When I asked why, they said, essentially, "it has less buttons."

Personally, I like both skins and I don't think this was a qualified evaluation of the two skins. It's just that, for beginners, simplicity trumps all other considerations. PatternSkin is a highly useable skin for more advanced users because it is easy to quickly access things like history. But all of this is just so much noise for new users...

For beginning users, I think we would get a lot better initial acceptance if we radically cut back all the UI features more experienced users like. And then make it easier for users to re-enable these features. Maybe just have an "advanced user" setting that turns them all back on.

-- LynnwoodBrown - 16 Feb 2007

Perhaps a compromise is not needed. See for instance the updated interface of Google images. They hide the image details, while making it very accessible at the same time.

-- ArthurClemens - 16 Feb 2007

Hiding so you have to experiment with the mouse to find a feature that you do not even know is there. That is a bad solution. I see so many flash websites that look very high tech and where you have to hover around with the mouse to find out how they work. That is not beginner friendly. That is the straight opposite. Features do not get easier when they are hidden. They go undiscovered worse case. Or make the user waste time searching for a feature that he does not know is there.

We have an extremely simple set of tools in Pattern Skin compared with so many other programs. It is not complicated at all.

We have a wiki where people have to learn *bold* _italic_ ---++ header level 2, WikiWord, |table cell|table cell| and we worry about 10 simple to understand features at the lower tool bar.

The time a user spends using TWiki may well be 1000s of hours. It is not the first 60 seconds we need to optimize. It is the daily use. As long as we do not scare people away at first glance. And we do not. We are very far from that. Pattern Skin is a simple UI and it takes very few minutes to become familiar with it. For just viewing and jumping from topic to topic users do not look at tools bars and menus at all. And the minute you start editing pages, you are already way past the first minutes of learning to worry about the back links and history links as being something scary.

What scares you is writing two lines of text and seeing that there is only one line as a result. And how do I make a headline? And how do I put in a picture and why is the syntax so 1970? THAT is the problem we need to address.

-- KennethLavrsen - 16 Feb 2007

That's a problem we need to address as well.

To compare Google's page with obscure Flash pages is an exaggeration. I am sorry, but dealing with this is my daily work and my expertise.

The fear of the geekyness looks is real. At my work I am dealing with designers and project managers who abhor this complex looking pages. Teaching is not enough. They first need to be motivated to learn.

I think the best way to find agreement is to create a Proof of Concept. Untill then nothing is decided.

Oh and by the way, I propose to rename Checkpoint to Save and continue.

-- ArthurClemens - 16 Feb 2007

YES. Rename Checkpoint to Save and Continue. That we can agree on! People have a problem understanding what checkpoint means.

And proofs on concept is always a good thing too. Then we know what we are discussing and can improve.

-- KennethLavrsen - 16 Feb 2007

I see, good arguments on both sides. Possibly add a selector in the registration page?

• I am a novice user, show me a simple UI
• I am an advanced user, show me a powerful UI

-- PeterThoeny - 17 Feb 2007