It's often difficult for people to agree that something is userfriendly - one mans skinnable GUI is another persons eye-socket-ripping visage.

It is often easier for people to agree what's user hostile.

Examples of where TWiki is user unfriendly: * All %FOO{"BAR" type="syntax"}% * All uses of $pattern type things

User unfriendly syntax is often however useful to users willing to fight through the syntax. Regex based includes are by definition more powerful than named include sections , a search that pulls out form fields using pattens or fields of bullet lists, in the same way is more powerful than any dedicated approach due to flexibility. This flexibility comes at the expense of user unfriendlyness.

Imagine for example:

• %SomeTopic#SomeSection% vs %INCLUDE{"SomeTopic" section="SomeField"}%
• %SomeTopic#SomeField% vs %FIELD{"SomeField" topic="SomeTopic"}% (or even the existing FORMFIELD functionality in use at Arthur's pattern repository, amongst many other places.)
• %SomeField% vs %FORMFIELD{"SomeField"}%

Most wiki syntax (with most wikis) is based on the predicate that you make the parser more intelligent to make the users life easier. A side effect of this is that most wiki syntax is there to replace more user unfriendly things.

Examples of where TWiki is less user unfriendly than alternatives:

Nice, not so user unfriendly:

|*Some Heading* | *More Heading* | *Yawn*|
|  Bla| Bla |Bla |

Less nice, more flexible, much more user unfriendly:

<table border="0" cellspacing="2" cellpadding="1">
<tr><th valign="top" bgcolor="#0c2577"><a href="/cgi-bin/oops/Codev/DifferencesBetweenRevisionsBroken?template=oopspreview" title="Sort by this column"><font color="#FFFF99"> Some Heading</font></a> </th><th valign="top" bgcolor="#0c2577"><a href="/cgi-bin/oops/Codev/DifferencesBetweenRevisionsBroken?template=oopspreview" title="Sort by this column"><font color="#FFFF99"> More Heading</font></a> </th><th valign="top" bgcolor="#0c2577"><a href="/cgi-bin/oops/Codev/DifferencesBetweenRevisionsBroken?template=oopspreview" title="Sort by this column"><font color="#FFFF99"> Yawn</font></a> </th></tr>
<tr><td align="right" valign="top" bgcolor="#F8F8F8"> Bla </td><td valign="top" bgcolor="#F8F8F8"> Bla </td><td valign="top" bgcolor="#F8F8F8"> Bla </td></tr>
</table>

I would suggest that when evaluating new syntax for specific new features that the principle of how hostile the feature is be taken into account. (This is why I'm now working on implicit named sections after working with named include sections for over 6 months now. (I wouldn't give up the latter for the world - in the same way giving up patterned includes would be bad, but implicit is much nicer - and based on looking at PurpleWiki and similar is really effective)

Note: Topic was originally called UserHostile.

Can we find a better name for this topic then "hostile"? Any ideas?

-- PeterThoeny - 13 Feb 2004

"user unfriendly" beats "user hostile" in a Google Smackdown

-- SamHasler - 13 Feb 2004

Thanks for the pointer on Google Smackdown, amazing what the Google API can do! Renamed this topic from UserHostile to UserUnfriendly.

-- PeterThoeny - 14 Feb 2004

Just realised I forgot the quotes, so it wasn't treating them as a phrase.

Without quotes:

• user unfriendly (7,780)
• user hostile (2,560)

With quotes:

• "user hostile" (160,000)
• "user unfriendly" (33,100)

However, looking at the number of results returned from Google you get:

• Google:"user friendly" about 5,630,000.
• Google:"user unfriendly" about 18,600.
• Google:"user hostile" about 6,110.
• Google:user+friendly about 8,940,000.
• Google:user+unfriendly about 82,400.
• Google:user+hostile about 403,000.

Choose whichever statistics/lies you want to believe.

-- SamHasler - 16 Feb 2004