Multimedia April 2014

multimedia@lists.wikimedia.org

41 participants
48 discussions

Moving Images and the (Digital) Humanities - Monday, May 5, Columbia University
by pbk＠intelligenttv.com 30 Apr '14

30 Apr '14

Hi: "Moving Images and the (Digital) Humanities" Monday, May 5 - Columbia University http://ccnmtl.columbia.edu/midh A select few seats & a few rafters still available - please contact me if interested. Cheers! -- Peter. Peter B. Kaufman President and Executive Producer INTELLIGENT TELEVISION & THE INTELLIGENT CHANNEL YouTube.com/intelligentchannel COLUMBIA UNIVERSITY CENTER FOR NEW MEDIA TEACHING & LEARNING ccnmtl.columbia.edu/staff/kaufman Direct: (212) 316-5494 Mobile: (917) 969-7756 Twitter: @INT_Channel intelligenttelevision.com Watch for more! Now available: RUSSIA"S OPEN BOOK: WRITING IN THE AGE OF PUTIN Hosted by Stephen Fry - on the Intelligent Channel and PBS nationwide: http://youtu.be/vRPDM7OTMrI http://www.openculture.com/2013/12/stephen-fry-profiles-six-russian-writers…

1 0

Metrics currently stalled
by Gilles Dubuc 30 Apr '14

30 Apr '14

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.

1 0

New gerrit dashboard
by Gergo Tisza 29 Apr '14

29 Apr '14

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…

1 1

MultimediaViewer & language labeling filtering
by Jean-Frédéric 28 Apr '14

28 Apr '14

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

3 2

Plans re rollout and imagescalers
by Greg Grossmeier 28 Apr '14

28 Apr '14

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 |

2 1

Gap in EventLogging data on db0147
by Gilles Dubuc 28 Apr '14

28 Apr '14

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?

2 1

Updated per-wiki metrics dashboard URLs
by Gilles Dubuc 28 Apr '14

28 Apr '14

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.

2 2

Re: [Multimedia] [Ops] Caching API responses
by Ori Livneh 25 Apr '14

25 Apr '14

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

1 0

More Media Viewer dashboards + percentile data
by Gilles Dubuc 25 Apr '14

25 Apr '14

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…

5 6

Media Viewer Launches on More Pilot Sites
by Fabrice Florin 24 Apr '14

24 Apr '14

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)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Multimedia April 2014