Wikimedia Apps/Features & Roadmap

See also the Table of Platforms Supported.

WORK IN PROGRESS

New features
Some lousy thoughts...

w:Help:Mobile_access shows an interesting table of no less than 36 Wikipedia based apps for the iPhone. Some excellent (like Wikihood, awarded in Germany), some probably less impressive. But *none* of them able to edit or (apparently) bring any significant contribution to the Wikimedia projects other than hits and traffic.

An official Wikipedia app should probably concentrate on what is more likely to benefit the Wikipedia project and what is also less likely that third party developers will focus on: contributions.

We need to have a prioritized list of simple features, implying one hand use and simple or no typing. A first attempt:


 * "Share this" like WikiNews does.
 * Watch an article - simple way to get readers progressively involved.
 * Patrol a new article - could be suggested by the app.
 * Geotag an article - maybe there is a way to offer suggestions.
 * Assess the relevance / importance of an article - app could suggest
 * Upload and embed a picture to a page - implementation might be tricky.
 * Add a comment in the discussion page - rather than applying templates directly.
 * Let SuggestBot to suggest me a mobile task - (with some fine tuning of the bot this could be a stand-alone mobile app in itself)
 * Spellchecking - highly automated, engine tbd.

Something against vandalism would be nice? Although the implementation might be tricky since there is not 100% automatic cure.

Same about categorization, notability and dead-end pages. Fixing them right is not simple and mobile, casual edits can cause more pain than healing.

More features could be extracted from http://en.wikipedia.org/wiki/Category:Wikipedia_backlog

There is also low level hanging fruit in the Community Portal: learn more about Wikipedia, Things to do, RSS feed of The Signpost...

Out of Wikipedia, Wikinews feed + rating looks also like a perfect match.

Let's have more ideas, without forgetting to focus the scope and concentrate on the implementation of top 3 features to start with.

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.