Rule #1 is:
People spend most of the time on other websites.
To be intuitive, TWiki should do it (and call it) as other sites do.
I changed the wording, but big part od discussion about version 1 is relevant also for vesion 2, so I decided, refactor, but keep both. Fell free to refactor your comments to better reflect new wording.
Version 1: "Write as in email"
Fits with text formatting, bullet list, tables, hyperlinks. Fits
WabiSabi.
--
PeterMasiar - 23 Jan 2003
Good advice.
Is it really rule #1? I think it depends on the social norms of the site.
--
GrantBow - 24 Jan 2003
I never called it Rule One, but I do use it as my primary
rule of thumb. It works very well in explaining text formatting to users because it's so utterly natural, and I believe this simplicity is its real power. We write Wiki content in a plain-text edit box, just like we do in e-mail. (Granted, our Notes system supports rich text formatting, but curiously enough, nobody ever uses it. So much the better for my rule of thumb!)
The most important point I would like to make is a little longer than my rule of thumb, but it's basically this: information sharing is vitally important to knowledge-based organizations, and as far as I have experienced, no other solution comes even close to TWiki concerning how easy it is for users to add and update this information. The reason is that is so simple: view, edit, save, done. The edit part is the focus of my rule of thumb. If the
edit part is just as easy as the rest, then simplicity is preserved and we can hope that knowledge workers will keep (or start) using TWiki, sharing their information. If the
edit step is bogged down with a lot of cryptic formatting rules, users give up. So in order to keep the simplicity, stick to a mindset that allows users to easily maintain their content. If your feature XYZ makes sense in an e-mail (or in Notepad), then it works. If it doesn't, then users won't use it -- or worse, they'll become confused and stop contributing.
Granted: a number of organizations are populated with highly geeky contributors that have no problems in discerning different results when using single or double quotes or such finer points, and in those cases the local Twiki implementation can benefit from highly advanced text formatting.
But for the wide target audience of TWiki, such advanced stuff does not help contribution, it blocks it. KISS applies.
--
TorbenGB - 25 Jan 2003
I definitely agree with this for the base TWiki distribution. I personally think having all kinds of neat formatting rules is great, thus stuff like my
RecursiveRenderPlugin. But I think that in many cases they should be plugins or addons, and not part of the "base" TWiki.
The exception is when the following apply to a non-intuitive formatting rule:
- Extremely useful when known.
- Hard to create accidentally.
- Difficult to do without where it applies. (IE, would involve resorting to HTML.)
- Simple/fast to implement.
If those three rules apply, then having even non-intuitive markup does more good than harm. The first two rules are pretty obvious in their reasoning. The third rule really carries this point: if you'd have to resort to
HTML to do it anyway, then having confusing but easy-to-use Wiki markup instead of confusing and long-to-type
HTML markup is a definite improvement. Technical users get ease, and non-technical users trying to edit the page with such markup aren't any more confused than they would otherwise be. The fourth rule is less important usually, but if adding a certain type of markup would slow down TWiki rendering noticably, it should definitely be a plugin unless it's absolutely
essential (and I've yet to see any really essential TWiki markup). Also, lots of crazy markup in the default renderer is a definite symptom of
CreepingFeaturitis and should be avoided.
--
WalterMundt - 25 Jan 2003
Version 2: "Do as other sites do"
People spend most of the time on other websites.
To be intuitive, Twiki should do it (and call it) as other sites do.
People who's comments helped me to verbalize
RuleOne:
I can see why Twiki developers understand this issue differently: if they use Twiki engine on intranet, they spend substantial amount of time on Twiki, and get used to Twiki's quirks. But for new and casual users, they are quirks, not virtues, and should be handled as so: get rid of them, use web standards.
--
PeterMasiar - 11 Feb 2003