The Ellora Caves in India – uploaded via mobile!

In the fall of 2012, the Wikimedia Foundation’s mobile team released a new interface to Wikimedia mobile sites, adding a navigation layer that allows for easy opting-in to our experimental Beta site.

We created the Beta site as a prototyping area to house early work on features that could help us meet our goals for 2012–2013, which are to get 1,000 mobile users to upload a file to a Wikimedia project every month, and to explore mobile editing and other contributions to the encyclopedia. The Beta site is giving us room to unleash the full creativity of our engineers and designers without disrupting the user experience for millions of readers.

Since the release of the new interface, the number of users opting into Beta has increased dramatically—we now have over 100,000 Beta users and climbing! If you’re one of our Beta users and you’ve signed up for a free account on Wikipedia or a sister project, you’ll see the following prototypes live and ready for testing:

1. Photo uploads. With the help of volunteer developers at the Bangalore hackathon and inspired by the Wiki Loves Monuments initiative, we’ve made it fast and easy to add an image to a Wikipedia article directly from your image library or the camera on your mobile device. Just look for the call to action at the top of articles that lack images in the lead section. Not only will you be illustrating the encyclopedia, you’ll also be donating your image to Wikimedia Commons under a free license, where it can be shared and reused by anyone in the world for free.

2. Editing. Our goal for editing on mobile this year was to begin experimenting with a mobile editing interface for small, on-the-go contributions, like correcting typos or removing vandalism, and we’ve released a section-level editor on Beta that allows for that. In the future, we’ll be working to make editing more fine-grained, as well as optimizing the interface, so that it’s easier to input text on a smaller screen.

3. Watchlists. The watchlist—a feed of recent changes to articles that a user chooses to “watch”—is vital to the health of Wikipedia content. It’s how experienced editors track changes to the pages and discussions they care about, and it helps keep vandalism and spam at bay. We’re trying out ways to serve this need for our current editors on mobile. We’re also experimenting with a watchlist view for new editors who may not be familiar with the feature, which presents the user with an engaging entry point into articles and highlights their continually evolving nature.

If you don’t have a Wikipedia account, create one on desktop or mobile and give these features a try! Just be aware that, as with all things Beta, features are prone to rapid change as we work to fix bugs and optimize the user experience.

In the coming months, we’ll be running user tests and collecting data on feature usage to help us figure out what’s working and what’s not. Ultimately, we aim to identify and promote the most promising experiments to the main mobile gateway and/or create apps that focus on specific contribution funnels. Our goal for the long term is to give potential and new editors the opportunity not just to read Wikipedia, but to take an active part in its continued growth.

Maryana Pinchuk, Associate Product Manager

De mica en mica s’omple la pica i de gota en gota s’omple la bota. —a Catalan proverb

During its most recent development sprint, the Wikimedia Foundation’s Language Engineering team continued to improve the user experience of the Translate extension to make it as smooth and efficient as possible. Highlights include:

• Pressing the “Save” button immediately shows the next string to translate, while the saving is performed in the background.
• When progressing to the next translation, the page smoothly scrolls up.
• Explanations about translatable strings are shown beside the corresponding message in a convenient box, which becomes expandable if the documentation is too long.
• Machine Translation was made available for suggested translations.
• The differences between older versions of translatable strings are also shown in a new expandable box.
• The Language Selector API was updated to allow displaying all the documentation strings.
• The Solr search engine schema was tweaked to make searching translatable strings more efficient and feature-rich by offering faceted search.

Below is a brief demo of the latest features of the translation editor in action. You can see translating the Etherpad Lite project into Russian there.

The Language team also continues to work on squashing bugs and adding prioritized features. You can check out the latest bleeding edge version of the translation editor on translatewiki.net, or go back to the stable translation editor. Please report Translate bugs in Bugzilla.

Amir E. Aharoni, Software Engineer (Internationalization)

Major news in December include:

• The launch of an alpha, opt-in version of the VisualEditor to the English Wikipedia, a project more complex than it appears;
• A research study on the use of the Article Feedback feature;
• New metrics for the MediaWiki community;
• The start of the Outreach Program for Women;
• Continued work to improve the workflow and interface for translators.

