Do we need a word for when a browser tab has sat too long and you just don’t trust thing are going to work as you expect them do when you come back?
I tweeted that the other day and apparently other people had them feels.
It’s that feeling where you just know your session isn’t valid anymore and if you actually try to do anything that requires you to be logged in, it ain’t gonna work. It’s particularly uncomfortable if you were actually trying to do something and now you’re unsure if it’s done or saved.
As for that name… here’s some good ones from the thread:
- Schrödinger’s tab
- Crusty tab
- Tab smell
- Stale tab
- Fossilized tab
- Tab napping
- Dead tab
- Orphaned tab
- Tab rot
So how do you fix it?
It’s a UX issue, really. Depends on the situation. Here’s some options.
Shut it all down.
Banks do this a lot. When your session expires, which they time-limit pretty aggressively, you don’t just sit on the page, they log you out and send you back to a log in screen with a message.
They might warn you:
Then you’re gone:
That might seem a bit much for a site with less sensitive security. But it does quite nicely solve the (let’s pick one) “Dead Tab” issue. You aren’t left wondering anything. It took action, logged you out, and dropped you on a page where there isn’t any half-baked state.
Stay where you are, but warn about actions.
Many sites want to keep you logged in. Ideally, as long as it’s secure, you’d be logged in forever until you explicitly log out. Logging in is an awkward dance that nobody particularly enjoys and keeps you away from doing what you want to do.
CodePen is in this category, I’d say. We’d rather not log you out agressively, but certainly you can get logged out either with long periods of inactivity, or you can log yourself out. Say you logged out on a different tab… that’ll log you out everywhere, but at the moment we don’t anything for those other tabs left often that look like you are logged in.
That’s the “dead tab” issue. But we do warn you if an action happens that you can’t actually do.
WordPress has a kind of awkward flow related to this. Tabs can easily become dead, and if they do, you get no warning at all. When you perform an action that you can’t do, you’ll get this:
That’s a kind of middleman page that actually does refresh you session, so if you do “try again”, it usually works. It’s scary every time though. Even if it doesn’t work, the biggest risk in WordPress is losing writing, but even then, autosave usually saves the day.
Here’s an example on CodePen where I created a Pen when I was logged in, but logged out elsewhere, then tried to save.
I’d give us a C- here. At least you know what’s going on and you don’t lose any work, but, from here on out it’s awkward. You’ll have to log in on another tab, and probably copy and paste code elsewhere to save it, as the “dead tab” can’t get un-dead unless you refresh it.
If we were gunning for an A, we’d allow you to log in on that page without refreshing somehow, and make sure any unsaved changed get saved after the successful login. And with an unsuccessful login, still make sure you get a copy of unsaved work somehow. We might call that…
Stay where you are, warn proactively.
Perhaps messaging like: “You’ve been logged out. You can log back in here.”
To know this, the front end of your site needs to know about the log in status either periodically or in real time. For example, a server-ping every X seconds to check that status and if you’ve become logged out, show the message (without requiring any other action). Or perhaps a more modern websocket connection that could push the logging out messaging as it happens.
If you can wire that up to all happen on any page of the site, not require changing pages to fix it, and never lose any unsaved work, that’s pretty ideal.
The truly dead tab
The worst case scenario is when the tab has died, and there is no path to recovery. It doesn’t tell you it’s dead, leaving the page could result in unsaved work or actions, and there is no warning or recovery steps.
Have you seen great UX for this?
This is a major issue in that it affects every single site you can log into. It’s both suprising that there isn’t more talk and best practices surrounding this, and that there aren’t some stand-out sites that handle this particularly awesome to shout out.
Do you know of some particularly good (or bad) examples?
ISO compliance (27k) has mentioned this for some years. Basically, the organisation needs to not only make a decision based on user-needs and expectations but to protect any sensitive data.
Here in the UK many businesses have traditional SW turn off after a minute or so of inactivity and supplement that with policies to lock the terminal you work on whilst you’re at work.
I’ve always found the true UX issue here that it’s a total PITA to be auto-logged out for any reason, but where compliance exists I’ll defer to simple “You can’t fight the man!”.
Craft CMS (your office mates, I believe) earns an A here – when your session has died, it brings up a login modal that lets you re-authenticate without losing the work you may have had going on in the background.
Also, it’s the best CMS out there by far.
WordPress does this too, also saves your progress even IF you close the tab
GitHub does this, but only on the desktop version of their website.
I think Jira handles this pretty well actually. Usually I come back from lunch and my session has timed out, but it warns me and brings me to the login page, then when I log in, it pops me right back to the page I was looking at. And of course when I go to any other tabs, I can just hit refresh and my login will be captured and I’ll be able to update the page as usual.
The solution to this belongs at the browser level.
Currently, tab parking extensions time out after 20 minutes (configurable) of being in the background. I think this should be built in to browsers.
I think this will never happend at browser side! Imagine the user can change the page’s timeout, then prepare to serious server upgrades maintaining all the http requests sessions alive. The costs doing so could be very important.
I hate it when I’ve been on a website for some time filling out a form. To the web server, I’ve been inactive so my session hasn’t been refreshed and in the background I have been logged off. When I finally push that submit button, I’ll be prompted with a login screen and… my painstakingly filled in form is gone.
When it’s just one field I have filled in, I’m in the habit of a quick Ctrl-A -> Ctrl-C before submitting (just in case the session has timed out or I experience a sudden loss of internet connectivity). That’s a bit harder to do with multiple fields.
As others before me have mentioned, I think this should be the responsibility of the browser. The browser should be able to retain filled-in form data, so the user may retrieve it if need be. For security reasons, maybe the web server could send a “flush cache” directive in the file header the browser must comply with.
The worst is when the form is long and the time-out is short. By the time you’re filling in the 3rd out of 20 fields, you are auto-logged out, there’s no warning, and you continue filling out the form, only to find none of it saved (the autosave function only works when all fields are filled out and you successfully click ‘next’). I hate the HR department where I work, as this is the only system they will use for accepting resumes or any other HR related issue.
I’ve found I have to manually write in all related info into Google auto-complete, then log in to HR’s form page, type in the first letter of my name, click the popup to accept Google’s autocomplete entries, and hit enter. I still only manage to get to the next page of the form about 50% of the time. The worst is that I have to start at the beginning after every time out.
The sad part is that HR sends out notification emails to remind us to fill out our forms and genuinely seem baffled as to why we don’t do it right then and there. I’d tell them why, but the email is no-reply and sending them a message requires more forms.
Ah, GitHub was already mentioned!
I believe it should not be solved on a browser level, but on a web-extension one. Something like https://addons.mozilla.org/en-GB/android/addon/form-history-control/ could do.
If the problem domain is explored well enough, feel free to suggest an API to W3C ;-)