Flow: As a website visitor I want to have a usable website even after my session expired or the UI was closed

[paulroemer]

As a website visitor it's likely that your session will expire or the UI will be closed or the client-side is disconnected because of other reasons. As we disabled all kinds of confusing notifications the user will never know about the website's state.

Unfortunately, this also means that the user expects the page to be fully functional. So, he/she may try to login and presses buttons. But nothing will happen and the only information you will get is in the dev console: Trying to invoke method on not yet started or stopped application. Which means that the application knows that something is not wrong but just accepts it.

Can't we just try to reconnect to the server or trigger a page reload. Same behavior as if you would press a (router) link.

[Legioth]

Can't we just try to reconnect to the server or trigger a page reload. Same behavior as if you would press a (router) link.

Router links _can_ be handled since the describe navigation to a state that can be recreated without knowing the previous state, since everything is in the URL.

This is not the case with arbitrary actions such as button clicks since the corresponding server-side button instance is gone. Even if recreating the server-side state based on the URL, there's no guarantees that the button will have the same generated id as previously, or that the button will be there at all.

What can be done is to ensure that there is either an error message (but only after the user has tried to do a an operation that cannot be re-applied) or then simply reload the page. Reloading would recreate the state based on the URL, but that would still be slightly confusing to the user since the action they just performed (as well as e.g. any data entered into a form) would be lost.

[paulroemer]

Yes, but I still believe that reloading the page and may loosing some input is better than doing nothing here. Of course, getting an error that can be displayed when pressing a button and the server connection is lost would be nice for typical Vaadin applications. But for websites, especially for the webpage project, we do not want to show such errors...

[Legioth]

But on the other hand, a website should mostly be based on links where it's already assumed that it's OK to do a full reload, whereas the parts where losing the state might have an impact are quite rare. This means that it might still be beneficial to explicitly let the user know that state will be lost in those few cases?

[pleku]

I'm not sure what do with this, this is clearly also an UX concern so we should have the most common default option for a closed/disconnected session situation and possibly allow some other easily changeable presets for this.

Could it be an option to make it possible to have the Flow client side automatically refresh if there is user interaction on an UI which has lost connection to server ? E.g. user changes to a tab with Flow app that has been inactive for a day, then the client side picks up the new activity (mouse move event?) and triggers the reload immediately before the user tries to interact with the app ?

[Legioth]

Transparent reloading is already implemented for any interaction involving router links. Any other actions have a significant risk of discarding user input or other similar state. Automatically refreshing would also have the risk of discarding input.

[pleku]

The desired UX is quite much influenced by what type page the user is looking at, and whether there has actually been any data entered or not. Thus it could be really nice to be able to configure this on view-by-view base or even dynamically depending if there are any changes.

I think the "take note of all changes and reload" notification is not the best UX when there is really nothing done and instead the user would just want to continue using the app without being forced to think.

[Haprog]

From the perspective of our webpage project, I would very much like it so we could easily set the default to do automatic page reload on any user interaction (or any modern way we can detect that a tab just became active) since on most of our implemented pages you can't really input anything anyway (other than use login/register dialog). Like what @pleku described above.

But it would be good to have a mechanism to also easily change this behaviour for some specific views where we want to make sure the user doesn't lose changes/input that may be important and in that case a friendly message could be displayed about taking note of your changes and that a reload is needed.

[jouni]

Continuing the brainstorm above, if the developer could configure when to show the message, I think it would be great if the developer could also configure _where_ to show the message. For example, if a user was filling a feedback form, comes back after the session is expired and tries to submit the form, it would probably be nicer to show the message right next to the form instead of a banner at the top of the viewport.

[heruan]

In my experience with FW8, most of the times the "Session Expired" popup was shown a silent new session wouldn't had hurt and could have saved the user from a forced reload. Also, we have apps displayed on video-walls to show charts and dashboards, where there is literally no user (and no keyboard) so when a session expires we need to log on the video-wall system and force a reload on every screen, where a silent new session would be fine.

