"Your WYSIWYG editor sucks"

[Janet Swisher]

http://www.rachelandrew.co.uk/archives/2011/07/27/your-wysiwyg-editor-sucks/

Good points to ponder for Kuma:
* Is letting users enter HTML because that's what they know really a
good thing?
* How much structure do we want to build into the system? We have some
content that is very well-structured and some that is not.

For example, I have seen a Mozilla developer, who I would think would
know better, format a code sample with
<blockquote><code></code></blockquote> instead of <pre></pre> because he
preferred the way the former rendered on MDN.

OTOH, most MDN users follow the same structure as existing pages and
don't try to get creative with HTML or inline formatting, so perhaps we
should err on the side of making things as easy as possible for the
majority.

--
Janet Swisher <mailto:jREMOVE...@mozilla.com>
Mozilla Developer Network <https://developer.mozilla.org>
Technical Writer/Community Steward

[Les Orchard]

On 4/4/12 5:09 PM, Janet Swisher wrote:
> http://www.rachelandrew.co.uk/archives/2011/07/27/your-wysiwyg-editor-sucks/

FWIW, I've always hated WYSIWIG editors. My last favorite word processor
was WordPerfect 5.1 for DOS. I hated MS Word after a few
thousand pages of book writing, and I especially despise WYSIWIG editors
in browsers.

But, I just assume I'm odd, and that WYSIWYG works fine for other people.

> Good points to ponder for Kuma:
> * Is letting users enter HTML because that's what they know really a
> good thing?
> * How much structure do we want to build into the system? We have some
> content that is very well-structured and some that is not.

What might be nicer isn't WYSIWIG HTML editing, but an editor driven by
semantic structure. Something like Ulysses, maybe:
http://www.the-soulmen.com/ulysses/

But, that's hard to build. So, encouraging conventions in HTML and using
someone else's rich HTML editor (ie. CKEditor) is easier.

Another approach might be to go with something like AsciiDoc, which is
what I'll do if I ever write another book.
http://www.methods.co.nz/asciidoc/

That's like DocBook, but more markdowny and less XMLy. But, that would
be a pretty drastic changeup

> For example, I have seen a Mozilla developer, who I would think would
> know better, format a code sample with
> <blockquote><code></code></blockquote> instead of <pre></pre> because he
> preferred the way the former rendered on MDN.

Yeah, that's hard to prevent, except through peer pressure and
conventions. I suppose we could try to make a content scanner that flags
issues with respect to common conventions, but that's also troublesome.

> OTOH, most MDN users follow the same structure as existing pages and
> don't try to get creative with HTML or inline formatting, so perhaps we
> should err on the side of making things as easy as possible for the
> majority.

What might help is to further refine / rework the toolbar buttons made
available in CKEditor. Label them with MDN structural conventions,
rather than HTML markup elements.

That's basically what my publisher did for MS Word to enforce
conventions - they gave every author a Word addon with buttons that
corresponded to the exact styles and formatting they required to process
books in their production workflow.

--
lorc...@mozilla.com
http://lmorchard.com
{web,mad,computer} scientist

[Eric Shepherd]

Yes. I want us to do exactly this. Have buttons for all the styles we want people to use and nothing else. It will help keep people from doing it wrong. Won't prevent it entirely but will help. Vigilance will attend to the rest.

Eric Shepherd
Sent from my iPhone

[John Karahalis]

On 04/04/2012 05:29 PM, Les Orchard wrote:
> Yeah, that's hard to prevent, except through peer pressure and
> conventions. I suppose we could try to make a content scanner that
> flags issues with respect to common conventions, but that's also
> troublesome.

If this happens frequently, we may be able to discourage it with some
interface tweaks. For example, in this case we would want to ensure that
code looks better when people actually use <pre>, maybe by syntax
highlighting code that is written this way or putting a nice techy
watermark in one of the corners.

--
John Karahalis
Developer Engagement
@openjck

[Eric Shepherd]

John Karahalis wrote:
> If this happens frequently, we may be able to discourage it with some
> interface tweaks. For example, in this case we would want to ensure that
> code looks better when people actually use <pre>, maybe by syntax
> highlighting code that is written this way or putting a nice techy
> watermark in one of the corners.

Yes, I think this is a great way to help. If the stuff looks great using
the provided buttons, people will be less likely to bypass it.

--
Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
Blog: http://www.bitstampede.com/

[Luke Crouch]

On 4/4/12 4:29 PM, Les Orchard wrote:
> What might help is to further refine / rework the toolbar buttons made
> available in CKEditor. Label them with MDN structural conventions,
> rather than HTML markup elements.

Yup, this is how I'd like to tackle the problem first - with careful
attention to keyboard shortcuts and semantic meaning rather than
stylistic meaning. E.g., Don't make a 'Plaintext (nowiki)' button, just
make a 'nowiki' button - the plaintext style is implied in the 'nowiki'
meaning.

I do like HTML because we can use cool tools, tricks, and hacks with
HTML. e.g., It's All Text into vim with all my HTML snippets! :)

-L