Help test the first visual editor developer prototype

The development of a Visual Editor is one of the Foundation’s top priorities for the upcoming year, as laid out by the 2011-2012 Annual Plan.  There is plenty of evidence that wiki-markup is a substantial barrier that prevents many people from contributing to Wikipedia and our other projects.  Formal user tests, direct feedback from new editors, and anecdotal evidence collected over the past several years have made the need for a visual editor clear.

Developing a web-based visual editor is an extremely complex task.  It is perhaps the most challenging technical project ever undertaken in the history of MediaWiki development.  Here are some of the characteristics that make this project unique:

  • We have to support editing in both the new way (via the Visual Editor) and the traditional way (via wiki markup).  This is important since it’s what our communities have used for more than 10 years: We can’t completely change the way they do their work overnight.  We need to, however, simultaneously support potential editors who are not comfortable with wiki markup.  So any editing system will need to be able to go back and forth between the Visual Editor and wiki markup with minimal, if any, disruption to the end user.  We will have to perform back-and-forth transformations without breaking things.  Anyone who has used an editor that has both “visual” and “html” modes should have a feeling for the challenges, but it’s even harder with wiki markup, because:
  • Wiki markup is enormously expressive, complex and complicated, and there’s a huge amount of content which uses every facet of this markup language. Wikipedia articles employ a rich set of layout features, including images, tables, citations, mathematical formulas, “infoboxes” and other dynamically loaded templates which preserve a consistent look and feel for certain information, and many other elements that enable a compelling and educational reader experience (see the article on Calculus as an example).  Supporting compatibility with the full breadth of these features is an enormous technical challenge.

Over the past several months, the engineering team at WMF has made a lot of progress in developing this visual editor.  Today, we’d like to share the first prototype of a basic editing surface which supports the translation of what’s on the screen into wiki markup.  The demo, which can’t yet save or edit documents, supports both basic formatting (e.g., bold, italics, section heading) as well as many of the required features that people take for granted (e.g., cut/paste and undo/redo). However, it’s still very fragile, and you may easily end up with an unusable document. In the best case scenario, you can use it to generate valid wiki markup that you can copy and paste into an edit box on any MediaWiki wiki.

This version of Visual Editor should support most of the modern browsers but was tested mostly on Firefox, Chrome and IE9. We do support IE8 as well, but not IE7 (yet). The editor isn’t internationalized yet, but will be with the next release.

Try the visual editor sandbox

You can view the demo and see the wikitext translation by visiting the visual editor sandbox on mediawiki.org and playing around with any of the articles available for pre-loading.

Manipulation of an example document, showing the link editor.

Using the debugging tools in the top right, you can switch to side-by-side view of different content representations, including wikitext (icon with square brackets), which are dynamically updated as the text on the left changes.

We would love to get your input on our progress.  Please leave us comments by clicking on the “Leave Feedback” in the upper right hand corner of the demo, which will place your feedback on this page.  Thoughts on which tasks this interface makes easier or harder compared to your current workflow would be particularly helpful.  We’re very excited to share this progress and look forward to your feedback.

Where do we go from here? From here on, we will iteratively release features, bug-fixes, and updates.  We’ll continue to make this tool useful for more real-world use cases, and tick off additional features: creating pages, saving them, editing existing pages or sections, adding/removing images, editing data in templates, editing tables. . .the list goes on.

Our goal is to enable real-world editing of a subset of content soon, but it’ll still be some time until we can serve all the needs of even a small wiki community, let alone Wikipedia’s. Currently we’re targeting June 2012 for first production use at scale, either on a smaller wiki or a section of a larger one. It’s the biggest and most important change to our user experience we’ve ever undertaken, and we look forward to your help in making it happen.

– The Visual Editor Team, Wikimedia Foundation
Trevor Parscal, Inez Korczyński, Neil Kandalgaonkar, Roan Kattouw, Brion Vibber, Gabriel Wicke