Note: We’re also proposing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.

(more…)

(Emor me’at ve-ase harbe. —a Hebrew proverb)

The Wikimedia Foundation’s Language Engineering team is continuing the makeover of the Translate extension, which started taking shape in early December. (Introduced in 2011, this MediaWiki feature powers the translation of Wikipedia’s software, announcements, reports and fundraising banners, and of other sites and software projects.)

During its latest two-week sprint, the team improved the actual interface used for submitting and editing translations:

A screenshot of the new work-in-progress translation editor

Information about the message and translations to other languages are now shown in a collapsible box on the right side of the translation area. Warnings about potential errors in the message are shown in a small box above the editing area, which is expandable, too.

The functionality for saving and skipping messages was updated. Usability testing observations by Arun Ganesh and Pau Giner suggest that users facing a hard part in a translation are more likely to just skip it than to report the problem. Because of this, skipping a message is now recorded and frequently skipped messages will be considered for re-wording.

In the next sprint the team will work on polishing the translation interface further: better display of documentation, translation suggestions and diffs, better responsiveness, more robust language selection and other features.

In other Language Engineering news:

• The December 2012 version of the MediaWiki Language Extension Bundle was released.
• Better support for language variants and alternative language codes was added to the Universal Language Selector.

Amir E. Aharoni, Software Engineer (Internationalization)

(This guest post comes from David Narváez, one of the organizers of Wiki Loves Monuments in Panamá. You can see the winning photos from the country here.)

El Cementerio de Corozal, 2nd Place, WLM Panamá

I started off by building our site using WordPress, the blog and content management system every volunteer in the team learned to tweak and love. We could have gone with other free software content management systems we are more used to, like Drupal, but we figured out that using the same technology most other countries were using for their WLM sites would help us leverage theme expertise from larger organizations.

WordPress provided a large set of plugins that helped us build a very dynamic website with just a few clicks, and most important of all, we were able to provide it in Spanish almost without any effort thanks to the great work of the internalization team for WordPress.

With the site online, we started thinking about putting the large plugin database to good use. One thing that came up was the idea to show the list of monuments that we built for WLM Panama in an interactive map using Open Street Map. While the toolbox for Wiki Loves Monuments already included such a map, by the time we started looking for a way to display our monument list, the WLM map did not work with our list. Because we needed to put the map online sooner rather than later, we decided not to wait for the toolbox map. We found the Fotomobil.at OSM Plugin, which lets you provide a text file that specifies all marks in the map, but we still needed an automated way to build the list of markers from the Mediawiki table on Spanish Wikipedia. After a lot of search (and I mean a lot of search), we found the Pijnu/Mediawiki-Parser tandem to parse the Mediawiki text and look for title, image, location and description of the monuments.

Once the site was complete, the next challenge was to develop a jury tool that would let juries browse the photos in the two categories we had, with monuments grouped by geographical location, EXIF metadata information for each photo and a simple account system. I ended up writing a web application, heavily based on the Dojo Javascript Toolkit. The database with the information for this tool was also provided by parsing the information from our list of monuments, but with the additional requirement of actually fetching the photos in various sizes. For this task, I went back to a project I was already familiar with: the MediaWiki API Client for Python.

One last task we needed to undertake was to move all of the photos uploaded to the contest through Flickr to Commons. Our obvious way to do this was to use the Flickrripper bot from the Python Wikipedia Robot Framework. Despite the issues we found with Flickr’s API, we managed to do a lot of our task using a patched version of Flickrripper. And speaking of API failures, I must add that during the whole process we never had a single glitch, or an unmet requirement from Wikimedia’s API, so I must stand up and congratulate the team of system administrators behind the Wikimedia projects.

In the aftermath of the event, after enjoying a very interesting prize ceremony, reading articles about WLM in our local newspapers, taking a break from the hard work around WLM and planning for next year, I’m starting to take on the large path of patches, integration code and development to collaborate with the many Open Source projects that made this a successful event for us. We are also contributing with donations to some of the projects that were key to our success, and expect to keep this tradition in years to come.

David E. Narváez, Wiki Loves Monuments, Panamá

