I just wanted to warn everyone that metrics data is currently stalled on
the limn dashboards and only shows data prior to April 28th. This is due to
an ongoing migration of the EventLogging database servers:
http://lists.wikimedia.org/pipermail/analytics/2014-April/001909.html
Hopefully once the situation is back to normal, we should have access to
the data for all the days that are currently missing, without gaps.
Hi,
I've been playing around with gerrit over the weekend, updated the old
dashboard [1] we had, and moved it into gerrit [2].
In case someone is interested, here is the process to set it up. (Which
might not be the best way, or even the correct way - gerrit has poor
documentation, so I mostly figured it out by trial and error. Still, it
seems to work.)
The dashboard configuration files must reside in a
/refs/meta/dashboards/<dashboard
group name> branch - that much is documented clearly. [3] There is no way
in to create an empty branch on the admin interface, though, and git
reviewrefuses to work without an existing branch. One can create a
branch by
simply pushing to the remote (it doesn't even require push rights - that is
probably a bug), and the dashboards will work, but the branch ends up
broken somehow, and gerrit will be unable to push further changes into it.
The solution is to create a parentless commit locally, then push it to
refs/heads/tmp on the remote. This won't actually do anything, but gerrit
will not reject the push, which means it will store the commit object.
After this, one can create a branch through the admin interface [4], using
this commit id. The branch will not be visible in the branch listing, for
no reason whatsoever (it is visible when created by pushing directly,
and refs/meta/config
is also visible), but it will be there, and can be targeted by git review.
So the whole process looks like this:
git checkout --orphan custom-dashboards
vim my-dashboard
git commit my-dashboard
git push gerrit custom-dashboards:refs/heads/tmp
<go to the branch menu in gerrit project admin, add branch
/refs/meta/dashboards/custom with id of the above commit>
The only obstacle left is that Jenkins will freak out from changesets in
this branch, and report a merge error. I haven't figured out a way to fix
that, but the workaround described on mediawiki.org [5] works: remove the
review made by jenkinsbot, set +2/+2, click "Publish and submit".
[1] https://www.mediawiki.org/wiki/Multimedia/CR_Dashboard
[2]
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Multim…
[3]
https://gerrit-review.googlesource.com/Documentation/user-dashboards.html#p…
[4]
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Multim…
[5]
https://www.mediawiki.org/wiki/Gerrit/Advanced_usage#You_need_to_override_J…
Hi,
I noticed a bug with MultimediaViewer but I am unsure if the best way is to
fix it in MMV (in which case I would have gone to Bugzilla ;) or on Commons.
On Wikimedia Commons description pages, descriptions are usually labeled
with language templates like {{fr|blabla}} {{en|blahblah}} etc.
Example:
<https://commons.wikimedia.org/wiki/File:Axis_axis_%28Nagarhole,_2010%29.jpg
>
{{en|1=Chital (''Axis axis'') stag attempting to browse on a misty morning
in Nagarhole National Park}}
{{fr|Un cerf axis (''Axis axis'') dans le Parc national de Nagarhole
(Inde).}}
which generates the following markup :
<div class="description mw-content-ltr en" dir="ltr" lang="en"
style=""><span class="language en" title=""><b>English:</b></span> Chital
(<i>Axis axis</i>) stag attempting to browse on a misty morning in
Nagarhole National Park</div>
<div class="description mw-content-ltr fr" dir="ltr" lang="fr"
style=""><span class="language fr"
title="Français"><b>Français :</b></span> Un cerf axis (<i>Axis
axis</i>) dans le Parc national de Nagarhole (Inde).</div>
Some pages use the alternative {{Mld}} template (which IIRC implemented a
language selection feature taken from Meta, which since then was folded
back into the old way. I think. >_>).
Example:
<https://commons.wikimedia.org/wiki/File:RhB_Ge_4-4_II_Wiesener_Viadukt.jpg>
{{mld
|en=A RhB Ge 4/4 II
|fr=Une RhB Ge 4/4 II
}}
which makes the (different) markup:
<div class="multilingual">
<div class="description en lang-en" lang="en" style="margin:0.3em
0;line-height:1.2;direction:ltr;"><span class="langlabel-en" lang="en"
style="font-weight:bold;">English :</span> A RhB Ge 4/4 II</div>
<div class="description fr lang-fr" lang="fr" style="margin:0.3em
0;line-height:1.2;direction:ltr;"><span class="langlabel-fr" lang="fr"
style="font-weight:bold;">Français :</span> Une RhB Ge 4/4 II</div>
</div>
In the second case, MMV does not filter the “English” or “Français” label.
What’s the best way to deal with that? Alter the classes on Commons or add
the feature to MMV?
(Feel free to copy/paste this email to Bugzilla/MediaWiki.org if it’s a
better way to deal with this)
Thanks,
--
Jean-Frédéric
Hi there Multimedia Team!
I'm pinging you to ask how you feel about the current rollout timeline
and the imagescaler issue. Specifically: what items from the imagescaler
discussion are you planning on implementing and will that work fit in
with the current timeline?
The only real reference I have for this is:
https://etherpad.wikimedia.org/p/image-scaler-plans
Is there something better I should follow along at? Bugz or what not?
Thanks!
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi all,
I assume that the db1047 migration is over now, since I'm seeing recent
data on db1047. I was looking at data this morning and noticed that there
was a gap in the EventLogging data on db1047:
for table MultimediaViewerVersusPageFilePerformance_7907636
the id jumps from 190 to 203. You can see it for yourself by running:
SELECT id FROM MultimediaViewerVersusPageFilePerformance_7907636 WHERE id >
180 AND id < 210
After id 203 no problem, all the data is there, but we're definitely
missing data between those 2 ids. I'm certain of it because these events
come from a test that records 6 rows per run, and the one appearing at 203
is truncated, with only 4 rows.
Is the missing data on db1048 and not replicated to db1047? Or is it lost
due to writes that happened during the migration?
Since we've started tracking non-wikipedia sites like English wikivoyage,
I've had to update the URL scheme of the per-wiki limn dashboards. You can
find the up-to-date list of dashboards here:
https://www.mediawiki.org/wiki/Multimedia/Metrics#Limn
I've noticed that czwiki is empty due to lack of data (I presume that maybe
Media Viewer wasn't in beta testing there, or that traffic was so low that
nobody hit the EventLogging sampling). And fiwiki doesn't load, presumably
due to a bug because there's definitely data for Finnish wikipedia in
EventLogging. I'll look into that. All the other dashboards are fine.
I also recommend concurrently engaging Fabrice to think about contingency
plans, especially as you're looking to deploy this immanently. If you
absolutely had to cut some functionality out in order to roll this out more
broadly, what would you eliminate? It's always good to have a plan like
that in your pocket, even if you don't end up resorting to it.
If it gets close to crunch time and you need me to clear my schedule and
focus on this, let me know -- you have that lifeline too.
I hope this is helpful. I think you're doing great work and I'm looking
forward to seeing this feature graduate out of beta.
On Fri, Apr 25, 2014 at 6:27 PM, Ori Livneh <ori(a)wikimedia.org> wrote:
> On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc <gilles(a)wikimedia.org>wrote:
>>
>>
>> Are these requests done on each page view, or only once a user explicitly
>>> opens the media viewer?
>>>
>>
>> When the user opens media viewer, but there are 4 API calls per image and
>> we preload the next/previous images fairly quickly after opening one. So
>> generally within a few seconds, you're looking at 12 API calls when opening
>> Media Viewer.
>>
>
> That's way too high. Since you're planning to deploy this soon, we should
> figure out how to meet the requirements using the infrastructure that we
> have rather than the one we'd like to have. Have you considered adding a
> MediaWiki API module to your extension that composes the data into a single
> response? You could do this without duplicating code by
> constructing DerivativeRequest objects to each endpoint, as described in <
> https://www.mediawiki.org/wiki/API:Calling_internally>.
>
> If you wanted to get really creative, you could experiment with ways of
> composing the image itself into the response. One case where we are already
> multiplexing code and binary data is to be found in ResourceLoader, which
> embeds small images as data URIs in CSS. Another way to multiplex image and
> metadata is to have Swift annotate files with extra EXIF tags and parse
> those on the client. But these ideas would require a lot of exploratory
> work to determine their viability, so for now the most practical course is
> the one I described in the first paragraph of my response.
>
I've split up the Media Viewer limn dashboard into a global one and one
dashboard per pilot site. We'll shortly be adding more pilot site
dashboards. For an up-to-date list of Media Viewer's limn dashboards, visit
https://www.mediawiki.org/wiki/Multimedia/Metrics
Also in this update were new actions (no data yet since the change to
record those actions just hit master) and key percentiles, following
Nuria's recommendation, which I was able to generate with MariaDB thanks to
a horrid trick described here:
http://web.performancerasta.com/metrics-tips-calculating-95th-99th-or-any-p…
Greetings!
I’m happy to announce that we just enabled Media Viewer by default on nine more pilot sites: Czech, Estonian, Finnish, Hebrew, Polish, Romanian, Thai, Slovak, and Vietnamese Wikipedias.
1. Overview
We’re releasing Media Viewer gradually, a few wikis at a time, to test it carefully before deploying to the next batch of sites. So far, the tool has been well received on our first pilot sites: Catalan, Hungarian and Korean Wikipedias, as well as on English Wikivoyage, as outlined below. Next Thursday, we plan to deploy to some of our first large wikis: Dutch, French, Japanese, Spanish and Swedish Wikipedias. Learn more about this release plan here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
2. Metrics
We’re now logging about 336,000 image views per day on a global basis, as shown on this graph:
http://multimedia-metrics.wmflabs.org/dashboards/mmv
About half of these views are coming from the Hungarian Wikipedia, and the rest from Wikimedia Commons, English Wikipedia and other pilots. More metrics dashboards are available for selected sites on this page:
https://www.mediawiki.org/wiki/Multimedia/Metrics
3. Performance
We are now tracking image load performance globally, and fist results suggest that images take over a second to load on average (50th percentile), but can take up to 5 seconds when looking at worst case for most users (90th percentile), as shown in this graph:
http://multimedia-metrics.wmflabs.org/graphs/mmv_performance_image_global
We’re also encouraged by early comparisons of the time it takes to open an image with Media Viewer versus on a Commons File, the current default: the mean load times for these two methods seem to be very close, on the order of 2-3 seconds on a cold cache, as shown in this preliminary graph:
http://multimedia-metrics.wmflabs.org/dashboards/mmv#media_viewer_vs_file_p…
4. Surveys
We are now running surveys in multiple languages, to validate whether or not this feature is useful to readers and editors alike. Overall response so far is generally favorable. Here are the current results:
* English Survey: 64% find the tool useful, 12% don’t find it useful, 24% are not sure (50)
* Hungarian Survey: 47% find the tool useful, 47% don’t find it useful, 5% are not sure (268)
* Catalan Survey: 62% find the tool useful, 15% don’t find it useful, 23% are not sure (13)
We’re also starting new surveys in French, German and Portuguese. You can find links to live results and comments from all these surveys here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey#Results
5. Usability
For the past few months, we have been running a series of usability studies, with positive results. Testers are typically able to complete most common tasks successfully, and they have helped us find new ways to improve the user experience for areas they found confusing.
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Usability_testing
6. Your feedback
How can we improve Media Viewer? Are there any critical issues that should be addressed for this first release? Please let us know what you think of this tool — and join other users from around the world on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
We’d also be grateful if you could take this quick survey, to let us know how Media Viewer works for you. It only takes a minute and means a lot to us:
https://www.surveymonkey.com/s/media-viewer-1?c=email
Many thanks to all the team and community members who made this launch possible!
Enjoy,
Fabrice — for the Multimedia Team
P.S.: New improvements take about 2 weeks to get deployed to all wikis. If you would like to test the latest version of Media Viewer, follow the test tips on this demo page on MediaWiki.org:
https://www.mediawiki.org/wiki/Lightbox_demo
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
.jpg){kind=link}
