On Mon, Jan 4, 2010 at 12:50 PM, David Gerard <[email protected]> wrote: > 2010/1/4 Gregory Maxwell <[email protected]>: >> 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 <[email protected]> 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 [email protected] To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