At the beginning of this year, we launched Wikipedia Zero with the aim of reducing barriers to accessing knowledge on mobile devices. Many people in the developing world use mobile phones as their primary–or only–means to access the Internet. Through partnerships with telecommunications companies, Wikipedia Zero removes the cost of data as an obstacle between individuals and the power of knowledge.

There are close to 6 billion mobile subscriptions in the world, but less than 600 million broadband connections, or 1/10th. Broadband connections are relatively scarce in developing countries, with less than 5 connections per 100 people, but there is nearly one mobile subscription per every single person on the planet [1].

As mobile becomes more of a ubiquitous access point in developing countries, it has immense potential to bring knowledge to many people who previously had limited means to access information. We’ve repeated this message throughout the year, and I wanted to share some data that substantiate our target for the Wikipedia Zero program. Below is a list of the top 25 most mobile-centric countries, meaning those that have the highest ratio of mobile to overall traffic on Wikipedia:

Top mobile countries to Wikipedia.

Of the top 25, there are 22 countries classified as developing. Twelve of them, including all of the top 8, are in Africa. Even more telling is that 16 of these countries have mobile usage percentages greater than 20 percent. Compare that to the global average of 11.5 percent–and 15.6 percent in the U.S.–and you get a sense for how much potential mobile has to change the world.

In 2012, we announced Wikipedia Zero partnerships in 31 developing countries. Eleven of those have launched so far, and from what we’ve seen, they’ve had measurable impact. In 2013, we plan to bring a lot more partners and countries on board, many of them on the list above. We expect the percentages in the list to increase even more next year, and we hope that our efforts help drive the accessibility and awareness of Wikipedia to accelerate the trend.

(Special thanks to volunteer Kajari Ghosh for helping compile this data.)

Amit Kapoor, Senior Manager, Mobile Partnerships

[1] http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats/a#subscribers

This feedback form engages readers to contribute to Wikipedia

How can we engage readers to contribute productively to Wikipedia?

Our recent work on Article Feedback v5 (AFT) provides new insights on that question. In this post, we’d like to share what we’ve learned by analyzing feedback and moderation activity — as well as give a quick update on our next steps for this project, which is being developed by the Wikimedia Foundation’s editor engagement team.

Article Feedback v5 aims to increase participation on Wikipedia (a strategic goal of the Wikimedia movement): this tool asks readers to suggest improvements to articles, then invites them to sign up and become editors. Another goal of this project is to help current editors improve article quality based on reader suggestions. (Learn more about Article Feedback.)

Last summer, we deployed this new tool on 10 percent of the English Wikipedia and we have been testing it extensively to evaluate its impact on readers and editors. Here’s what we found so far.

Slides from the AFTv5 report (2012-Q4)

Key findings

These highlights of our latest research on Article feedback are based on feedback and moderation data collected from September 7 to November 7, 2012 (more details can be found in these slides):

Many readers use this feature

Readers are already posting a lot of feedback with this tool — an average of 4,100 posts per day from 2,800 daily unique readers, on just 10 percent of the English Wikipedia. At this rate, we project up to 900,000 feedback posts with comments per month once Article Feedback is deployed to 100 percent of English Wikipedia in 2013. About 98 percent of this feedback is from anonymous users who are not currently participating on Wikipedia. About 70 percent of the readers we surveyed liked this feedback tool after using it. Their responses suggest that it makes it easy for them to get involved and that they enjoy doing it.

This tool is converting readers into new editors

Article Feedback appears effective in getting new users to contribute to Wikipedia. For example, 2.7 percent of readers who post feedback go on to create a new account, after being invited to sign up. And 3 percent of these new users go on to edit articles within 24 hours from signing up. At this rate, we project several hundred thousand new registrations per year on the English Wikipedia — resulting in many new contributors, which we hope can help reverse the current editor decline.

Useful feedback is buried under a lot of noise

In our first feedback evaluation study last spring, we asked 20 Wikipedia editors to blindly assess 900 random feedback posts for usefulness. About 40 percent of the feedback was found useful by at least two evaluators. This finding is consistent with this moderation data, which shows more negative than positive evaluations by community moderators. We also found that most of the moderation takes place on high traffic articles, which attract lower quality feedback. (To get a sense of what comments look like on a recently created article, check out the feedback page for the Sandy Hook Elementary School shooting article.)

