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

http://blog.self.li/post/23668063348/few-lines-of-code-improved-ux

by legierski • 14 years ago

21 20 14 years ago

blog.self.li

rrrene• 14 years ago

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?

terinjokes3• 14 years ago

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• 14 years ago

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.

glassx• 14 years ago

The sessions are probably stored on the server, and they expire after some time.

It happens a lot here where I work: our legacy ASP.NET WebForms use Sessions (because it used to be easier this way) and once in a while people complain that the app kicks them after some 20 minutes.

mootothemax• 14 years ago

What are these "universe glitches", when one gets logged out by the browser

I've had a situation in the past where a session has regenerated - giving the impression of expiring - due to lots of AJAX calls over a period in time. Basically, you got X number of pageviews with the current session token before a new token was generated.

IIRC, the browser's session cookie wasn't getting updated due to the calls being via AJAX, and hence the user was logged out. It's been a long time since this happened though, so I may have a detail wrong.

artursvonda• 14 years ago

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• 14 years ago

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?

givan• 14 years ago

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.

chime2• 14 years ago

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.

terinjokes3• 14 years ago

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

michaelfeathers• 14 years ago

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.

bobsy• 14 years ago

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• 14 years ago

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

Jabbles• 14 years ago

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

MehdiEG• 14 years ago

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• 14 years ago

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

chime2• 14 years ago

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• 14 years ago

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.

bluesmoon• 14 years ago

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.

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

Related Stories