Spoil the user? Why are not always the WYSIWYG Editors the right way?

April 11, 2008

Last week, I was at the re-publica.de conference. Often, the most interesting aspect of conferences are the side talks with other visitors. And this one was not the exception. I had a great chat with Martin Koser, an enterprise2.0 expert (with excellent bookmarks) and Andreas Gohr, the head developer of the interesting DokuWiki. We discussed in length the barriers and potentials to start implementing social software in organizations and once again agreed on the importance of the organizational culture. But the technical side is also quite complex and, for example, wikis can be implemented in various ways.

So far, I am amazed about the collaboration potential of wikis, but also disappointed about their usability. Until this discussion, I was kind of convinced that the user shall be in the focus. Participation should be as easy as possible, so no technical barrier hinders users to add or edit content. But Martin and Andreas surprised me at one point by saying that WYSIWYG are not necessarily an advantage. I shared my surprise on twitter, which brought up these reactions, and hence, I decided to write a blog post about it:

wisyis.png

So far, I argued for WYSIWYG editors for these reasons:

  • There are different little barriers one has to bear before one can start editing a wiki page. Most people are used to Word, and WYSIWYG editors are familiar in this regard. Cryptic code might be confusing and needs some experience.
  • WYSIWYG give guidance and integrate nicely other media such as images or table.
  • A wiki is not seldom confusing because of its missing hierarchy. WYSIWYG editors ease to set up new pages or link to existing ones.
  • Many wikis still lack user orientation and are rather confusing (e.g. no hierarchical menu or insufficient linking). The less a user has to think or adapt, the better. Content should matter.

So here it is a list of arguments against WYSIWYG editors. Martin Koser also wrote another excellent post about it.

  • Too much function distracts from content. It is the same problem with Word. Hours spent on elaborating sophisticated tables instead on concentrating on the content.
  • Code editors limit users and let them focus on structured content — what is useful and which structure (e.g. header and bullet point lists) is best for the reader? If used properly, those texts have more clarity.
  • WYSIWYG invite to paste all content completely from word, which is not necessarily conducive for collaboration.
  • Basically, it is a short code list to learn, and then you can write faster and it is more simply to edit codes.
  • No doubt the code created by WYSIWYG is often a mess and does not separate content and formatting.

Does that convince you?
The discussion, once again, showed me how complex the implementation of social software can be, or how easy if you just let the people use it. The question of WYSIWYG editor might be trivial, but in contrary, the lack of those editors are a key argument to decline social software, as Martin pointed out.


Possibly related posts:

Tags: , , , , , , | Print this post | RSS Subscribe to my blog

Comments

4 Comments so far

  1. Xavier on April 12, 2008 7:20 am

    I’m quite interested by this discussion as well.

    I commented alreay on Martin’s blog, as well as on Scott Schnarrs’ one (http://scottschnaars.com/2008/04/10/adoption-wysiwyg-editors/)

    I tend to agree with you Christian.

    But let’s see what the community thinks about it …

  2. Ray Sims on April 12, 2008 6:51 pm

    Hi Christian,
    Thanks for the write-up. I also read Martin’s post, thanks for pointing to that. I think my ideal is:
    a) lightweight is good. WYSIWYG with a minimalist functionality set. Not much more than: bold, italics, links, bullets, numbered-lists, and indents. Perhaps Heading levels. Don’t make wiki into MS Word bloatware.
    b) also support wiki mark-up for this minimal set and let the user use either, within same editor.
    c) only support additional functionality via HTML and build-in a good separate editor for that
    d) upon pasting from MS Word or HTML somehow strip-out all the extra and start out with the minimalist functionality set only…regardless of how the input looked in MS.

    I agree with “show” and “educate”, and personally I’ll be using the wiki markup and HTML; however, I just don’t see it as real-world to expect adoption across broad audience when new syntax (no mater how small or easy) is a requirement for basic formating such as creating a bullet-list.

    Ray

  3. Martin Koser on April 13, 2008 11:54 am

    Christian,

    thanks for the write-up. Yes, this triggered a lot of twitter responses, I guess that’s because we’ve hit a nerve.

    From my point of view this stems from a kind of dissatisfaction with WYSIWYG editors, in combination with “not knowing what to do about it”.

    BTW, I’ve got another idea for a blog post. Do you remember me and Andi showing you the “namespace concept” of DokuWiki?

    This basically adresses another point you mention as confusing: “A wiki is not seldom confusing because of its missing hierarchy.”

    While advanced users get the emergent nature of wiki structure and like the adaptivity, this really is something that disturbs beginning users.

    Here, preparing an “empty structure of stubs and portal pages” can help overcome this barrier, this resembles Stewart Maders concept of “scaffolding” in a way - see http://tinyurl.com/4r5mgm

  4. Christoph on April 20, 2008 10:21 pm

    Christian,

    I tend to agree with Ray. A lot of our clients are using Atlassian’s Confluence platform, which is one of the most advanced enterprise wikis these days. In my experience the WYSIWYG editor does facilitate the adoption of the platform, since the user has something at hand with which he is familiar.

    The editor is minimalistic but allows the user also to handle links, attachments, tables, images, smileys without inserting any code. Trying to convince end-users that using wiki markup is much faster and easier is in a lot of cases in vain. However, once they have familiarised themselves with the technology a lot of them switch to using wiki markup.

    I admit that I adopted this very same strategy when first confronted with Confluence wiki markup, even though I would call myself quite IT literate ;)

    Christoph

Name (required)

Email (required)

Website

Speak your mind

*
To prove you're a person (not a spam script), type the security word shown in the picture.
Anti-Spam Image

Rounded corner top left
Rounded corner bottom left