WebSeitz/wiki

Expanding Wiki Words

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 WikiWord?

(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 (Tim Bray) unexpanded.

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

some test words

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-ExpandingExceptions])

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 Meatball Wiki:Free Link model? Or simple old HTML HREF?

Unexpanded WikiWords 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 Emergent behavior.

  • Others think the whole idea of WikiWords Is A 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 WikiWords approach (a) increases Emergence and (b) makes one more conscious about how the immediate thought relates to other past and future thoughts. I can make up a WikiWord 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 WikiWord page, and then discover BackLinks cases from the distant past (this is one reason I want to cache BackLinks 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 WikiForCollaboration Ware context, I've found the creation of WikiWords 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 Go Meta 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 WikiWord-s come in as a helpful tool.

Hmmm, I suppose you could make a User Options preference for how you want to view a WikiWord - 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...)

Edited:    |       |    Search Twitter for discussion

Made with flux.garden