What is official name for "feature" how all wikis create links using words in proper case stuck together? I've seen StudlyCaps. If it's "mixed case" or something, please rename page as needed, and delete this.

In my experience with evangelizing Twiki (or other wikis), I noticed that non-technical users do not like WikiWords from mixed case words (see i.e. TopicCaseSensitivity). They do not consider it much readable and they like more - what a surprise - words separated by spaces as usual. There is whole plugin to add spaces back, which of course adds more problems.

I am aware that MixedCase came from original wiki - but user is always right, correct?

Users are also used that URL is not case sensitive.

Page name resulting from wiki word could be wikiword, no mixed case, easy to spell into phone as URL. So WikiWord could be case insensitive, with nice meaningfull links for abbreviations, like F1 or even H1-B and v1.2. Problem might be that banana or ban ana and b an ana will differ only in spaces added, and will link to same wiki page name, but it might be even a feature.

Could be link to WikiWord be created by using some unused character? I was thinking about underscore character ('_'), because it is visually so close to space, and even is after Z in ascii table - but it is taken to denote italics. The only one not taken is '^' (IIRC pronounced carrot?) and '~' (tilde?): if there is carrot in word => link, if not => no link, like wiki^word. When displaying, carrot could be displayed as space (and page name will be without it, of course). Also, simple convention could define system pages (hidden in casual browsing): hide if pagename starts with ^ , so we could have ^notify instead of WebNotify (or ZoneNotify). User pages, which name is single word, could end with ^ , like glossary^.

How hard will be to include this feature into Twiki code? Are there some underwater boulders which I am not aware of?

-- PeterMasiar - 11 May 2003

---

In the TWiki I have set up I do use underscore characters to create WikiWords with spaces. So the WikiWords are created with underscores, and displayed with spaces. Except for readability, spaces make us able to differentiate in meaning: "ActionsQueue" is a name, "Documenting code" is just the title of a page. In traditional WikiWord syntax this would become all homogenuous.
Single WikiWords just end with an underscore. I find it is not easier or more difficult to use when linking pages.

http://www.VisibleArea.com/flash/

-- ArthurClemens - 11 May 2003

Looks good!

What problems do you see?

What did you have to change? (Some of the TWiki Perl code?)

-- RandyKramer - 11 May 2003

I changed TWiki.pm in 14 places. Note that I am new to perl, and just used common sense, not necessarily the best or most optimized code. I also use SpacedWikiWordPlugin, which I changed too.
I'll add the files so you can have a look. I added some other code, too, and I don't have a clean .diff file, so it is best if you read selectively.

Look for the phrase "# code added for underscore WikiWords:"

To make linking easier (or actually, finding out how an existing page is called), I added a page that you can access from the Edit page as a pop-up, called Topic_names (see above URL). It is just a table with 2 columns: left the links to the pages, and spaced out, and right the real names of the pages, with underscores. You can just double-click on a real name and copy it to your edit window. This could be useful for 'traditional' WikiWord webs too.

The use of underscores is also quite familiar to programmers.

-- ArthurClemens - 11 May 2003

Other wiki's have made highly-readable links by using double quotes or double-single-quotes to make links. Underscore is good, though it takes two fingers (shift plus -).

• double quotes example: ""this would be a link""
• single quotes example: ''this would be a link''
• If I understand your underscore example correctly, only "link" would be a link in this example: this would be a link_
• On twiki, equal signs are used for monospace font, but on some wiki's, they make links; example: =this would be a link=

Other points:

1. Be careful about changing the regex's. They can create hidden problems elsewhere. For this reason I believe twiki should have some good test vector topics (perhaps in sandbox) with every type of supported & unsupported syntax.
2. I believe part of the rationale for WikiWords is to create common vocabulary, because many duplicate topics can be created; example: "this is a link to this and that" duplicates "this is a this and that link" duplicates "link to this and that" duplicates "this and that". If these are forced (via WikiWord convention) to be ThisAndThat then the likelihood of duplicate topics is reduced. (Unfortunately, it is more difficult to read.)
3. A related problem is the namespace problem due to lack of megatwiki/twiki OO. A good example is http://www.visiblearea.com/cgi-bin/twiki/view/Flash/Design_ which has WikiWords for Design, Design books, Design topics. Because each topic is not a web, the name space has to be protected by manual words. An example of a conflicting namespace would be having Design, books, topics, which conflicts elsewhere with programming books and programming topics. Creating single-word-links can result in name space clashes.
   • There are also many examples on twiki.org itself, in case the above example isn't clear; topics like Main.TWikiOn, Main.TWikiOnUnix, Main.TWikiOnSolaris, Main.TWikiOnLinux. With "smaller webs" and object oriented inherentance, these would be main.twiki.installedon., main.twiki.installedon.unix, main.twiki.installedon.solaris, main.twiki.installed.linux, which would be seperate namespace from the unix, solaris, and linux topics under main.operatingsystems

-- JonathanCline - 11 May 2003

I was trying to create links using ForcedLinks - [[]], but it did not worked as I liked. Twiki always tried to make first letter capital and no way around it. Also, I read somewhere that plural links do not work automagically there.

