Fabrice Florin | 1 Oct 21:23 2014

Warning users when they click to enlarge huge images

Hi guys, 

Geni brought up a good point that Media Viewer doesn’t provide a warning when users click to enlarge huge files (e.g.: 400 Mb) on our talk page:

This is not a new issue, as this is the same functionality we have provided for years on the File: page. But Media Viewer makes it a lot easier for users to accidentally load a huge file. So I think we should seriously consider providing a warning, if it is easy to implement and if we can identify a threshold that is based on data and that is acceptable to our communities.

Do any of you have data on what the threshold might be for identifying file sizes that might crash your browser? Or do you know what best practices are on that point? It would be good if we could agree on a limit that is at least partly informed by data. 

If there is no reliable data or best practices, we might have to determine this threshold together arbitrarily, based on common sense. In that case, what do you think would be a reasonable threshold when we would start giving the warning? 50Mb or above? 100Mb or above?

For now, I just filed this ticket #933 to track this issue:

Thanks for any recommendations you might have,



Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Fabrice Florin | 1 Oct 01:19 2014

Media Viewer Update: First Improvements

Hi folks,

I am happy to announce that we have just released a first round of improvements to Media Viewer, based on community feedback.

The goal for these improvements is to make Media Viewer easier to use by readers and casual editors, our primary target users for this tool. 

To that end, we created a new 'minimal design’, with these features:
* "More Details” button: a more prominent link to the File: page
* separate icons for “Download" and "Share or Embed" features
* an easier way to enlarge images by clicking on them
* a simpler metadata panel with fewer items
* faster image load with thumbnail pre-rendering

These features are now live on Wikimedia Commons and sister projects (1), and will be deployed on all Wikipedias this Thursday by 20:00 UTC.

Next, we plan to work on these other improvements:
* an easier way to disable Media Viewer for personal use
* a caption or description right below the image

Learn more about these features on the Media Viewer Improvements page (2). They are based on findings from our recent community consultation (3) and ongoing user research (4). For more information, visit the Help FAQ page (5).

Please let us know what you think of these new features on the Media Viewer talk page (6). 

We would like to thank all the community members who suggested these improvements. Our research suggests that they offer a better user experience, that is both clearer and simpler -- and that clarifies the relationship between Media Viewer and the File: description page. 

We will send another update in October, once the next round of improvements has been released.


Fabrice and the Multimedia Team

(1) Pictures of the Day on Commons: 

(2) Improvements page:

(3) Community suggestions:

(4) User Research:

(5) Help page:

(6) Talk page:


Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
James Heald | 30 Sep 02:21 2014

Inclusion criteria for Wikidata items for paintings, engravings, illustrations, manuscript folios, photographs, old postcards, etc ?

Hi everybody,

With the Structured Data for Commons project about to move into high 
gear, it seems to me that there's something the Wikidata community needs 
to have a serious discussion about, before APIs start getting designed 
and set in stone.

Specifically: when should an object have an item with its own Q-number 
created for it on Wikidata?  What are the limits?  (Are there any limits?)

The position so far seems to be essentially that a Wikidata item has 
only been created when an object either already has a fully-fledged 
Wikipedia article written for it, or reasonably could have.

So objects that aren't particularly notable typically have not had 
Wikidata items made for them.

Indeed, practically the first message Lydia sent to me when I started 
trying to work on Commons and Wikidata was to underline to me that 
Wikidata objects should generally not be created for individual Commons 

But, if I'm reading the initial plans and API thoughts of the Multimedia 
team correctly, eg

there seems to be the key assumption that, for any image that contains 
information relating to something beyond the immediate photograph or 
scan, there will be some kind of 'original work' item on main Wikidata 
that the file page will be able to reference, such that the 'original 
work' Wikidata item will be able to act as a place to locate any 
information specifically relating to the original work.

Now in many ways this is a very clean division to be able to make.  It 
removes any question of having to judge "notability"; and it removes any 
ambiguity or diversity of where information might be located -- if the 
information relates to the original work, then it will be stored on 

But it would appear to imply a potentially *huge* increase in the 
inclusion criteria for Wikidata, and the number of Wikidata items 
potentially creatable.

So it seems appropriate that the Wikidata community should discuss and 
sign off just what should and should not be considered appropriate, 
before things get much further.

For example, a year ago the British Library released 1 million 
illustrations from out-of-copyright books, which increasingly have been 
uploaded to Commons.  Recently the Internet Archive has announced plans 
to release a further 12 million, with more images either already 
uploading or to follow from other major repositories including eg the 
NYPL, the Smithsonian, the Wellcome Foundation, etc, etc.

How many of these images, all scanned from old originals, are going to 
need new Q-numbers for those originals?  Is this okay?  Or are some of 
them too much?

