How to handle history events from scolling and other in-page events

Question

On a website that has several sections and subsections on one page, I was thinking about implementing scrolling to a new section as a new browser history event. The main reasoning for doing so is to allow for linking to a specific section of the page by keeping the URI in sync to the section currently viewed by the user. I.e. on a page http://mypage.com/apage/ scrolling to the second section of the page, the browser address would change to http://mypage.com/apage/section2/ without any page refresh, and also enter this new URI as a history point to the browser's history.

Similarly, I have a lightbox overlay in some of the sections. I want to register a history event for having the overlay opened with a specific content. Here, too, the reasoning is that I want users to be able to link to something like http://mypage.com/apage/section3/subsection2/lightboximage4/ and people clicking this potentially shared link open the page scrolled to section3, subsection2, with lighboximage4 open.

Is the entering of history events like scrolling to a section or opening an lightbox overlay confusing? I imagine a scenario like someone browsing different pages, then scrolling to a section and clicking back to return to the previous page - with the result of scrolling up one section, because that was the last history event.

-

Do the advantages of well structured URI's outweigh the potentially harmful effect on usability, or am I worrying about a problem that is none?

What other situations or events could be equally problematic to programmatically insert into the browser history?

Should I detect history back events and internally redirect to user as far back in the history to what I deem the real last history event (i.e. actual different page view or top section change)?

Answer 1

The "#" fragment URL is the standard way to indicate a location on a page and the history management for that is already build into the browser (basic example).

The lightbox state could also be encoded in hash fragment URLs, I think this is standard enough behavior that wouldn't pose any usability problems.

Answer 2

Interesting question. People generally expect the back button to take them back to the previous page, rather than back to an arbitrary point on the same page. By that logic, one should only add an event to the browser history if the transition from one view to another appeared, from the user's perspective, to be from one page to another page. People are unlikely to associate the act of scrolling up-and-down with moving between pages, even if it's triggered by clicking on a link.

Answer 3

If the main goal is to allow users to bookmark various locations on the site, why not use URL variables that change as the user navigates the site?

This would allow the browser history to remain untouched and work as the user expects, and likely reduce the work load of trying to make it perform a lot of abnormal functions.

EDIT

If this is a potential solution, I will try to explain what should work without going too deep into code. If you were to set events on either scrolling (using something like jQuery Waypoints) or on your lightbox clicks, you could update the hash with something like

location.replace("#puppy-lightbox");

which will update the hash in the URL but not affect the history in any way. This will allow you to freely update and change the hash based on the user behavior, but not force them to use the back button multiple times to return to where they were.

A bit more code would have to be added to make the bookmark links initialize the state of the URL, but more information can be found at here on that.

Hope this helps! :)

Answer 4

I think that autoscrolling a page to some section specified in a shared (or saved) link is a bad idea.

The problem is with scrolling. I mean, if you use anchors (i.e. '#' parts of an URLs) in a regular way, browser will open the desired section (a section anchor points to) in front of users eyes quickly.

And sometimes it doesn't happen quickly (heavy page which is still loading, etc) . I.e. user have to wait until something unknown will happen to get the content. The worst thing is that there is no any visual aid of that (i.e. user may even don't know he or she have to wait to be relocated or scrolled to the right section, etc).

So, in your case, user will see the whole thing, will start to look at the page and then everything will begin to scroll and change. That's really really annoying.

So, I think you should not touch URL at all (and let users to use a navigation), or avoid changing the page layout after the page was loaded or do it very quickly so user will not notice this change at all.

Answer 5

This is a problem we tackled in products as well. Our issue was for the do/undo stack, rather than sharing. In our case, some undo would have significant impact on the navigation of the user. We handled it by adding navigation actions to the undo stack. This is a similar approach to what you are talking about.

I also had a talk from Jeff Heer, prof at Stanford, from when he was working on ManyEyes. He had a similar approach to yours to accommodate referring to content within a page. i believe that with single-page web app pattern becoming mainstream, this approach will become the norm quite rapidly.