How to let the user decide to keep the state of a site

Question

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?

Answer 1

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.

Answer 2

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>

<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>

<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>
</div>

<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';
    }
</script>

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

Answer 3

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).

_Ken