distributedlife

News Just In: The back button on a web browser is not an acceptable solution to failing to provide appropriate navigation.

Consider the following scenario on a web application: You have a page that displays a list of items. This list is sorted in a complex manner. I.e. you sort the list by more than two columns by default. As an interface designer you need to provide a way to revert to the default sorting. As soon as the user clicks one of the columns to specify a custom sorting they lose the ability to return to the default sort.

Recently I had a UI designer suggest that we educate the user on using the back button to return to the default sort. Aside from educating the 6,000 users current users and N new users, this has several problems.

This solution only works if your web-page literally navigates to display a different sort. Users associate backward and forward transitions with navigation. If you don’t navigate then the back button isn’t the logical solution. Users do not use the back button to correct a typing mistake. If you do navigate to a different page to change the sort order, use Ajax to do it inline. Nobody likes a flickering web-page just to provide sorting capability.

If you use Ajax then the back button will return the user to the previous navigated page, not the previous sort. The back button only uses the browser history for navigation. It does not support fine grained undo functionality.

Neither of these are the real problem. The real problem is that you want to provide two tier sorting by default without providing any visual indicators that you are performing two-tier sorting. On top of this you are not capable of providing a means by which the user can return to the default sorting.

You can do this by displaying how the sort is currently implemented above the table “sort: column A then column B” and providing a “reset sort” link that is enabled when the default sorting has been changed.