Village Pump (technical) - Alpha Version of The VisualEditor Now Available Here

Alpha Version of The VisualEditor Now Available Here

TL;DR: Today we are launching an alpha, opt-in version of the VisualEditor to the English Wikipedia. This will let editors create and modify real articles visually, using a new system where the articles they edit will look the same as when you read them, and their changes show up as they type enter them — like writing a document in a word processor. Please let us know what you think.

Why launch now?

We want our community of existing editors to get an idea of what the VisualEditor will look like in the “real world” and start to give us feedback about how well it integrates with how they edit right now, and their thoughts on what aspects are the priorities in the coming months.

The editor is at an early stage and is still missing significant functions, which we will address in the coming months. Because of this, we are mostly looking for feedback from experienced editors at this point, because the editor is insufficient to really give them a proper experience of editing. We don’t want to promise an easier editing experience to new editors before it is ready.

As we develop improvements, they will be pushed every fortnight to the wikis, allowing you to give us feedback as we go and tell us what next you want us to work on.

How can I try it out?

The VisualEditor is now available to all logged-in accounts on the English Wikipedia as a new preference, switched off by default. If you go to your “Preferences” screen and click into the “Editing” section, it will have as an option labelled “Enable VisualEditor”.

Once enabled, for each article you can edit, you will get a second editor tab labelled “VisualEditor” next to the “Edit” tab. If you click this, after a little pause you will enter the VisualEditor. From here, you can play around, edit and save real articles and get an idea of what it will be like when complete.

At this early stage in our development, we recommend that after saving any edits, you check whether they broke anything. All edits made with the VisualEditor will show up in articles’ history tabs with a “VisualEditor” tag next to them, so you can track what is happening.

Things to note

• Slow to load - It will take some time for long complex pages to load into the VisualEditor, and particularly-big ones may timeout after 60 seconds. This is because pages have to be loaded through Parsoid which is also in its early stages, and is not yet optimised for deployment and is currently uncached. In the future (a) Parsoid itself will be much faster, (b) Parsoid will not depend on as many slow API calls, and (c) it will be cached.
• Odd-looking - we currently struggle with making the HTML we produce look like you are used to seeing, so styling and so on may look a little (or even very) odd. This hasn't been our priority to date, as our focus has been on making sure we don't disrupt articles with the VisualEditor by altering the wikitext (correct "round-tripping").
• No editing references or templates - Blocks of content that we cannot yet handle are uneditable; this is mostly references and templates like infoboxes. Instead, when you mouse over them, they will be hatched out and a tooltip will inform you that they have to be edited via wikitext for now. You can select these items and delete them entirely, however there is not yet a way to add ones in or edit them currently (this will be a core piece of work post-December).
• Incomplete editing - Some elements of "complex" formatting will display and let you edit their contents, but not let users edit their structure or add new entries - such as tables or definition lists. This area of work will also be one of our priorities post-December.
• No categories - Articles' "meta" items will not appear at all - categories, langlinks, magic words etc.; these are preserved (so editing won't disrupt them), but they not yet editable. Another area for work post-December - our current plan is that they will be edited through a "metadata flyout", with auto-suggestions and so on.
• Poor browser support - Right now, we have only got VisualEditor to work in the most modern versions of Firefox, Chrome and Safari. We will find a way to support (at least) Internet Explorer post-December, but it's going to be a significant piece of work and we have failed to get it ready for now.
• Articles and User pages only - The VisualEditor will only be enabled for the article and user namespaces (so you can make changes in a personal sandbox), and will not work with talk pages, templates, categories, etc.. In time, we will build out the kinds of specialised editing tools needed for non-articles, but our focus has been on articles.

Final point

This is not the final form of the VisualEditor in lots of different ways. We know of a number of bugs, and we expect you to find more. We do not recommend people trying to use the VisualEditor for their regular editing yet. We would love your feedback on what we have done so far – whether it’s a problem you discovered, an aspect that you find confusing, what area you think we should work on next, or anything else, please do let us know.

Jdforrester (WMF) (talk) 03:26, 12 December 2012 (UTC)

How will the WMF track the VisualEditor's quality impact on the encyclopedia? What metrics will be used? What parameter space in those metrics will determine success or failure of the tool? Jason Quinn (talk) 05:35, 12 December 2012 (UTC)

