How a few lines of code greatly improved a crucial part of UX

Another even easier and quicker way to greatly improve UX in many products is better copywriting (possibly by hiring an actual copywriter).

Quite frankly, I know I'd be quite puzzled if a message popped up out of nowhere telling me "You might be logged out, please, back up your content and refresh the page!".

What do you mean by I /might/ be logged out? Am I logged out or not? And why would I be logged out? What does this have to do with anything anyway?

And what on earth am I supposed to do to "back up my content"? What does this even mean?

And what is this "refreshing the page" business all about?

To be honest, being a developer myself, I would actually figure out what you actually mean. But I can guarantee you that 99.9% of the people out there won't have the faintest clue of what you're talking about. They'll just do what they always do in this case: they'll click OK, or Cancel, or whatever they think is going to make the annoying message go away.

I agree that there are better ways of solving the problem. Getting back to the root cause would be good. But, over the years I've seen too many cases where users have to live with a poor experience while the development team is working on the "right way." It's nice to see the experience of the user taken seriously.

This strikes me as odd: "After a complaint from one of our users [...], we realized that the very same thing could happen to someone else"

One user complains about something that might have happened by his own doing and the OP starts implementing a feature, that not circumvents the end result (can't save the content) but notifies the user that the software is broken somehow.

Anyway, I'm genuinely interested in the following:

What are these "universe glitches", when one gets logged out by the browser? Session Cookie vanishes? Server restart invalidates some kind of access token?

We did something similar while building the CMS for the Yahoo! home page. Now the way auth works (and should work), is if you try to access a restricted page and you're not logged in or don't have the necessary privileges, you're redirected to a login page. This is all done automatically by apache and your back end app has no control or knowledge about this.

On the front end, auto-save is done using an XHR call from JavaScript. If we detect a 302 response from the server, and the Location: header was set to a known login pattern, we'd inform the user of this, and allow them to log in in a new window/tab.

On login, the new window/tab redirects the user back to a page in our app. The page in our app does two things. 1. It calls window.opener.someCallback() 2. It calls window.close()

The callback function then makes a call to the server to fetch a new csrf token (you do use csrf tokens, don't you?) and then re-attempts the save.

This reduced user frustration significantly.

I do not know if this app is still in use.

I don't think this is a good solution. If you have 1000 users logged in you have a 1000 extra requests a minute just checking the status of the user. This is to solve an edge case.

My company had a problem with clients being logged out after 20 minutes. You would think this is enough time but some people would spend hours editing content without pressing save. We implemented 2 solutions. The first was an auto-save. This pinged the server and removed the primary cause of the issue. The second thing was a warning which triggered after 15 minutes of inactivity. If they pressed OK some data would get sent to the server and the timer would start again. We are not concerned about random "universe glitches"

I would have thought a better way would be to add a listener for form submissions. Check if user is logged in. If so - send data. Otherwise login form can pop up or data can be put into a session or something and reappear after the client logs back in.

This means the user doesn't need to know how to copy and paste.

Here's another way to deal with this. Upon each successful am-i-logged-in call, the server returns a relogin-as-user-X ID back to the browser (this can continue to be the same cached value or have timestamp/TTL if you want). If since the last call to am-i-logged-in, the session is lost for any reason (server reboot, client changed IPs), the browser will simply post this ID back to the server, which will perform the authentication and relogin.

To make this secure, make am-i-logged-in no-cache, don't store the ID in cookies/localStorage, encrypt/decrypt the relogin-as-user-X only on the server-side, and timestamp it with short TTL.

If you are already able to detect that the user has logged out unintentionally and just minutes prior to that you knew they were logged in, then you might as well just log them back in again. Of course, if the user logs out intentionally in one tab, then do not log them in automatically in the other tab. Simply stop returning any valid relogin-as-user-X IDs.

Why not just give a random session key or something equivalent? That way, the user can post to /save/?key=<userkey> to save, regardless of sessions.

I think the probleme is elsewhere, maybe some cookie or memcached problem, I never heard of browser logging out people, maybe the cookie expire time is incorrectly set.

Another way to make sure work isn't lost is to save it in browser storage when available. This would also work in case connection is lost.

Does the auto-save function they've already implemented not return a value representing failure? Is that value ignored?