Most feedback never gets moderated

Editor moderation activity is very low when compared to the volume of feedback posted every day. Less than 10% of all posts for a sample of the 100 most visited articles are moderated by registered editors within a month. In fact, less than 10% of feedback posted every single day receives any kind of moderation within a month, whether by readers or registered editors. In the current version of the tool, many editors can’t easily find comments for articles they edit, an issue which could be addressed by making feedback more visible to editors on the article pages.

More results can be found in these slides, which summarize our analysis of feedback and moderation data. Live moderation data can also be viewed on this dashboard.

Next steps

Mockup of new moderation tools and filters under consideration.

Based on our these findings, we are now developing a final version of Article Feedback 5, which we plan to release in early 2013. Our goals for this release are to:

• surface more good feedback
• reduce the editor workload
• improve software performance.

Here are some of the key features we are working on:

Better feedback filters

We are improving our filtering tools to automatically surface more good feedback and remove irrelevant comments. For example, the new feedback page will only feature comments that have been marked as helpful — and feedback that has not yet been moderated will be listed in a separate filter. We are also creating more abuse filters to prevent users from posting inappropriate comments.

Simpler moderation tools

To reduce the editor workload, we are simplifying the feedback moderation tools. These new tools will enable moderators to quickly sort feedback into different groups, so that editors can focus on useful suggestions for improvements, without being distracted by comments that are not usable. We also plan to make useful feedback more visible to editors, through a special link on article pages.

Improved performance

We are refactoring our code to make this tool more scalable so it can support millions of comments with better database performance. This backend engineering work has taken longer than anticipated, in order to provide a solution that can be used by other projects.

Once these features have been developed, we plan to test them on 10 percent of the English Wikipedia, then release them to 100 percent in the first quarter of 2013. We expect more projects to deploy Article Feedback after this full release. For example, the German Wikipedia has already started a pilot to evaluate this tool on their site, and a similar pilot is under discussion on the French Wikipedia. For now, we invite you to try out Article Feedback for yourself on this sample article.

We would like to thank all the Wikipedians who have helped us design and develop Article Feedback this year. We look forward to deploying it widely early next year, to encourage more participation from readers. We hope this engagement tool can help sign up new contributors, to revert the editor decline and provide new ways for users to improve Wikipedia together.

Happy holidays!

Fabrice Florin, Product Manager
Dario Taraborelli, Senior Research Analyst
Oliver Keyes, Community Liaison
Wikimedia Foundation’s Editor Engagement Team

Ei kannata mennä merta edemmäs kalaan. —a Finnish proverb

The Translate extension, a central piece in the puzzle that makes Wikipedia and the community around it massively multilingual, is getting a major overhaul.

“Translate”, as it’s commonly called, powers the translation of Wikipedia’s software, announcements, reports and fundraising banners, and of other sites and software projects. It focuses on making the translators’ work easy, efficient and, if possible, fun. The software gets frequent under-the-hood updates, and now the time has come for a major overhaul of its most visible part: the translation user interface.

Arun Ganesh and Pau Giner, from the Wikimedia Foundation’s Language Engineering team, have studied the current translation workflow by testing the software and interviewing translators. They drafted new interface ideas and tested experimental designs with users who speak different languages and have different levels of experience with the translation functionality.

In the team’s thirtieth two-week coding sprint, which ended last Tuesday, two major components of the overhaul have taken shape: the message group selector and the list of translatable messages.

The Message group selector. Message groups are groups of related translatable messages: a software project, a multilingual blog post or announcement, etc.

The group selector helps a translator find a project to translate using a tree-like structure of groups and sub-groups. Every project shows the completeness of the translation using a colorful progress bar. For quick and easy access to the projects that interest the translator, there’s a tab that shows recently used projects, and a responsive search function.

Listing of translatable interface message for the Visual Editor. Some messages are translated to French and some need review.

The list of strings to translate has been redesigned to improve clarity, making it easier to scan and distinguish between messages that are translated, untranslated and need to be updated (“fuzzy”).

