WYSIWYG vs. Markdown

Currently, at work, I’m writing a knowledge base and ticket system. If you’re not familiar, a ticket system is a way to ask for assistance from your IT department, or a way for them to talk to each other.  Why am I doing this, when there are several commercial products available? Because my boss would rather pay my paycheck than give the money to a vendor. I think this is a fine plan.

So, in my knowledge base, which is basically a speed bump on the user’s way to writing a ticket, I wanted to do some simple rich formatting, bold, italics, bullet lists, and hyperlinks. However, the other employees in my tiny IT department are not as familiar with HTML as I am. So, I want to use some kind of intermediary plugin to help them write it.

The first solution I looked at was Markdown. Markdown is a simplified syntax used in site like the Reddit and Stack Exchange for rich formatting. If you are at all into computers and don’t know about Stack Exchange, you should take a look. Markdown looks kind of like this:

**bold text ** _emphasis_  [html link (url)]

Markdown might not be the easiest syntax in the world, but if you goof it up, you don’t have broken HTML in the middle of your page. For this application, I’d probably use a jQuery Markdown interpreter and keep the Markdown in the database.

The other solution I looked at was, and I have a feeling you’ve already guessed, WYSIWYG, or What You See Is What You get. WYSIWYG editors have a high comfort level for users, as they can literally see what the page will look like. However, that doesn’t always work so well. WYSIWYG interfaces have to deal with anything the user throws at them, so if a user plays around with the formatting, you can easily get some weird, leftover markup hiding in the background. Still, some of these WYSIWYG editors do very nice things, I’m nearly happy with TinyMCE, the editor used in WordPress. It looks like this:

In the end, I think I’m going to move ahead with Markdown. It might mean a little more learning curve for the staff developing the knowledge base, but I think will ultimately be the better user experience for the people using the knowledge base. Also, having used some WYSIWYG editors in the past, I think I want to try something different.

4 thoughts on “WYSIWYG vs. Markdown

  1. D. Moonfire

    Just to be annoying, there are some WYSIWYG controls for Markdown to help ease the pain of learning the format. You might consider looking into those.

    I would *highly* recommend you store the original format and do the formatting on the view side. Doing so has made my life easier so many times.

    I’m starting to like Markdown over Creole. Mainly because GitHub uses it as its preferred markup format, but also because it has a few other features that Creole doesn’t have (like the table of links).

    Naturally, that means I’ll insist on reworking my entire writing framework to support it, but that shouldn’t be *too* hard. Unfortunately, the awesomeness that GitHub uses to do its markup processing across a ton of formats is Ruby, not Python.

    Reply
  2. Shannon Ryan Post author

    I’m actually opting for a hybrid approach, using the Showdown javascript library, I’m using a textarea for entry, but I am converting it on-the-fly to a preview div that sits below the textarea.

    Yes, I’ve decided to store the data in markdown, mainly because I want the user to be able to edit, and I don’t like back & forth conversions. I think in most cases, this should actually save some space and make ajax calls slightly zippier, a few kbs or milliseconds isn’t a huge concern, but I like to make things more efficient when possible.

    Using this guide on how to combine showdown and jQuery, http://mathiasbynens.be/notes/showdown-javascript-jquery, I managed to put together this little snippet which will take care of the viewer:

    var converter = new Showdown.converter();
    $(‘.triedItem’).each(function(){
    $(this).html(converter.makeHtml($(this).text()));
    });

    Reply
  3. Tricia Rosetty

    So glad to see someone else in a super similar position. Since it’s been a few years since you wrote this, do you mind updating us on how it turned out / what you’d do now? I’m looking at markdown as a limited way to add some meaning-focused formatting (lists, bolding, links) without allowing users to get caught up in how the content looks ( all in the name of structured content!). Feel free to email me directly—I’d love to talk to you more!

    Reply
    1. shannon Post author

      My comment to Dylan above pretty much stands as I’ve not had a chance to do maintenance on that code since I wrote it. If I were doing it today, I might wrap the library into a query extension to make it easier to call–I wasn’t as good with jQuery back then.

      It ended up being a sparsely-used subsystem, the main project I used it for never rolled, and the other I wrapped it into is not heavily used. In that respect I’m glad I went with a KISS solution. I’d hate to be putting time into it. As it was, I put a lot of thinking into how to format text that my users don’t even bother to format.

      Such is coding.

      Reply

Leave a Reply

Your email address will not be published.

Connect with Facebook