[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

[EPIC] Adopt Vue.js as the framework for MediaViewer, create a performant and modern user experience
Open, LowPublic10 Estimated Story Points

Description

This task is proposed as volunteer effort.

MultiMediaViewer is mostly implemented in JavaScript, generating the DOM client-side. It is a very suitable candidate for adopting Vue.js. This would be a good time to update the user experience.

This task is a collection of targets and features I've been thinking of. It's not an exhaustive list and will change in the future.

Targets
  1. Massively reduced code size. The resource bundle just for MMV currently weighs in at around 0.5 MiB JavaScript uncompressed, minified. In comparison: WikiWand - using Angular - ships this feature and everything else needed for reading an article in about 350KiB JS uncompressed.
  2. Updated, smooth UX (minor details, shadow around image, zoom animation).
  3. Article visible (dimmed) in the background.
  4. Image zooming (long-requested feature: T77423).
  5. Jumping between images in the gallery (thumbnails at bottom of the screen, fully fleshed out history navigation - done in patch below).
  6. Correct identification of images to show, ex. don't show icon sized images in userboxes (<=46px?), unless the user opens that image specifically. Show small images in div.thumb elements, though.
  7. Updated tests, possibly replacing all Ruby-Selenium tests.
  8. DOM and CSS cleanup, no more positioning with JS - done in patch below.
  9. To avoid reinventing the wheel, evaluate existing image lightbox solutions and make use of a suitable, free licensed implementation, preferably a Vue.js component.
Expected benefits
  1. Faster loading and execution time as a result of smaller code-size and Vue's focus on performant DOM generation.
  2. Higher conversion (acceptance) rate in the long-timer community, where MMV usage is very low.
New UI Features
Zooming
  1. Zooming with mousewheel and UP-DOWN, PLUS-MINUS keys.
  2. Opening-closing animation zooms between the thumbnail and the full-sized image (like medium.com).
  3. Fullscreen with 'F' key.
  4. Close viewer when clicking on article.
  5. Panning image with drag-n-drop (optional, some lightbox implementations support it out-of-the-box). Useful if the metadata overlays the image and also to view the article behind.
Image metadata reskinned
  1. Image metadata has transparent background, can overlay the image.
  2. Gallery thumbnails at the bottom between the two metadata columns.
  3. Toolbar buttons above thumbnails: zoom in, out, reset, previous, next, slideshow, fullscreen.
  4. Buttons in bottom-right corner above metadata: share, download, settings, "Open original image", "Open metadata page".
Method to extend metadata
  1. With a key yet to be determined (used to be UP-DOWN which is used for zooming in many image viewers).
  2. Scrolling not connected to it.
  3. Open initially: the user can easily zoom or pan the image, if it's obscured by the metadata.
  4. Metadata hiding button.
Optional
  1. Preloading full-size images when thumbnail is scrolled on-screen.
  2. Preloading neighbours of viewed image.
  3. Use it as image viewer in Reasonator.
Personal motivation

Many websites all around the world deliver image viewers with pleasing UX. Viewers of Wiki*edia should have a similar experience.
This story began when as a user of MMV I was frustrated by the scrollbar constantly jumping back to the top of the page, which prompted me to investigate the issue. Alongside removing the source of the issue I've made a massive cleanup of the DOM and the CSS (patch 560576) that nobody dares to review. In the process I've gained familiarity with MMV and its features that are specific to Mediawiki. This knowledge can be turned beneficial with this project.

Event Timeline

Demian renamed this task from Adopt Vue.js as the framework for MediaViewer, create a performant and modern user experience to [EPIC] Adopt Vue.js as the framework for MediaViewer, create a performant and modern user experience.Apr 6 2020, 11:52 AM
Demian added a project: Epic.
Demian updated the task description. (Show Details)

@Catrope how would this project proposal fit into the plans with Vue?
With a very superficial estimate, assuming I have as much free time as in the last month, I would be ready with a prototype in a month and with a beta in 1-2 months more.

Demian set the point value for this task to 10.Jul 3 2020, 11:12 PM
Demian added a project: User-Demian.
Demian moved this task from Freezer to Plan on the User-Demian board.

[Resetting assignee due to inactive user account]

Aklapper triaged this task as Low priority.Jul 14 2022, 9:51 AM

For an actual full rewrite to Vue.js, we should look into CdxDialog and split off its focus capture and background overlay into a component that we can use for the fullscreen component. Then with that, we can build a vue 'app' and replace all the other components. This is something I have been thinking about doing, as some of the rework to make it mobile compatible is going to be so invasive, that it might just be better to rewrite it in vue, with modern JS, modern CSS.

But that will essentially require reimplementing the whole thing, which is going to be one heck of an effort. It's probably better to keep looking at cutting up existing code a bit more first, simply to have a more manageable base.

Change #1048862 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/MultimediaViewer@master] wip Migrate MultimediaViewer to Vue

https://gerrit.wikimedia.org/r/1048862

Hi @Jdlrobson and @TheDJ, I've drafted a patch to get an idea how the Vue.js future of MultimediaViewer could look like. It's far from complete and lacks plenty of animations and interactions. Also, it should use the native Vue.js Codex components, eventually. What do you think? Is this (draft of) Vue.js migration worth pursuing?

@simon04 I'm personally in favour and think it will make the code more maintainable, easier to read and easier to adapt for more situations.

I will note that there is a team that is looking into making the images zoomable (T77151) and I'm not entirely sure what their timelines are, but it might be wise to talk to that team if we set out on this.

Thanks @simon04 for the patch! I think eventually this is what we want to get to, but I'd say consolidating mobile and desktop would be needed to be done first (e.g. reducing the bloat).

I would worry that rewriting and rolling out a Vue version would require creating a third version of MMV and rolling that out gradually which may slow down that goal and would mean maintaining 3 versions until that happens. On mobile we do not even use Vue.js right now in article views so there are unknown challenges ahead there. Switching to Vue will also likely increase the size of MMV. I think for that reason it could be important to have some team in Wikimedia Foundation sponsoring that work and making sure it gets seen through to completion.

I would worry that rewriting and rolling out a Vue version would require creating a third version of MMV and rolling that out gradually which may slow down that goal and would mean maintaining 3 versions until that happens. On mobile we do not even use Vue.js right now in article views so there are unknown challenges ahead there. Switching to Vue will also likely increase the size of MMV. I think for that reason it could be important to have some team in Wikimedia Foundation sponsoring that work and making sure it gets seen through to completion.

So generally I agree... BUT, I'm equally worried that in order to do a merge with mobile first, we are going to write a whole lot of code, and do stuff that Vue would could deliver for us and at the some time be more readable and maintainable. By the time it is then done, i wouldn't be surprised if Vue is going be present on mobile after all and it was wasted effort.

You can already see that the code to handle the buttons etc, which was quite cumbersome to implement. The other team apparently wants to add zooming and that too would then have to be reimplemented. I see it a bit as one of those "why spend twice the effort and time, when we can just wait a little and do it right in one go"-situations.