Page MenuHomePhabricator

Investigate mobile map gadget for eventlogging
Closed, DeclinedPublic

Description

We should look at what has been done in this code and see what we'd want to capture, via event logging, for this feature if it would go live: https://en.wikipedia.org/wiki/MediaWiki:Gadget-mobilemaps.js

Add gadget to your enwiki account:

mobile-web-maps-gadget-preferences_page.jpg (995×1 px, 810 KB)

and then go to en.m.wikipedia.org and see this (when searching on articles that have coordinates, ie: https://en.m.wikipedia.org/wiki/Denver

Screen Shot 2017-08-10 at 4.01.02 PM.png (472×610 px, 108 KB)

Screen Shot 2017-08-10 at 4.01.18 PM.png (658×586 px, 505 KB)

Event Timeline

I'm looking at various maps grafana dashboards, amongst others:
https://grafana.wikimedia.org/dashboard/db/julien-maps-dashboard?orgId=1

And I notice that collection of event logging seems to have broken down in late july ??

@TheDJ - unfortunately, we have a bug that we're trying to get fixed so that new data is shown on all the dashboards: T173333.

I'm looking at various maps grafana dashboards, amongst others:
https://grafana.wikimedia.org/dashboard/db/julien-maps-dashboard?orgId=1

And I notice that collection of event logging seems to have broken down in late july ??

We deprecated/discontinued the scripts that calculated metrics for Grafana. For Maps metrics, please refer to https://discovery.wmflabs.org/maps/, which we're currently having issues with but hope to fix very soon (as Deb mentioned).

We're also working on adding interaction/usage metrics (like the ones seen in https://people.wikimedia.org/~bearloga/reports/maps-usage.html & https://people.wikimedia.org/~bearloga/reports/maps-interactions.html) to that dashboard.

@TheDJ Event logging would be quite an undertaking, but we can start with tracking tiles requested specifically by the gadget (as opposed to mobile web in general). When the gadget (or leaflet, maybe?) makes the API calls to Kartotherian for the tiles, do you use a custom user agent or are you able to specify one? Because if you can specify a custom user agent, on our side we can then look for that UA specifically when we count tiles served. A good UA would include name of gadget & URL or your name & contact info, for example.

This wouldn't be tracking interactions, but if we can start counting tiles served to instances of the gadget specifically, it would be a proxy for usage and would be a good first step.

https://en.wikipedia.org/wiki/MediaWiki:Gadget-mobilemaps.js

It's already partially logged, since it's just calling out to existing kartographer code. I just disabled the mw.track's when i copied the code from the maplink modules, because I didn't want it to pollute those events. We could of course adapt Schema:Kartographer, but I was considering using that "extra" field that the schema has and use that to differentiate between maplinks from the default module, and maplinks triggered by this gadget..

This is also why i can't add user agents strings etc, the Kartographer code doesn't give me access to that level of interaction.

Ah, got it. Cool, that makes things easier! Yeah, adding some kind of a marker to the extra field somewhere in https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.kartographer.js#L141--L232 would be the way to go.

This was my idea:
https://en.wikipedia.org/w/index.php?title=User:TheDJ/Gadget-mobilemaps.js&diff=797987134&oldid=797985056

This is similar to how the layer information is being passed for the wikivoyage tracking events. Note that this is just my sandbox version of the gadget, not live yet.

Seems there is a bug in the existing event logging that we should probably also fix in that case...

Change 378522 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/extensions/WikimediaEvents@master] Kartographer: Capture geohack variant

https://gerrit.wikimedia.org/r/378522

Change 378522 abandoned by TheDJ:
Kartographer: Capture geohack variant

https://gerrit.wikimedia.org/r/378522

Declining for now but open to re-opening in the future if the parent task is re-opened and this work is needed.