Page MenuHomePhabricator

[Wikidata] Tracking UI interaction
Open, Stalled, HighPublic

Description

It may make sense to split this task when it comes to implementation..
Everything explained below has an inherent, make some way to display the data... (grafana)

JavaScript events can be tracked directly to graphite using https://www.mediawiki.org/wiki/ResourceLoader/Modules#mw.track
We would want to track events as counters (implementation example on the wikipage)
https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.statsd.js#L43-59

Track every click to an edit link

As far as I know this can be done somewhere in jquery.wikibase.edittoolbar.js, potentially with the "afterstartediting" event.
event.target could be used to track the type of edit link.

The resulting metric name should be something like"wikibase.ui.event.edit.start.TYPE"

Track every render of the Special edit pages

This should be split up:

  1. The UI edit links should also contain a parameter, for example http://localhost/w/index.php/Special:SetLabelDescriptionAliases/Q12/en-gb?fromUI=1 fromUI can then be checked in the PHP and calls with this parameters can be tracked, as "wikibase.ui.specialpage.uimiss.TYPE"
  2. The special pages should also contain a small amount of JS code to track users using the special page when they have JS. Something like "wikibase.ui.specialpage.js.TYPE"
  3. The special page should also track the number of calls regardless of the fromUI parameter existing or not. "wikibase.ui.specialpage.all.TYPE"

The three change above would allow the tracking of:

  • Special page usage vs JS UI usage
  • People that choose to use the Special pages (both with and without JS)
  • People that end up on the Special pages due to clicking before the JS has loaded fully

Track errors surfaced throguh the UI

These could be tracked in the JS, although it may make more sense for these to be tracked in PHP in the API.
It could be possible to distinguish API calls that are made by the UI vs API calls made by bots if an extra parameter is passed to the UI, perhaps fromUI=1 again as mentioned above.
Error counts of key errors could then simply be sent to statsd in PHP.
Example metric name could be: "wikibase.api.error.NAME"

Track usage of key gadgets

With the JS tracking needed in the first point I imagine some nice methods will be used similar to the example linked.
This could allow gadget to record the number of clicks on key buttons (such as opening the gadget)
Firstly this should be done with the LabelLister gadget
For example: "wikibase.ui.gadget.NAME.EVENT"
Note: we don't really want to track very much here, at most 1 or 2 key events per gadget...."

Track collapses & expands

Very similar to the first point expands and collapses of sections should be recorded.
This should again be recorded with the type of element being expanded or collapsed.
For example: "wikibase.ui.event.expand.TYPE"

Event Timeline

Addshore created this task.Feb 1 2016, 5:20 PM
Addshore raised the priority of this task from to Needs Triage.
Addshore updated the task description. (Show Details)
Addshore added subscribers: Addshore, Lydia_Pintscher.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptFeb 1 2016, 5:20 PM
Lydia_Pintscher triaged this task as High priority.Jun 11 2017, 6:04 PM
Addshore changed the task status from Open to Stalled.Feb 28 2018, 1:01 PM
Restricted Application added a project: Design. · View Herald TranscriptJul 22 2018, 9:18 AM

Adding WMDE design people as this ticket will probably interest them (feel free to untag if it does not)