There are several good researches on how an average user expects the browser's Back/Forward buttons to work. But there are quite few well-known good practices regarding the browser-level page refresh (F5 key, refresh button or swipe from top to bottom on mobile devices). Some of them are:
- Preserve user-already-entered values in form fields when page is refreshed
- Do not refresh pages unexpectedly
But let's think about page query parameters and have a look at the OpenID Connect specification. It contains the
ui_locales URL parameter and I'm sure there are other protocols out there that take UI locale into account in a similar way.
Now this case example has spawned some controversy within our development team:
- A Russian-speaking user visits a website which has no Russian localization. So the user selects English locale among the provided options.
- The user clicks signup button which directs him/her to an external OpenID Connect signup form page with
ui_locales=en(because that's what the user seemingly prefers).
- The user notices that the signup page does support Russian locale and switches to it.
- The page then loads Russian locale resource file via AJAX and dynamically replaces all texts to Russian equivalents.
At this point we have a Russian-localed page but with
ui_locales=en in the URL. If the user decides to refresh the page for some reason, this may suddenly bring back the English language if the page has not been intentionally coded to override the query-passed locale with the "local" user-explicitly-selected locale and if it does not dynamically update the
ui_locales in the page URL via History.replaceState() when the user changes it.
My questions are:
- What do real-world users expect and don't expect from page refresh in general and in this case particularly?
- When do they actually manually initiate a browser-level page refresh?
Does anyone have relevant data?