Readme - Seamless UI Upgrade

[petrklapka]

Jira Epic & Requirements

---

User Story:
To complete the “zero down time” experience for the end user, the UI should be upgraded seamlessly. The user will experience a transition to the new version of the client assets without losing unsaved state changes. The users experience will avoid an indeterminate state in the event that the user does not refresh their browser across two or more upgrades. A user who has not refreshed their browser that navigates in a way that calls for the loading of as-needed assets will not experience an indeterminate state.

---

Vadim's Initial Assessment:
There is a lot of work being invested into zero-downtime server upgrades. For our end users to make the whole upgrade process be transparent the UI should also upgrade seamlessly.

Essentially it comes to refreshing the browser page after the server has upgraded, so that the browser can load the new assets after refresh and show the new UI to the user.

In my understanding, the browser refresh must happen before the next server upgrade, for example, if we deploy to Serverless every day, the browser has to be refreshed within 24h after the last upgrade.

So, the question is how do we refresh the browser page? I am thinking we could try to do it seamlessly, so the user would not even notice, and in some cases make it explicit. Here is the idea:

We could refresh the browser automatically after the server has upgraded. The server would notify the UI and the UI would refresh at some convenient time. Now what is a convenient time?

Firstly, there should be no user unsaved state, so we will need to detect that.

Secontly, as Sebastien suggested, a nice timing would be to refresh when the user navigates. For example, the user clicks on some like and during that navigation we refresh the whole page.

There would be cases where we could not refresh the page automatically, because either there is unsaved work and/or the user never navigated. In that case we still need to refresh the page until the next deployment, otherwise it will have undefined behaviour. So here, we could:

Show a banner at the top of the page with a "Refresh" button, saying something like "Elastic was upgraded, please click refresh".

If the user still has not refreshed after some period, we will have to do a hard refresh, before the next deployment.

Those are just some of the ideas, still worth brainstorming in the team, maybe we can come up with something better.

---

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[petrklapka]

@vadimkibana - I recommend a conversation with Core on how to implement the notification mechanism given they've already put some thought into this. Beyond that, the implementation should be kept minimal for MVP. I would stay away from things like upgrading while saved state is being edited, maybe even the "hidden" refresh on navigation shouldn't be in the first iteration. Server to Client notification mechanism with banner notification to user might be all we need for iteration 1.

@sixstringcode - thoughts?

[sebelga]

If the user still has not refreshed after some period, we will have to do a hard refresh, before the next deployment.

I wonder if that is really necessary. Let's take the following scenario:

• Browser and server are on v1. Form has the following shape and that's what the server expects to store

interface MyFormV1 {
  fullName: string;
}

• The server upgrades to "v2" and expects this new payload now

interface MyFormV2 {
  name: string;
  lastName: string;
}

• The browser detects that the server has upgraded and immediately
  • Save the MyForm (v1) to local storage
  • Show a banner to invite the user to refresh the page (indicating clearly that their work has been saved and they can safely click the "Refresh" button)
• The user does not act yet
• The server upgrades to "v3", it now requires a new "age" property to be passed

interface MyFormV3 {
  name: string;
  lastName: string;
  age: number;
}

• The banner is still on the page.
• The user finally decides to refresh the page.
• Once the page is loaded we can:
  • Read the MyForm (v1) from local storage
  • Upgrade it to v3 (splitting the fullName in 2 fields and adding the missing "age" field)
  • Prepopulate the form with the new fields transformed from v1 in local storage
  • Both the browser and the server are "v3".. all good.
  • The "Age" field in the form will be "undefined" and the user will have to fill it before submitting the form

We will have to put a limit to how many upgrades we allow (or maybe better how much time "off" from the latest server version. e.g. "48h" that could represent 10 upgrades) before we really can't do a seamless upgrade of the form. But I think that in practice we should always be able to perform multiple transforms and leave the new form in a good state for the user.

[petrklapka]

The conversation around this topic has lead in a different direction and can be found here. No UX component or user interaction work is planned until the UX behaviors surrounding seamless upgrades are quantified post MVP.