For example, for maps, cf this data
, each map sheet will have a separate Northernmost, Southernmost, 
Easternmost, Westernmost bounding co-ordinates.  Does that mean each map 
sheet should have its own Wikidata item?

For book illustrations, perhaps it is would be enough just to reference 
the edition of the book.  But if individual illustrations have their own 
artist and engraver details, does that mean the illustration needs to 
have its own Wikidata item?  Similarly, if the same engraving has 
appeared in many books, is that also a sign that it should have its own 
Wikidata item?

What about old photographs, or old postcards, similarly.  When should 
these have their own Wikidata item?  If they have their own known 
creator, and creation date, then is it most simple just to give them a 
Wikidata item, so that such information about an original underlying 
work is always looked for on Wikidata?  What if multiple copies of the 
same postcard or photograph are known, published or re-published at 
different times?  But the potential number of old postcards and 
photographs, like the potential number of old engravings, is *huge*.

What if an engraving was re-issued in different "states"  (eg a 
re-issued engraving of a place might have been modified if a tower had 
been built).  When should these get different items?

where I raised some of these issues a couple of weeks ago, there has 
even been the suggestion that particular individual impressions of an 
engraving might deserve their own separate items; or even everything 
with a separate accession number, so if a museum had three copies of an 
engraving, we would make three separate items, each carrying their own 
accession number, identifying the accession number that belonged to a 
particular File.

(See also other sections at 
https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Visual_arts for 
further relevant discussions on how to represent often quite complicated 
relations with Wikidata properties).

With enough items, we could re-create and represent essentially the 
entire FRBR tree.

We could do this.  We may even need to do this, if MM team's outline for 
Commons is to be implemented in its apparent current form.

But it seems to me that we shouldn't just sleepwalk into it.

It does seem to me that this does represent (at least potentially) a 
*very* large expansion in the number of items, and widening of the 
inclusion criteria, for what Wikidata is going to encompass.

I'm not saying it isn't the right thing to do, but given the potential 
scale of the implications, I do think it is something we do need to have 
properly worked through as a community, and confirmed that it is indeed 
what we *want* to do.

All best,


(Note that this is a slightly different discussion, though related, to 
the one I raised a few weeks ago as to whether Commons categories -- eg 
for particular sets of scans -- should necessarily have their own 
Q-number on Wikidata.  Or whether some -- eg some intersection 
categories -- should just have an item on Commons data.   But it's 
clearly related: is the simplest thing just to put items for everything 
on Wikidata?  Or does one try to keep Wikidata lean, and no larger than 
it absolutely needs to be; albeit then having to cope with the 
complexity that some categories would have a Q-number, and some would not.)

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Gergo Tisza | 27 Sep 17:40 2014

UploadWizard funnel - findings and next steps

Hi all,

