User:Qgil-WMF/Old

w:User:Qgil

Working at Nokia as MeeGo advocate and interested in contributing to the Wikimedia projects on Mobile stuff. A first mission could be to push the development of a Qt Quick app for MeeGo and Symbian devices.

Below you have some mobile related topics that I'm cooking here before finding a better place for them.

= Wikimedia @ Mobile = Mobile stuff ;) has become a strategic topic for the Wikimedia Foundation and the community. Currently (March 2011) there is a lot of information scattered and here are some pointers I'm keeping for myself and whoever is interested:


 * Mobile relative actions agreed in the new Strategic Plan or the MWF.
 * Strategic opportunity: Mobile section in the Product Whitepaper, part of the new Wikimedia strategy.
 * Mobile access status from the point of view of mobile browsers and apps (contains info decently updated).
 * Mobile is the central point of anything related to the Wikimedia mobile sites.
 * Translating:Wikimedia_mobile is useful to see the languages/communities interested in good mobile support.
 * Current mobile apps projects: Wikipedia iPhone app (official) and WikiSnaps (community/inofficial, for iPhone with an Android port in the works).
 * Mobile @ Wikimedia - Past, Present, and Future are PDF slides by Tomasz Finc (February 2011) summarizing all of the above.

Language support
The ability to read and write Wikimedia content is a first premise, critical for those languages using scripts with poor or no commercial support. Installing fonts and language packs can be trickier or even impossible in certain mobile platform. As a rule of thumb, cheaper devices have a more restricted expandability - and many times are those cheap devices the ones most commonly used by the speakers of those unsupported languages...

Language support includes many areas and actually some of the most demanding for a device vendor (e.g. all pre-installed apps localized in language XX) are not critical for Wikimedia projects. What really matters for us is:


 * Fonts supported in browser.
 * Possibility to install additional fonts.
 * Text input supported.
 * Possibility to install additional virtual keyboards.
 * Text prediction supported.
 * Possibility to install additional predicted languages.
 * Dictionaries supported.
 * Possibility to install additional dictionaries.

It would be useful to have a table showing the languages/fonts/keyboards supported and available as installable in different platforms - if it doesn't exist somewhere already. I can start searching the Nokia specific information, which would cover already a nice % of mobile users - especially in the territories where the less supported scripts are natively used. The table could highlight the platforms / vendors / models that are expandable, inviting the respective Wikimedia communities to find their software development counterparts in order to collaborate in new language support packs. Commercial parties might be interested in getting involved as well.

Note that the data might get complicated. Some languages might be supported in a device purchased in Country X but then not available and not installable in the same model purchased in Country Y. The same platform might have devices that are expandable and models that are not - this may even xhanges for a same model from country to country, from operator to operator. Third parties may offer their own input methods, text prediction and dictionaries with a different set of languages supported. Still it's worth to start mapping the defaults, and we will see how to deal with the exceptions.

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.

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

Apps
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, which is the one the friend that lent me an iPhone uses all the time, pretty cool), 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.

So, I believe that our future Qt app for Wikipedia should actually 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.

I have more ideas, but I rather focus the scope and concentrate on the implementation of top 3 features to start with.