At the moment I imagine the quality tracking is "not at all", since it's only available to a small number of users - a large chunk of whom are going to be power users. Tracking quality wouldn't necessarily be useful. I'm actually working on a review of the VE's impact on full deployment now. Okeyes (WMF) (talk) 19:47, 12 December 2012 (UTC)

Oliver is correct; we don't currently plan to collect quantitative data whilst the VisualEditor is only in an opt-in state for a handful of users. Later, when it will be deployed to a much larger number of accounts, is the time for that. Jdforrester (WMF) (talk) 19:59, 12 December 2012 (UTC)

I was asking about post large-scale deployment. I was wondering if quality impact studies were going to occur at all. Your relies seem to imply that there will be some which partly alleviates my concern. I imagine modeling "quality impact" to be complex and subtle so I was curious about details such as the variables that will be tracked. The model ought to be made fully public and transparent so it can be reviewed and critiqued. It would be easy to misinterpret data in such a study. As the VisualEditor will affect a dramatic change to editing habits, a lot of thought needs to be put into such studies to make sure the editor is actually helping rather than harming the project. Jason Quinn (talk) 04:14, 13 December 2012 (UTC)

I agree. In my mind, post-deployment tracking has to be twofold. The first is quality, sure, but the second is sociological impact. Even if 90 percent of the edits from newcomers are perfect, if edit volume has increased tenfold there's still going to be a dramatic uptake in junk, and while I think we'd all agree that the good outweighs the bad, there, we have to be very careful that the uptake in junk doesn't burn out the users who deal with it. If it does, there's a knock-on effect on everyone else. We need to be measuring burnout as well as good/bad ratios.

Out of interest, how would you measure quality? Are we simply talking a very basic comparison between quality of pre-VE and post-VE edits using hand coding, or...? Okeyes (WMF) (talk) 21:41, 13 December 2012 (UTC)

To approach your question in a very literal sense, I would take this problem by starting with a very simple foundation and modifying that step-by-step to make it more useful. This could lead to several models, which is fine. The question of quality impact of the VisualEditor seems very specialized and the solution is not likely going to fit easily into some textbook solution. It also doesn't make sense to try to develop some grand analytical solution: too many subjective aspects to be perfectly quantifiable in a way that means something. Some model that "does well enough" is probably the best to be hoped for. Let's first just mention some of the variables likely worth tracking:

• absolute number and percentage of reverts within X (24?) hours of an edit (in general and by IP/account editors)
• number and percentage of blocks within X (24?) hours of an edit (in general and by IP/account editors)

The key is to focus on discontinuities in the graphs and a change in these variables that persist long-term. I say "long term" because I advise not to pay too much attention to any initial "jumps". People will edit abnormally for a while upon the introduction of new features because they are curious about them and test them out (er, play with them). After a few weeks or a month, things will become "old hat" and settle down. Any changes in the variables between this point and the point prior to the introduction probably have some significant meaning.

Your argument about burnout is a good one but I would frame it differently. Instead of thinking of it as a sociological effect (which is complicated and messy to handle), I would turn it into an analytical question: is the encyclopedia accumulating more undetected/reverted vandalism because of the VisualEditor? It would take a bit of thought to figure out how to estimate the rate of "undetected/reverted vandalism". I'm not sure off the top of my head how to do it but I've seen studies that graph the expected lifetime of vandalism, and perhaps that could be combined with the above data to estimate a reasonable yes or no.

Once tracking variables have been settled upon, I would pick some sensible values by which they are allowed to change due to the introduction of the VisualEditor. If they change by more than that, they should trigger (at the minimum) a second-guessing to the value of the Editor and prompt more study of the VisualEditor's impact. Regardless, a large amount of unbiased, common sense will be required to interpret any results. I would not have the same people who developed the editor helping to judge its success or failure. Jason Quinn (talk) 17:35, 17 December 2012 (UTC)

You may also wish to look at some quick thoughts I had on useful metrics for VE once we get closer to full deployment (linked to from the agenda of the latest monthly Metrics and activities meeting). Jdforrester (WMF) (talk) 16:05, 18 December 2012 (UTC)