27 Show

27 Comments on Help test the first visual editor developer prototype

Stefano Costa 3 years

It looks fantastic. Any chance of integration with http://sharejs.org/ for real-time editing and no more edit conflicts?

Luis Orlando 3 years

Fantastic!
I’m customizing mediawiki for a huge intranet wiki of fifty thousand users and this Visual Editor is exactly what we need. It will make the contribution easier and economize a lot of training. I would like to put this into production as soon as you have a beta version. This is so good that we won’t wait for the stable version. Eventual bugs are better than have to invest in training thousands of people in Wiki markup in order to use WikiEditor.
Is there already a trunk version that we could install as an alternative editor in localsettings.php for start testing?

Pointillist 3 years

Congratulations on getting this far. But what about citations? Surely we don’t want to go back the bad old days of inexperienced contributors adding unsourced stuff that other people have to fix. That would accelerate the decline in experienced editors, and new editors aren’t likely to stick around if their contributions are greeted with a blizzard of “fact”, “says who?” and “uw-unsourced” messages. Sorry to pour cold water, but a visual editor that encourages unsourced content would be a disaster for Wikipedia, not a triumph. – ~~~~

Neil 3 years

This is great, and long overdue. Fantastic work.
I know there’s still lots to do but is there any policy towards smartphones? Even though mobile browsers are not listed in the supported list, my android phone can work passably with it, however text selection seems impossible on the touch screen. If it’s likely to be out of scope, would the direct manipulation interface be hidden by default with an option to try it? (this strikes me as the best approach for all unsupported browsers, even non-mobile)

Jon Verville 3 years

I run wikis for NASA.

I would highly suggest that folks within WikiMedia seriously have a look at Atlassian Confluence 4.0, which was just released a few months ago. Confluence has had a Rich Text Editor for years, but kept an ability for end users to edit via wiki markup. For version 4.0 they have completely eliminated the wiki markup editor, because they switched from wiki markup on the backend to custom XHTML which end users, even experts, would have great trouble manipulating. The big reason for eliminating the wiki markup was round trip issues, which are problems which occur in switching between a visual editor and the markup. I’m sure you will encounter this issue.

While the transition Atlassian just made is slightly different, some of the impacts to end users is the same, in terms of changing the editor interface. I would strongly suggest that you guys look at the conversations that are occurring in public on their wiki pages and forums. From my gathering 3/4ths of folks are adopting the new approach but 1/4 are being very vocal in expressing their disapproval. The links are below:

= FAQ on new editor: http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+FAQ
= The “why”: http://blogs.atlassian.com/2011/11/why-we-removed-wiki-markup-editor-in-confluence-4/
= Index of customer feedback: http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+-+Customer+Feedback
= Version 4.0 release notes: http://confluence.atlassian.com/display/DOC/Confluence+4.0+Release+Notes

Nicolas 3 years

Nice to see progress on this oh so hard challenge ! :-) And oh so much needed ! I am impatient to be able to make a little change on some word without having to swim in all the wikisoup surrounding it.

Please make the easy buttons mark up content as (X)HTML elements “strong” — strong emphasis — and “em” — emphasis —. These are the accessible and semantic elements that are almost always the correct ones when insisting on some content. A contrario, the elements “b” — bold — and “i” — italic — are very rarely the correct ones, they are not semantic, not accessible, they are presentation only, i.e. style, and so their right place is CSS rather than (X)HTML, and so XHTML plans to phase them out.

Thanks, and keep up the good work !

Nicolas

quixote 3 years

@Nick J.: “Link to” is much better. You’re quite right!

Mihály Héder 3 years

That is truly awsome!
I wonder if there will be any way to create plugins for this new editor. It would be wonderful to be able to plug in our recommender tool, Sztakipeda:

Ano Nym 3 years

Where can I report bugs?

