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. The Wikimedia project must focus on the widest reach. This implies supporting about 5-8 platforms, with potential variants and versions inside each.

We are proposing a dual approach to survive in this mess:


 * A generic Wikipedia mobile app written in HTML5/CSS/Javascript should offer the basic functionality and be ported easily to as many platforms as possible.
 * Specialized tools requiring features not covered by the "web app" toolkits can go native and target a specific platform. Ports to other platforms can be made on the basis of community offer and demand.

Rationale
w:Help:Mobile_access shows a bunch of Wikipedia based apps for the iPhone (including the official one) but all of them are read only. An official Wikipedia app should also provide the means to contribute casually & on the go.

This is the type of app we are after:


 * Browsing content in your preferred language is easy and fun.
 * Also playing and storing media files in your device.
 * Offers information relevant to your preferences and location.
 * Invites to share articles & media with your friends.
 * Saves bookmarks and full content for later/offline reading.
 * Easy contributions: rate an article, fix a typo, geolocate an article, upload & embed a picture, undo last change...
 * Suggestions: rate this article, patrol this new article, this article needs improvement.
 * Notifications: you've got a message!, watchlist update.

Not all this needs to be on the first day! See below for features specified and in their way for implementation.

Features committed
Someone is planning to deliver these:


 * None yet.

Wishlist
Someone is looking at the appropriateness and feasibility of these. Add and sign your proposals at the bottom, ideally linking them to a wiki page pr bug report with all the details.


 * "Share this" like WikiNews does.--Qgil 21:47, 14 April 2011 (UTC)
 * Android's 'intents' system makes this very easy to do and integrate with other apps (email, twitter & facebook & statusnet clients, notetaking apps, etc). iOS requires you to manually figure out the available URL schemes for other apps, and doesn't let you check what apps are available. Painful but key apps can be listed this way. Unfamiliar with other OSs, but they likely have similar facilities whether expansive as Android or primitive as iOS. If triggered from an HTML UI, Android needs to hook into the native OS; iOS can probably do it from browser with clickable URLs. --brion 22:50, 15 April 2011 (UTC)
 * Watch an article - simple way to get readers progressively involved.--Qgil 21:47, 14 April 2011 (UTC)
 * Watch/unwatch is a simple API hit, so easy to do with authentication setup.
 * Patrol a new article - could be suggested by the app.--Qgil 21:47, 14 April 2011 (UTC)
 * Geotag an article - maybe there is a way to offer suggestions.--Qgil 21:47, 14 April 2011 (UTC)
 * Assess the relevance / importance of an article - app could suggest--Qgil 21:47, 14 April 2011 (UTC)
 * Upload and embed a picture to a page - implementation might be tricky.--Qgil 21:47, 14 April 2011 (UTC)
 * Can upload via API fairly easily; main difficulty is integrating with licensing template schemes and such if uploading to a Wikimedia site. Adding image to a page can be done with a simple page edit in API, but positioning it nicely might need some magic. --brion
 * Add a comment in the discussion page - rather than applying templates directly.--Qgil 21:47, 14 April 2011 (UTC)
 * Using newsection edit on the talk page would be relatively simple. Longer-term, needs integration with future version of LiquidThreads etc.
 * 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.--Qgil 21:47, 14 April 2011 (UTC)
 * Most OSs will have some spelling tools available in the system input methods, usually tied into the keyboard language features, so this is probably not a high priority. --brion
 * Something against vandalism would be nice? Although the implementation might be tricky since there is not 100% automatic cure. --Qgil 21:47, 14 April 2011 (UTC)
 * Same about categorization, notability and dead-end pages. Fixing them right is not simple and mobile, casual edits can cause more pain than healing.--Qgil 21:47, 14 April 2011 (UTC)
 * More features could be extracted from http://en.wikipedia.org/wiki/Category:Wikipedia_backlog--Qgil 21:47, 14 April 2011 (UTC)
 * There is also low level hanging fruit in the Community Portal: learn more about Wikipedia, Things to do, RSS feed of The Signpost...--Qgil 21:47, 14 April 2011 (UTC)
 * Out of Wikipedia, Wikinews feed + rating looks also like a perfect match.--Qgil 21:47, 14 April 2011 (UTC)
 * See other editors in the map / near you. Open to editors willing to take part. "Editors you follow"...--Qgil 21:47, 14 April 2011 (UTC)
 * Ogg Vorbis, Theora and/or WebM playback for OSs that don't natively provide it (eg iOS). Unless Wikimedia starts serving MP4 transcodes, most non-Android devices won't have native support for these, but ARM-optimized decoders are available and playback could be embedded. --brion 22:59, 15 April 2011 (UTC)

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.
 * Consider implementing OAuth for API access; advantages in avoiding exposing passwords directly to client apps (an app's authorization can be revoked separately), and potential ability to provide read-only or otherwise limited access. --brion 22:57, 15 April 2011 (UTC)

See the table of integrated services in each mobile platform.