I’m looking for ideas to resolve the following: In a Web application with different parts that don’t have a direct relation it should be possible to switch between these parts and not losing the state of the parts. For example:

  • Client
    • List of clients
      • Client’s address
      • Client’s orders
      • Client’s xy
  • Employees
    • List of Employees
      • Employee’s timetable
      • Employee’s sales
  • Etc.

If the user is about to change the address of one Client and gets interrupted and has to see the timetable of an employee. After that the user needs to get back to the unfinished clients address.

I’m looking for a solution to give the user a possibility to do that. The common solution to switch between sites would be using tabs. Since this application runs on mobile devices, tabs are not a good solution because the lack of available space.

My idea is, if the user uses the navigation to go back to clients, the system will show the list of clients and the user would have to drill down again. In the navigation I would like to show a “show recent” function. This function would show a list of the pages the user had open during the session. There would be only one page per main navigation item (one for clients, one for employees, etc.)

Is there another way to let the user choose between going back to the same state of a part or go to the default page of a part?

  • Is this a web app or a native mobile app?
    – Matt Obee
    Oct 22, 2014 at 15:20
  • It's a web app. But my question is not about what technology to use. It's about how to accomplish a userfriendly solution for this. So I think it should not matter if it's a web app or nativ app.
    – BrunoH
    Oct 22, 2014 at 15:28
  • 3
    It matters a great deal because different platforms have different constraints, conventions and user expectations.
    – Matt Obee
    Oct 22, 2014 at 15:33
  • 2
    @BrunoH, the web is stateless en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
    – Ken
    Oct 22, 2014 at 20:46

3 Answers 3


It really depends on a whole lot of factors...the least of which is the complexity of the state you need to preserve. It sounds like in addition to state, you need to store user-entered data. This is not a simple task.

So, I'd begin with considering if opening a new tab is TRULY a burden for the users. Tabs are ubiquitous--even on mobile devices. If your users are relatively savvy with their device, you may find that this is what they already do...open up separate tabs so they can return to the 'state' they left your page from.

If, however, you have to preserve state, you likely want to ensure that--as much as you can--that any state change on the page is reflected in the URL's querystring. And that the app can rebuild the page as needed based on the data in the querystring.

For deciding 'which slide of a carousel to show', this is a fairly doable solution. On the other hand, if you need to handle complex branching of the UI based on dozens of variables, this may simply be untenable.

As for storing user-entered text, there's no simple way to go about this short of a constant syncing of the UI with the server. Apps such as Google Docs do this. There's a constant ping back to the server to 'autosave' the data presently being entered by the end user. The big hurdle here for mobile is that this can quickly eat up one's data plan--which isn't always a pleasant UX for the user when they get their bill.

  • Client state can easily be stored in HTML5 local storage when it needs to be persisted across browser sessions. You don't need to sync constantly...
    – perry
    Oct 22, 2014 at 21:24
  • @perry that's true...to an extent. There are memory limitations with local storage. But it may be a good option. The catch there, though, is if the data has to truly persist across devices (in which case you do want to sync directly with the server as much as you can).
    – DA01
    Oct 22, 2014 at 21:43
  • Querystring is more compatible, bookmarkable and easier to implement for persisting simple state variables, so it's not a bad recommendation.
    – perry
    Oct 22, 2014 at 22:00

Pretty easy. Put all your content into a single page so that initially the user can just scroll up and down the page to access everything. Now you break down the page into multiple sections by wrapping each section in a DIV. Finally, you hide all but one of these DIVs using CSS display:none, then you use the visible DIV to control the visibility of other DIVs.

For example, if you want to switch from one DIV to another, you hide the first DIV (CSS display:none) and show the other DIV (CSS display:block). This keeps all of the content within a single page without having to switch between pages or browser tabs to access it. Essentially the DIVs work like virtual pages. This technique is now loosely referred to as a Single Page App.

Working example:

<div id="page1" class="page">
    <p>This is page 1.</p>
    <a href="#" onclick="gotoPage('page1');">Page 1</a>
    <a href="#" onclick="gotoPage('page2');">Page 2</a>
    <a href="#" onclick="gotoPage('page3');">Page 3</a>

<div id="page2" class="page" style="display:none;">
    <p>This is page 2.</p>
    <a href="#" onclick="gotoPage('page1');">Page 1</a>
    <a href="#" onclick="gotoPage('page2');">Page 2</a>
    <a href="#" onclick="gotoPage('page3');">Page 3</a>

<div id="page3" class="page" style="display:none;">
    <p>This is page 3.</p>
    <a href="#" onclick="gotoPage('page1');">Page 1</a>
    <a href="#" onclick="gotoPage('page2');">Page 2</a>
    <a href="#" onclick="gotoPage('page3');">Page 3</a>

<script type="text/javascript">
    function gotoPage(id) {
        // first, hide all page divs:
        var divs = document.getElementsByClassName('page');
        for (var i = 0; i < divs.length; i++) {
            divs[i].style.display = 'none';
        // finally, show the page div that was requested
        var div = document.getElementById(id);
        div.style.display = 'block';

Paste that into an .html file and open it in your browser to test.

  • This isn't always viable on mobile, where you tend to be severely limited by network speeds and the like. Having to download the entire app as one page can add frustrations when on mobile.
    – DA01
    Oct 22, 2014 at 17:34
  • I disagree; it is the most viable UX-friendly option for mobile without having to resort to a native app. Of course you don't have to load your ENTIRE app into the page; just load your initial views and then use AJAX to request additional data or views from the server if needed. My answer was kept rather simple to make it easier to grasp the concept, since this is UX we are talking about.
    – perry
    Oct 22, 2014 at 17:45
  • AJAX is good, but I don't see how that solves the issue in the way you propose.
    – DA01
    Oct 22, 2014 at 20:37
  • Here's how. Let's say Page 1, 2 and 3 are each 500 KB which is simply too much data to send to a mobile device during the first page load - a 1500 KB page would negatively impact UX for mobile devices and cause some users to abandon. Instead of sending all three pages (1500 KB) on the first view, you send just Page 1 (500 KB) and you modify the gotoPage() function to make an AJAX request for the other page(s) from the server when the link for one of those pages is clicked. If the page has already been requested before, we just skip the AJAX call and proceed to the show/hide as usual.
    – perry
    Oct 22, 2014 at 21:04
  • I understand AJAX. I'm not clear how that resolves the 'preserve state when user leaves page' issue.
    – DA01
    Oct 22, 2014 at 21:06

You'll want to prototype a few solutions (even if just paper), validate with real users and validate the technical solution with an engineer. The information will likely uncover discussions about validation routines, connectivity, client/server trips and compromises about forced constraints and technical feasibility.

Be careful not to over-engineer a solution around a "gets interrupted" scenario. My usability mind starts thinking about the users environment and why tasks separated by various disconnected views are available on mobile (high cognitive load).

Again, dig a bit deeper into the use case, see if interruptions are what you should be solving. People are human and get distracted - especially in mobile settings. I am not confident any piece of software could change that. Perhaps your research will lead to a solution that leverages this aspect and you will look like a rockstar (of ux, of course).


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.