

How a few lines of code greatly improved a crucial part of UX - legierski
http://blog.self.li/post/23668063348/few-lines-of-code-improved-ux

======
MehdiEG
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.

~~~
mhurron
> what is this "refreshing the page" business all about?

Look at a calender and note the year. Now realize that NSCA Mosaic was
released in 1993. Eternal September was in 1993 as well. That is almost 20
years ago. Do you really think that 'refreshing the page' is beyond 99% of
peoples knowledge?

That error message does need cleaning up but your target audience are most
likely not fetuses, so don't treat them like they wouldn't be able to put
their pants on in the morning if you didn't tell them how to in excruciating
detail, despite doing it every day, when they visit your site.

Oh excuse me, a 'website' or a 'site' is a virtual location accessed through a
'web browser'. A 'web browser' is a program that is used to access 'web sites'
over an interconnected series of networks called 'the Internet'. I know you
said you're a developer and may be able to figure this out for yourself but as
you said 99.9% of people wouldn't, I wasn't going to take that chance. Was it
too advanced for you?

Also depending on the issue 'might be logged out' may be completely correct.
Obviously something has occurred that is making part of the webapp believe
something has gone wrong, but it probably still has "Welcome [username]" or
"Logged In" at the top of the page. Reloading the page is really the only way
to verify something really bad is going to happen.

------
michaelfeathers
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.

------
rrrene
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?

~~~
terinjokes
That's what I was wondering, they solved user's problem, but not their
problem.

To me, it sounds like they might be expiring the session due to inactivity,
while the user is actively writing something.

EDIT: Typo

~~~
relix
Yep, that's probably exactly what's happening, I've had it happen too.

And the solution is the ping that he proposes. So if that was the problem, the
ping is resetting the session cookie every 60 seconds and the problem should
go away.

One thing I would add is a logging feature that tracks how many times this
actually happens (is happening) so they have metrics to back up any decision
in the future.

~~~
terinjokes
Then why isn't this ping _already_ part of the auto-save feature, and not an
extra request.

------
bluesmoon
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.

------
bobsy
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.

~~~
brlewis
IMO if you have 1000 users logged in, an extra 1000 requests/minute is in the
noise. And I tend to be paranoid about such things (e.g. I would add a small
random number to the 60s delay to avoid synchronization).

------
chime
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.

------
StavrosK
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.

------
givan
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.

~~~
chime
Browsers do not log out people, but servers do. My web host randomly drop all
sessions once a week. It is cheaper/easier for me to build auto-re-login
script than deal with a new host or pay current host to debug my server
issues.

~~~
terinjokes
Sounds like your webhost is deleting PHP's file based session store.

------
artursvonda
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.

~~~
wink
Yes, the proposed solution sounds a lot like working around a shortcoming of
the design with a hack (that needs constant connection and, if I didn't miss
the part, not actually saves the content, just displays a warning.

Why not save the content as a 'semi-anonymous' user, together with the user's
session cookie and on the next login tell there's some ghost session lurking
around and whether it should be kept?

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

