Fabrice Florin | 24 Apr 23:08 2014
Picon

Media Viewer Launches on More Pilot Sites

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:
We’re now logging about 336,000 image views per day on a global basis, as shown on this graph: 

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: 

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: 

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:

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:

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)
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Gergo Tisza | 23 Apr 20:55 2014
Picon

Weekly Multimedia team update

Hi all,

another week, another update; a little sooner this time, as we are adjusting our sprint schedule to have more distance between the sprint end and the automatic deployment day, now that MediaViewer is going into production.

== MediaViewer pilot ==

MediaViewer has been enabled last Thursday on the Catalan, Hungarian and Korean Wikipedia and the English Wikivoyage. You can find some numbers in the announcement we recently sent to this list [1]. This Thursday, it will be enabled on the Czech, Estonian, Finnish, Hebrew, Polish, Romanian, Slovak, Thai and Vietnamese Wikipedias. For our full release plan, see [2].

== Work done last week ==

We have fixed some bugs reported in the pilots: the scroll position being lost [3], no scrollbar for the survey on Firefox [4], captions not displayed for images in galleries [5]. The license name now links to the license deed, not the file page, whenever possible [6]. We did some improvements to performance (both real and perceived): there is less parallel loading [7], the progress bar appears sooner and is more visible [8][9]. Last but not least, we improved our metrics considerably - we track more kinds of events [10]; following the Analytics team's recommendation, we switched from arithmetic to geometric means, resulting in much cleaner charts [11]; we track loading speeds in the slower percentiles (slowest 10% and 1% of users) [12].

== Work planned for this week ==

As mentioned on this list recently [13], the image scalers have buckled under the load after a number of large TIFF images from a GLAM content donation have been uploaded; we will investigate how to prevent that in the future [14].
For MediaViewer, there are no major new features planned for this week; we have some performance improvements coming up [15], we will continue improving the metric dashboard [16][17], improve our test coverage [18], fix some minor bugs [19][20][21][22][23], and be ready to handle whatever comes up in the pilots.

== Contact ==
As always, comments, criticism or suggestions are welcome, on this list, or at the MediaViewer discussion page [24], or on the IRC channel #wikimedia-multimedia <at> Freenode.


_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Gilles Dubuc | 23 Apr 18:06 2014
Picon

Re: [Multimedia-Alerts] browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-firefox - Build # 1 - Failure!

Hi Antoine,

Looks like we'll soon be running cucumber tests on our own infrastructure, right? Exciting!

I had a glance at the error and I think it might be this option preventing our test from running:
--tags <at> firefox
Because our basic E2E test doesn't have that tag.


2014-04-23 13:58 GMT+02:00 jenkins-bot <nobody <at> integration.wikimedia.org>:
FAILURE: browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-firefox Build #1 (Wed, 23 Apr 2014 11:58:39 +0000)


_______________________________________________
Multimedia-Alerts mailing list
Multimedia-Alerts <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia-alerts


_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Gilles Dubuc | 23 Apr 01:48 2014
Picon

More Media Viewer dashboards + percentile data

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-percentile-with-single-mysql-query/
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Fabrice Florin | 22 Apr 19:12 2014
Picon

Media Viewer Metrics Dashboards

Hi team,

Here are the projects we propose to track next with our Media Viewer metrics dashboards:
* de - German
* he - Hebrew 
* ko - Korean 
* pl - Polish
* pt - Portuguese
* English Wikivoyage

I have updated this metrics ticket #476 which Gilles created, so we can track Media Viewer metrics on these sites:

The purpose of this task is to monitor activity in key sites where Media Viewer is deployed (or coming soon), so we can evaluate its impact on both community and performance. My selection criteria for this second batch include:
* diverse mix of languages and sizes
* already on first pilots list (or coming soon)
* active relation with community champions

Any other important sites we should track right away — or in the next batch? We are already tracking commons, en, fr, hu and mediawiki. For the next batch, I propose the following large Wikipedias: es, hi, it, ja, ru, zh — plus any other sites you guys think we should track.

Thanks,


Fabrice




On Mon, Apr 21, 2014 at 2:23 AM, Gilles Dubuc <gilles-AeOJrEpdGNeGglJvpFV4uA@public.gmane.org> wrote:
Gilles how much work is entailed in creating dashboards for each major language? If there is any chance we could do more of them? What would be a reasonable amount on your end? It would also be great if we could accelerate this metrics update task, so it would give us and our community champions more visibility sooner on what’s happening on these sites.

