A workshop on wiki markup standards Wednesday morning at WikiSym 2006 began with a viewing of the EDS cat herding. That was the anticipated metaphor for any discussion about markup, particularly with a number of wiki engine developers in the same room. The workshop — conducted by Chuck Smith, Christoph Sauer, Janne Jalkanen, Ward Cunningham and, by virtue of taking control of the meeting halfway through, Eugene Kim — had a simple but seemingly impossible goal: develop a standard wiki markup language that would allow portability from one wiki engine to another.
Introduction
Wiki markup is the brainchild of the Father of All Wikis, Ward Cunningham. His intent was to make it simple (“That was going to make it difficult later on,” he joked). He wanted an “easy translator” that wasn’t very precise. Ward explained this distinction at the workshop:
I don’t need it to be very precise, and here’s why. As a computer programmer, I knew how to make things very precise. But the people I was building this for wouldn’t know the difference. … They were all about the content. … Put it in a feedback loop. Write something, see what you get. Oh. Change it, see what you get. Wiki markup is a lot like those ships in Star Trek, when they push all the buttons and the rocket ship goes. Make a change until your rocket goes.
Markup works, but that lack of precision bothers some. The more it is expanded, the less “easy” it becomes.
What is proposed by Smith and Sauer is not a new standard, actually. It is a portable language that every wiki engine would support alongside their own markup. “Creole” is meant to become a useful language, but not the ideal language. People who leave one community and go to another can feel welcome, but still leave room for the developers who want to change wiki markup. It has to be able to accomodate the needs of each wiki community as well as make it possible for a single wiki author to smoothly move content from one kind of wiki to another.
They propose to make Creole an editing option alongside the local wiki engine markup. A visitor coming to a page would see an Edit button (for native markup) and an Easy Edit button (for Creole translation). The guidelines are to make this intuitive, logical, declarative, and not a replacement for the developer’s markup. It is conceivable that wiki engines might switch to Creole and not support their own native option, but that would be a decision made by each wiki. It is more important, though, to provide some feedback to explain to authors which markup is Creole and which is not.
The initial offering of Creole markup is based on a close examination of the various markups in existence, as determined through the extraordinary wiki engine resource, Wiki Matrix (there is also a companion site now, Forum Matrix). There are 65 wikis detailed on the site. Smith and Sauer went through the entire matrix to determine which markup was most popular and where conflicts might arise, before coming up with their own language.
What Creole Should Be
That is where this workshop really began, with the charge to help identify and refine this language. After some false starts, the group started to collect possible goals for this project. The language should:
- Collision free (principle of least conflict)
- Not new (principle of least innovation)
- Accessible for international authors
- Case insensitive
- Be non-ambiguous
- Be non-destructive to the current page structure
- Stable for next 3 years
- Extensibile by omission
- Able to cover the common things people need
- impossible to implement the “wrong way”
- Easy to learn
- Fast to type
- Not HTML
- Readable
- Clearly separated bewteen markup and content
- Well-defined when processing white space
- Governed by fewer principles than markup
Once we got to that last one, the goal-generation stopped.
That international issue was a very interesting one. Apparently, square brackets ([]) — the cornerstone of most wiki links — are not easy to get to on foreign language keyboards. On participant noted that a recent study showed it took at least 2-1/2 minutes for users to hit those two keys. Code that should ignore wiki markup — typically known as “nowiki” tags — may be non-intuitive for non-English authors. Use of the English language, then, is something that should be avoided. Even something as trivial as the ” used to indicate italics causes problems for Napolitan wikis due to different rules of grammar.
User-centeredness was also at issue. Some feel wiki markup is not meant, ultimately, for every user. This Creole language is more of a transition language which would help most those who switch from one wiki engine to another (read: not your typically wiki author). Others feel that it should be so easy to learn and use that anyone can master it, willingly, and thus be able to join the wiki community. New users are going to need to make immediate sense of it.
One really interesting idea that Ward grabbed a hold of but the group let pass involved reserving all first characters of each line for markup. “If we say that the only markup is the first character of a new line,” Ward said, “that’s something I could get behind.” That’s a pretty powerful idea since it makes it possible to trigger more kinds of markup in a more predictable manner. Any time an author wanted to make a style or formatting change, hit return then the code. Perhaps the default for a return is a break tag. That would be an interesting concept to run through some usability tests.
Discussion
In the second half of the workshop, we selected from the long list of goals & principles the three areas we most wanted to focus on for the final hour. I selected Readability, International issues, and Common things people need. I think readability speaks the most to ease of learning, and I thought it would be interesting to approach a markup from that perspective. The international issues really intrigued me, mainly because I had an idea for using the location on the keyboard rather than the character that key represents. I’d like to explore whether user interaction with keyboards could cognitively separate the content (characters) from the format (position).
What the group wound up focusing on is:
- Collision free (principle of least conflict)
- Not new (principle of least innovation)
- Extensibility by omission (don’t specify things)
- Cover the common things people need
We then went through the most basic formatting markup — Lists, Bold/Italics, Headings, Links, Paragraphs, Pre-formatted, Images and Tables — and measured suggestions against these four primary goals. With representatives from a number of wiki engines present and lots of international input, consensus was very difficult to find. In the end, this was as far as we got:
-
whitespace before not allowed
* bullet list
# number list
mixed lists ok - //italics//
With Ward’s help, the workshop concluded with six wiki engines — MediaWiki, C2, JSPWiki, PurpleWiki, DokuWiki and TWiki — agreeing to work on implementing the Creole concept with some basic standard markup. Incidentally, I was really impressed with his ability to reflect and summarize the group and jump in to help regain focus. That was a consistent observation throughout the three days.
You can follow progress at http://www.wikicreole.org/.
