Editors using the mobile website on Wikipedia can opt-in to new advanced features via your settings page. This will give access to more interface links, special pages, and tools. Feedback on the discussion page is appreciated. 
Due to the absence of volunteer maintenance of Cologne Blue skin, the link to activate it will be hidden. The skin will still work, but editors using it are encouraged to switch to another skin. 
Changes later this week
Due to Wikimania, there is no deployment this week. 
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 August at 15:00 (UTC). See how to join.
The “Wikidata item” link will be moved from “Tools” to “In other projects” section on all Wikimedia projects, starting on August 21st. Full announcement, Phabricator task.
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 August. It will be on non-Wikipedia wikis and some Wikipedias from 7 August. It will be on all wikis from 8 August (calendar).
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 7 August at 15:00 (UTC). See how to join.
Today everyone can see IP addresses if someone edits without an account. In the future this could be more hidden. This is to protect unregistered editors so fewer can see their IP address. This would only happen after we make sure the tools for vandal fighting can still be effective. You can read more and comment.
Editing Wikipedia with VisualEditor on the mobile web
The Wikimedia Foundation’s goal for VisualEditor this year is to create a frictionless environment for editing on mobile to help editors publish more frequently, with more joy. After brainstorming, the Foundation’s Editing team came up with a set of mobile design principles to apply to a plethora of possible design interventions. This post describes our thinking behind the first round of interventions.
Intervention 1: Manage Performance Expectations
Evaluating the user experience, we noticed that certain areas of the experience felt pretty slow to editors. While performance is something that we will continue to work on (and can really only manage to some degree as the other part of the equation is the user’s environmental bandwidth), we can make this moment feel less painful for the user by managing their expectations around performance.
The key issue here is that users aren’t given any kind of feedback during moments like these. Many folks click their edit button and see this blank white screen with a spinner.
We thought of a few different ways to address this, including microcopy telling users what’s happening, skeletons and loading screens. Ultimately, we decided to address this by creating a seamless animation transition. To do this we grey out the read mode and transition it to line up with the edit mode. Then when the editor is ready we seamlessly swap it in. We combined this with a user interface refresh to provide a more reassuring throbber and instructional microcopy. In addition to reassuring contributors, the loading overlay helps editors to maintain their focus on the edit that they initiated the editor with the intention of making.
Intervention 2: Improve Wayfinding through Section Editing
We believe that mobile editors can be more productive when they are able to focus on editing only one section at a time.
While the performance expectation intervention is in the realm of meeting fundamental expectations, the second issue we tackled is more unique to Wikipedia: navigating to your edit! One complaint that we repeatedly heard from editors during user testing was that they would find something to edit, click the edit button and then take a really, really, really long time to scroll to the part of the page that they intended to edit. This is acutely painful for users on mobile devices because the amount of information revealed to them at any given time is significantly smaller than on a desktop experience. What was happening in mobile was that you’d click a section editing button and get taken to the editing view but scrolled more or less in the proximity of the section you intended to edit.
Our intervention removed all of the other content so that you can focus on just that one specific part of the content. This directly relates to our mobile design principles — we are removing stimulation and setting the stage so that an editor can do one thing at a time.
Initial Testing Results
We tested these interventions on-wiki, on usertesting.com and, at in-person editing events. The initial feedback has been quite positive. Users have been able to maintain their location within the edit and are using words like “expected” or “obvious” when describing the behavior of the interactions.
We’ve also learned that many people expected to be able to have the functionality to edit the whole page as well as choosing to dive in and edit within sections. Additionally (while unrelated specifically to this intervention, but useful for the future iteration of the product), we observed several users attempting to switch back and forth between the different edit modes without much success.
Shipping and Next Steps
These first two interventions (the loading overlay and section editing) have already shipped to Wikipedia and, in addition to the qualitative analysis efforts that I described above, we have recently concluded an A/B test thatshowed that “contributors using Section Editing are ~3% more likely to save the edits they start than contributors using full-page editing.”
The loading overlay was deployed to all Wikipedias and the same was done for section editing after we analyzed the test results.
What’s next for VisualEditor on Mobile?
Although 3% seems like such a small increase, we are banking on lots of incremental interventions having a large collective impact. The Editing Team analyst, Neil Patel Quinn said, “Considering the difficulty of making it possible to contribute to an encyclopedia on a four-inch screen, a 3% increase from a single tweak to the interface is a real accomplishment.” The next three interventions that we are tackling are:
1. Make VisualEditor default for new users on mobile. All of our testing suggests that there are just too many steps for an editor to get into VisualEditor, which in theory, is the more new-contributor-friendly experience. Let’s lessen the burden and make VisualEditor more discoverable by openly testing out this hypothesis.
2. Make it easier to edit context items (links, citations, images, infoboxes, templates, etc.) on mobile. Editing these items is an unnecessarily complex activity. We’re creating a new part of the interface that will show additional details about, and actions related to, editable elements within articles. These interventions will help editors to focus on one thing at a time while simultaneously creating more structured workflows around specific editing tasks.
3. Make a single state toolbar. Contributors are confused about what steps to take to publish their changes, how to undo a mistake and go back without losing all of their changes, and how to get back into editing mode after “accepting changes”. That combined with the fact that contributors are confused about why the toolbar behaves in unexpected ways is why we need to refine the toolbar so that it can be used as a guidepost during editing.
A few things that you can do to help
Excited? Great! So are we. We want to collaborate with you to make this a great mobile editing experience. Here are three things that you can do right now.
Edit Wikipedia using your smartphone via the mobile web
The best way to help with this effort is to try editing on your phone. Don’t focus on the new features, just make some great additions to the encyclopedia.
After you’ve made edits or contributed in some other way on mobile, tell us about it by posting on our product page.
Incorporate user testing into an upcoming event
Do you organize events for editing Wikipedia articles? If so, we would love to collaborate with you to learn how Wikimedians are editing directly from you, so drop us a note on the Talk page.
Thanks to Ed Erhart, Peter Pelberg, Sherry Snyder, Bartosz Dziewoński, Carolyn Li-Madeo, and Ed Sanders for proofreading and feedback. Thanks again to all those who have participated as testers.
🤜🏽 David Chan, Bartosz Dziewoński, Ed Sanders, and Peter Pelberg for working on the implementation of the Wikipedia editing features described here.
Structured Data on Commons (SDC) relies on two other pieces of software to make it work: federated Wikibase and Multi-Content Revisions (MCR). Both of these things required a lot of time and resources to make them work, with federated Wikibase developed by Wikimedia Deutschland, and MCR development shared by several teams across the Wikimedia Foundation and Wikimedia Deutschland. MCR, as one of the most significant changes to MediaWiki in the past decade, underwent an extensive proposal-and-discussion period before development.
Wikibase is a free, open-source database software extension for MediaWiki developed to as part of the Wikidata project. Federated Wikibase allows a wiki with Wikibase installed (the client) to communicate back to a central Wikibase installation (the repository). In the context of the structured data project, the client, Commons, needs to be able to get and return information from the repository, Wikidata. The information Wikidata holds that Commons needs is the structure and relationship between concepts being described in files Commons. For example, if an image depicts a house cat, the labeling of “house cat” as depicted is stored on Commons, while the concept of “depicts” comes from Wikidata.
Federation means making calls from one wiki’s Wikibase instance to another to retrieve information, and those calls have the potential to end up affecting the performance of the websites. Making sure that structured data didn’t cause such a slow down was one of the challenges with federated Wikibase. Additionally, enabling cross-communication between Wikibase instances required a lot of new code changes that sometimes had surprising side effects on the host wiki. The development teams spent months finding and fixing all of these problems.
Multi-Content Revisions completely changes how pages are assembled and displayed to a user. On a wiki without MCR, a page revision – that is, the version of a page as it exists when edited and saved at a particular state in time – is stored and displayed as a single type of data, such as some form of wikitext mark-up, JSON, or Wikibase entries. Since SDC needs to store and display more than one type of revision at a time, software needed to be written to change how a page revisions work for Commons.
MCR restructures a part of how MediaWiki stores information, by adding a layer of “indirection” as a way to link between revisions with different data components. The additional layer required not only new server-side code and an interface, but a massive change in the data schema and accompanying migration to the new schema.
Since the way page revisions and the data contained were stored in the back-end, there was additional work to make this change on the front-end, facing Commons users.
Diff views have to work with multiple slots. A diff view details a revision of a page, and engineering had to be done to show diffs from multiple slots of a revision.
Multi-slot views were needed. This work parallels the work on diff views, and shows the content of all slots when viewing a revision of a page.
MediaWiki’s internal search engine, Cirrus Search, had to be engineered to work with MCR. Cirrus Search can crawl each slot, which will surface the information there to the widest possible audience. The enables semantic search of structured, linked data in files.
All of this engineering for MCR and federated Wikibase had to be completed before the Structured Data team was able to release its features to Commons. The Structured Data team is very grateful to the Core Platform, Wikidata, and Search Platform teams for all their work to make structured data storable, displayable, and searchable on Commons. With the infrastructure they created, the SDC team can create more powerful structured data features for Commons contributors.
Structured Data on Commons (SDC) is a three-year software development project funded by the Sloan Foundation to provide the infrastructure for Wikimedia Commons volunteers to organize data about media files in a consistent, linked manner. The goals of the project are to make contributing to Commons easier by providing new ways to edit, curate, and write software for Commons, and to make general use of Commons easier by expanding capabilities in search and reuse. These goals will be served by improved support for multilingual content and ways of working on Commons. This is the first in a blog series that will document the different parts of implementing SDC, starting with this introduction to the project and brief outlines of the software involved in making it happen, each to be covered more in-depth later.
Part One – an introduction to the software
Commons is built on MediaWiki, the same software used by the other Wikimedia projects. MediaWiki was primarily developed to host text. Because of this, information about files on Commons is stored in plain-text descriptions (wikitext, templates) and categories. The information includes at least the uploader, author, source, date, and license of a file, with many other optional items. These pieces of data are usually only available in one language—mostly English—and, most importantly, not structured in a way that software developers can consistently write programs to understand the data that is stored in file pages. Data that is structured in a consistent, understandable way is called “machine-readable,” and having machine-readable data is a primary goal for the Structured Data on Commons project.
In order to provide this consistent, machine-readable data, the information needs to be stored in a database instead of plain-text in MediaWiki. Wikibase is the software solution for that need. Wikibase is the software that enables MediaWiki to store structured data or access data that is stored in a structured data repository, developed by Wikimedia Deutschland to support Wikidata. The project needed a way to use Wikibase on other wikis and connect the information back to Wikidata, a feature which had recently been developed. Called Federated Wikibase, this software is crucial to organizing media information on Commons.
The next piece of software needed was Multi-Content Revisions (MCR). MCR is a way of putting a wiki page together that needs to pull information from different places with different ways of storage—in other words, MCR can assemble information from both MediaWiki and Wikibase to be displayed and managed together. More information about Federated Wikibase and MCR will be covered in a future post in this series.
Once Federated Wikibase and MCR were ready for release, the Structured Data on Commons team produced the first user-facing feature to use the new underlying software: multilingual file captions. Captions—stored in Wikibase—have a similar function to the description template used on file pages, which is stored in MediaWiki; they both are supposed to say what is in the file. However, descriptions are not limited in length, they may contain extra detail not necessary to finding the file including wikilinks and external links, and while the template supports adding extra languages, the process is not necessarily easy. Captions support an easier way to add other languages and captions are limited in length and should describe the file only in a short, factual way. This makes files with captions easier to find in search in a structured, multilingual way for both humans and software programs alike.
After releasing Wikibase and MCR to Commons with captions to make sure it all worked, the development team put out support for the first structured statement type, “depicts.” Depicts statements make simple, factual claims about the content of a file and link to their matching concept on Wikidata. To further develop depicts statements, support for qualifiers was released as well. Qualifiers allow depicts statements to have more information about what is being depicted. So for example, a picture of a black house cat can have the structured statement depicts: house cat[color:black]. Depicts statements are on a new tab that was introduced to the file page, “Structured data.” Aside from captions, all structured data is on this tab.
After this short introduction, the SDC blog series will have further information about depicts and qualifiers, as well as support for making other types of statements about files.
Usability improvements: This project will make the mobile visual editor easier to use. The goal is to let contributors stay focused on editing and to feel more confident in the editing tools.
Wikimania: Several members of the Editing Team will be attending Wikimania in August 2019. They will lead a session about mobile editing in the Community Growth space. Talk to them about how editing can be improved.
Talk Pages: In the coming months, the Editing Team will begin improving talk pages and communication on the wikis.
The VisualEditor on mobile project page is a good place to learn more about the projects we are working on. The team wants to talk with you about anything related to editing. If you have something to say or ask, please leave a message at Talk:VisualEditor on mobile.
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
The mobile web will get more advanced editing tools. Seven more Wikipedias can use them now. This works for Arabic, Indonesian, Italian, Persian, Japanese, Spanish and Thai Wikipedia. You can try the tools on the mobile web and give feedback. 
Changes later this week
The abuse filter system user will soon do maintenance edits on broken abuse filters. This user is called Abuse filter and has administrator rights. This is meant to fix technical problems. It will not do any other changes. You can read more.
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 July. It will be on non-Wikipedia wikis and some Wikipedias from 17 July. It will be on all wikis from 18 July (calendar).
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 17 July at 15:00 (UTC). See how to join.
The Wikipedia app for Android will invite users to add image captions to images on Commons. It will only invite users who have added a number of edits in the app without being reverted. This is to avoid spam and bad edits. You can read more and leave feedback.