5

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:

  1. A Russian-speaking user visits a website which has no Russian localization. So the user selects English locale among the provided options.
  2. 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).
  3. The user notices that the signup page does support Russian locale and switches to it.
  4. 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:

  1. What do real-world users expect and don't expect from page refresh in general and in this case particularly?
  2. When do they actually manually initiate a browser-level page refresh?

Does anyone have relevant data?

2
  • 1
    I'm not familiar with how the external OpenID Connect page works. I surmise that this is not a page that you have developmental control over, correct? You're suggesting that this external page is not updating the query parameter, which is the key for which language to load at page load? – maxathousand Oct 22 '20 at 15:14
  • @maxathousand the authentication page does not matter, it's here as an example of a conflict based on page refreshing. The question is more about deriving UX-related functional requirements to web UIs that take page refreshing into account. – Stanislav Bakharev Oct 22 '20 at 15:57
1

As you mentioned, there are some best practices that are consistent with general UX design principles. However, in your case if the technology requirement/constraint seems to be the dominant/primary factor that is creating potential issues with the user experience, then chances are creating workarounds in the user interface is going to lead to a suboptimal experiences anyway.

Addressing your questions specifically (as a real-world user):

  • What do real-world users expect and don't expect from page refresh in general and in this case particularly? --> In general, I don't think that users expect any major changes to the state and status in a page refresh, unless they initiated it and are waiting for the update. They do expect it to be done in a timely manner and for the change or update from the refresh to be confirmed or indicated clearly.
  • When do they actually manually initiate a browser-level page refresh? --> I think that this will vary depending on the type of application and features, but if I was simply changing language I wouldn't expect to have to do this if there is robust internationalization and localization implemented for the application.

Not sure there would be a lot of relevant data for this, certainly not from my quick search and glance for what's online.

2
  • I agree with you on the first question but the second is more about finding balance between UX and code complexity - not about requiring the user to refresh a page when he changes locale. If the locale is changed so seamlessly (via a single AJAX request as I described), the actual new page locale gets into a conflict with the one passed via URL query parameters. Now we need to decide: how crucial the scenario of a possible page refresh at this point is? Should we introduce more code complexity for the page to not revert the locale if it would be refreshed? – Stanislav Bakharev Feb 26 at 20:40
  • @StanislavBakharev the second part about finding the balance between UX and code complexity can't really be answered without having input from the developer and getting into implementation details, which would probably be outside the scope of the UXSE forum. And if we are answering the question from a UX perspective, the user won't care about the technical details so it is not really relevant unless we have to make decisions based (or weighed more towards) technical constraints. – Michael Lai Feb 27 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.