Is Markdown Friendly Enough for Non-Technical Users?

Question

The Problem

I love using markdown to write questions, answers, posts, comments etc. That being said, I am a very technical, detail oriented, programmer type. However, I am working on a CMS of sorts to be used by non-technical folks. I am using Markdown for this, but I'm becoming increasingly worried that it will be too technical for the users. It works great for users of SO but let's face it, we love to learn new languages. Users hate new things.

Context

You and I both know (because we're good programmers) that WYSIWIG editors produce a jumbled mess of non-semantic markup. (If you don't know this, check out this excellent article by David Demaree and then you will.) What you and I don't know is how users feel about it. Programmers are terrible when it comes to guessing at users' pain points.

The Question

Can Markdown simultaneously solve the need for clean markup and not be grating for non-technical users?

[Update]

After a year of watching users with our Markdown editor, and dealing with the HTML generated on the server side, I am firmly convinced that Markdown can be used by non-technical users of varying skill levels. Users have had no trouble getting the basic syntax (since it already resembles email conventions) and with some helpful tips (look at Ellie's answer below for some specifics) they can get the more advanced syntax very quickly.

Answer 1

Define 'non-technical user' because in my experience, it's more of a sliding scale than technical or non-technical. I don't think it's beyond most intelligent humans to get to grips with markdown, but it depends on your audience as to how much they will love or hate it.

As a general approach, I would use it but add buttons which allow less techy people to fill in the details in a way they're more likely to understand (give them prompts). If you do this, but keep the result visible, you'll teach them how to stop using the buttons too :-)

[EDIT] If the users are in a hurry and have little or no word processing skills, I would be suprised if they bothered with anything but plain text. If you'd never used word (or something similar), chances are you'd normally just use a pen so underlining and font size is likely the most advanced formatting you'd have experience with. In which case, I'd personally drop the idea of using markup. Depends a bit on what you're building though I should think as to how critical this will be.

Answer 2

Yes, I think it can.

What I have personally found very helpful:

• Having a preview and allowing user to see what the resulting text will look like

• Having a short help section explaining the basic markdown elements

Answer 3

Unfortunately not.

When you say non-technical: there's a huge difference between non-programmer and 90% of the non-technical users out there.