a little more detail from the funnel analysis of UploadWizard (if you haven't been following the other funnel thread, [[mw:UploadWizard/Funnel_analysis]] has a quick summary).

Users repeat the upload process many times

The main thing I am trying to understand at this point is why people use the "upload another file" button so much. UploadWizard allows uploading up to 50 files at the same time, which should be more then enough for the average user, but our click-tracking data shows that most people click through the tutorial-file-deed-details-thanks screens, then click on the upload more button (which effectively resets the process and starts again from the file screen), then click through the screens again, then click on the upload more button again, then do the same again, and again, and again. (Doing this fifty times in a row is not uncommon.) This suggests some fundamental failing in UW - Sage suggested it is the instability of uploading more than a few files at the same time. I wonder if others have relevant experience?

Errors do not seem to be the main problem

I have tried to identify the reason for failed UploadWizard sessions (a series of UploadWizard events logged on the same page which are not terminated by reaching the thanks page) by checking what the last event was, and assuming that for failed sessions caused by errors, that error would be the last event. Assuming this is sound, errors do not seem to be the main problem - they only appear at the end of ~25% of the failed sessions (which is ~8% of the total sessions).

Top errors

That said, here is a list of error codes (these are mostly API error codes, but a few are internal to UploadWizard) sorted by frequency, collected over ~1000 sessions:

| filename             |    20 |
| badtoken             |    19 |
| missingresult        |    14 |
| title                |    13 |
| publishfailed        |    11 |
| stasherror           |     7 |
| server-error         |     3 |
| fileexists-forbidden |     2 |
| filetype-banned-type |     1 |
| unknown              |     1 |
| verification-error   |     1 |
| unknownerror         |     1 |

A little explanation about the more frequent ones:
  • filename: these seem to be user errors - most often invalid filetype (doc, bmp etc), sometimes no extension at all or trying to add the same file twice.
  • badtoken: some sort of CSRF token expiration; bug 69691
  • missingresult: returned by the upload API in the details step when the uploaded file has gone missing; bug 43967
  • title: an error about duplicate files (i.e. the same file already exists on Commons) that somehow happens in the details step instead of the file step.
  • publishfailed: this seems to be some sort of race condition: first api call to publish a file from stash puts it into the job queue and sets it status to pending, second call will throw this error.
  • stasherror: could be lots of things. bug 56302bug 54028 and more.

Some suggestions based on the findings so far

Quick wins:
  • review UX for "fatal user errors" (i.e. when UploadWizard says "you can't upload this file type") - is the error message helpful?
  • review and improve api error messages (api-error-*), possibly override them with UW-specific ones. Do they identify next steps? Do they even exist?(e.g. api-error-publishfailed does not.)
  • renew token on badtoken error (bug 69691)
  • make sure that the specific error message thrown by ApiUpload::dieUsage gets logged somewhere. Currently we only log a generic message derived from the API error code, so e.g. all the dozen different UploadStashException subclasses are reported with the same message.
  • poll for success on publishfailed error (unlike its name suggest, it seems to be actually meaning something like "publish in progress")
Medium wins:
  • understand better why people repeat the upload process so often. This might reveal serious UX deficiencies or functional errors (e.g. in an older thread about funnel analysis, Sage claims uploading more than three files at the same time is too unreliable for him).
  • Investigate if there is a low-effort way to recover entered details when the upload process has to be restarted. (There are drop-in solutions like garlic.js or sisyphus.js but the very dynamic nature of UW forms might be a problem.)
  • figure out why are some title errors only reported in the details step
  • log information about uploaded files to better identify size- or filetype-specific issues
Bigger / longer-term effort:
  • figure out a way to retry when the user already entered all the details but publishing the file failed. (This points towards the per-file-workflow-instead-of-global-workflow direction.)
  • make stashed / async uploads rely on the database instead of the session (bug 43967)
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Rob Lanphier | 26 Sep 02:49 2014

From the MW Core Backlog....

Hi folks,

There's an item that's Luis Villa added to the MW Core backlog that I'd like to move to the Multimedia backlog:

I'm assuming everything that he describes fits nicely into what is planned for Structured Data.  Assuming that's true, should I just copy/paste into a new card in Mingle, or a new page on mw.org or what?


Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Russavia | 19 Sep 12:32 2014

Slideshow functionality for Wikipedia

Hi all,

After working on an article on English Wikipedia, I came to realise that it might be useful if we had a slideshow feature for media for use in articles.

I was informed that Hebrew Wikipedia has a fantastic slideshow template that can be used in articles.[1] The slideshow is created with this template.[2]

The design is very sleek and it would no doubt be a fantastic addition to all Wikipedias.

I've left a message for the person responsible for this template on he.wp asking if they can help create it for English Wikipedia, but I have been informed that they are basically semi-retired/on extended wikibreak.

Would anyone out there like to take this on board and get it created for English Wikipedia at the earliest convenience. It can be tested live on the article I am working on at the moment if need be.[3]



Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Pau Giner | 17 Sep 14:14 2014

Captions, descriptions, and duplication

Hi all,

While adding details on story #589 about showing the caption above the fold in Media Viewer, I recalled that we were considering not showing the file description below the fold for files that have both a caption and a description. I wanted to confirm if that is the case, and the changes it will imply.

I created story #895 to capture required changes if we remove the below the fold description. Basically it reorganises a little bit the authorship information so that is can expand using the room the description used and avoids just having an empty area below the fold.

The rationale for removing the description below the fold was that for files that have both caption and description they tend to be redundant most of the time. I did a quick exploration by picking some random vital articles and going through 62 images:
  • 46% of the images lack description or it was not shown in Media Viewer
  • From the rest of the files where both caption and description:
    • 58% (26% of total) provide redundant information or the description didn't add additional details (example).
    • 44% (20% of total) show more details on the description or complementary info to the caption (example).
I'm not sure how representative this is compared to all our files (any data on the subject is welcome), but taking into account that the file description can be accessed through the "more details" button which we plan to make more prominent, I'm ok with removing it if we don't found stronger evidence of its need.

Should that be made as part of the changes of #589? I don't know, I created card #895 as a separate card so that it can be done after  #589 or at the same time, as it makes more sense according to development efforts.

Any thoughts?


Pau Giner
Interaction Designer
Wikimedia Foundation
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Gergo Tisza | 15 Sep 02:30 2014

PayPal video player

PayPal published an opensource HTML5 video player a couple days ago, with focus on accessibility. Seems pretty neat at a glance.

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Fabrice Florin | 14 Sep 04:35 2014

Media Viewer Tasks for next week

Hi guys,

I am getting ready to turn off my work email until I return from vacation on Sep. 24.

Before I go, here’s my recommended to-do list for next week, with a focus on Media Viewer improvements. 

It is based in part on this updated improvements plan:

I considered emailing each of you individually about specific tasks on this list, but a single message to the team may be more helpful, so we’re all on the same page.

* Lead Wednesday's sprint planning meeting 
* Update the Etherpad, Mingle site and Improvements page
* Deploy and monitor 'Pre-render thumbnails on backend’ (#301)
* Investigate better performance metrics solution for Media Viewer (#881)
* Run "versus" test on a dedicated labs instance (#884)

* Complete and deploy ‘More Details’ button with project icon (#830, 873)
* Complete and deploy Download and Share buttons (#841, 834)
* Develop Disable / Enable tools (#836, 719, 870) 
* Show clearer indication of authorship (#837)
* Work closely with Pau on all design questions (via IRC in your AM, then email in the PM)

* Disable MediaViewer for logged-in Commons users (#822)
* Help with back-end on Disable / Enable tools, as needed (#836, 719, 870) 
* Update 'File: Page vs. MMV' performance dashboard with improved user data (#880)
* Performance histogram for MediaViewer and File page (#815)
* Help with attribution/licensing improvements for metadata cleanup effort

* Update specs with all assets for Disable / Enable tools (#836, 719, 870) 
* Finalize design for Caption above the fold + how to expand/collapse it (#589) 
* Propose a design for how to access ‘Help’ or ‘About’ pages from Media Viewer
* Join our IRC MM channel at the end of your day (to work more closely with Mark)

* Respond to new comments on consultation or MV talk pages 
* Thank contributors to consultation whose suggestions made it to the list
* Archive old comments on Media Viewer talk page

* Write findings from Disable / Enable user testing with Pau
* Add a few more screenshots on August report (with credits)
* Post wiki report on July user studies, for transparency reasons

See Current Cycle wall for more details:

I hope this outline is helpful. There may be other priority tasks that are not listed here, but I wanted to give you a sense of action items that seem important for the next 2 weeks, from my standpoint.

In my absence, Erik and Howie will tag team to provide product input on all this. Erik will join next Wednesday’s sprint planning meeting and can help test important features for deployment.

I look forward to seeing you all the following Wednesday, Sep. 24, at the 9am PT weekly meeting. I will not check work email during that time. If you need to reach me urgently, my personal email is fabriceflorin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org .

Good luck and speak to you soon!



Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Chris McMahon | 12 Sep 19:03 2014

MMV browser tests for IE versions

We created a set of these, you can see them at: 

In the near future I would like to refine exactly what is required for these builds as regards

* browser
* version
* OS (if applicable)
* target environment (beta, test2, mw.o)

as well as whatever additional feature coverage we might provide. 


Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Fabrice Florin | 12 Sep 05:01 2014

Media Viewer Consultation Results

Thanks to everyone who participated in the recent Media Viewer Consultation! 

Our multimedia team appreciates the many constructive suggestions to improve the viewing experience for
readers and casual editors on Wikimedia projects. We reviewed about 130 community suggestions and
prioritized a number of important development tasks for the next release of this feature. Those
prioritized tasks have now been added to the improvements list on the consultation page. (1)

We have already started development of the most critical improvements: 'must-have’ features that this
consultation helped identify and that have been validated through user testing — see research
findings (2) and design prototype (3). We plan to complete all these 'must have' improvements by the end of
October and will deploy them incrementally, starting this week. For more details, see our improvement
plan (4) and development tasks for the next 6 weeks (5).

As we release these improvements, we will post regular updates on the Media Viewer talk page (6). We invite
you to review these improvements and share your feedback. 

The foundation is also launching a file metadata cleanup drive (7) to add machine-readable attributions
and licenses on files lack them. This will lay the groundwork for the structured data partnership (8) with
the Wikidata team, to enable better search and re-use of media in our projects. We encourage everyone to
join these efforts.

This community consultation was very productive for us and we look forward to more collaborations in the

Thanks again to all our gracious contributors. We consider ourselves lucky to have so many great community partners.



(1) https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Media_Viewer_consultation

(2) https://www.mediawiki.org/wiki/Media_Viewer_Research_Round_2_(August_2014)

(3) http://multimedia-alpha.wmflabs.org/wiki/Rapa_Nui_National_Park#mediaviewer/File:Ahu-Akivi-1.JPG

(4) https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Improvements

(5) http://ur1.ca/h7w5s

(6) https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer

(7) https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive

(8) https://commons.wikimedia.org/wiki/Commons:Structured_data


Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation


Multimedia mailing list
Multimedia <at> lists.wikimedia.org