The development of the improved user experience continues. In the next sprints, the team will complete these features and add new ones, such as an improved sign-up process and better search. Usability testing efforts will continue to ensure that the new designs provide an improved experience. If you are interested in trying the new translation tools, please volunteer for our usability testing sessions.

Other ways to connect with the Language Engineering team:

• Pau Giner and I will present on multilingual user testing and internationalization “dos and don’ts” in the live broadcast Wikimedia Open Tech Chat on Thursday, December 13 at 20:30 UTC.
• We’ll hold IRC Office Hours on Wednesday, December 17 at 17:30 UTC. Topics of discussion will be the translation user experience improvements, Universal Language Selector and general Q&A.

Amir E. Aharoni, Software Engineer (Internationalization)

Yesterday we launched 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.

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. We also want to get their thoughts on what aspects should be 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 alpha VisualEditor 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 two weeks to the wikis, allowing you to give us feedback as we go, and tell us what you want us to work on next.

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 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.

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.

James Forrester, Product Manager, VisualEditor and Parsoid

“Live bird”, an illustration by Kim ‘Isarra’ Schoonover, one of Wikimedia’s interns for the Outreach Program for Women.

I’m glad to announce that Kim Schoonover, Mariya Miteva, Priyanka Nag, Sucheta Ghoshal, Teresa Cho and Valerie Juarez will join the MediaWiki community as full-time interns between January and March 2013. They have been selected as part of the FLOSS Outreach Program for Women, an initiative of the GNOME Foundation, with participation by several other free software projects: Deltacloud, Fedora, JBoss, Mozilla, Open Technology Institute, OpenITP, OpenStack, Subversion, Tor and Wikimedia. A total of 25 women have been selected in this edition.

Each MediaWiki intern will work on a specific project:

• Kim Schoonover (aka ‘Isarra’) is a Wikipedia contributor based in Colorado (USA) with an interest in user experience and design. She has contributed a few patches to MediaWiki projects already. She will work on design documents for Flow, the planned UI for user discussion pages, mentored by Brandon Harris and Heather Walls.
• Mariya Miteva is a Masters of Information Systems Student in New York (USA), although she is originally from Sofia (Bulgaria) and will conduct her internship from there. She will find MediaWiki vendors and define the best ways to work with them, and will also have a backlog of product management tasks. Her mentors are Sumana Harihareswara and James Forrester.
• Priyanka Nag is a Computer Science post-graduate student from Pune (Maharashtra, India). She will work in the documentation of noteworthy local templates, gadgets and styles used in various Wikimedia projects, mentored by Amir E. Aharoni.
• Sucheta Ghoshal is a Computer Science and Engineering student based in Kolkata (West Bengal, India), an active Wikipedia contributor and member of the Wikimedia Kolkata meetup. She will work on the productization of EtherEditor MediaWiki extension. She will be mentored by Mark Holmquist.
• Teresa Cho has double major in Computer Science and Economics and she lives in Redwood City (California, USA). Her project consists of developing a MediaWiki extension to interact with Git repositories, and is mentored by Sébastien Santoro.
• Valerie Juarez has a BS in Computer Science and she lives in Sour Lake (Texas, USA). She will help managing the bug reports, organize a couple of “Bug Days” and will develop a proposal for streamlining user feedback from multiple Wikimedia sources. She will be mentored by Andre Klapper and Quim Gil.

Our mentors assisted about 25 women interested in the MediaWiki community during the application process. From those, 10 submitted full applications, including a project proposal and a microtask completed as part of the submission. We were impressed by the quality of many submissions, but we couldn’t take more due to lack of related mentors and funding. We encourage all applicants to stay around in the MediaWiki community, since we have no doubt they can all become top contributors and have future opportunities.

In addition to the availability of specialized mentors and the quality of the proposals, our selection criteria took into account the diversity of profiles, origins and previous involvement in Wikimedia projects. We had a rather open process for submissions and selection of candidates that gave participants a chance to check other proposals, improve their own and receive public endorsements.

We wish a happy landing to our new interns and the best of luck in their projects! You’ll be hearing more from them over the next few months.

Quim Gil, Technical Contributor Coordinator