A key part of the WiKi approach is using Camel Case/Smashed Together Words to identify actual/potential nodes.

(Want to insert some philosophy here later relating to why I hate [Free Linking] models...)

But this can be off-putting, especially to a newbie, or when wanting to forward a page to an "outsider".

What if we add some code to the rendering to split up the pieces of a Wiki Word?

(This will also help Search Engine placement.)

• in hopes of handling the false-split problem ("Wi Ki") for Search Engine placement, I've added a title property to each HREF, which you'll see if you hold the mouse over a wiki word. It probably won't work, but you never know...

  • confirmed that this doesn't work with GooGle.

I did this in early 2002 for inside head tags, but want to do it everywhere.

A downside to this is that it makes artificial wikinames (e.g. PyThon) look silly. In some cases I don't mind that, because it makes you look at the word pieces more closely, which is sometimes educational ([Linguistic Hack]). But in others it's just silly.

• could use square brackets to create names like Python, but I prefer to avoid square brackets except to accomplish some other weird trick (like put dashes into date-stamp names which have a special meaning).

This triggers another requirement which I wanted to change anyway. For a create-new-page link, the wikiword isn't linked, just the appended ?. And I've always hated that question-mark, as (a) I've found that it distracts [Wiki Newbie]-s, and (b) it really looks stupid when you print a page to hand to someone who's never seen a wiki before (and everyone else, too, since the question marks are just grey instead of blue, assuming you're printing without color). So I'm putting the expanded phrase into square brackets, and making the closing bracket the href to create a new page (I may make both brackets "hot" eventually, if I think that's a good idea).

Exception handling

• from the beginning I avoided expanding pure acronyms - PDA, PIM, etc.

  • though that doesn't catch mixed acronyms - PyOKBC, MySQL

• how about ignoring short names (<=7 chars)?

• how about ignoring short phrases (1-2 "words")? (but each person name is only 2 words, so that's a lot of exceptions, plus lots of other nodes names contain only 2 words - aside from aesthetics, this would be bad for Search Engine placement)

  • note that triggering on character length will still leave some short person names (TimBray) unexpanded.

• might it also help to use nbsp for some cases (like when only 2 words)?

some test words

• acronyms and mixed acronyms: PDA, PIM; PyOKBC, MySQL

• false splits: WiKi, PyThon, ZoPe, GooGle, LeeWay, MozIlla, Democra Cy

• true but short splits: AppWiki

• people: Jon Udell (Rys Mc Cusker is always going to be a bad split), TimBray

Meta-thought: while this might make things more newbie-friendly, does it make things more confusing for mid-experienced users trying to form a conceptual understanding of what the system is doing? Or do you just say "don't worry about how it looks, just know you have to use Smashed Together Words when you edit"?

Progress

Apr2003 - I'm working on it. (It's actually easy/done, but I'm trying to upgrade my overall code base at the same time, which is slowing things down...)

May12'03 - got tired of integrating other code changes, so just hacked this feature into the old code.

May21 - Exceptions code (z2003-05-21- Expanding Exceptions)

Some reactions from people: (leaving out names because I'm paraphrasing and I didn't ask for permission anyway - but feel free to append to this page with the form at the bottom...)

It doesn't matter because wiki is a hack. It accomplishes a lot with a small amount of code, but at some point you need to start over with some real node/link management process.

Too many ugly cases of split words ("WiKi")

Why not just use MeatballWiki:FreeLink model? Or simple old HTML HREF?

Unexpanded [Wiki Words] are a good thing - their difference from normal words encourages a powerful sense of naming (as in we gain power when we name things). Also they encourage Emerg Ent behavior.

• Others think the whole idea of [Wiki Words] IsA bad thing: mashing concepts together in unwarranted neologisms actually encourages conceptual elision, increases misunderstandings between disparate cliques, and reduces the chances of finding important missing nothings.

• My thoughts: I'm torn here. I agree that the [Wiki Words] approach (a) increases Emerg Ence and (b) makes one more conscious about how the immediate thought relates to other past and future thoughts. I can make up a Wiki Word in an item, and not create that word's page. Then months later, something else related to that will come up, so I'll post that temporal item, then happen to create that Wiki Word page, and then discover Back Links cases from the distant past (this is one reason I want to cache Back Links data and show it on every page, so that these emergent connections get recognized/strengthened). This is why I think the Free Link or HTML HREF approach is inferior. And I definitely have some concerns that not reading in Smashed Together Words mode will dilute that way of thinking. On the other hand:

  • in a deep Wiki For Collaboration Ware context, I've found the creation of [Wiki Words] containing lots of individual words - these are less likely to be casually re-used in an emergent way, but they still have lots of value. And expanding them makes them a whole lot more readable.

  • also in a Collaboration Ware context, I've found that some people do a lot of writing, and some other people do a lot of reading (or they do the bulk of their writing in EMail, which I encourage as the Group Discussion complement to WiKi). Those people never go beyond [Wiki Newbie] level, and I think expanding names for them is a service, and may server to draw them into writing a little more.

  • in a WikiLog context, there's one central author doing 99% of the writing. And the vast majority of readers will probably have never seen a wiki before. And most of those don't want to [GoMeta] about it, they want to read the content on that page. Again, expanding is a service.

  • (will try to think of other reasons)....

Update: Chris Dent Oct'03 on why [Free Links] are bad. In my opinion, successful collaboration occurs when there is a Shared Goal that exists and is known by at least some major portion of a group that gathers in some space to work on it (use of the term work is not meant to suggest lack of fun: people do work (spend energy) when having fun together). Effective collaboration does not emerge from people getting together to do unspecified stuff because they think it might be nice. .. Crystallization of goals occurs through discussion, through the evolution of understanding and knowledge. Awareness of concrete goals can, in good circumstances, lead to action. [Shared Action] is created out of [Shared Understanding]... For [Shared Understanding] to exist amongst a group of people, they must have or develop Shared Language... This is where Wiki Word-s come in as a helpful tool.

Hmmm, I suppose you could make a User Options preference for how you want to view a Wiki Word - expanded or not. And could also set a folder-level default for the owner (which could be overridden by the user preference) (Not happening today...)

User Options Recent Changes Help Page