I posted to foundation-l concerning the other way to get more people editing Wikipedia: the perennial wish for good WYSIWYG in MediaWiki.
This is a much bigger potential win than many people think. From mediawiki-l in May, a Canadian government official posted how adding a (locally patched) instance of FCKeditor to their intranet got eight times the participation:
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.
The geeks refused to believe that not requiring people to wade through computer guacamole worked and that everyone new must be idiots. The poster disabused them of this conceit:
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.
Eight times the number of smart and knowledgeable people who just happen to be bad with computers suddenly being able to even fix typos on material they care about. Would that be good or bad for the encyclopedia?
Now, WYSIWYG has been on the wishlist approximately forever. Developer brilliance applied to the problem has dashed hopes on the rocks every single time. Brilliance is not enough: we’re going to need to apply money.
- We need good WYSIWYG. The government example suggests that a simple word-processor-like interface would be enough to give tremendous results. So that’s an achievable target.
- 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. Engineers and developers are perpetually shocked at what ordinary people make of their creations.
- 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? What else could do with money spent on it?
Magnus Manske, in his usual manner, has coded up a quick editor whose name I’ve stolen for this post. It’s rough, but it’s a nice working example of some of the way there. WYSIFTW. Screenshot.
It astonishes me that we have not done this yet. It’s so obvious that 1 million of our recent 16 should be geared towards nothing else except solving this problem. The ONLY reason not to is to keep out hordes of new editors… but that’s a problem we should want! The future of this project depends on User Interface Design, namely the editor. It’s amazing we haven’t put it at the head of the priority list.
It doesn’t matter if this is a $50,000 problem or a $500,000 problem or a $5 million problem – ***it needs to be solved***. The heart of Wikipedia is the editors who add and improve content, and almost every language version has been in a continual decline (in terms of numbers of edits) since early 2007. We need to reverse that trend, and the sooner the better. And the only way to do that (in my opinion) is to make editing far, far easier than it is today.
I also note two more aspects of a comprehensive solution (which can be done separately):
* Moving the text of footnotes, tables, and templates out of the main editing box. (In the screenshot,footnote text is still in main editing fox). Some time ago, Magnus coded up a working version of an editing interface in which the footnotes were put into a separate edit box (for the Monobook user interface), so this is eminently doable.
* Providing a **single click** way of generating the standard text/code for a footnote – that is, in a browser window, looking at a source, if someone presses (say) Cntrl-Option-W, that would post web cite or news cite or similar text to the clipboard, ready to be pasted into the Wikipedia editing box. This is actually eminently doable (Zotero can do this, albeit with more than one click, and a Firefox extension exists that generates limited web cite code with a single click).
The problem so far has been that (1) we’re used to getting development done with sheer brilliance, rather than money (2) it turns out to actually be a really hard problem.
That’s why I’m pushing it as basically on the level of a moon shot – it’ll take brilliance and lots of actual resources.
Erik Moller has noted on wikien-l that the usability initiative is seriously interested in the topic. There’s several discussions going on at the moment in email lists and in cc lists.
What I’d like to see right now is some usability testing on WYSIFTW, to see if Magnus’ approach works well for the seriously nontechnical.
Re John Broughton’s idea for “a **single click** way of generating the standard text/code for a footnote”…
Would there be any way to make a nice little bookmarklet so people could drag a URL onto the button, and it would copy a wiki-citation to the clipboard?
What a wonderful statistic: 8 Times, that is a “FACTOR EIGHT”. To support that this point is really true and that we are suffering from the geeks thinking that anyone can learn wiki syntax, we have built a wiki product just to solve that problem: namely many intelligent people know MSWord but are not ready to step outside that comfort zone.
So we created a wiki product where you can create and edit pages using MSWord. That approach would be of no use for Mediawiki as word’s html leaves a lot to be desired for. However when it comes to sharing information and building wiki knowledge bases, this is what triggers people to use it. Most likely 8 times as many.
– Frans
@Jen – “Mr Adequate” on wikien-l suggests the Cite4Wiki Firefox extension: https://addons.mozilla.org/en-US/firefox/addon/62583/ http://en.wikipedia.org/wiki/Wikipedia:Cite4Wiki
Color me interested. Why, between a WYSIWYG editor and Liquid Threads, RationalWiki might actually become bearable to work with! :D
@Radioactive – I’ve been using WYSIFTW a bit. It’s horribly slow on my Dell Mini 9, but usable on Magnus’ iMac and MacBook, which he develops on. Testing is done in Chrome, Firefox 3.6 and Firefox 4. Nearing feature-completion, apparently, which will then be time to optimise.