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 <[email protected]> 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 > [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > _______________________________________________ foundation-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
