Page MenuHomePhabricator

ULS should indicate when display preferences change is complete
Closed, ResolvedPublic

Description

In Display Settings/Fonts, change the font in the selectbox
Quickly click for a random page in the wiki

New font is likely not displayed

Changing preferences for fonts takes some time, on the order of several seconds. Suggest a spinner or other acknowledgement to the user that the preferences have been changed successfully.


Version: unspecified
Severity: normal

Details

Reference
bz53772

Event Timeline

bzimport raised the priority of this task from to High.
bzimport set Reference to bz53772.

Change 82654 had a related patch set uploaded by Cmcmahon:
changing prefs takes a long time, see Bug 53772

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

Could it be this occurs because the changes to the DOM are made first, and only then the setting is saved in the local storage? If so, it may be possible to fix this by saving the preference first.

A spinner or something while the settings are saved would be useful here I think

The preferred solution here is to ensure that the preference is saved as soon as possible, and that no spinner is needed.

I don't understand what your point is. The preference is saved immediately and the time it takes to save the preference for logged in users is dominated mainly by network latency and then server side processing. IMHO optimization of either is not in scope for this bug. We cannot know beforehand whether spinner is needed.

We have been using the spinner to indicate that data will be loaded there. Here, the dialog is about to close and a spinner would probably only add distraction.

I propose to communicate the storing without adding new elements by doing all the following:

  • Button label change to ("Applying changes" or "Applying settings")
  • Button become disabled
  • Cursor changes to "progress"

I made a quick example to visualise it at http://www.youtube.com/watch?v=ac0Bhy0P1I0

(In reply to comment #8)

I made a quick example to visualise it at
http://www.youtube.com/watch?v=ac0Bhy0P1I0

That looks fine, Pau. One possibly drawback is that the button size is changing, which is also a distracting element. This could be circumvented if the button width would initially be that of the widest width needed for any string that might be used in that button.

Change 95353 had a related patch set uploaded by Santhosh:
Visual indication while saving the settings

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

Change 95353 merged by jenkins-bot:
Visual indication while saving the settings

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