Page MenuHomePhabricator

Catalogue where the MobileFrontend loading overlay is used
Closed, ResolvedPublic

Description

As part of the editing team's work improving the user experience for mobile editing, we've identified that improvements can be made to the design of the loading overlay that is triggered when VE is opened. That overlay is currently used in multiple scenarios, so we need to make a decision about whether a new design treatment will work in all the use cases or whether we should fork the loading overlay so that we can create one specific to the visual editor loading.

This first step will be determining where the overlay is used, followed by design review and discussion.

Event Timeline

marcella created this task.Nov 16 2018, 3:56 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 16 2018, 3:56 PM
marcella updated the task description. (Show Details)Nov 16 2018, 3:57 PM
marcella moved this task from To Triage to FY 19-20 on the VisualEditor board.Nov 16 2018, 5:21 PM
marcella moved this task from FY 19-20 to Q4 on the VisualEditor board.Nov 16 2018, 7:28 PM
  1. Designers review and see if the new treatments make sense for all use cases

@marcella: Could you attach the designs for the new treatments?

  1. Designers review and see if the new treatments make sense for all use cases

@marcella: Could you attach the designs for the new treatments?

I'm going to copy @iamjessklein here for this right now, but I think she's still working on some of the details.

Jdlrobson added a subscriber: Jdlrobson.

Per https://phabricator.wikimedia.org/T201687 this is not a problem isolated to the editor. Would be great if we could think about the other part of the product as part of this research as i think it would be dangerous to think about this in isolation.

Would be great if we could think about the other part of the product as part of this research as i think it would be dangerous to think about this in isolation.

This is covered by step 1 in the description, right?

DannyH added a subscriber: DannyH.Nov 26 2018, 6:16 PM
marcella renamed this task from Research Design Improvements to MobileFrontend Loading Overlay to Catalogue where the MobileFrontend loading overlay is used.Nov 28 2018, 8:53 PM
marcella updated the task description. (Show Details)
phuedx added a comment.EditedDec 12 2018, 11:04 AM

This first step will be determining where the overlay is used, followed by design review and discussion.

If you've set your preferred editor to VE, then when you click an edit icon, you'll see a fullscreen, semi-transparent overlay with a spinner in the centre.

This overlay is also shown in the following scenarios:

A. Special:Nearby

B. The talk overlay

Note: When a topic is added via the talk overlay the loading overlay is shown //very// briefly and then hidden as the talk overlay is hidden. It causes quite the flicker.

C. The categories overlay

D. The Media Viewer

E. The languages overlay

See also "steps to reproduce" in T201687. Happy to walk someone through these if helpful!

I suspect there may be a distinction between processes we expect to complete quickly (e.g. <500ms) and long processes like loading VE, which can take a few seconds. A design which works for one may not be optimal for the other.

I suspect there may be a distinction between processes we expect to complete quickly (e.g. <500ms) and long processes like loading VE, which can take a few seconds. A design which works for one may not be optimal for the other.

Is there a way to bootstrap the loading of VE to get the first load smaller? Maybe by providing a minimal set of components to render the editing interface for typing without the toolbar? Many of the mobile overlays load quite slow these days (to the point beta cluster selenium tests timeout) and it would be great to find a way to make this less noticeable by improving performance rather than focusing on the UI portion of it.

Note, the LoadingOverlay is on the way out. One of the things we've working towards across the mobile site is localising loaders to sub components
For example on the CategoryOverlay, the Overlay will load and render with the title and back button, and the spinner will show as we load the categories (in future we might want to explore the placeholder pattern). This will avoid the flash we are currently seeing and remove the need of the LoadingOverlay in a variety of interfaces. I hope that we'll have this in place around Feb next year so that might help you with whatever you have planned for the editor.

Is there a way to bootstrap the loading of VE to get the first load smaller? Maybe by providing a minimal set of components to render the editing interface for typing without the toolbar? Many of the mobile overlays load quite slow these days (to the point beta cluster selenium tests timeout) and it would be great to find a way to make this less noticeable by improving performance rather than focusing on the UI portion of it.

I agree with @Jdlrobson - it would be super great to have a collection of components to help us manage performance expectations. I'm thinking that if we had a throbber, a set skeletons, progress bar and perhaps a template for how to use those in conjunction with microcopy, we would have enough to make some extensible solutions.

I am working on mocking up solutions, and talking with @alexhollender to ensure that all of the scenarios that @phuedx outlined are addressed. I will post some mockups in T211595 that show a few different situations.

I suspect there may be a distinction between processes we expect to complete quickly (e.g. <500ms) and long processes like loading VE, which can take a few seconds. A design which works for one may not be optimal for the other.

I wholeheartedly agree.

We're using the same treatment to cover processes that involve API requests (e.g. showing the categories overlay) and those that finish trivially quickly (e.g. after adding a topic via the talk overlay). This work should probably include reevaluating the use of the loading overlay in certain cases as well as making it more versatile.

@JTannerWMF: I'm the Sam you're looking for 🙂

Is there a way to bootstrap the loading of VE to get the first load smaller? Maybe by providing a minimal set of components to render the editing interface for typing without the toolbar? Many of the mobile overlays load quite slow these days (to the point beta cluster selenium tests timeout) and it would be great to find a way to make this less noticeable by improving performance rather than focusing on the UI portion of it.

VE is split roughly into three parts: data model (DM), content editable (CE) and UI. The toolbar is only a small portion of the UI code. To render the edit surface with editable HTML we need to load all of DM, CE and most of UI, so it wouldn't really be helpful to load that first.

For the 2017 wikitext editor we do do this trick, as a simple textarea makes for a reasonable edit surface, so we use one temporarily while the rest of the code loads.

marcella closed this task as Resolved.Dec 19 2018, 2:57 PM
marcella claimed this task.

The cataloguing is completed here. Big thanks to @phuedx and his team for helping us sort that out! More discussion of component designs can be found on T211595. Thanks!