[Foundation-l] Big problem to solve: good WYSIWYG on WMF wikis

[Stephanie Daugherty]

On Tue, Dec 28, 2010 at 11:43 AM, David Gerard <dgerard at gmail.com> wrote:

> On 28 December 2010 16:06, Victor Vasiliev <vasilvv at gmail.com> wrote:
>
> > I have thought about WYSIWYG editor for Wikipedia and found it
> > technically impossible. The main and key problem of WYSIWIG are
> > templates. You have to understand that templates are not single
> > element of Wikipedia syntax, they are integral part of page markup.
> > You do not insert "infobox template", you insert infobox *itself*, and
> > from what I heard the templates were the main concern of many editors
> > who were scared of wikitext.
> > Now think of how many templates are there in Wikipedia, how frequently
> > they are changed and how much time it would take to implement their
> > editing.
>
>
> Yes. So how do we sensibly - usably - deal with templates in a
> word-processor-like layout? Is there a way that passes usability
> muster for non-geeks? How do others do it? Do their methods actually
> work?
>
> e.g. Wikia has WYSIWYG editing and templates. They have a sort of
> solution to template editing in WYSIWYG. It's not great, but people
> sort of cope. How did they get there? What can be done to make it
> better, *conceptually*?
>
> What I'm saying there is that we don't start from the assumption that
> we know nothing and have to start from scratch, forming our answers
> only from pure application of personal brilliance; we should start
> from the assumption that we know actually quite a bit, if we only know
> who to ask and where. Does it require throwing out all previous work?
> etc., etc. And this is the sort of question that requires actual
> expense on resources to answer.
>
> Given that considerable work has gone on already, what would we do
> with resources to apply to the problem?
>
>
I think the second part of what I just posted answers this. Split parser to
disallow markup constructs that would break editing interfaces and confuse
new editors (the complicated stuff happens out of sight out of mind in
templates and article layouts). With a little work, the way templates are
designed could be changed to insure they provide a usable prototype to be
able to be edited like forms. Make the editor WYSIWYM rather than WYSIWYG,
it's close enough to WYSIWYG to provide a good editing experience, but
dispenses with 1:1 fidelity in favor of clarity within the
editing environment when necessary - we allow for some elements to be
rendered in an "editing friendly" manner that can be drastically different
from the way the article renders when only viewing it, for example, by
having a template show up as a block or inline element symbol (according to
it's prototype), which can be clicked on and edited as a form. Some
formatting can also be ignored in WYSIWYM mode, so long as there is some
representation that shows the user what to expect (think "show formatting
codes" mode in some WYSIWYG word processors, except, in this case rather
than show all formatting codes, we show the ones that aren't being rendered
at the moment. Other than the initial surprise factor for those that haven't
used that sort of interface, there's not much in the way of a learning curve
- one or two edits at most before someone picks up on what's happening and
can roll with it, and it beats a WYSIWYG interface for a lot of complicated
tasks because it emphasizes "say what you mean" rather than worrying about
how exactly to format it.