Page MenuHomePhabricator

Manual refresh message in case of slow connection
Closed, ResolvedPublic3 Estimated Story Points

Description

Acceptance Criteria

  • Disable auto-refresh when the connection OR size of content causes the refresh to take longer than 6 seconds to load 3 times in a row.
  • Disable auto-refresh when the connection hits a timeout 3 times in a row.
  • The normal 'Reload' hover button disappears when the manual message is displayed.

Display this message in the UI instead:

Please refresh now to manually preview your edits. Reload

Visual Reference:

manual-refresh_bar.png (2Γ—3 px, 1016 KB)

Event Timeline

Please refresh now to manually preview your edits. Refresh now.

@NRodriguez: Should this say "refresh" or "reload"? The latter is used on the error display, so it might make sense to match that.

Change 778220 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Move realtime preview loading bar to be a proper element

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

Change 777495 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Realtime Preview: display manual-reload bar on slow connections

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

@Samwilson Let's go with Reload to be consistent, good catch, a quick glance also shows me it's more translatable.

Change 778220 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Realtime Preview: Move loading bar to be a proper element

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

@nayoub Now that the reload hover button is done, did you want to change the design of the manual bar? I think you mentioned moving the 'Reload now.' button (which might now just read 'Reload', with no dot?) to the end of the bar, so it appears in the same position as the hover button.

Yes exactly @Samwilson. The reload hover button can be at the same place when the manual bar is active:

Hover buttonManual Bar
Screen Shot 2022-04-13 at 20.11.20.png (1Γ—2 px, 427 KB)
Screen Shot 2022-04-13 at 20.16.55.png (1Γ—2 px, 892 KB)

There's a discrepancy in the position because of the design system dimensions between the OOUI progressive button (in the reload hover one) and the OOUI quiet button (in the manual bar).
You'll find the Figma mock here: https://www.figma.com/file/Jb6SALEoHWQRawSxscd3Ap/Wikipedia%2FReal-time-preview?node-id=1565%3A32666
Let me know what you think :)

I actually fixed the dimensions discrepancy on Figma but not sure how that would affect the OOUI elements...
Also, here's an interactive prototype you can try: https://www.figma.com/proto/Jb6SALEoHWQRawSxscd3Ap/Wikipedia%2FReal-time-preview?page-id=1565%3A32354&node-id=1565%3A33595&viewport=315%2C48%2C0.32&scaling=scale-down-width&hide-ui=1

Ah great, looks good!

Should the hover button read "Reload now" as well? It's currently just "Reload". It also has the curly arrow icon; should that be removed?

Also, @MusikAnimal raised the point about when things should be disabled/greyed-out during loading β€” should the manual bar be made opaque, or the button disabled, or anything? And similarly, should the hover button be disabled during loading?

Per @MusikAnimal's comments, I agree that removing the word Now makes sense.

On that note, see also the question at https://phabricator.wikimedia.org/T304568#7854636. We're thinking the Reload buttons should be hidden/disabled while loading is taking place, so that they don't appear clickable when they don't do anything.

Agree with the above.

In addition let's make the whole gray area clickable, including the area outside of the button in this screenshot:

Screen Shot 2022-04-14 at 3.37.54 PM.png (150Γ—1 px, 174 KB)

This should help us to mitigate @DLynch's concerns, so if folks are confused the whole area is clickable and hopefully there's enough context where they understand it's not a reload of the whole page:

As a complete drive-by comment, I'd be worried about confusion over whether "reload" means to reload the entire page, and that causing user worries about data-loss.

Also, @MusikAnimal made me realize that we disable auto-refresh and kick into manual refresh (this experience) if the load time is less than 10 seconds. I think that is too high, can we make it so we disable the auto-refresh if the load time is > 6 seconds?

Sounds good.

The above patch is ready to go, and because we're wanting to get this main feature done by the end of this week, it seems like it'll be quicker to hold these new changes off for separate changes. I'll start working on them now.

To summarise, still to come are the following:

  • Reduce $wgWikiEditorRealtimeDisableDuration to 6 seconds.
  • Make the whole manual-load bar clickable. Will the blue 'Reload' text remain as it is, as a clickable target itself?
  • Disable and grey-out all reload buttons during loading (might as well apply to all three buttons: the hover one, the manual-bar, and the error message one).

To summarise, still to come are the following:

Reduce $wgWikiEditorRealtimeDisableDuration to 6 seconds.
Make the whole manual-load bar clickable. Will the blue 'Reload' text remain as it is, as a clickable target itself?
Disable and grey-out all reload buttons during loading (might as well apply to all three buttons: the hover one, the manual-bar, and the error message one

Hey @Samwilson where are we keeping track of these changes?

Let me know if you need anything else and sounds good re: different patch!

Change 777495 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Realtime Preview: display manual-reload bar when previews are slow

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

Change 784803 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Reduce $wgWikiEditorRealtimeDisableDuration from 10 to 6 seconds

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

Change 784805 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Disable the realtime preview reload button during loading

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

Hey @Samwilson where are we keeping track of these changes?

I've created two patches here for the small parts (now ready for review), and lodged T306590 to handle the larger manual-mode bar changes.

Change 784803 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Reduce $wgWikiEditorRealtimeDisableDuration from 10 to 6 seconds

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

Change 784805 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Disable the realtime preview reload button during loading

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

dom_walden subscribed.

Acceptance Criteria

  • Disable auto-refresh when the connection OR size of content causes the refresh to take longer than 6 seconds to load 3 times in a row.

We calculate a mean over all the Preview requests for the editing session. On the 3rd request of the session (and every request after this), if the average is over 6 seconds we show the manual-mode bar.

So it is not strictly necessary to have 3 requests in a row taking over 6 seconds. Just the mean of all the requests to be over 6 seconds.

For example, if your requests have so far been quick but you then have one particularly long request, this might be enough to tip the average over 6 seconds and into manual-mode.

  • Disable auto-refresh when the connection hits a timeout 3 times in a row.

I have not seen it auto-refresh in manual-mode. Once you are in manual-mode, there is no way to go back to auto-mode (unless you refresh the page).

(I assume when we say "timeout" here we mean the 6 seconds.)

  • The normal 'Reload' hover button disappears when the manual message is displayed.

I never saw it in manual mode.

manual-mode_message.png (706Γ—1 px, 180 KB)

The English translation of the message is: Please reload now to manually preview your edits.

Test environment: https://en.wikipedia.beta.wmflabs.org and https://en.wikisource.beta.wmflabs.org. Latest version tested: WikiEditor 0.5.3 (c23c11a) 06:45, 3 May 2022.
Test browsers: Firefox 91, Chromium 87.

thanks for the explanation on it being based on average and not on all being over 6 seconds @dom_walden