A surprising number of users (I think it's around a third of everyone on the web) can't scan text - they will use their finger on a page to read and will lose their place if forced to scroll.

These users will struggle with even simple WYSIWYG, never mind any sort of markup.

A good article on the issue is: http://www.useit.com/alertbox/20050314.html

I'd recommend taking a look at that site for most usability research like this.

If a user is struggling to understand the I-bar and caret they're never going to understand any sort of meta-information.

Answer 4

I think everyone is guessing again. As brad suggests, our guesses are likely to be way off.

The only way to be sure is to run usability tests.

Does anyone have any information about usability tests which have been done to look at using markdown?

(Or something similar e.g. Wikimedia?)

The closest thing I've found is a screencast comparing the usability of markdown vs. a WYSIWYG editor. It's not a usability test, however.

Answer 5

If you are worried about WYSIWYG editors producing jumbled HTML, check out MooEditable, a project I work on to produce standard, valid HTML no matter what the browser (it's a MooTools plugin).

Back to the question at hand though, Markdown is friendly enough for the majority of users, as long as you provide some sort of "cheat sheet" that's visible from the text area. And also link to a more in-depth description in a help link, maybe even a tutorial, for those who are a little slower with computers and technology.

Answer 6

I think Markdown is worth it.

If the formatting syntax (like asterisks, etc) is too much for them, Markdown will at least handle paragraphs they way they expect.

Even the least tech-savvy user will hit return twice to create a paragraph, and Markdown will do the right thing with that. Even if they don't take advantage of anything else, handling paragraphs will make for MUCH more readable content than enormous blocks of text.

Answer 7

Unless your users need tables...then you'd need some kind of weird WYSIWYG + (WYSIWYM + preview) hybrid, which may not exist.

Answer 8

On a largeish project, I thought textile would be simple enough for non technical users. It turns out I was wrong, and my clients just couldn't cope with it at all. The problem eventually became so severe that they replaced my whole system. The system I spent 8 months building.

Live and learn. To be honest, I don't think Markdown is easy enough for TECHNICAL users. The problem is it gets applied to content entry forms without informing the user that it's going to be filtered through markdown. Text gets mangled, and there's no way to know what happened unless your eyes are sharp enough to notice some tiny note somewhere.

There's a dozen of these different markupish languages with slightly differing semantics, and each one is a whole new set of things to learn. You come to a comment form, and who the hell knows what's going to happen? is it textile, markdown, bbcode, how on earth do I make a link? It's a mess.

Well there you go. Two data points. A client couldn't cope with it. I can't cope with it. The only reason I have any idea what's going on here on stackoverflow is the gui buttons. and the realtime preview.

@tj111 a cheat sheet helps me, but it didn't seem to help anyone else. I'd even pointed it out numerous times, but it just didn't seem to take hold. I ended up doing all the textile myself.

Answer 9

Not a direct answer, but might be helpful: Look at LyX. It's a almost-WYSIWYG editor that produces (something very close to) LaTeX. I used it to introduce my mother to LaTeX and she loves it, even 'though she's got no technical background whatsoever.

I think it is a great example how you can produce a usable editor for a well-designed technical syntax.

Answer 10

I know I'm coming to this thread rather late, but I actually have run usability tests comparing a WYSIWYG editor (iWeb) to a non-WYSIWYG editor based mostly on markdown.

Here's what I've found that users struggle with when using markdown:

• Tags that require character-level precision. For example, a user's inclination is to put a space between the square brackets and parentheses when making a link--but that doesn't work. Likewise, lists only work when there is a space after the asterisk or dash.
• They get paragraphs fine, but users are often inclined to use a single linebreak (when formatting an address, for example) and these are ignored if you don't add two spaces to the line before. Not intuitive, and those two spaces are invisible.
• More complicated tags, like for links and images, slow them down more than simple ones (like for strong and em)--but they can eventually get it if there's a helpful guide.
• Users are often not confident that X will work or unsure of exactly what it will do.
• Users don't always understand paths, directories, files, file extensions, URLs, etc. This makes making links and images difficult.

Here's what I've found helps:

• Provide a clear and explicit guide to markdown
• Tell them they are using a markup language
• Style the text field so that it doesn't look like a WYSIWYG field (eg: use a fixed width font)
• Consider syntax highlighting
• Be clear about any situations that are counter-intuitive or require attention to detail
• Provide a preview option (it doesn't have to be real-time, but it must be easy and unobtrusive)
• Depending on the application, consider tweaking it slightly (like allowing a URL like www.example.com and adding http:// automatically)
• At the very least, provide buttons for the more complicated tags like images and links. It's trivially easy for the programmer to make a little dialog box that asks for the URL and the link text and inserts the code automatically. Consider making the language easy to understand. Instead of asking for the URL, ask "What web address would you like to link to?" Take a look at how Javascript WYSIWYG editors use non-technical language here.
• Give them an idea of why this is important. Explain that semantics and presentation are separated in web design, and that computers generate bad code--so they are helping the program understand the semantic structure of the document.

I was surprised to find that people were mostly getting it, with no guidance from me and just a short guide to the markup language. In a study with 22 total users, the average satisfaction was slightly lower for iWeb than with my application.

If you're talking about an entire WYSIWYG web design program, not just a little widget for text entry--they're not as usable as you'd think. There are so many little details, and so much can go wrong, even when the interaction is supposed to be intuitive.

Caveat: my participants were all college students of varying technical skill levels, but they were all more tech-savvy than the average user. They were also being compensated for their time, which may account for their interest in the task.

Edit Almost all of the above issues have been improved by the stuff in the second list. The only one I'm still really struggling with is the single linebreak problem.