I tested to rename a page created by ForcedLinks Sandbox.SpacedWordTest. I cannot rename in Sandbox, tested at home. When page is renamed, old link created as old wiki word is changed to old wiki word.

It looks like a bug to me - I'll like at least to have option to full rename it to new wiki word. Should I file bug report/enhancement request?

-- PeterMasiar - 13 May 2003

---

(In reaction to JonathanCline) I like the double quotes solution to creating WIkiWords. This would be really easy to use.
I am totally for readability and usability. Content is king. So while it is nice to recognize a Wiki site by its peculiar link syntax, it also goes against readability. Just compare: TextFormattingRules to Text formatting rules. Well, you already said this, but for me this is THE main concern when creating an interface.

I don't agree that WikiWord syntax is really helpful in preventing duplicates. You can see it here on Codev that a lot of topics are named differently while they do have more or less the same subject. It is more helpful to have a hierarchical view of the topics, and be able to understand the relations between the topics, also at the moment of creating a new topic. Using parent-child relationships is one way of creating relationships, but it's a bit too simple. I would like to be able to link pages like a thesaurus, that is to use other kind of relationships such as Related Terms. That way you could build a semantic network of topics. http://www.semanticweb.org is a bit too much focused on data mining methods.

This idea of a thesaurus-like network is somewhat similar to your idea of a OO Wiki. My main concern is that such a system should be transparent to the users, the inner workings of the system should not be imposed on the users when using the site.

-- ArthurClemens - 13 May 2003

Arthur, there are two separate topics discussed in this page

• how to denote ForcedLinks
  Jonathan suggested quoted string, I like original double []. If quotes are for linking, how do you quote? So let's keep [[link]].
• I originally wanted to talk what to put into links. Most people on this page like words separated by spaces, not squished together.

Qustions for CoreTeam: is it feasible to have additional meaning for undescore ( '_' ) inside double []: WikiWord link using only lowercase words and remove underscores from page name. Exactly as is used in URLs: http://thispageonline.com . Everybody understands that. (links with single word have underscore on the end) Inside ForcedLinks only. And this underscore will be displayed as single space separating words when rendering pages, with capitalization as entered.

So [[This_link]], [[this_link]], [[THIS_LINK]], and even [[ThIs_LiNk]] ot [[Th_is_l_ink]], will all link to a page thislink.txt and displayed with spaces in place of _ . I know last two examplas does make no sense, but you get the point.

Idea is:

• make even wiki's pagename in URL case non-sensitive, as is domain part of the URL.
• don't be too picky about proper case: allow [[javascript_]], [[Javascript_]], and [[JavaScript_]], [[JAVASCRIPT_]] and even [[java_script]] to point to same page, even if links will be rendered with different cases.
• in links, separate word with spaces, as users are used to see.
• make more visible where links in raw text are.

This is again about usability, about Twiki working exactly like other parts of the internet, which user already know. RuleOne.

I know this will be couple of extra keystrokes for content creators, but there is at least 100 readers for one writer, and so readers should get some preference.

-- PeterMasiar - 13 May 2003

Just a few thoughts from a Wikipedia user: CamelCase (as this link style is commonly known) is one of the reasons wikis have not reached quick adoption after their invention in 1995. People react very differently to them, but for some people, especially those speaking languages which are higly case-sensitive such as German, they can be downright intimidating. They make a page look ugly and foreign, and let many decision makers shy away from wikis. It is true that they make linking very simple and fast. But there are far better ways to accomplish this. The problem with CamelCase is that once you go CamelCase, it will be very difficult to turn back. If you have a page called AbiWordFaqHowDoIInstallMyGraphicsCard, how will you ever convert this automatically back to free link form? You can insert spaces and hope that the result is acceptable, but you lose case differences between the words (a much bigger deal in German than in English).

On Wikipedia, we simply use double square brackets. This is not necessarily the optimal solution, but it is one with which we have grown from 0 to 160,000 articles in less than 3 years. TWiki supports double square brackets, too, and if you install the spaces plugin and disable autolinking, you get something which is reasonably close to free linking. But in the best case, there should be a single flag in the TWiki configuration where I decide whether I want to use free linking or CamelCase-based linking, and the generated page titles should not be capitalized. Certainly, wide adoption of CamelCase is not an argument to retain it -- Wikipedia is by far the largest wiki which many people will already be familiar with. All language Wikipedias combined have more than 300,000 pages. In comparison, this wiki has about 20,000, and it is the largest public TWiki. (I say this not to disparage this great wiki! The reasons for the differences in size should be obvious.)

On the one hand, I am pleased to learn that many here understand the problems with CamelCase. On the other, it is somewhat frustrating that when you install TWiki, the first thing you get is a default web full of WikiWords. If TWiki would make true free linking the default, I believe this together with Wikipedia would be the required impetus for getting the majority of wiki engines to at least offer free linking as an option. Almost everyone in the wiki community grimly agrees that CamelCase was a bad idea. Hopefully we will all be able to move on to better ideas soon. I really would love to see TWiki in wider use, and getting away from CamelCase would be the first step to reduce its "geek factor" (getting rid of the curly brackets in the default skin and adopting the link titles to wiki standards -- Recent changes, Page history etc. -- would be another step). Don't get me wrong: TWiki is much more mature than most of the alternatives. We are talking about minor optimizations which could make a big difference in the real world.

