Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

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 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

40 Responses to “Help test the first visual editor developer prototype”

    1 2
  1. 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:

  2. Ano Nym says:

    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’.

  3. U5K0 says:

    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.


  4. U5K0 says:

    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.

  5. shpendk says:

    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.

  6. Chzz says:

    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.

  7. Trazeris says:

    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 but it won’t be full wysiwyg for obvious reasons.

  8. Stu West says:

    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!

  9. RedZ says:

    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.

  10. 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.


  11. Nick J says:

    @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.

  12. Peter Thoeny says:

    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!

  13. quixote says:

    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.”

  14. Erik says:

    Ioannis, these are just for debugging purposes–this is still a developer prototype. They’ll go away or get stashed away eventually.

    Stephan, it’s an extension sitting in trunk at:

    You can use the extension distributor to download:

    Or follow the checkout instructions here:

  15. Is there a branch under, or is the code held on some other source control system?


  16. Ioannis says:

    Why are there HTML and JSON views? A good reason for the use of wikitext apart from its relative simplicity (compared to full-scaled languages like HTML) is the fact the pages cannot be manipulated easily by various tags which could mess up the whole thing.

    Sure, I guess it can’t be edited in HTML directly (good move) but I don’t see the point of having the HTML source there, that would simply confuse people. Why not just leave the “view source” button at the top and maybe have a drop-down to include JSON as well? This is needlessly confusing to users–even longtime ones. I wouldn’t think such an inclusion would be very wise.

    Nevertheless, it looks brilliant. I just hopes it work with Internet Explorer 8 as Windows XP is still around and we need to cater to that! All it needs is a ref system and obviously a way to show templates dynamically (which Wikia doesn’t do, for instance) and it’s ready to go!

  17. John Ericson says:

    Excellent work guys! I’m looking forward to see how this project progresses. Love the clean and pleasent design of it.

  18. This is beautiful. Thanks for working on this. I look forward to seeing what you guys will come up with as the next steps.

  19. Filceolaire says:

    Left feedback.

    On a different subject … what’s happening with Liquid Threads?

    I saw it on the strategy wiki a year ago but I haven’t seen any progress reports on it in the technology blog since.

  20. As far as WikiText translation has to go, this definitely has a ways to go. But as far as WYSIWYG interfaces, this is one of the nicest I’ve seen so far.