WYSIWYG
From Organic Design wiki
"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.
> > 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? - d.
> > 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? > > My primary interest at the moment in this area is to reframe the question a bit; rather than "how do we make good WYSIWYG that works on the way Wikipedia pages' markup and templates are structured now" -- which we know has been extremely hard to get going -- to instead consider "how do we make good WYSIWYG that does the sorts of things we currently use markup and templates for, plus the things we wish we could do that we can't?" We have indeed learned a *huge* amount from the last decade of Wikipedia and friends, among them: * authors and readers crave advanced systems for data & format-sharing (eg putting structured info into infoboxes) and interactive features (even just sticking a marker on a map!) * most authors prefer simplicity of editing (keep the complicated stuff out of the way until you need it) * some authors will happily dive into hardcore coding to create the tools they need (templates, user/site JS, gadgets) * many other authors will very happily use those tools once they're created * the less the guts of those tools are exposed, the easier it is for other people to reuse them The incredible creativity of Wikimedians in extending the frontend capabilities of MediaWiki through custom JavaScript, and the markup system through templates, has been blowing my mind for years. I want to find a way to point that creativity straight forward, as it were, and use it to kick some ass. :) Within the Wikimedia ecosystem, we can roughly divide the world into "Wikipedia" and "all the other projects". MediaWiki was created for Wikipedia, based on previous software that had been adapted to the needs of Wikipedia; and while the editing and template systems are sometimes awkward, they work. Our other projects like Commons, Wiktionary, Wikibooks, Wikiversity, and Wikinews have *never* been as well served. The freeform markup model -- which works very well for body text on Wikipedia even if it's icky for creating tables, diagrams and information sets -- has been a poorer fit, and little effort has been spent on actually creating ways to support them well. Commons needs better tools for annotating and grouping media resources. Wiktionary needs structured data with editing and search tools geared towards it. Wikibooks needs a structure model that's based on groups of pages and media resources, instead of just standalone freetext articles which may happen to link to each other. Wikiversity needs all those, and more interactive features and the ability for users to group themselves socially and work together. Getting anything done that would work on the huge, well-developed, wildly-popular Wikipedia has always been a non-starter because it has to deal with 10 years of backwards-compatibility from the get-go. I think it's going to be a *lot* easier to get things going on those smaller projects which are now so poorly served that most people don't even know they exist. :) This isn't a problem specific to Wikimedia; established organizations of all sorts have a very difficult time getting new ideas over that hump from "not good enough for our core needs" to "*bam* slap it everywhere". By concentrating on the areas that aren't served at all well by the current system, we can make much greater headway in the early stages of development; Clayton Christensen's "The Innovator's Dilemma" calls this "competing against non-consumption". For the Wikipedia case, we need to incubate the next generation of templating up to the point that they can actually undercut and replace today's wikitext templates, or I worry we're just going to be sitting around going "gosh I wish we could replace these templates and have markup that works cleanly in wysiwyg" forever. My current thoughts are to concentrate on a few areas: 1) create a widget/gadget/template/extension/plugin model built around embedding blocks of information within a larger context... 2) ...where the data and rendering can be reasonably separate... (eg, not having to pull tricks where you manually mix different levels of table templates to make the infobox work right) 3) ...and the rendering can be as simple, or as fancy as complex, as your imagination and HTML5 allow. -- brion vibber