-- ErikMoeller - 21 Oct 2003

Eric, I am curious what you think of underscore wiki words, as proposed in UnderscoreWikiWords.

-- ArthurClemens - 21 Oct 2003

Arthur, I discovered your solution shortly before writing my comment and I like it a lot. The overall design of your wiki is also very pleasing. I hope you will consider releasing this as a package, or a set of patches, if you have not already done so.

It is a bit of a curious coincidence that I suggested the exact same style (underscores between words) as an alternative to free links in my discussions with SunirShah of MeatballWiki. It retains the main advantage of CamelCase, namely that users are encouraged to create short, smart link titles (it becomes harder to write long titles as you have to insert undescores between all words) while not sacrificing readability in presentation. For many wiki purposes, underscores may well be the best solution, whereas for Wikipedia-type knowledge bases, standard free links may be preferable because you often cannot avoid having long page titles, and then typing all those underscores can get a bit cumbersome. But in any case it seems clear to me that this style is vastly preferable to CamelCase.

Maybe one problem that needs to be addressed for getting this into the main TWiki distribution is how to deal with existing installations. The proper solution seems to be to have the preferred link pattern a site-wide configuration option, with a little conversion script that can transfer CamelCase-wikis to underscore-spaced ones. I haven't played with TWiki's "RenamePage" feature yet so I don't know how comfortable it is to rename existing pages, there may need to be a mass rename interface for this to deal with cases of UgLy page titles.

I find it quite depressing to see promising wikis like the OSAF or Abisource one littered with really ugly titles like "ConvertingMyTasksToSomeoneElsesTasks" or "UnixFaqAbiWordCouldNotLoadTimesNewRoman". I think this is one reason these wikis often remain a relatively closed circle with little outside participation. -- ErikMoeller - 21 Oct 2003

---

I have slowly come round to the idea of non-WikiWord based 'free links', partly from seeing how well this works at Wikipedia. I have a few examples of such free links on my TWiki site (see Donkin:Debian and Donkin:Knoppix) and I find this Wikipedia like style produces a more natural link and a more readable page.

Getting people to actually write WikiWords is hard, though for experts it can be quite nice. Links such as Debian, Free Software, or even OS/390, would be very helpful since they are more 'discoverable' by someone just typing them in, without knowing if the word exists - some punctuation might be helpful particularly for names of software products etc.

The ideal is an easy way of browsing and selecting currently extant pages in any web and inserting them as [[Page on something]] type links - one reason why many users don't create links to existing pages is that they don't know the exact page names. The JavaScriptBasedEditor provides some of this. Another possibility would be a spell checker type pass on the preview page, suggesting links - I think there's a plugin for this, something like 'link suggestion' (I would put the link in but it's a pain finding it ).

BTW the case sensitivity of WikiWords is also a pain, discussed previously, and should be addressed - the above link should be JavascriptBasedEditor (note the lower case 's'...).

-- RichardDonkin - 21 Oct 2003

I complained about this usability issue for like 2 years now, and looks like CoreTeam has different breed of users. Long time ago I started Twiki improved (TimDistro) with BetterDefaults, but it is a lot of work (many pages need to be edited to create forced links) and doing it me alone it will take long time. ErikMoeller, if you are interested, drop by sometimes at TWikiIRC.

I wonder why where is constant pain with this issue, but not enough of pain to break free? Anyway, with TWikiUnixInstaller will be possible to install different distros. Another crucial usability improvement is IMHO CommentPlugin (working OK now) and of course better skin.

-- PeterMasiar - 21 Oct 2003

Well, Camel Case is quite tolerable if you use SpacedWikiWordPlugin. Just browse http://koala.ilog.fr/wiki/bin/view/TWiki/WebHome to see the effect. Of course, there are always case where it will not work, but they tend to be not so common. I am not saying that it is better than underscores, but I suspect that the incentive to move away from Camel Case is less felt by people using SpacedWikiWordPlugin.

Standard Camel Case is bad however on one important point: WhatAboutSearchEngines? Someone using a google-like engine on the intranet will not use the links like JavascriptBasedEditor optimally for its page ranking algorithm (especially on titles). Thus anything that renders topic names with embedded spaces is good in this point of view.

-- ColasNahaboo - 21 Oct 2003

---

I stumbled across this conversation while looking for a good place to ask about Wiki standards. I believe that Wikis will inevitably catch on and that TWiki has a lot to offer, but I find it inefficient to bounce back and forth between TWiki and MediaWiki. Is there any effort to establish WikiStandards that span the various Wiki engines? (Please move any discussion to WikiStandards.)

(I agree by the way that CamelCase should go. Incidentally, the highly interlinked nature of Wikis causes their entries to be preferred by Google and similar search engines.)

-- RandallSchuh - 14 Apr 2004