Comment by danneu | Hacker News Reader

Comment by danneu | Hacker News Reader

Parent Full thread

I found this out last year when I offered markdown support on my forum that used traditional bbcode.

I run a collaborative writing forum and, newly obsessed with markdown at the time, I figured that since users were mostly writing many paragraphs of text, they could pick up the markdown basics if a toolbar + cheatsheet helped them out. In my head, it was going to be some sort of amazing improvement and my forum community would begin chanting my name as they experienced the splendors of markdown.

Classic mistake.

Yeah, sure -- the writers could certainly grasp markdown #headers, how two linebreaks become a new `<p>`, and even `[]()` vs `()[]` links (with toolbar/cheatsheet help). Great! But nested elements and pretty much anything more complicated were a real monkey wrench or just plain unsupported.

Writers would put great effort into their posts (just like a blogger would), changing colors, right-aligning, center-aligning, changing font sizes. -- Things that markdown just doesn't support without some extending or post-processing that would turn into something far more confounding than the intuitive bbcode you started with.

Everyone just understands:

    [center][size="6"][color="red"]My Cat, Mittens:[/color][/size][/center]
    [img]http://imgur.com/mittens.jpg[/img]
    [size="3"]Mittens says: [i]"Meow!"[/i][/size]

There might be a hump to get over at first, but I think Markdown is going to be by far the best to go for in the long run.

What did your cheatsheet look like?

My cheatsheet was a simple condensed table of "this | produces this" beneath the post textfield.

Also, other communities that deal with a similar audience had the same problem with Markdown and moved back to BBCode. For example, these guys (http://guildwork.com/forum/threads/4e46f3d5205cb22721000765-...) moved from BBCode to Markdown and then ended up moving back and writing their own BBCode parser in Python.

Markdown is good when users have limited syntactical/formatting options. But BBCode makes it easier to extend features with an intuitive syntax that nobody seems to have trouble with.

One example would be Markdown's dependence on character glyphs:

    ![my puppy](mypuppy.jpg)
    [click here](http://google.com)
    
        preformatted
        text

While BBCode is easy to recall in plain English and you don't need to remember any glyphs or the order of them:

    [img]mypuppy.jpg[/img]
    [url="http://google.com"]click here[/url]
    [code]
    preformatted
    text
    [/code]

Adding dice and a youtube embedder to BBCode intuitively extends the syntax set. It doesn't introduce any new symbols or anything.

    [dice]4d6[/dice]
    [youtube]http://youtube.com/v?i2h38aoj[/youtube]

Finally, it's been half a decade since I used Wordpress and I think I'm way off topic here since, on second thought, I'm pretty sure Wordpress just offers a WYSIWYG editor that lets you drop into html. Doesn't even use any sort of BBCode-like syntax. :O)

That’s a great point about the inherent ability to extend the number of tags that isn’t inherently present in Markdown.

I am currently writing a forum CMS (http://pygm.us/IbkgNZ4d), and I, too, have wondered how to expand the number of tags within a rigid nomenclature. Using a lexer that automatically converts links to tweets and YouTube videos to embedded scripts seems like an unintuitive solution, but on the other hand, people unfamiliar with the commands will automatically display the embeds in their posts.

For commands that don’t convert links, I was thinking about something like ':<COMMAND>:' with an expandable list of whatever people prefer. Something Awful already use this model for their emoticons, and it could be extended to things like images in general like states for election conversation and such.

I have always found the `[url]` solution to be incredibly bothersome and to some extent unintuitive, and with the advent of mobile devices, letting people write their posts in as few characters as possible is a big advantage to be taken into consideration when weighing the pros and cons.

Cool project.

Lots of vBulletin forums use the `:<string>:` syntax because vBulletin's default smilie set ships with that form of syntax (even though you can use arbitrary strings like setting "lol" to display a laughing gif) so everyone just piles onto it. Basically, direct string replacement seems to be universally understood by all users.

But the real riddle here is devising a syntax superior to bbcode that transcends string replacement and does things like take arguments and act like functions.

Because, it's this less-straightforward symbolism that requires the higher order of savviness/pattern-recognition that less-experienced users struggle with. Like `![]()` turning into an image (but not `! []()`) or why you'd need to indent 4 spaces to resume a bullet point after an empty line.

In other words, where you and I may find it obvious that we're conforming to the rules of a parser (on some back-of-the-mind intuition at least), I found that this concept of mechanical recognition is nonobvious to the user archetype that expressed confusion over Markdown. To them, `! []()` doesn't work because of a negative rule "there can't be a space", not because the token is simply no longer recognizable to the robot behind the curtains that renders their post. That's the crux I've arrived at that makes Markdown suboptimal for my particular community demographic.

The final point I discovered is that users almost always use the toolbar button for anything that comes from their clipboard (namely image and website URLs). Click, paste, and done. Even on smartphones. So essentially all Markdown did there was take cumbersome syntax that was seldom typed-in to begin with and replace it with less intuitive syntax for a benefit that was seldom awarded: being easier to type! Users then had to confront the `[]()` beast when editing posts or modifying their post's layout.

Fun stuff to ponder. It's always extremely eye-opening and humbling to be so wrong.

Reply on news.ycombinator.com