[pleku]

I think we will want to design and fix this properly before releasing 1.0. It can have a major impact for UX thus I consider it to be critical we make this as customizable as possible, with sensible (and good looking) default behavior.

Now just need to make the designs and find the time for the implementation.

[jouni]

@pleku, any update on this? Is this still a priority for 1.0?

I’m still up for helping with the design, but I can’t do it alone.

[pleku]

It is not currently a priority for 1.0, unfortunately.

We should do the design at some point though so then we could evaluate this as an enhancement to do during maintenance.

[pleku]

Decided to take this for Flow 1.0 scope and change the default to reload the web page on _any_ user interaction for the following use cases:

• Internal Error Dialog (server side exception)
• Session Expired Dialog (Session has expired)

Currently the session expired dialog is triggered by default and show a message to the user, and can be only triggered off by removing the messages.
Currently the session expired dialog is triggered on client side when the user interacts with the UI in a way that causes a server side request be done.

The defaults are changed for both dialogs in the PRs #3665 and #3666.
We will investigate if we should also change the session expired to happen immediately on _any_ user interaction on the page, instead of just something that causes a server communication.

[mstahv]

Please do those as defaults. This is also a developer experience issue. Then when developing with e.g. Spring dev tools, the view would be automatically visible on a second screen if you do a change in your IDE. //cc: @samie

[jouni]

I’ve spent some time thinking about various use cases around this, and trying to visualize them somehow to get a better understanding of the whole picture.

I ended with a flow diagram (no pun intended) for three use cases, which are the archetypal I identified the last one is not necessarily even directly related to Flow sessions, but it seemed relevant in this context. Feel free to add and disagree with these.

I tried not to be limited by technology and concentrated more on keeping the end user experience in tack. I think I ended up with a proposal that might be technically unfeasible, but I need @pleku, @Legioth and @Artur- to answer that.

I also didn’t yet think what kind of API changes this might mean, what would be left as the developer’s responsibility.

I think the current Flow behavior is somewhere between cases 1 and 2, and that’s the reason why it feels odd.

Diagram source: https://drive.google.com/file/d/1nG4VMtffwD2Yzjx-rso-JmgPkIN49TJu/view?usp=sharing

A more rough ideation document I used (in case you want some more food for thought): https://www.figma.com/file/aipLqwnRqAGaWqWx5VAIaDBi/Flow-system-message-scenarios

PS. I noticed while testing the behavior on ticketmaster.com, that Safari seems to stop client-side timers/rendering in some cases when the page is in the background. Possibly something to keep in mind when designing the implementation.

[masbaehr]

For those who want a scenario like in "case 2". (E.g. on session expiration the page returns to the login screen) this should do as a workaround

server.servlet.session.timeout=5m

In a global js file put this.

var reloadTimer;
var sessionTimeoutTime = (5*1000*60)+500;
document.addEventListener("DOMContentLoaded", function(event) { 
   reloadTimer = setTimeout(function(){
    Vaadin.Flow.clients.ROOT.poll();
   }, sessionTimeoutTime);  
});
(function() { // Overriding XMLHttpRequest
    var oldXHR = window.XMLHttpRequest;
    function newXHR() {
        var realXHR = new oldXHR();
        realXHR.addEventListener("readystatechange", function() { 
            //console.log("an ajax request was made");
            clearTimeout(reloadTimer);
            reloadTimer = setTimeout(function(){
                Vaadin.Flow.clients.ROOT.poll();
            }, sessionTimeoutTime);
        }, false);

        return realXHR;
    }
    window.XMLHttpRequest = newXHR;
})();

Feel free to improve/correct my workaround, or show other ways to do it, as I'm not yet happy with this.. feels "hacky" ;)

[mrts]

Would saving current state (data entered etc) to sessionStorage before page reload and restoring it from there after reload perhaps be a way forward?

[jouni]

@mrts yeah, for “case 1” that would one implementation alternative. I think it implies a full page reload, so it’s slightly less convenient for the end user. But it would be a great improvement.