[WikiEN-l] Why we need a good WYSIWYG editor

[Stephen Streater]

I tend to agree with GM here, and am generally opposed to a WYSIWYG  
editor
for a widely read wiki.

For a start, HTML renderers will output different pixels for the same  
source
- for example in the case of a partially sighted person who may have  
bigger text,
or people like me who often read on a mobile phone with only 800x480  
pixels.
The last thing I want is some style Nazi insisting on a 1024 pixel  
wide window.

I also don't like the idea of style wars being carried into subtle  
formatting issues.
If people want to customise the appearance of pages, this should be  
done as
a post-processing stage, so all pages look "right" for each viewer.

On 4 Jan 2010, at 19:41, Gregory Maxwell wrote:

> On Mon, Jan 4, 2010 at 12:50 PM, David Gerard <dgerard at gmail.com>  
> wrote:
>> 2010/1/4 Gregory Maxwell <gmaxwell at gmail.com>:
>>> So lets not confuse the usability goals or making editing SIMPLE,
>>> NON-INTIMIDATING, and DISCOVERABLE all of which are very much "wiki"
>>> concepts, with the values of WYSIWYG which encourages increased but
>>> hidden complexity.
>>
>> And never mind the actual numbers from Wikia, which look very like
>> having a WYSIWYG system for presentational markup was *the* key to
>> having people actually complete a planned edit rather than click
>> 'edit', go "what on earth" at the computer guacamole and go away?
>
> Any they compared this to how many other solutions?
>
> We're in agreement that there is a great need for improvement. But I'm
> of the view that you're of the view that "something must be done! this
> is something! this must be done!". Can you help convince me otherwise?
> :)
>
>> Obivously proper usability testing would be needed. But, y'know,
>> there's nothing wrong with bad presentation in the edit. This is a
>> wiki, someone will be around with a bot to fix it in about two
>> minutes.
>
> "nothing wrong with bad presentation in the edit" is an argument
> against bothering with WYSIWYG.
>
> If it doesn't matter what the edit looks like, because someone will
> just come along and fix it, then why bother cluttering people with
> visual markup stuff at all.  Just have PLEASE SPLAT YOUR BRAIN HERE,
> MARKUP NINJAS WILL MAKE IT PRETTY.
>
> Bad presentation in the edit isn't, in my view, the biggest problem
> with WYSIWYG systems the problem is that they frequently behave
> inscrutably, even ones designed from the start as WYSIWYG (as opposed
> to boltons as we'd have).  Issues like... "Help! in order to un-intent
> this I have to copy, delete, paste and reformat!" or "I pasted this
> bit and everything turned bold or vanished and now I can only fix it
> by throwing out all of my edits!"
>
>> The barrier is getting them to contribute at all and not run
>> away screaming forever. I believe you posted something recently
>> pointing out how easy it is to get someone to run away screaming
>> forever.
>
> Absolutely.  But keeping most users users out of the markup business,
> not attempting to put lipstick on the markup is the best way to to
> reduce the complexity.
>
>
>
> On Mon, Jan 4, 2010 at 12:47 PM, David Gerard <dgerard at gmail.com>  
> wrote:
>> You may think that a semantic markup system is just the ticket, but
>> people who casually write stuff almost universally pick  
>> presentational
>> markup and do the semantic bit in their heads, where it belongs.
>> Whatever number of decades it is of computer scientists and other
>> enthusiasts for semantic markup haven't changed this, which leads me
>> to suspect they won't.
>> Wikitext uses '' and ''' for emphasis purposes, not <cite> <address>
>> <quote> etc. Why is that?
>
> We use presentational markup for italic and bold. (Our linking is also
> a mostly presentational markup) A little sprinkling of presentational
> markup is fine. Absolutists are always proven wrong. ( ;) ).
>
> But most the rest of the markup we have is semantic. Every infobox and
> nav-box is semantic markup. Categories, etc.  All semantic. It's the
> only way to make the site usable to readers, otherwise the place would
> have even more of a mishmash of incompatible styles. It's also the
> only way to make life sane for an editor, as creating a nicely shaped
> nav box using tables with some 40 different style tweaks is no less
> tedious when done via a wysiwyg interface, and its usually worse (at
> least in a markup language you can find all the x pt wide areas in
> some template you're copying and change them to y pt wide in bulk).
>
> My belief and limited experience is that its the complicated markup
> like tables (egads) and infoboxes which cause the most confusion.
> Unfortunately it's only the simple markup (bold, and italic, for
> example) that I've ever seen someone make work well in a wysiwyg
> editor for wikitext.
>
> For an example of the failure modes I'm talking about:
> http://twilightsaga.wikia.com/index.php?title=Kellan_Lutz&action=edit
> The table is uneditable black on black text for me.
> (but I must admit, this implementation appears to be *far* better than
> any attempt I've seen before, worse could be done than imitating that)
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l