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 <dger...@gmail.com> > wrote: >> 2010/1/4 Gregory Maxwell <gmaxw...@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 <dger...@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@lists.wikimedia.org > To unsubscribe from this mailing list, visit: > https://lists.wikimedia.org/mailman/listinfo/wikien-l _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l