When interacting with the app offline I want to see a visual 'offline' indication rather than an infinite loading indicator, so that I know that the app is offline and some app features may be limited.
This is a design task and has space for defining the exact user experience. The use cases are:
- The browser looses the network connection when the app is already open and the user is in the middle of doing something, but no network request is in progress.
- For a client-side view my UX expectation is that the app detects the online / offline status change and displays a permanent visual indication of the 'offline' state, but lets the user to continue working with the view. The developer may disable some UI elements while the app is offline.
- For a server-side view my UX expectation is that the app detects the online / offline status change and displays a permanent visual indication of the 'offline' state, and blocks any user input until the connection is restored. Once the connection is restored the user input is unblocked.
- The browser looses the network connection when the app is already open and the user has pressed a button, and is waiting for the response. The loading indicator is visible.
- For a client-side view my UX expectation is that the loading indicator disappears (and gets replaced with the offline indicator). The network operation fails with a network error and the developer is expected to handle it. The user is free to interact with the app further, though the developer may disable some UI elements while the app is offline.
- For a server-side view my UX expectation remains the same as with V17 and before: the app shows a 'reconnecting...' message and blocks any user input until the connection is restored. Once the connection is restored the pending request is re-sent and the app continues from where it was interrupted.
- The browser looses the network connection when the app is already open. The offline indicator is visible. Then the user navigates to another view.
- For a client-side view my UX expectation is that the URL is updated and the new view is rendered. If it makes any network requests on the first render or in response to user actions, they are handled as described above.
- For a server-side view my UX expectation is that the URL is updated, but instead of rendering the actual view content, the app shell renders a 'you are offline' stub view (as described in https://github.com/vaadin/flow/issues/9132). Once the connection is restored the view is rendered (unless the user has already moved to another view).
Current behavior with Vaadin 18.0.0.alpha1 / Flow 5.0.offline-SNAPSHOT:
vlukashov
All 9 comments
A quick prototype for one idea: https://output.jsbin.com/hurulub
Not really usable on touch devices, so those would need additional care.
Some thoughts:
- The default indicator has to be very discreet, not really block any parts of the UI, since we can鈥檛 know what might be in the app, what parts are still usable even when offline
- There should be events (or some other API) that allows developers to create custom UIs to indicate the offline state (this seems to be the most common approach in real-world applications)
- Developers should be able to disable the default offline indication, if they want to manage that part of the experience completely in the app
- We could create a reference example about a widget/component that you can place somewhere in your application UI, that reacts to the connection status
jouni
on 23 Oct 2020
Comments from a grooming session:
- need a state machine diagram with a clear definition of all states: online / offline, request in progress / no request in progress, navigator.online but connection lost, server-side view / client-side view
- need to find the right term: it may be not OK to tell that the user is _offline_ when the app is not able to reach the backend, but
navigator.online == true(e.g. _connection lost_) - need to define if there is a need for separate visual indicators for offline (
navigator.online == false) and connection lost (navigation.online == true) - need to define what should happen with the devmode gizmo in the offline mode
vlukashov
on 27 Oct 2020
With V14 the app could be in the following states: connected, loading, reconnecting, connection lost. The navigator.online flag plays no role in determining the application connectivity state - it depends only on the ability to connect to the Vaadin UI instance on the backend. The state diagram would he roughly this:
With V18 I suggest to keep the same 4 states and avoid introducing a separate "offline" state that would be different from "connection lost". However, the 'reconnecting' state would only make sense for Flow views, but not for Fusion views.
The navigator.online flag and the online and offline events could be used as an optimisation to avoid sending Flow heartbeats while the browser is offline, and as a substitute for heartbeats when Flow is not used in the app and Flow heartbeats are not available:
An updated (still very rough) live prototype: https://stackblitz.com/edit/vaadin-loading-indicator-proto?file=index.ts
vlukashov
on 3 Nov 2020
@vlukashov That jsbin doesn't seem to work for me (504 Gateway Time-out) even though jsbin front page works.
Haprog
on 4 Nov 2020
@vlukashov That jsbin doesn't seem to work for me (504 Gateway Time-out) even though jsbin front page works.
updated a live prototype link
vlukashov
on 4 Nov 2020
SubTask
Have a state store for storing the connection state of the app. Implement state transition based on the statechart and real use cases #9343.
SubTask
Have a state indicator component for storing the connection state of the app. #9322. Note this shouldn't break the custom loading indicator and reconnection dialog. Currently, styles can be customized based on v-xxx styles, timout can also be configured. See https://vaadin.com/docs/v14/flow/advanced/tutorial-loading-indicator.html
SubTask (#9424)
When receiving an online event, should also check the connection to the backend, similar to the heartbeat request or head request.
SubTask (#9401, #9402)
API for customizing the loading indicator, and the reconnection dialog. Currently, the API is in AppShellSetting. This should be supported for compatibility reasons.
SubTask (part of #9401, #9402)
Be able to customize the text in the visual indicator.
SubTask (Optimization)
For Flow, stop the reconnection request when offline, should continue sending when back online. Heartbeat is handled in #9207.
haijian-vaadin
on 5 Nov 2020
Updated state diagram, combining the Flow and Fusion transitions and with the state names proposed in #9377 (CONNECTED, LOADING, RECONNECTING and CONNECTION_LOST):
joheriks
on 12 Nov 2020
Make sure we can have both fusion and flow views, and navigation between them would have a consistent connection state.
haijian-vaadin
on 17 Nov 2020
Close this Epic as it passed due. All the tickets in this Epic are closed except one in Review.
haijian-vaadin
on 3 Dec 2020
Related issues
marcushellberg
路
4Comments
Artur-
路
4Comments
vlukashov
路
3Comments
mcollovati
路
4Comments
manolo
路
3Comments