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

[The Cunctator]

I can promise you that the reason edit rates has gone down is not because of
problems with wikitext. Though the cruft is a symptom.

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

> [crossposted to foundation-l and wikitech-l]
>
>
> "There has to be a vision though, of something better. Maybe something
> that is an actual wiki, quick and easy, rather than the template
> coding hell Wikipedia's turned into." - something Fred Bauder just
> said on wikien-l.
>
>
> Our current markup is one of our biggest barriers to participation.
>
> AIUI, edit rates are about half what they were in 2005, even as our
> fame has gone from "popular" through "famous" to "part of the
> structure of the world." I submit that this is not a good or healthy
> thing in any way and needs fixing.
>
> People who can handle wikitext really just do not understand how
> offputting the computer guacamole is to people who can cope with text
> they can see.
>
> We know this is a problem; WYSIWYG that works is something that's been
> wanted here forever. There are various hideous technical nightmares in
> its way, that make this a big and hairy problem, of the sort where the
> hair has hair.
>
> However, I submit that it's important enough we need to attack it with
> actual resources anyway.
>
>
> This is just one data point, where a Canadian government office got
> *EIGHT TIMES* the participation in their intranet wiki by putting in a
> (heavily locally patched) copy of FCKeditor:
>
>
>   http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html
>
> "I have to disagree with you given my experience. In one government
> department where MediaWiki was installed we saw the active user base
> spike from about 1000 users to about 8000 users within a month of having
> enabled FCKeditor. FCKeditor definitely has it's warts, but it very
> closely matches the experience non-technical people have gotten used to
> while using Word or WordPerfect. Leveraging skills people already have
> cuts down on training costs and allows them to be productive almost
> immediately."
>
>   http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html
>
> "Since a plethora of intelligent people with no desire to learn WikiCode
> can now add content, the quality of posts has been in line with the
> adoption of wiki use by these people. Thus one would say it has gone up.
>
> "In the beginning there were some hard core users that learned WikiCode,
> for the most part they have indicated that when the WYSIWYG fails, they
> are able to switch to WikiCode mode to address the problem. This usually
> occurs with complex table nesting which is something that few of the
> users do anyways. Most document layouts are kept simple. Additionally,
> we have a multilingual english/french wiki. As a result the browser
> spell-check is insufficient for the most part (not to mention it has
> issues with WikiCode). To address this a second spellcheck button was
> added to the interface so that both english and french spellcheck could
> be available within the same interface (via aspell backend)."
>
>
> So, the payoffs could be ridiculously huge: eight times the number of
> smart and knowledgeable people even being able to *fix typos* on
> material they care about.
>
> Here are some problems. (Off the top of my head; please do add more,
> all you can think of.)
>
>
> - The problem:
>
> * Fidelity with the existing body of wikitext. No conversion flag day.
> The current body exploits every possible edge case in the regular
> expression guacamole we call a "parser". Tim said a few years ago that
> any solution has to account for the existing body of text.
>
> * Two-way fidelity. Those who know wikitext will demand to keep it and
> will bitterly resist any attempt to take it away from them.
>
> * FCKeditor (now CKeditor) in MediaWiki is all but unmaintained.
>
> * There is no specification for wikitext. Well, there almost is -
> compiled as C, it runs a bit slower than the existing PHP compiler.
> But it's a start!
> http://lists.wikimedia.org/pipermail/wikitext-l/2010-August/000318.html
>
>
> - Attempting to solve it:
>
> * The best brains around Wikipedia, MediaWiki and WMF have dashed
> their foreheads against this problem for at least the past five years
> and have got *nowhere*. Tim has a whole section in the SVN repository
> for "new parser attempts". Sheer brilliance isn't going to solve this
> one.
>
> * Tim doesn't scale. Most of our other technical people don't scale.
> *We have no resources and still run on almost nothing*.
>
> ($14m might sound like enough money to run a popular website, but for
> comparison, I work as a sysadmin at a tiny, tiny publishing company
> with more money and staff just in our department than that to do
> *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
> efficient organisation.)
>
>
> - Other attempts:
>
> * Starting from a clear field makes it ridiculously easy. The
> government example quoted above is one. Wikia wrote a good WYSIWYG
> that works really nicely on new wikis (I'm speaking here as an
> experienced wikitext user who happily fixes random typos on Wikia). Of
> course, I noted that we can't start from a clear field - we have an
> existing body of wikitext.
>
>
> So, specification of the problem:
>
> * We need good WYSIWYG. The government example suggests that a simple
> word-processor-like interface would be enough to give tremendous
> results.
> * It needs two-way fidelity with almost all existing wikitext.
> * We can't throw away existing wikitext, much as we'd love to.
> * It's going to cost money in programming the WYSIWYG.
> * It's going to cost money in rationalising existing wikitext so that
> the most unfeasible formations can be shunted off to legacy for
> chewing on.
> * It's going to cost money in usability testing and so on.
> * It's going to cost money for all sorts of things I haven't even
> thought of yet.
>
>
> This is a problem that would pay off hugely to solve, and that will
> take actual money thrown at it.
>
> How would you attack this problem, given actual resources for grunt work?
>
>
> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>