This topic was drift on Codev.ConsolidateFunctionalityFromSkins
and inappropriate for TWiki.WikiWord
so here it is.
- 28 May 2003
Discussion moved from ConsolidateFunctionalityFromSkins.
Note that KoalaSkin
does not force you into multiweb mode. For instance you can see that it works also with only one level,
as is shown for the Koala_Skin web there: http://koala.ilog.fr/wiki/bin/view/Koala_Skin/WebHome
. And moving the web around in the "hierarchy" does not break the URLs as they are note hierarchical in the file system, only as shown in the navigation bar.
may be overkill due to its current implementation as a bash script, implying the installation of cygwin on windows
(but maybe you need cygwin anyways for a TWiki install?) Yes, on Windows you always need cygwin. [ TorbenGB 28 May 2003 ]
-- No, you can run TWiki using "native" versions of RCS and three remaining needed executables (
egrep). -- PavelGoran - 30 Jun 2003
For myself, I am really impressed by ArthurClemens
skin (see http://www.visiblearea.com/patterns
) and I would like to see most of his points made mandatory for all skins (including mine :-).
(perhaps except the use of underscores to denote links. The Bumpy Case is some kind of "trademark" of wiki systems
and these kind of "Standard" help users be confortable in using a wiki, not being locked in what they perceive
as a weird syntax used only by one implementation)
- 16 May 2003
About my 'N' in the table for "User managed layout": I think it depends on what we see as user. Like Matt I would discourage the layouting of the Twiki by the end users, except for having some shortcut links on or off. I think this should be a feature mainly for Twiki owners like admins, or you would weaken usability.
About putting the side bar in a separate plugin (ThomasWeigert
): please give me ideas where to put the navigation? Because this is so severely lacking in the standard distribution (and in most Wikis for that matter). You see, a skin should not be only about appearances. The way the page is layed out, which features are presented where and when all contribute to the ease of use, usability and acceptance of Twiki. And there is a lot of work to be done on that part.
About the bumpy case (ColasNahaboo
): The Bumpy Case is some kind of "trademark" of wiki systems and these kind of "Standard" help users be confortable in using a wiki, not being locked in what they perceive as a weird syntax used only by one implementation)
I don't completely agree: how many wiki systems will the average end user see before working with one? How many times will the admin change the Wiki system? I bet the answers are: none, zero. Wikis are not well known or widely used. But when
users see one, the second negative thing they will notice is the unearthly syntax, like it's some kind of programming language or secret code (BTW, the first negative thing is the lack of graphics - it does not look like a nice website).
If you want Twiki to succeed, to be widely supported, make it look and function as humanly as possible.
One more to add to this: Wikipedia is perhaps the greatest advocate of Wiki. And they don't show WikiWord syntax.
- 25 May 2003
Re all wikis have BumpyCase:
I agree with Arthur. Many users (not admins) will start with wiki without seeing another one. And first thing they complain (even technicaly adept, like perl hackers) how hard is read links. And there is at least one wiki (Chiq-chaq) which uses words separated by '_'.
- 25 May 2003
I find Underlined_Words easier to read, and SquashedWords easier to type. And for me, the ease of editing is the main reason of using wiki technology in the first place. So if it comes to a vote, I prefer WikiWords
. However I don't prefer it strongly enough to make it a sticking point, I'll go with the majority.
Oh, I also vist and contribute to three different wikis, all running separate codebases which is another reason to keep as much syntax in common as possible. Judging from the names I see repeatedly in different wikis I'm not unusual in this regard.
However for the topic at hand, I think there are more important issues to get worked out first; before we start talking about what colour to paint the shed, can we draw the floorplan first?
This is the point where we need something solid to bang on.
- 25 May 2003
"Bumpy case" is inherently an auto-detected link within a focused namespace, right? There are separate issues of what's typed in from a user's perspective and the display
of it. I think the display is what most people are wanting to improve. In fact there's a plugin for this that I use. I think it has helped in the usability of HurdWiki:Hurd/WebHome
quite a bit. Plugins.SpacedWikiWordPlugin
- 26 May 2003
Discussion about "Bumpy Case" is little off-topic in this page
(or should I say "off-topic in this topic
), but anyway: Everybody agrees that there is much more reads for every page that requests to edit it. So if optimizing design, we should optimize frequently used parts first - it means reading. All new users complain about word mashed together without a space between. Some newbies even complained to me that hyperlink is not visible enough in raw text and will prefer something more apparent (they have
, but many links are without them). Plugins.SpacedWikiWordPlugin
is smart, but not too smart - where to add spaces in McDonald?
So we force words without spaces first (alienating users), then as afterthought we add plugin to add spaces (to look
more user friendly), and then parameters to plugin adding spaces to make it smarter. Does it make sense to you?
I'll like somebody from CoreTeam
to tell us what is official name for "Bumpy Case" (mixed case? and move this discussion there (to die from neglection).
- 27 May 2003
FWIW, I've always referred to bumpy case/mixed case as CamelCase
. I like the term. it's both evocative and alliterative.
- 30 Jun 2003
I think we ought to make recommendations about the naming of each WikiWord
For example, I find that it is better to say:
The underlying objective is to encourage convergence.
I'm not pushing my standards
, I'm advocating that we ought to encourage companies to establish their own.
- 14 Oct 2003
It occurs to me that we should store topics in a Stemmed version of the wikiword. This would facilitate quick matching of LocallyOptimised
, etc, all of which invariably don't offer much except confusion by being stored separately. Indeed, we could even have a path mechanism where the stemmed version is looked for first and have it know whether variants on the theme exist.
NB. there are two levels of decision to be made here: storage and conceptual.
- 27 Nov 2003
Should we follow the Unix way, we must strictly separate mechanism from policy. I prefer to have mechanism to allow everything (that underlying filesystem does) to be a topic name. And another mechanism to render/autolink WikiWords
. On top of it, there should be CamelCase
or other user-definable policy for creating new topics. We would then avoid bugs like TopicSaveErrorWithTopicsContainingSpace
, etc. Entire TWiki codebase is based on assumption that CamelCase
is used and this is fixed only occassionally and in one place on occurrence of a bug. It is real problem
. My patch
is a small step in this direction, as it attempts to quote every filename passed to shell.
Moreover, even a current policy is weak and inconsistent. If you create new topic by clicking on SpacedWikiWord
in brackets, TWiki attempts to guess corresponding CamelCase
name. If you type it into Go: box, you won't get any guess, instead an error. You may allow direct creating non-CamelCase topics with custom form, but there isn't any system-wide setting....
will came into picture, but will they really solve anything? It will add just another method to make autolinked WikiWord
- 30 May 2004