1. Put the cursor at the end of ‘errors’ in the second paragraph.
2. Ctrl-shift-cursorleft.
3. Press key ‘x’

Instead of replacing ‘errors’ with ‘x’ the editor replaces it with ‘xs’.

U5K0 3 years

PS: could you include a spell check function for those of us who contribute to english wikipedia but aren’t native english speakers. It seems like an easy enough thing to do for a computer but a very anoying task when you have to copy paste your edits into an external aplication to filter for mistakes.

Thanks

U5K0 3 years

Forgive the all caps but it’s the only way I know hoe to express what I’m thinking right now.

I LOVE IT!

Couple of things I would still like to see are a way to create wikitables, insert images, references etc in a way similar to the B, ”I” and paragraph functions already present.

Can’t wait to show this to all my geeky friends.

shpendk 3 years

This is surely not the first visual editor for mediawiki. There are numerous (though not public) MediaWikis with integrated WYSIWG editors. We are making use of it already.

Chzz 3 years

As far as enwiki goes, by far the most important aspect – indeed, the entire point – of a “visual editor” is helping to make referencing easier.

For new-user submissions, references are really the only thing we care about. And that is the thing everyone struggles with.

Everything else – wiki-links, formatting, infoboxes, headings, etc. – can be sorted out reasonably easily by other editors. The one, single thing we cannot fix is, lack of good references.

So whilst I can see this might help make things more approachable, I think it’s missing the crucial problem, the single hurdle that prevents new users adding to enwiki – referencing.

Trazeris 3 years

Great work guys, I’ve been following the work on the visual editor for quite some time and I must say you’ve managed to do an amazing job with brilliant ideas for tackling the challenges of this feature.
@RedZ, actually they seem to be working on visual edition of templates http://www.mediawiki.org/wiki/Visual_editor/Software_design#Template_Encapsulation but it won’t be full wysiwyg for obvious reasons.

Stu West 3 years

Awesome, awesome, awesome. I am so happy to see this progress. You guys are doing great job tackling a really hard issue. You’re going to have a HUGE positive impact on editing once this goes live. Keep up the good work!

RedZ 3 years

Ernesto: WYSIWYG editors tend to create bad code, making it impossible for advanced users to easily edit. It would appear this has been averted so far by limiting the amount of functions that the editor has. If the visual editor is only intended for casual users, then templates won’t need to be included.

Ernesto Balaji 3 years

It would be much helpful if the edit tool bar having buttons for all Wiki operations like [Citation], References, {{}} tags, templates and so on. A partial conversion of WYSIWYG wouldn’t be effective. Go fully WYSIWYG.

Thansk.

Nick J 3 years

@quixote: If you dont like “Page title”, how about just “Link to” ? “Url” is a bit technical when there’s no reason to be, I think the aim has to be reduced the barrier to entry as much as possible to encourage the widest possible uptake.

Peter Thoeny 3 years

Kudos to the MediaWiki team for tackling this issue. I can testify that it is very challenging task. TWiki has a WYSIWYG editor for several years now where users have a choice to edit in raw wiki markup or with the visual editor. The back and forth translation between TML (TWiki markup) and WYSIWG HTML editor is very challenging. We have a somewhat usable solution, but we still have some issues left where the wiki markup may look somewhat different after a TML => HTML =>TML round trip. Visually OK to look at, but the revision history shown too many changes caused by the errors in the round trip. It looks like you create our own visual editor without relying on a browser based WYSIWYG HTML editor? That looks like a better approach, but at a price of a very big effort. Good luck!

quixote 3 years

Good job! My normal mode is to carp. I don’t often say that to software developers. Very intuitive to use. I like the way you have a drop down menu at the cursor for the commonest functions: B I and link.

One small issue: when making a link, the context box asks for “Page title” when what it really means is usually referred to as the page url. Unless there’s some special reason for using “title,” I’d suggest changing that to “url.”

Leave a Reply

Your email address will not be published. Required fields are marked *