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>

Reply via email to