Hi,
As a part of a mobile spike [1], I evaluated the possibility of using MMV on mobile instead of the custom viewer we have right now in beta. The good news is that it works. The bad news is that it's quite heavy compared to what we have right now. We don't know yet when we'd like to see MMV on mobile, but this moment will eventually come.
Let's start with the additional dependencies I needed to add to mobile to make it run: * jquery.fullscreen - not needed on mobile * jquery.throttle-debounce - make sure that events fire only once, needed? * jquery.ui.dialog and dependencies - file reuse dialog, can/will be replaced? (on Multimedia roadmap) 'jquery.ui.core', 'jquery.ui.widget', 'jquery.ui.button', 'jquery.ui.draggable', 'jquery.ui.mouse', 'jquery.ui.position', 'jquery.ui.resizable', * jquery.color - what for? can we use CSS transitions? * jquery.colorUtil - what for? can we use CSS transitions? * moment
Fortunately, Mark told me that removing jquery.ui.dialog is already planned. I created a simple page with a thumbnail and checked what Chrome reports in Network tab for no multimedia viewer, the viewer we currently have on mobile (in beta) and MMV:
* no viewer: 379KB
* mobile viewer: ** 384KB at page load (all JS + LESS + HTML template) ** 390KB when lightbox shows (images used in LESS + API request) ** 561KB when image is loaded (custom size, in this case 171KB for 746px) ** +6KB, +11KB, +182KB
* mmv: ** 395KB at page load (only bootstrap JS loaded) ** 722KB when lightbox shows (the rest of JS and other assets) ** 2.7MB when image is loaded (129KB for 640px and 901KB for 1920px) ** +14KB, +343KB, +2.3MB
** mmv (without jquery.ui.dialog) ** 395KB at page load ** 573KB when lightbox shows ** 2.6MB when image is loaded ** +14KB, +194KB, +2.2MB
Remaining questions/problems: * There's no indication of overlay loading (on Multimedia roadmap). * Can we do animations using CSS transitions? * Why do we load both 640px and 1920px version of images? * What is loaded at the end apart from images (+2.3MB, images are ~1MB)?
Related patches: https://gerrit.wikimedia.org/r/#/c/116155/ https://gerrit.wikimedia.org/r/#/c/116154/ https://gerrit.wikimedia.org/r/#/c/116156/
[1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1688
Thanks, Julius!
I really appreciate this preliminary evaluation of how Media Viewer v0.2 looks on mobile.
I’m glad that our current version works already, even though we haven’t done anything yet towards mobile support. :)
It’s also good to know about some of the issues that need to be addressed before we can properly support mobile devices with the Media Viewer.
We would like to take on mobile support next quarter, as part of version 0.3, as outlined here:
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer#Next_Version
For now, I have added a link to this email thread on our Mingle card for this epic story:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/201
I will ping Kenan and Tomasz next week to determine when would be a good time for our teams to collaborate on developing this Mobile Version of Media Viewer.
Thanks again for his great start … to be continued!
Fabrice
On Feb 28, 2014, at 5:31 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
Hi,
As a part of a mobile spike [1], I evaluated the possibility of using MMV on mobile instead of the custom viewer we have right now in beta. The good news is that it works. The bad news is that it's quite heavy compared to what we have right now. We don't know yet when we'd like to see MMV on mobile, but this moment will eventually come.
Let's start with the additional dependencies I needed to add to mobile to make it run:
- jquery.fullscreen - not needed on mobile
- jquery.throttle-debounce - make sure that events fire only once, needed?
- jquery.ui.dialog and dependencies - file reuse dialog, can/will be replaced? (on Multimedia roadmap) 'jquery.ui.core', 'jquery.ui.widget', 'jquery.ui.button', 'jquery.ui.draggable', 'jquery.ui.mouse', 'jquery.ui.position', 'jquery.ui.resizable',
- jquery.color - what for? can we use CSS transitions?
- jquery.colorUtil - what for? can we use CSS transitions?
- moment
Fortunately, Mark told me that removing jquery.ui.dialog is already planned. I created a simple page with a thumbnail and checked what Chrome reports in Network tab for no multimedia viewer, the viewer we currently have on mobile (in beta) and MMV:
no viewer: 379KB
mobile viewer:
** 384KB at page load (all JS + LESS + HTML template) ** 390KB when lightbox shows (images used in LESS + API request) ** 561KB when image is loaded (custom size, in this case 171KB for 746px) ** +6KB, +11KB, +182KB
- mmv:
** 395KB at page load (only bootstrap JS loaded) ** 722KB when lightbox shows (the rest of JS and other assets) ** 2.7MB when image is loaded (129KB for 640px and 901KB for 1920px) ** +14KB, +343KB, +2.3MB
** mmv (without jquery.ui.dialog) ** 395KB at page load ** 573KB when lightbox shows ** 2.6MB when image is loaded ** +14KB, +194KB, +2.2MB
Remaining questions/problems:
- There's no indication of overlay loading (on Multimedia roadmap).
- Can we do animations using CSS transitions?
- Why do we load both 640px and 1920px version of images?
- What is loaded at the end apart from images (+2.3MB, images are ~1MB)?
Related patches: https://gerrit.wikimedia.org/r/#/c/116155/ https://gerrit.wikimedia.org/r/#/c/116154/ https://gerrit.wikimedia.org/r/#/c/116156/
[1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1688
Juliusz
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
Hi Juliusz,
On Fri, Feb 28, 2014 at 5:31 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
- jquery.throttle-debounce - make sure that events fire only once, needed?
It is used for rapid-fire events such as mousemove or scroll. Mobile doesn't have either, so not needed there. (Not much of a difference though - the library is 0.7K when minified.)
- jquery.color - what for? can we use CSS transitions?
- jquery.colorUtil - what for? can we use CSS transitions?
Dependencies for doing color transitions with jQuery.animate(). Probably can be replaced with CSS; I'll look into that when I have some free time. At any rate, .animate() still runs without those files (just doesn't produce any visible effect) so they can be omitted.
- moment
Used for date localization. Moment is heavy (25K minified) but the browser's built in date formatting is very unreliable. Might be possible doing this on the server side, although it would be ugly from an API design point of view.
- There's no indication of overlay loading (on Multimedia roadmap).
We have no plans for that AFAIK.
- Why do we load both 640px and 1920px version of images?
We preload the fullscreen version of the image. We didn't make that configurable, but we should.
- What is loaded at the end apart from images (+2.3MB, images are ~1MB)?
Probably more preloading? We do a lot of that. You can set mw.mmv.mediaViewer.preloadDistance = 0 to disable. (This only works once you have opened some image already as mw.mmv.mediaViewer is created when the main JS lib is loaded; we don't have a lazy-loading compatible way to configure the viewer yet. Created #275https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/275 about that.)
Also, we request every image twice to get certain performance metrics; this should not result in the image actually being downloaded twice (although we did not test that in mobile browsers), but might confuse the network stats in Chrome. Probably also something that we should make configurable :-)
The big win in terms of size would be to make the UI modular and configurable, so you can request a MultimediaViewer instance which does not have most of the information on the metadata panel, for example, and the related files would not be loaded. We have some vague plans about that, but nothing specific yet.
On Fri, Feb 28, 2014 at 09:01:21PM -0800, Gergo Tisza wrote:
- There's no indication of overlay loading (on Multimedia roadmap).
We have no plans for that AFAIK.
Yuh-huh:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/248
- Why do we load both 640px and 1920px version of images?
We preload the fullscreen version of the image. We didn't make that configurable, but we should.
Ohhhh. I hadn't thought of preloading as causing that much trouble, but at least it's bandwidth that is asynchronous and (hopefully) invisible to the user.
On mobile it should probably never preload anything, though.
- There's no indication of overlay loading (on Multimedia roadmap).
We have no plans for that AFAIK.
I think Juliusz means #248https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/248
On Sat, Mar 1, 2014 at 6:01 AM, Gergo Tisza gtisza@wikimedia.org wrote:
Hi Juliusz,
On Fri, Feb 28, 2014 at 5:31 PM, Juliusz Gonera jgonera@wikimedia.orgwrote:
- jquery.throttle-debounce - make sure that events fire only once, needed?
It is used for rapid-fire events such as mousemove or scroll. Mobile doesn't have either, so not needed there. (Not much of a difference though
- the library is 0.7K when minified.)
- jquery.color - what for? can we use CSS transitions?
- jquery.colorUtil - what for? can we use CSS transitions?
Dependencies for doing color transitions with jQuery.animate(). Probably can be replaced with CSS; I'll look into that when I have some free time. At any rate, .animate() still runs without those files (just doesn't produce any visible effect) so they can be omitted.
- moment
Used for date localization. Moment is heavy (25K minified) but the browser's built in date formatting is very unreliable. Might be possible doing this on the server side, although it would be ugly from an API design point of view.
- There's no indication of overlay loading (on Multimedia roadmap).
We have no plans for that AFAIK.
- Why do we load both 640px and 1920px version of images?
We preload the fullscreen version of the image. We didn't make that configurable, but we should.
- What is loaded at the end apart from images (+2.3MB, images are ~1MB)?
Probably more preloading? We do a lot of that. You can set mw.mmv.mediaViewer.preloadDistance = 0 to disable. (This only works once you have opened some image already as mw.mmv.mediaViewer is created when the main JS lib is loaded; we don't have a lazy-loading compatible way to configure the viewer yet. Created #275https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/275 about that.)
Also, we request every image twice to get certain performance metrics; this should not result in the image actually being downloaded twice (although we did not test that in mobile browsers), but might confuse the network stats in Chrome. Probably also something that we should make configurable :-)
The big win in terms of size would be to make the UI modular and configurable, so you can request a MultimediaViewer instance which does not have most of the information on the metadata panel, for example, and the related files would not be loaded. We have some vague plans about that, but nothing specific yet.
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Gilles Dubuc wrote:
* There's no indication of overlay loading (on Multimedia roadmap). We have no plans for that AFAIK.I think Juliusz means #248 https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/248
Yes, that's what I meant.
multimedia@lists.wikimedia.org