VisualEditor/Roadmap/Update 2016-06-23/da

All,

I thought it would be helpful to send an update about editing software. It's been over a year since my last, and things change (and it's easy to lose track). We set out some higher-level objectives for Editing in the Wikimedia Foundation's annual plan for the coming financial year. This gives a little more detail on that, with particular emphasis on the team working on content editing tools directly. There's also a brief, more feature-focussed roadmap available on MediaWiki.org if you are interested.

Status

In Editing, we're continuing to work on our commission from the 2010 community strategy to create a rich visual editor which makes it possible to edit all our content, and participate in our workflows, without knowing or having to learn wikitext. This is a work in progress; as with all our improvements to the software, we will never be "done", and hopefully you notice improvements over time. Each week, new features, improvements, and bug fixes are released, often led, altered or supported by our volunteer developers and community pioneers; my thanks to you all.

We are now roughly five years into this visual editor work, and have made good progress on a credible content editor for many users' workflows, helping editors spend more time on what they're editing instead of how. First and foremost, not having to think about the vagaries of wikitext and instead focus on the content of their writing is something that many new and experienced volunteers alike have mentioned they appreciate. The automatic citations tool makes adding new references to websites or DOIs much more quickly and thoroughly, improving the quality of the content. The visual media searching tool makes it simple to find and add more of the great images and other media on Commons and add to a page. Visual table editing helps make changes to tables, like moving columns or parts of tables around, much more easily than in wikitext, saving time of our volunteers to focus on their work making the wikis better.

The visual editor supports many (but not yet all) of our content languages, and thanks to community support and engagement the editor is available by default on over 235 Wikipedias (and for opt-in use on the remaining 55), including almost all of our largest Wikipedias. It is on by default for logged-out users and new accounts on 233 of these, and on for new accounts (but not yet for logged-out users) on two, English and Spanish. As of this week, this now includes representatives from each of the "CJK" language group, with four different Chinese script languages (Classical, Cantonese and Wu, as well as Min Nan), Korean and Japanese. We're currently working our way through each of the remaining communities asking them if it's OK to switch; the next groups will be the thirteen Arabic script Wikipedias and the twenty-three Indic Wikipedias. You can see specific details at the rollout grid if you're interested.

We have recently been working with the non-Wikipedia sister projects. As you might imagine, each project has different needs, workflows and concerns, and it's important to us that we ensure the tools we provide are tweaked as appropriate to support, not undermine, those requirements to the extent justifiable by demand. Per community request, the visual editor is already available to all users on several different sister projects, but we think there is more to do for some before we encourage this more widely. Recently, we have been working with the communities on the Wikivoyages, which are quite similar to the Wikipedias in needs from the visual editor; our thanks to the patience and assistance from the Wikivoyagers. We're also working with User:tpt and other volunteers who create and maintain the software used by Wikisources to adapt the visual editor to work with those features; our thanks to them, and to Wikisourcerers more widely.

Core and maintenance work

Despite this progress, there are still several areas in which the core functionality of the editing software needs extensions, improvements and fixes. In many places within the visual editor software we have to work around browsers' bugs, missing features and idiosyncrasies, and nowhere is that more problematic than the critical areas of typing, cursoring, and related language support. There continue to be irritating, occasionally serious bugs related to these, for which we continue to partner with browser vendors and experts around the Web to try to develop workarounds and improvements.

Another important area related to language support is coming up with a solution for the nine languages in the Wikimedia family which use content language variants, biggest amongst them Chinese, which poses some very large challenges as it is fundamentally incompatible with a visual editing method. If you're interested in discussing how this might work we would love to discuss with you what possible options you think would work out, even more so if you wish to work on support for this.

The performance of the software is not yet as good as we would wish, in terms of speed, network use, and load on users' browsers. This is a usability issue for all users, but is especially critical for users of lower-powered devices (like older machines) and more powerful but limited-resource ones (like most mobile phones and tablets), where in some cases it can be not merely awkward to use, which is disrespectful of volunteers' time, but prohibitive, excluding community members from volunteering their time. We have several strategies lined up to tackle this basket of issues, from editing only small parts of a document at once – sometimes called "sentence-level editing" – to loading smaller bits of the editor at first and then larger, less-used bits as needed whilst retaining a consistent interface without changes in interface which can be confusing and distracting. More widely, working to let the software include as many possible volunteers in the community if they wish to join also covers accessibility in all its forms, making sure editors who have learning impairments or physical disabilities are supported as much as possible.

Many of our communities have put in significant effort over the past fifteen years to come up with specialised workflows on their wikis. Sometimes these efforts have involved complicated extensions and gadgets, like the use of the "inputbox" button to start a new article based on a template, as used on several wikis. Others provide additional tools inside the wikitext editor, like the English Wikipedia's tool to automatically created references based on a link, some of which we provide inside the visual editor now, but many of which are not yet there, and which we at the Foundation can never scale to provide the individual attention for each of our hundreds of wikis. For the visual editor to be successful, pleasant and as un-confusing as possible, it is vital that we help communities provide gadgets as appropriate, and duplicate or extend the integration with the various other editors. We look forward to helping you help others.

A big technical change we're hoping to achieve this year, as we set out directly in the annual plan, is to re-engineer how MediaWiki supports content. We want to allow multiple "parts" of content, of different parts, to be stored as revisions of pages. This is a much-needed feature already, most obvious with file pages – each file's upload history is shown separate from its description page, and videos' subtitles are stored in a different namespace rather than shown on the page. This also is an issue in other areas, making workflows more complicated, like the common documentation sub-page of templates rather than having a combined template and documentation page needing two edits to improve a template and document how it now works. With Wikimedia Deutschland's work on moving Commons' file meta-data into a proper structure linked to Wikidata, addressing this need is now acute. We look forward to driving forward the technical discussion and implementation of multi-part content revisions in the back-end, and we have some hopes with how it can be used to do new things which we discuss below.

