On Thu, Jun 23, 2016 at 11:17 AM, James Forrester <jforres...@wikimedia.org> wrote: > All, > > > TL;DR: The Editing Department is working to make the content editing > software better. The big work areas are improving the visual editor and > editing wikitext. We will bring in a wikitext mode inside the visual editor > for simpler, faster switching. We will experiment with prompts to give > users ideas for what they might want to make as they edit. We will do other > things as well. Your feedback is welcome. > > > 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.[0] 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.[1] > > Status > > In Editing, we're continuing to work on our commission from the 2010 > community strategy[2] 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.[3] > > 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,[0] 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,[4] 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.[5] > 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.[6] 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.[7] 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 > > [0] — > https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2016-2017/revised#Program_4:_Maintain_and_improve_content_creation_and_editing_tools > > > [1] — https://www.mediawiki.org/wiki/VisualEditor/Roadmap > > [2] — > https://strategy.wikimedia.org/wiki/Wikimedia_Movement_Strategic_Plan_Summary > which has been gradually developed into > https://www.mediawiki.org/wiki/Feature_map for possible Product work. > > [3] — https://www.mediawiki.org/wiki/VisualEditor/Rollouts > > [4] — https://phabricator.wikimedia.org/T107595 > > [5] — The plain wikitext editor (with the dark blue buttons toolbar), > WikiEditor (with the light blue/grey toolbar), CodeEditor (with the syntax > highlighting, based on WikiEditor), Flow's discussion editor, and > LiquidThreads's editor (mostly not seen now). > > [6] — https://www.youtube.com/watch?v=jgd2ZHOZGBE > > [7] — > https://lists.wikimedia.org/pipermail/wiki-research-l/2014-September/003807.html
This is very long, but in case anyone feels they'd like the information available in their language, there's a translatable version here: https://www.mediawiki.org/wiki/VisualEditor/Roadmap/Update_2016-06-23 //Johan Jönsson -- _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
