John Gruber has posted Markdown, a text-to-HTML conversion tool for web writers.
It is yet another in a long line of plaintext formatting tools. Let’s see, we have Textile, Structured Text and about a billion slightly different Wiki markup languages. TMTOWTDI, but it’s starting to get ridiculous.
The problem that these formatting languages solve is that it’s a pain in the ass for most people to format HTML inside <textarea>s. Weblogs and Wikis are the two places I see these markups being used most. They use ASCII to format the text, using a * to make a <li> tag or !! to make a <h2>. Since the competing formats are hashing it out ad-hoc there’s no standardization and everyone it pointing out how simple theirs is compared to everyone else’s.
I see these languages as a half-way solution to the real problem. They attempt to make the plain text look like the rendered HTML, while defining their own arbitrary formatting rules. They are designed so that what you see is pretty close to what you get.
Most simple HTML isn’t much more complex than these rules. Is it easier to remember <strong>this is bold</strong> or this is bold? One is certainly easier to type, but another formatting language may have this is bold. Because there’s no standardization you need to remember where you are when you use these markups, whereas with HTML the same rules apply (mostly) everywhere.
Since simple HTML is simple enough, and global enough, why not just use HTML? Well for one thing, people seem to have trouble using HTML. Take a look at Fark’s comments sometime and you’ll find comments that use the UBB link tag [url]http://www.example.com/[/url] or you’ll see photoshop contest entries where people just post the URL to the image because they don’t remember how to make an <img> tag.
These people (probably) aren’t dumb, they just have better things to do with their time than remember arbitrary formatting rules, even HTML. Put them on a Wiki and they’ll be far too intimidated to contribute, even though they may be an expert on the topic. Giving them yet another way to format text won’t help, they don’t want to learn markup languages. A good Wiki should respect that and work with them to come up with a better solution.
I’ve searched and I’ve searched and I have yet to find a Wiki that has a WYSIWYG editor. If you take a step back, all these formatting languages are attempting to make <textarea>s as close to WYSIWYG as possible, so why not do away with the <textarea> all together?
I predict that a Wiki that incorporates Epoz, an open source cross browser WYSIWYG editor, will have phenomenal success. It would empower real people to contribute with the smallest barrier to entry. LiveJournal is already sporting a rich text editor and I suspect that it’s doing quite well, although I can’t find any statistics on it. I would love to see Blogger, TypePad and Moveable Type follow suit. Isn’t that what Wikis and weblogs are all about, lowering the barrier to entry?
Maybe there’s already a Wiki out there that uses a WYSIWYG editor and it’s not phenomenally successful and I’m wrong, but it doesn’t look like it. Are we really helping users by confusing them with competing markup languages that they don’t want to learn anyways?
8 responses to “Markdown and Wikis”
I gotta disagree on two counts.
Firstly, I don’t think that it’s the lack of a wizzy editor that kills wikis. It’s the lack of overall wiki navigation and structure. Some wikis provide categories and categorical navigation, which is good, but not good enough. Socialtext does well here, but it costs (and the free playground doesn’t appear to be working, or I’d link to it).
Secondly, there’s this abundance of roughly equivalent poor-man’s-markups — Markdown, or the year-and-a-half-old, vastly superior Textile, aren’t inherently any easier to use than “baseline” wiki formatting. Note also that many wikis have divergent syntax. None of them are that hard to use, or to teach. If you want a wizzy editor, and it’s acceptable to Javascript it, it wouldn’t be that hard to do.
But, as I mentioned above, I think you’re correct in saying that there is a fundamental problem with wiki. I don’t think wiki formatting, or text formatting in general, is the problem. 🙂
When I say that “the real problem” of Wikis is that they don’t have WYSIWYG editors I mean in the context of formatting. As you point out there are certainly more problems with Wikis than just the formatting but this is the problem that ties into the abundance of plain text formatting languages.
If you pressed me about what the big problems with Wikis were I’d point out that I’m not nearly as qualified as other ArborBloggers to weigh in. cough cough If you held a gun to my head, I’d say that the two biggest problems for Wikis are both “Edit This Page.” People who might deploy a Wiki are paranoid about anonymous collaboration and people visiting don’t really believe that they’re supposed to edit pages. There aren’t any technical solutions for etiher of those, so I’ll just stick to pontificating about WYSIWYG editors.
…and until then, wiki will be a great way for five people to talk to each other!
Hello folks,
Ed is much more the wiki “expert” – I have just been trying to figure out how to get people to use them.
I see this as an organizing problem. Over at SwitchWiki I have been working on compiling all the public wikis out there.
I think because I am interested in creating a WikiSummit, to discuss issues that you all are talking about. I think that people need to be challenged about how they think of the web. Once this begins to occur, wiki becomes a lot more than 5 people. Check out some ideas at Mass use of wikis
Medical and legal transcriptionists use keystroke macros for hundreds of common phrases unique to their profession. When you’re paid by the word, you want to have shortcuts!
Working with a group of content administrators, who need to edit in WYSIWYG, I wonder about how to standardize their posts — and am considering keystroke macros to insert Xhtml tags. It’s important that the output be in Xhtml, nested with proper closing attribution (and other rules).
Perhaps driven by client-side scripting? It would have to use “standard” word processing rules (Ctrl-B = bold).
Just a thought.
jsteele – If you pipe it through Tidy, you can make damn near anything valid XHTML. Right now most WYSIWYG editors use the browser to write the code, which in IE is a disaster. If you want to accomidate IE, which you do, you need to turn their <BR> tags into <br />, so Tidy seems like a good solution.
You’re absolutely correct, and I’ll likely use Tidy on the content provided. I’ve used Tidy many times and it is a great tool.
I guess I’m interested in changing the first tool instead of using a second one. I believe that the WYSIWYG editor should create valid Xml (Xhtml) in the first place!
wild ride
An evening of web surfing took me on an interesting journey from bookmarks to ancient text and back again. It…