Adoption & WYSIWYG Editors

SimplicityPersonally, when I’m doing wiki editing, I like the wiki markup language. I find that I can edit things faster by typing than by looking around for which button to press, how many times to press it and then going back to typing. It is easier for me to type ‘—‘ than to have to highlight text and press the indent button over a few times. I do the same thing when editing WordPress.

Apparently, I’m not alone in this. Aside from having one of the funniest graphics I’ve seen in a long time (above), Martin Koser has a good post today in which he debates the merits of wiki markup language and why WYSIWYG shouldn’t be a barrier to adoption.

While I agree with many of his points, from a sales standpoint, this is still a major obstacle. Especially:

So the argument that adoption hinges on the existence of a WYSIWYG editor is flawed – wiki markup can be easily explained and adding some coaching efforts to an implementation project doesn’t hurt, explaining the rationale behind wiki usage etc. I have had decent successes with 15 minute short introductions, followed by “train the (peer) trainer” coachings, after all editing wiki markup editing is neither programming nor rocket science.

People, for whatever reason, expect their wiki to work like Word or at least Outlook. This may be, as the comments suggest, a nice way of saying ‘not interested’, but I think that in the corporate world, where applications try to be all things to all people (see above graphic), that jamming a bunch of stuff into an application may in fact help adoption.

It is well documented that people only use 10% of Word, but perhaps it is just more comforting to see this level of functionality. Instead of comparing wikis (or other WYSIWYG editors) to Word, perhaps it is time to start to compare them to Outlook.

After all, isn’t this the method of collaboration that we are trying to replace?

Advertisements

3 thoughts on “Adoption & WYSIWYG Editors

  1. Scott, I agree with you that this is different from a sales perspective. And I sure don’t turn down prospective customers when they ask for WYSIWYG – well, sometimes I try to educate them a little bit …

    Overall, I guess we shouldn’t jam everything into our applications – while it may help with the initial sale (“look at all the stuff you can do”) it may hurt adoption (too complicated, too confusing, too distracting). From my perspective this should also govern intranet design, application design etc.

    In fact I like the way Socialtext does it – offering both ways of editing and letting the user decide freely, so newbies can enjoy the familiarity of the WYSIWYG editor, while more advanced users may choose the “direct and faster way”.

  2. As stated on Martin’s blog already, I don’t totally agree with this idea.

    And having reflected a bit on this since Martin’s post on the subject, I’m wondering if these point of views aren’t biased by our background …

    I’m not an IT guy, and while I harness technology quite easily, i have allways liked to use the tools and features invented to make the life of non IT computer users easier.

    I remember around 1985, my uncle, who was already a computer freak since a few years (so clearly one of the very early adopters), and I had a debate about the use of the mouse! He prefered to use keyboard commands to do everything … Just because when he had started using computers, the mouse did not exist, so keypunching commands was natural to him.

    In your case, as wiki early adopters, you have started to write everything using wiki markup. So naturally, you find it easier to use them still today in this wolrd of WYSIWYG …. While I prefer to use the little buttons in the tool bar … (I will confess though that having used forums since a while ago, I do prefer to type in the BBCodes when wanting to bold or underline something in my answers)

    So all in all, I think the key is to always consider who your audience is …

  3. Totally agree on considering the audience, which is why we offer both wiki markup and a WYSIWYG editor. But I can’t help to think, though, that trying to jam too much functionality into a product, be it a wiki, a search engine, a phone, or whatever, makes it complex and hampers adoption.

    Not being a product designer, the goal, I suspect, is to make any product both simple and comprehensive at the same time. It isn’t an easy task, but it is what Google, Apple, Twitter, Flickr and others have been able to accomplish. This, IMO, is how to get adoption.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s