Hi guys,
Last year we build the Wiki Loves Monuments mobile app [1]. In my
opinion this was a good learning experience. The app suggested monuments
to take photographs of based on you location. This information was
coming from the monuments database [2] using the api we build for that
purpose [3]. The monuments database contains over a million items [4],
but the data isn't very clean and i18n was an issue. We had to do a lot
of hacking to compensate for that.
So we need a better structured source of this information and we now
have that: Wikidata. Wikidata doesn't support coordinates yet, but
that's just a matter of time. At some point in the future it will be
possible to get coordinates for an item. If we harvest these items with
coordinates and make them searchable by location (point/bounding box)
using for example Solr/Lucene, we could have a suitable backend for the
mobile app to get information from. This wouldn't just be monuments, but
every item with coordinates. We started a task force [5] to import as
much data as possible about our cultural heritage, thus making the
Monuments database in its current form obsolete.
User story would be something like this: A user would have a way in the
app to find things to take photographs of in the app. User selects an
object, takes a photo. The fields are already filled out with the
information from Wikidata. The photo is uploaded to Wikimedia Commons
and tagged with a template like {{Depicts Wikidata|Q12345}}. This
template can be used by the bot operators on Commons to enhance the
metadata of the image (for example adding better categories).
Are ideas like this on the roadmap for the mobile app? Do you think I
missed something here?
Maarten
[1] http://www.mediawiki.org/wiki/Wiki_Loves_Monuments_mobile_application
[2] https://commons.wikimedia.org/wiki/Commons:Monuments_database
[3] http://toolserver.org/~erfgoed/api/api.php
[4] https://commons.wikimedia.org/wiki/Commons:Monuments_database/Statistics
[5] https://www.wikidata.org/wiki/Wikidata:Cultural_heritage_task_force
Since I started working on MediaWiki in the mobile team a common
complaint has been "why do I have to make my homepage mobile friendly"
(especially during Wikimania 2012). As background - currently Main
Pages have to be marked up specially for mobile [1].
Although I share the hate (this has been a long standing bug [2]) - if
I'd been around in the early days would have prevented from happening
- I believe people are more inclined to fix ugly broken things then
fix things that do the job.
The main problem here is that the majority of wiki projects have
homepages that are extremely badly written for mobile. There are
various hacks that we can do our end but there is no guarantee these
will work on older phones without a massive rewrite. The main
offenders are typically inline styles which are near impossible to
predict/override/control (many people familiar with me know all about
my vendetta against them [4]) and the use of tables which are also
problematic on mobile.
Luckily with a recent change it's now easier to see what is wrong with
your favourite Wiki homepage even after lots of hacks from our end. If
you opt into the experimental mode [4] and visit the home page it will
no longer be special cased and inline styles on it will be scrubbed
with javascript enabled...
I'd encourage anyone who cares about killing this 'feature' of
MobileFrontend with fire to reassess their favourite homepages.
Suggested actions after opting into experimental mode:
* Disable javascript and see what your homepage looks like with inline
styles - edit the main page to make any inline styles that involve
pixels or %s's more mobile friendly and where possible and reusable
move these inline styles to css rules in MediaWiki:Common.css which is
not run on mobile.
* Add the class nomobile to elements which should not be shown on mobile.
If there is enough traction/interest here I'd be keen to make no
special casing an opt in configurable global feature. It would be nice
to have consistent mobile and desktop views. If there's no interest
that's cool as well - it just means I can resolve this long standing
bug as RESOLVED WONTFIX :)
Let me know either way... FWIW Wikivoyage and Wikipedia are almost
there in terms of mobile friendliness without any special casing...
[1] http://meta.wikimedia.org/wiki/Mobile_Projects/Mobile_Gateway#Mobile_homepa…
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=30405
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=35704
[4] https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto…
The "add image to article" functionality in the mobile view is such an
awesome idea. I liked it so much I created a simple page suitable for
viewing on a mobile device that highlights local articles that need an
image:
http://inkdroid.org/ici/
It uses geonames' wikipedia api to figure out what articles are
relevant to your current location, and then the Wikipedia API
(currently just en) to determine if the article needs an image. In the
process I noticed that some articles that lack images but don't have
the handy "add image to article" button. For example:
https://en.m.wikipedia.org/wiki/Coastline_%28sculpture%29
Would it be difficult to add image upload support for articles like this?
//Ed
Did the core change https://gerrit.wikimedia.org/r/#/c/60954/ get deployed?
I'm still seeing gadget errors on the mobile site from these scripts
amongst others and wondering whether I should reopen the bug [1]:
*https://en.m.wikipedia.org/w/index.php?title=MediaWiki:Gadget-metadata.js&action=raw&ctype=text/javascript&421724048
*https://en.m.wikipedia.org/w/index.php?title=MediaWiki:Gadget-edittop.js&action=raw&ctype=text/javascript&553824600
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44918