I think one dashboard per site makes sense, plus a global one, instead of the current setup where each tab is a long list of graphs. It would also allow us to have per-site maps. Setting this up would be an initial 3 points, and 1 point every time we want to add (an) additional site(s). If new ones come later, it's better to do them as a batch, because what makes it time-consuming is updating all the different parts and having them reviewed, but the task itself isn't complicated.

I've created a card for it:https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/476  if you want more sites than commons, en, fr, hu and mediawiki, please update the ticket.



Thanks, Gilles, much appreciated.

I will update the ticket with recommended additional sites to track, for consideration at Wednesday’s sprint planning meeting.

_______________________________

Fabrice Florin
Product Manager
Wikimedia Foundation




_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Fabrice Florin | 22 Apr 03:11 2014
Picon

Media Viewer Surveys

Hi folks,

I wanted to share the first results of our Media Viewer surveys (1), which started last week in three languages: English, Hungarian and Catalan. (2) (3) (4)

* Hungarian Survey: 42% find the tool useful, 51% don’t find it useful, 6% are not sure (159 responses)
* English Survey: 62% find the tool useful, 10% don’t find it useful, 27% are not sure (37 responses)
* Catalan Survey: 50% find the tool useful, 25% don’t find it useful, 25% are not sure (8 responses)

I just compiled comments from the Hungarian Wikipedia (3), which suggest that these are the most frequent requests on that site:
* Too slow (17)
* Blurred images (6)
* More image sizes (4)
* Can't see images (4) 
* Return where I clicked on article (scroll bug, now fixed) (5)

We are now using this feedback as a guideline for improvements to make as we approach wider deployment. Note that this survey is aimed at all users, not just editors, so we can get feedback from other viewpoints than those already expressed on our talk page. For example, about 61% of respondents on the Hungarian survey so far have never edited Wikipedia. 

Next, we will start surveys in French, German and Portuguese — and perhaps a few more languages, as requested by community champions for large wikis. Hearing from readers around the world helps complement the feedback we get from experienced editors on our talk pages, to give us a more comprehensive perspective from all of our users.

As discussed earlier, we would now like to invite respondents to leave their email address at the end of the survey, if they are open to being contacted about their comments. For example, our team would like to follow up directly with users about image load issues, to find out why some of these images are taking so long to load.

Our legal team thinks it is reasonable for us to collect email addresses for WMF team follow-ups, as covered by our feedback policy, which specifically says "If you submit an email address, we may use it to communicate with you and send you updates on your feedback.”

Community members on this thread, would it be all right with you if we retained these email addresses for two years? Their emails would be kept private, in accordance with our Privacy Policy, and will only be used by the Wikimedia Foundation to follow up with them about this or related multimedia products. One thing we don’t do enough with our users now is to check back with them a year or so later, to see how they like the product.

Thanks for your constructive guidance, as always!

All the best,


Fabrice

_______________________________

(1) Media Viewer Survey:

(2) English Survey:

_______________________________

Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation




_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Gergo Tisza | 21 Apr 08:56 2014
Picon

New gerrit dashboard

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 review refuses 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".




_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Ori Livneh | 21 Apr 08:04 2014
Picon

Brief image scalers outage, Mon Apr 21 03:12 UTC

The number of Apache busy workers on the image scalers spiked between 2:55 and 3:15 UTC, peaking at about 3:12 and overwhelming rendering.svc.eqiad.wmnet for about a minute.

The outage correlates fairly well with a spike of fatals in TimedMediaHandler, consisting almost entirely of requests to this URL: <http://commons.wikimedia.org/w/thumb_handler.php/2/2c/Closed_Friedmann_universe_zero_Lambda.ogg/220px--Closed_Friedmann_universe_zero_Lambda.ogg.jpg>.

The full stack trace is included in <https://bugzilla.wikimedia.org/show_bug.cgi?id=64152>, filed by Reedy yesterday. It appears File::getMimeType is returning 'unknown/unknown' and that File::getHandler is consequently not able to find a handler.
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Gergo Tisza | 21 Apr 03:36 2014
Picon

Help us collect more information about the speed of MediaViewer

Hi all,

