Should tabs changes in a web app be part of the browser history?

Question

I've implemented a JavaScript plugin that tracks tab changes in through the browser history. Here's a brief overview of how it works:

• Once tab is clicked, the URL hashtag (the part that looks like #hashtag) changes and the tab's content appears.
• Clicking the back button brings up the previous hashtag and the previous tab is given the focus.

Now that I have it working, I'm rethinking whether or not I should use it from a usability perspective. On the one hand, I have a legitimate use case for it: clicking on in-page links will both scroll to the appropriate section and open the appropriate tab. This is a very useful feature for my app and I would have a hard time abandoning it.

On the other hand, if one has looked through a lot of tabs (some pages could have a lot of sections, each with its own tab menu) on a page and then tried to use the browser's back button, I could imagine a user growing frustrated pretty quickly if they have to navigate through 20+ tab changes just to get to the previous page.

I'm leaning toward keeping the tab history functionality as it would be useful across my app. Also, there are only a few pages for my app and they are easily accessible from the menu, so that mitigate the problem to a degree. Before going down that path, however, I'd like to know if there is a better way of doing this, what my trade-offs may be, or if it's even a real problem.

Are there any usability studies on this particular issue? Any experiences or best practices that you could share?

Answer 1

I don't see any problem with the way that you have it now.

When someone clicks the back button it is to go back to where they were before rather than some idea that it should take you back to the previous node in some structure.

You're using it for a browser, so if I really want to go back to a tab that I was at 20 tab changes ago, I can simply click on that tab as a shortcut. However I doubt that anyone would be thinking about navigating to a tab that far back often enough for this to be a consideration.

I can't remember where I read this, but most change between tabs is between two or three tabs. When people open up 20 tabs, they usually read a tab and close it, then read the next.

But testing it with customers or beta testers is still going to be the best way to get feedback on whether this is a problem for your particular audience.

Answer 2

That "back" is related to "page load" is a technical artifact and not something the user expects unless they are used to being crippled by technology.

In an ideal world, "back" would work a bit like "undo" and get us back to where we were in time. The main problem is purely technical: How do I restore the state of a complex web app to the pixel? If the user closes the app on his desktop and opens it again on his mobile phone?

The question you need to answer is: What does the user expect? In Eclipse, "back" can switch between tabs and even perspectives (think of switching from one browser window to another). It includes: Reopen tabs (or even windows) if you closed them in the meantime, scrolling to where you were, setting the focus on the input that was active when you left.

If that makes sense in your case, that's what you need to do. But usually, technical limits will get in your way and you'll have to settle for the low hanging fruits.

Answer 3

As others have said, a starting point is needed.

However - where possible, I suggest starting with the standard mental model - in this case, clicking a tab within a page that doesn't reload does not affect the back-button.

You can then follow this up to check whether the other solution would be more beneficial.

Answer 4

This is a common dilemma - what's the correct browser history resolution for your app... Too much (eg updating the hash part whenever the user selects an object) and it can be very annoying. Too little and users might be surprised that the url they bookmarked (or sent to someone) doesn't bring them back to where they were. There is also the combined approach, where you don't update the url after every state change, but then you give the users a button that says "link to this page" which does update the url in the highest resolution you wish to support.

The answer ultimately boils down to user expectation. If users complain about the above issues (too high or too low res) then fix it accordingly. It's really hard to give a rule that would fit any application.

But you have to start somewhere, right? (before getting feedback) so I would recommend you try to answer the following questions as a way of deciding about the tabs:

• Would users expect to be able to forward or bookmark the tab selection?
• Would the back button's behavior surprise users if it changed tabs?
• Do tabs correspond to a "location" in your application?
• would users mind (or even prefer) explicit url updating via a button (that can also facilitate copying into the clipboard - added value)
• how frequently do users change tabs? (if not that frequent it's probably not a problem)

Answer 5

I would leave the browser history as it is now, especially if there are no complaints. People who rely on this behavior will actually face a minor form of data loss when changing the behavior.

If it is a concern, you could add a page-level breadcrumb trail to the application, either as an hierarchical display (top>cat>subcat), or as an actual browsing history. (Or do both, and test to see what the users prefer.)

Answer 6

As far as could tell from my personal expectations and things I read here in this very post, I guess Mark's answer is most compelling. I also have the same expectations as a user. If a browser reloads the page to show up tab content, then it should be listed in the browser history. Nevertheless I do not consider tabs that make page reload an actual tabs though. That's why I guess if I was you I would decide not to reload tabs and not including them in the browser history but just add up a "page link" button or field to be sure users will be able to share their location.