7

In a web application, let's say the user has several sections, which are lists of records of data that can be searched, sorted, etc.

Example navigation:

- Clients
- Accounts
- Projects

let's say a user has done some work on the client section, i.e. did a search, and then goes to the projects page. they then go back to the clients section, should that section be in the same state it was when they left it, or should it be back to its default view? If it should stay the same, how long should it stay that way, i.e. should it remember the users last action after log out?

Improve this question
1
  • 2
    Are they going back to the clients section via the Back button or via navigation links you've got on a sidebar or header? My general expectation as a user is back button = remember, navigate = clean slate. Sorting, I generally expect to be remembered regardless because that can/should be handled via cookies.
    – Karen
    Dec 21, 2011 at 21:26

3 Answers 3

Reset to default
3

It’s a bad idea to destroy users’ work, unless they explicitly say they want it destroyed. I would think that if users have gone through the trouble of filtering and sorting the data, chances are they want to keep it that way, perhaps even between sessions (e.g., with cookies), not just between paging. If you anticipate users often wanting to return to the default presentation of the data, then you can include a Default or Reset button for each or all your presentation criteria.

Your real problem may be convincing users their work won’t be destroyed by merely navigating away for a moment. Experience from the stateless web may make them assume their work will be lost, and they’ll do awkward work-arounds (e.g., adding tabs) to avoid page-navigating. Now they’ll won’t be able to benefit from your work to make your pages state-ful. Training or documentation could help.

Another possibility is to bag the whole pages thing entirely and show each page in a separate window. Users won’t hesitate to “navigate” away from a window to another if the first remains open –they’ll expect that the state will be preserved when the click back on that window. The only catch is you have to have separate windows for every page. If you mix separate windows with paging navigation, it’ll confuse your users –they won’t know what rules apply. It’s probably only a good idea if you have relatively few pages/windows that users use at a time.

Improve this answer
1
  • I would like to mention your insightful article about Back Button zuschlogin.com/?p=41 . It was a interesting read.
    – FrankL
    Dec 22, 2011 at 14:10
0

The web is stateless. Most clients don't get that, so always expect the web to act like their desktop software.

So, from a technology standpoint, no, there should be no need for this as it's really counter to how the web works.

It can be done, though. Cookies are one way. Updating query strings from page to page is another. Or with rich AJAX apps, you can forgo the concept of a page altogether and just do constant DOM updates within the initial page (and updated the URL accordingly to preserve back button functionality)

Improve this answer
7
  • The cookie (or session, if using PHP) idea is a good one that I've used a few times. I save a custom SavedState or PageState object into the cookie or session (serialization) and, upon the user's return, un-serialize it. Sometimes it contains a series of commands or "steps" to manipulate the DOM, if necessary, upon page load. At least these objects contain any information for server and client to restore the state.
    – Matt
    Dec 22, 2011 at 0:03
  • If users' expectations are counter to how the web works, does that mean users should change their expectations?
    – Taj Moore
    Dec 22, 2011 at 1:01
  • @tajmo: sometimes. But I was referring to clients. Clients often request things that are completely counter to their own experience as web users themselves. A client may ask for 30 second flash intro with music soundtrack while completely not making a connection to the fact that, as users, they likely hate 30 second flash intros with music on sites they visit. :)
    – DA01
    Dec 22, 2011 at 5:10
  • @DA01 So true. I guess that's why we have "user experience" and "client experience" AKA account services, marketing, sales, etc.
    – Taj Moore
    Dec 22, 2011 at 15:55
  • A web application often strives to replicate the experience of working on a desktop application, so I think the client expectation is a valid one. Furthermore, while the internet is stateless, why would that mean that every application or web page should be stateless? Introducing state is basically the entire point of cookies. "from a technology standpoint" doesn't seem to be a very useful statement when asking what the best user experience is. Finally, the question was asking about whether they should store this aspect of state, not how it could be achieved.
    – AlannaRose
    Mar 11, 2015 at 1:17
0

Whether you retain state for different aspects of your site depends primarily on how your site presents itself. If each area of the site feels like a completely separate 'application', then I would not expect state to be remembered between areas. However, if the site is the application, and each area is is presented more like a 'tab' in a single application I would expect state to be preserved.

As far as how it should be presented, that would depend on performance issues. If the amount of state is tiny (search terms, sorting parameters) then there is little reason not to retain state, and you can present the site as a single application with multiple areas. Your users will likely benefit from being able to return to an incomplete task. However, if the state required is large, and your user count is high, then it would probably be smarter to forget state information when leaving one area for another.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.