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

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

In T209708#4758219, @phuedx wrote:

2. 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.

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.

In T209708#4763326, @Jdlrobson wrote:

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?

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

• Visit https://en.m.wikipedia.org/wiki/Special:Nearby
• Click "Show nearby articles"

B. The talk overlay

• Visit https://en.m.wikipedia.org/wiki/Cult_of_Luna
• Scroll to the bottom of the page
• Click "Talk"

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

• Visit https://en.m.wikipedia.org/wiki/Cult_of_Luna?mobileaction=beta
• Scroll to the bottom of the page
• Click "Categories"

D. The Media Viewer

• Visit https://en.m.wikipedia.org/wiki/Cult_of_Luna
• Click on the image in the infobox

E. The languages overlay

• Visit https://en.m.wikipedia.org/wiki/Cult_of_Luna
• Click on the "languages" icon:

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.

In T209708#4817463, @Esanders wrote:

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.

Hey @sam

@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.