30

I'm looking for an answer considering both technical limitations and user experience.

Does it need a reload from a technical standpoint?

Improve this question
2
37

Sort of, yes.

Global login uses HTML5 localStorage (under the stackauth.com domain) to work around cookies not being available*. As a consequence, this means that we can't recognize a user at page render time; we have to wait for a non-trivial amount of javascript to load and execute.

Once global login has finished, we've got the user information... but the user could already be interacting with the page; a hard refresh would be really unpleasant. We actually tried this in the very early days of the global log system; if you've got a really speedy connection** it's ok, but any sort of latency results in a UX that makes you want to punch your screen.

The one exception to this rule, where we do in fact automatically navigate away, is when a user is on the login page. Presumably all the user wants to do is login there, so global login completing is a strong signal to navigate away from the page.

*We can't attach a cookie on askubuntu.com from stackoverflow.com, nor can we access stackoverflow.com's cookies from askubuntu.com; as an example. This is the crux of the issue. We used localStorage instead of third-party cookies (which would impose the same constraints, but be simpler to implement) because Safari has really dodgy support for third-party cookies.

**Remember, a solid 1/2 of our user base is on a different continent than our data center. We work hard to make our code fast, but we can't do much about the speed of light.

Improve this answer
5
  • 1
    Great answer for very non trivial issue.. added to favorites for future reference. :) – Shadow The Vaccinated Wizard Feb 14 '12 at 7:15
  • 14
    "we can't do much about the speed of light." Slackers. – Pollyanna Feb 14 '12 at 7:39
  • Can you explain what you mean by "to work around cookies not being available"? – Adam Lynch Feb 14 '12 at 12:33
  • Can you also explain, how can you save localStorage cross-domain? I thought localStorage is limited to one domain, as well as cookies are. – Karel Bílek Feb 25 '13 at 2:26
  • I'm sure you guys have already looked at this, but it strikes me that relatively little of any page's static content is altered depending upon the user's login status. Surely login completion does not need to force a page refresh, but instead trigger dynamic updating of relevant page elements (topbar, past voting signals, favourite tags, etc.)? – eggyal Mar 14 '14 at 9:01
5

According to balpha's answer at Why does it says "welcome back -user- click here to 'refresh page'" it is not a technical issue, rather it's because you may already be reading a post. If that was the case, an automatic refresh would be annoying.

Improve this answer
2
  • 3
    Certainly not enough reason to inconvenience all those who may NOT be reading a post. – Kris Feb 14 '12 at 4:26
  • I login in to multiple sites sequentially. The login process up to the point where I reach 'new questions' is tedious enough, and with its repetition for all the sites, well you can imagine. – Kris Feb 14 '12 at 4:28
5

Does it need a reload from a technical standpoint?

Kevin explains why it's this way now.

If they wanted to make it so that a reload was not required, they would have to change a lot of data that's currently static based on the cookie to dynamic (AJAX/javascript/jquery/whatever) loading.

So it's possible to change the system so that a reload is not necessary.

However, it causes a substantial penalty in page loading time. Right now a lot of page data is static, but if everything were dynamically loaded you'd have to wait some time for the javascript to load and run, communicate with the authentication servers, and then communicate with the original server again prior to letting the browser render the page.

You could do a hybrid, where it loads the static content, then replaces it once it's received new info, but that may result in the same symptom - the page appears to reload while you're reading/scrolling/etc.

So yes, it's possible, but it's not practical from a performance standpoint.

Improve this answer
7
  • 2
    "it's not practical from a performance standpoint" - I don't buy this. If a user is logged in, the server need not send the relevant dynamic updating code; for users not logged in, the code is sent but not triggered unless the user is automatically logged in by the existing auth code. So the only negative impact would be slightly more network load/delay for anonymous users... is that a priority that outweighs additional convenience for regular users? – eggyal Mar 14 '14 at 9:04
  • So you want them to hold off on page rendering until enough JavaScript has run that the system knows who you are? You want every page for non logged in users to take that long before it starts showing content? That's a terrible choice. You might have a fast computer with a fast internet connection, but why should stackexchange optimize for you, and leave the other 30-80% of its google audience to twist in the wind? – Pollyanna Mar 14 '14 at 12:05
  • No, render per anonymous user and then update page elements from hook that existing auth code currently uses to display the "refresh this page" message. – eggyal Mar 14 '14 at 14:52
  • @eggyal Perhaps you missed the part where Kevin explains that they did try this: "Once global login has finished, we've got the user information... but the user could already be interacting with the page; a hard refresh would be really unpleasant. We actually tried this in the very early days of the global log system... but any sort of latency results in a UX that makes you want to punch your screen." I suppose you might be one of those individuals that enjoys your webpages changing while you're interacting with them, but I've seen this before and I hate it. Fewer punched screens is good. – Pollyanna Mar 14 '14 at 14:58
  • Whoa, I don't know that the personal attack was deserved. I'm not talking about a hard refresh. I'm talking about dynamic updating of page elements: it'd be no more harsh from a UX standpoint than the current dynamic updating of rep, etc. Which is what I had thought your answer was all about. Perhaps I misunderstood? – eggyal Mar 14 '14 at 16:44
  • @eggyal I'm sorry you felt attacked, it's not my intention. It sounds like I don't understand your proposal. There are many, many things on the page that change once you login. For instance the voting buttons and text for each post have different javascript attached to them. The right hand bar may show different content. New buttons appear for those with higher reputation. There aren't just a "few" places on the page where a dynamic refresh must take place - nearly the entire page changes. The biggest is the removal of inline ads - which will mess up layout while reading. – Pollyanna Mar 14 '14 at 17:27
  • Perhaps you can add an answer here to better describe your idea. A marked up screenshot with circles around all the elements your suggested dynamic refresh would change might help people understand your proposal better. – Pollyanna Mar 14 '14 at 17:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .