Wikimedia Apps/Features & Roadmap

See also the Table of Platforms Supported.

WORK IN PROGRESS

How to address multiple platforms
There are many mobile platforms out there and developing a great Wikimedia experience for all of them is not trivial. Commercial developers might choose to support only those platforms offering more potential revenue but the Wikimedia project must focus on the widest reach instead. This implies supporting about 5-8 platforms, with potential variants and versions inside each.

The first question is: web based or native?


 * Web apps contain a promise of simpler cross-platform compatibility and reuse of code. Probably at the expense of a more limited feature set, a less stable ground and still a significant need of local testing and customization for specific browser engines and platforms.
 * Native apps contain a promise of full platform integration and efficiency, potentially accessing to a richer API. The drawback is the effort required to rewrite and maintain several ports of a native application.

Perhaps the solution comes from a combination of both?


 * A web app can be used to cover the basic uses cases with the goal of getting maximum reach among mobile users: access the Wikimedia content, search, tag, upload pictures, etc are use cases that potentially could be accomplished with a fairly common and cross-platform source code based on HTML5 and Javascript.
 * Native apps could have a role covering very specific and complex use cases useful for a target of contributors. The community or the Wikimedia Foundation could then commit to the development and maintenance of one upstream version focusing on the platform(s) more sensible for the specific app and the door would be open for anybody willing to maintain additional ports, based on their interest and real demand.

To be discussed.

Wikimedia services integration
Between mobile sites and apps, Wikimedia services integration offer an elegant (and usually simple to develop) way of connecting mobile users to Wikimedia projects.


 * Bookmarks in the Browser app or in the device desktop invite users to discover Wikimedia projects since the day they get their new mobile device. Idea: a single URL with browser and language detection, capable to redirect each user to the best default destination.
 * Search integration offers the possibility to define e.g. Wikipedia as a preferred or additional target. This search engine might be part of the platform's system UJI, be part or an extension of the browser, be provided by an application... Our API needs to answer the needs of the developers of these engines.
 * Share integration offers the possibility to upload content to Commons directly from the default camera app, the media player, the file manager. Our API needs to be checked against the share frameworks available in some mobile platforms.
 * Accounts integration offers the possibility to log-in users automatically and set some preferences from their mobile devices, enhancing the user experience when interacting with the Wikimedia sites and services. It would also help us gathering a bit more or registered users apps and less anonymous/IP based stats more difficult to evaluate.

The checklist:


 * Bookmark browser available out of the box.
 * Bookmark browser installable.
 * Desktop bookmark available out of the box.
 * Desktop bookmark installable.
 * Search integration out of the box.
 * Search integration installable.
 * Share integration out of the box.
 * Share integration installable.
 * Accounts integration out of the box.
 * Accounts integration installable.

First we need to do a reality check against the Wikimedia API to see what could be supported today and what would need development from our side. For that there relevant platform APIs need to be identified as well.

The pre-installed bookmarks and pre-integrated services affect the marketing of a mobile product (Wikipedia is a recognized brand) and the so-called out of the box experience. This means that even something technically as simple as a bookmark in the pre-installed browser can create a notable overhead of product management, marketing and legal work for the platform owner, the device vendor, the operator, affected apps owners and the Wikimedia Foundation too. A way to solve this is to have open licensing terms and clear developer documentation, allowing vendors interested to ahead themselves. Then, if there are gaps that the Wikimedia community want to fill, the Wikimedia Foundation could do the proactive steps talking with the relative vendors.

It is expected that most of them would welcome such integration with the cool and free Wikipedia brand as long as it doesn't cost them money and legal hassle.