Finally with regards to core work, our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing in MediaWiki, and not just to be another single editor. Depending on how you count them, there are currently six pieces of editor software beyond the visual editor installed on most of our wikis, which gives us six different interfaces by which to confuse users, six different sets of bugs to track down, and six different places where features can interact in unexpected ways and which need to be tested. Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform. This has already been done for example in Flow, where it uses the visual editor for rich content editing rather than re-inventing its down, and we are planning to work with our colleagues in the Language Engineering team to do the same for the Content Translation tool. We are experimenting with providing a more modern wikitext editor which can provide a consistent experience between the visual and wikitext editors, and between desktop and mobile; there's a video of our work to date on this, still incomplete, which some of you may have seen. Naturally, any new wikitext editor would have to be not just change for its own sake but better for users to be worth switching, so we're cautious about how quickly we would introduce this; certainly, a beta feature test of the initial version for the intrepid will be necessary before we make any plans as to wider availability.

Feature work

As well as our core work, it is important to us that we also spend some of our time to explore ways in which new features can improve the experience of the site for users, helping them improve quality, breadth and depth of content more effectively and efficiently. Not all of the ideas below are ones on which we're actively working right now, but we should have some progress this coming year on at least most of them.

An idea I'm quite excited about in terms of possibilities is providing a system in the visual and wikitext editors that can prompt users as they edit. The range of different kinds of edit, from copy editing and improving references to a full up re-working of whole sets of pages, means that newbies can get lost in knowing where to start. There are lots of different kinds of improvements that we could provide, from simple static ones like "this article isn't illustrated yet" to very complex and specific ones like "this article's main wikiproject is about the USA, so wants you to write in American English". This work is aimed at reducing the burden on experienced users when they review new editors' changes, letting each wiki configure hints appropriate to that community. We also intend for these experiments to improve the "on-boarding" experience for new users, helping them learn what is wanted and valued by their wiki's community, and what makes for more constructive edits.

Once we have multi-part content streams (which I mentioned above as core work), there are several possible feature areas we think are worth considering.

A big one is that we think that there's a lot of potential in storing edits in HTML DOM as well as in wikitext. Firstly, this should allow us to help MediaWiki understand changes in edits more like the way that humans do. This would allow us to provide neat features like visual diffs and animated histories of pages. Showing clearly who wrote which parts of an article, or what parts of the article have been changed most recently, is not a new idea but hasn't been practical to implement at scale. It would be fascinating to see if this tool could assist in deepening the richness of understanding for readers of the staleness or volatility of articles in practice.

More importantly, it should allow much better automatic handling of edit conflict situations, and so reduce the occurrence of edit conflicts that need manual correction. Theoretically, it could let us remove edit conflicts entirely, though this would mean making some decisions about how edits work which we may decide are worse long-term than having manual resolution of edit conflicts; we're not planning to make a decision on that until we know more.

Storing pages in DOM could also allow smart partial document saving, splitting up your bigger edits into different chunks, each of which you can save as you go. Making smaller, simpler edits. This could also let us reduce edit conflicts by prompting people to save bits as they edit, and pushing those new versions "live" into the editor of others also editing at the same time.

The final thing I'll mention that DOM edits could do is allow DOM-based annotations to pages. With this, citations could be 'applied' to bits of the article showing which statements are (and aren't) backed up with a reference. Discussions could refer to a specific image, sentence or word choice to let editors have deeper, faster conversations, and understand when they're editing a potentially divisive section. Illustrations like diagrams and maps could highlight an area.

Another thing we're keen to explore with content streams is improving how page meta-data is edited, centralising the data about a page's name, protection level, whether it should show a table of contents, what pages redirect to it, and so on. Each of these examples is currently edited in a different place and with a different tool. We think it could help a lot to provide these controls together, editing a new "part" of the page alongside the wikitext block. Note that we're not planning on removing the existing mechanisms, which each work well enough – this would be an additional tool, at least at first.

A final item worth mentioning, because it comes up a lot as a technical/editor wishlist item from some editors and developers alike, is real-time collaborative editing. I wrote some details a couple of years ago about how this, especially the "full-throttle" collaboration system (like Etherpad or Google Docs, where there can be multiple users at the same time each with their own cursor) is a huge problem, not just a technical one but critically a social one. Despite this, I do hear quite often from people about how this would be very helpful, for mentoring new users and those doing something with which they're unfamiliar, and for content editing collaborating, like for edit-a-thons, breaking news articles where lots of changes are wanted at the same time, and themed collaborations of the day or similar. I'm keeping an open mind as to whether we will ever do this, but it's not something we're worrying about right now.

Summary

As you can see if you have made it this far, there's a lot of different things we're working on in the department. I'm hopeful that the improvements we make have already made, and will continue to make, the editing lives of those reading this a bit easier.

I'm thankful for all the support we get from across the communities, be it in the form of clear suggestions, complaints and proposals, technical advice and volunteering, or anything else. If you're technical, and a current or prospective volunteer developer interested in working on some of these areas, we would love to help you.

I'll be at Wikimania this year. As always, I'll be happy to talk about anything in this update — or missing from it — in person there, online on Phabricator or IRC, on-wiki, or wherever else. Your thoughts and responses are what guide us, and what makes it worth doing. Hope this was interesting!

Links

Oprindelig: [1]