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.

Features assumed
Feasibility looks ok - commitment is missing.

Browsing
 * Search by keywords.
 * site search or search within article being viewed?
 * Recently browsed articles.
 * -> keeps local history
 * Jump to related categories & external links.

Localization
 * Content of all Wikipedia languages renders correctly.
 * Fonts can be an issue; iOS and Android seem to have good text rendering but sometimes need to pull in web fonts; the web views can do this for us if all the right info is tied in, but if doing offline reading consider that local copies of fonts might need to be kept. Other OSs unknown support; note that Indic scripts for instance are complex and require a modern text rendering system that understands glyph shaping and such.
 * Text input (e.g. for search) works for the languages supported in the device.
 * The web-based supplementary input methods like Narayam can help with this, but only within a web view where they're running. If there are native text input fields they wouldn't benefit from that unless we replicate how it works. Should test and confirm how well this works with the on-screen keyboards.
 * Default language is the one used in the device.
 * Registered user can change preferred language in Settings.

Multimedia
 * Audio and video content can be streamed & downloaded.
 * 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)

Authentication
 * Registration of new account.
 * Global log-in.
 * Check profile (User page + Talk:User page).

Watching
 * Watch/unwatch articles.
 * Watch/unwatch is a simple API hit, so easy to do with authentication setup.--brion 22:59, 15 April 2011 (UTC)
 * "Favorites" = Watchlist mobile UI

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)
 * 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
 * We can start with the most evident use case to start with: user uploads a picture taken by himself with a CC-by-sa license to a page with no pictures, placing it to the top-right. Once this works, creating a select menu for the obvious alternative licenses is simple. Maybe an option could be given to place the picture in a specific section of the page?--Qgil 17:36, 18 April 2011 (UTC)
 * 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)
 * Landing page based on Last news + On this day + Featured article + Pic of the day + Media of the day.--Qgil 20:23, 19 April 2011 (UTC)
 * Can be tricky for languages other than English? Are all the homes using the same conventions?--Qgil 20:23, 19 April 2011 (UTC)
 * "Related articles"--Qgil 20:23, 19 April 2011 (UTC)
 * This would be "What links here", stripping away user pages, talk pages, Wikipedia pages, category pages... leaving only the genuine links between articles.--Qgil 20:23, 19 April 2011 (UTC)
 * Search articles by location around you.--Qgil 20:23, 19 April 2011 (UTC)
 * Depends on maps and location API - is this generally covered for web apps in different devices?--Qgil 20:23, 19 April 2011 (UTC)
 * Search articles by location pointing to a specific place in the World map.--Qgil 20:23, 19 April 2011 (UTC)
 * Same problem as above (articles around you).--Qgil 20:23, 19 April 2011 (UTC)
 * Limit searches & browsing to pages with a degree of quality: featured, A, B...--Qgil 20:23, 19 April 2011 (UTC)
 * Edit profile - mobile features.--Qgil 20:38, 19 April 2011 (UTC)
 * Template to easily fill your User page. Some info could be retrieved from the device?--Qgil 20:38, 19 April 2011 (UTC)
 * Insert user banners to User page browsing them as a gallery.--Qgil 20:38, 19 April 2011 (UTC)
 * Location of user updated in User page whenever new location info is available: "Last time I checked I was near town in country."--Qgil 20:38, 19 April 2011 (UTC)
 * Automatic update of "Pictures I have uploaded (optional: from my device)"--Qgil 20:38, 19 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.