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:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Media_View...
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:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/933
Thanks for any recommendations you might have,
Fabrice
_______________________________
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
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.
I imagine its less about file size, and more about number of pixels (or uncompressed file size)
https://commons.wikimedia.org/wiki/Template:Largeimage says 50 MP, but that seems small to me. Do we know what causes browser crashes for large images - is it simply running out of RAM causing the browser to swap all over the place and be slow or are there other issues at play. (Based on back of the napkin calculations, 50 MP = very roughly 280 MB ram. )
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?
Keep in mind its not just crashing the browser. Accidentally downloading a gigabyte (or whatever) of data without meaning to is often a bad thing. Particularly for people on metered internet.
If I was to pick numbers out of a hat, I'd start warning maybe at images > 50 MB, or > 75 MP, but that's chosen rather arbitrarily
--bawolff
Showing a warning and making the user explicitly chose is one option to explore, but it has some potential drawbacks:
- For users that can display the image, the workflow is less fluent requiring one more upfront decision. - For users that cannot display the image in more detail (they may just wanted the image a bit bigger to read some label) the options are to (a) crash the browser or (b) do nothing.
An alternative behaviour I was considering for huge files, is to load a "large" version of it (not the original huge one) and indicate so while the image is loading ("due to its big size, a scaled version of the file will be loaded instead. You can access the download icon to get or display the original file."). In this way, most users that are interested in just viewing some more details will be able to do so just by clicking, and those specifically interested on displaying huge images will do that in an explicit and more informed way (file size is shown in the download panel) and with a "download" option (less likely to break crash their browser) next to the "view in browser" one.
In any case, a notion of when a file is considered huge, and whether we should estimate that on resolution or file size will be very useful for whichever approach we choose.
Pau
On Thu, Oct 2, 2014 at 6:56 AM, Brian Wolff bawolff@gmail.com wrote:
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.
I imagine its less about file size, and more about number of pixels (or uncompressed file size)
https://commons.wikimedia.org/wiki/Template:Largeimage says 50 MP, but that seems small to me. Do we know what causes browser crashes for large images - is it simply running out of RAM causing the browser to swap all over the place and be slow or are there other issues at play. (Based on back of the napkin calculations, 50 MP = very roughly 280 MB ram. )
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?
Keep in mind its not just crashing the browser. Accidentally downloading a gigabyte (or whatever) of data without meaning to is often a bad thing. Particularly for people on metered internet.
If I was to pick numbers out of a hat, I'd start warning maybe at images > 50 MB, or > 75 MP, but that's chosen rather arbitrarily
--bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
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.
See [[bugzilla:29967]], “ Better support for viewing and downloading large files” https://bugzilla.wikimedia.org/show_bug.cgi?id=29967
On Thu, Oct 2, 2014 at 9:02 AM, Jean-Frédéric jeanfrederic.wiki@gmail.com wrote:
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.
See [[bugzilla:29967]], “ Better support for viewing and downloading large files” https://bugzilla.wikimedia.org/show_bug.cgi?id=29967
-- Jean-Fred
Ah, great, thanks for the link, Jean-Fred. In the back of my mind I thought I'd seen something about this on Bugzilla.
As I pointed out in a meeting an on-wiki and this bug confirms, this is a problem that exists for viewing large files in general, not just Media Viewer, so I'd like to make sure that the solution is practical for the file page as well and not just put together because there was a problem with Media Viewer. The bug is a big enough issue outside of Media Viewer that it deserves the attention.
When exposing original-size or otherwise huge file versions *for download* when they're not intended to be viewed in browser, it may be wise to use the 'Content-Disposition' HTTP header, as we do for XML output from Special:Export.
This should force most browsers to show a download dialog instead of loading the giant file inline; you can then take your mega-image and stick it in Photoshop or Gimp or whatever if you really wanted it (such programs are optimized to work with huge files, while browsers are most emphatically *not*).
Of course this may mean we need to either filter the file through PHP to add headers (scary!) or have a second "downloadable" URL where the swift or caching infrastructure adds the headers.
-- brion
On Thu, Oct 2, 2014 at 11:41 AM, Keegan Peterzell kpeterzell@wikimedia.org wrote:
On Thu, Oct 2, 2014 at 9:02 AM, Jean-Frédéric <jeanfrederic.wiki@gmail.com
wrote:
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.
See [[bugzilla:29967]], “ Better support for viewing and downloading large files” https://bugzilla.wikimedia.org/show_bug.cgi?id=29967
-- Jean-Fred
Ah, great, thanks for the link, Jean-Fred. In the back of my mind I thought I'd seen something about this on Bugzilla.
As I pointed out in a meeting an on-wiki and this bug confirms, this is a problem that exists for viewing large files in general, not just Media Viewer, so I'd like to make sure that the solution is practical for the file page as well and not just put together because there was a problem with Media Viewer. The bug is a big enough issue outside of Media Viewer that it deserves the attention.
-- Keegan Peterzell Community Liaison, Product Wikimedia Foundation
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On 10/2/14, Brion Vibber bvibber@wikimedia.org wrote:
When exposing original-size or otherwise huge file versions *for download* when they're not intended to be viewed in browser, it may be wise to use the 'Content-Disposition' HTTP header, as we do for XML output from Special:Export.
This should force most browsers to show a download dialog instead of loading the giant file inline; you can then take your mega-image and stick it in Photoshop or Gimp or whatever if you really wanted it (such programs are optimized to work with huge files, while browsers are most emphatically *not*).
Of course this may mean we need to either filter the file through PHP to add headers (scary!) or have a second "downloadable" URL where the swift or caching infrastructure adds the headers.
-- brion
That's already a thing: https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png?download
--bawolff
Sweet!
-- brion
On Thu, Oct 2, 2014 at 2:00 PM, Brian Wolff bawolff@gmail.com wrote:
On 10/2/14, Brion Vibber bvibber@wikimedia.org wrote:
When exposing original-size or otherwise huge file versions *for
download*
when they're not intended to be viewed in browser, it may be wise to use the 'Content-Disposition' HTTP header, as we do for XML output from Special:Export.
This should force most browsers to show a download dialog instead of loading the giant file inline; you can then take your mega-image and
stick
it in Photoshop or Gimp or whatever if you really wanted it (such
programs
are optimized to work with huge files, while browsers are most
emphatically
*not*).
Of course this may mean we need to either filter the file through PHP to add headers (scary!) or have a second "downloadable" URL where the swift
or
caching infrastructure adds the headers.
-- brion
That's already a thing: https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png?download
--bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
The reason why this particular feature (click on image) doesn't download the file is because that's what a significant amount of the users requested. It's a poor man's zoom, so to speak, and it's reproducing a workflow that people used to have on the file page and missed in media viewer.
I think we're paying the price of implementing this hack as a placeholder for zoom. To me the point where we have to build convoluted mechanisms (especially extra menus, warnings...) to compensate for a strange feature is usually a sign that it shouldn't be built like this in the first place.
Pau proposed a good compromise. I.e. clicking should open a bigger image (the "zoomed" version) but not the original, unless the original happens to be smaller than what we consider to be the bigger version. I think that's a smarter placeholder hack than what we're currently doing. It's worth a shot.
On Thu, Oct 2, 2014 at 11:09 PM, Brion Vibber bvibber@wikimedia.org wrote:
Sweet!
-- brion
On Thu, Oct 2, 2014 at 2:00 PM, Brian Wolff bawolff@gmail.com wrote:
On 10/2/14, Brion Vibber bvibber@wikimedia.org wrote:
When exposing original-size or otherwise huge file versions *for
download*
when they're not intended to be viewed in browser, it may be wise to use the 'Content-Disposition' HTTP header, as we do for XML output from Special:Export.
This should force most browsers to show a download dialog instead of loading the giant file inline; you can then take your mega-image and
stick
it in Photoshop or Gimp or whatever if you really wanted it (such
programs
are optimized to work with huge files, while browsers are most
emphatically
*not*).
Of course this may mean we need to either filter the file through PHP to add headers (scary!) or have a second "downloadable" URL where the
swift or
caching infrastructure adds the headers.
-- brion
That's already a thing: https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png?download
--bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
multimedia@lists.wikimedia.org