we have gotten lots of reports that it can take very long for MediaViewer to display (unblur) the images (some people mentioned 20-30 second waiting times); our tests and metrics [1], on the other hand, show 1-2 second loading times. We need to find out under what conditions does the application become so slow; if you experience something like that, or know other people who have experienced it, please help us collect more information.

Ideally, we would like to know the following:
- how long did it take for the image to load? (time spent between clicking on a thumbnail, and the blurry image becoming sharp)
- can you reproduce the slow loading time with other images? (Use images from a different wiki page, so that they are not preloaded)
- can you reproduce the slow loading time with same image, after refreshing the page with a clear cach (Ctrl-F5 on most browsers)?
- what OS/browser do you use?
- what kind of internet connection do you use, what bandwidth does it have?

If you are comfortable with using the network tab on the web console of your browser (F12 on most browsers), and can look at it and tell us in detail which requests took up the majority of the loading time, that would be even more helpful.

You can report the results here or on-wiki at [2].

Thanks in the name of the multimedia team!


_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Ori Livneh | 21 Apr 01:23 2014
Picon

TimedMediaHandler and startup scripts

Hello,

The 1.23 release of MediaWiki deprecates the ResourceLoaderGetStartupModules hook which TimedMediaHandler / MwEmbedSupport depend on. See <https://bugzilla.wikimedia.org/show_bug.cgi?id=63240> for details.

I'd like to accelerate the complete removal of this hook. It was created as a special kludge for MwEmbedSupport, with the expectation that it would be used only on pages which require the extension, and only until MwEmbedSupport could be refactored to be in-line with other MediaWiki extensions. Instead, MwEmbedSupport uses it to load five modules on every single page: 'jquery.triggerQueueCallback', 'Spinner', 'jquery.loadingSpinner', 'jquery.mwEmbedUtil', and 'mw.MwEmbedSupport'. (A sixth module, 'mw.MwEmbedSupport.style', is also added to every page, but by different means.)

This has been the status quo for just under three years, now: commit dc5c9fe9efa, which added "TODO look into loading this on-demand instead of all pages", was merged in June 2011.

Could the multimedia team please make this a priority? I'd recommend using the opportunity to fold MwEmbedSupport support into TimedMediaHandler. MwEmbedSupport passes itself as a generic module-loading framework, but three years in, TimedMediaHandler remains its single application.

The relevant bugs are:


I can't imagine it's too much fun to wade into these problems, but we need to fix this, finally. I would be happy to help.
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Gergo Tisza | 18 Apr 00:39 2014
Picon

MediaViewer URL format

Hi all,

we have just deployed a new URL format for MediaViewer [0], I am submitting it here for comments and for the benefit of people who have to do something similar in other contexts.

MediaViewer stores the name of the image in the hash part of the URL so one can share links to a page with a specific image open in the lightbox. (We considered using the History API [1] to change the path or the query part, but that degrades poorly.) I have looked at three options:
  1. Just put the file name as-is (with spaces replaced by underscores) in the URL fragment part.
    Pro: readable file names in URLs, easy to generate.
    Con: technically not a valid URI. [2] (It would be a valid IRI, probably, but browser support for that is not so great, so non-ASCII bytes might get encoded in unexpected ways.) Creates nasty usability and security issues (injection vulnerabilities, RTL characters, characters which break autolinking). Would make it very hard to introduce more complex URL formats later, as file names can contain pretty much any character.
  2. Use percent encoding (with underscores for spaces).
    Pro: this is the standard way of encoding fragments. [2][3] Always results in a valid URI. Readable file names in Firefox. Easy to generate on-wiki (e.g. with {{urlencode}})
    Con: Non-Latin filenames look horrible in any browser that's not Firefox.
  3. Use MediaWiki anchor encoding (like percent encoding, but use a dot instead of a percent sign).
    This would have the advantage that links can be generated in wikitext very conveniently, using the [[#...]] syntax. Unfortunately the way MediaWiki does percent encoding is intrinsically broken (the dot itself does not get encoded, but it does get decoded when followed by suitable characters, so file names cannot get roundtripped safely), so this is not an option.
We went with option 2, so URLs look like this:



One issue that we ran into is that window.location.hash behaves weirdly with percent-encoded hashes in Firefox [4], but that's easy to avoid once you know about it. Other than that, it seems to work reliably.


_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia

Gmane