How to navigate between item list, search and item details?

Question

I have a hierarchy explorer-like list of folders and items. User can select one and explore its children (child folder and items):

[Top folder] -> [Child folder 1] -> [Child folder 2] -> [Child item 1]

Back button navigates back up to the parent folder.

At any moment, user can search through all the hierarchy by the search bar at the top:

[ActionBar  ]
[Folder View]

When user hits search, a list of search results is shown below replacing the current folder view:

[Folder] -> [Search results]

The user can click on the search result list representing a list of folder and\or items to show the content of that folder or item:

[Folder] -> [Search results] -> [Folder A]

The user can navigate within folder and then perform another search:

[Folder] -> [Search results 1] -> [Folder A] -> [Folder B] -> [Search result 2]

But with this kind of infinite navigation, how should the back button work like?

After a few searches, navigation by the back button can become very confusing.

It would still be nice for the user to be able to navigate back to the search results.

One solution I have:
Place the search results in a separate tab. Navigating back within the folder\item view tab, will only navigate up. User will need to switch back to the search result tab. It would also require having a way to close this search tab.

What are your recommendations?

Answer 1

Very interesting question indeed. Suppose the search feature does not exist yet. How do you handle the back button? Probably you simply have a pointer to the current folder (the one displayed at the folder view) and when the user press the back button you simply move to the folder parent. Right? In that way, I think is safe to assume that the "search" you are talking about only happens along the children of the current folder. Otherwise, it kinda does not make sense to have a tree-like navigation, and it would simply be better to have the search results in a different window (where the user can indeed specify where the search starts).

If you want to have a solution with search results included in the hierarchy, you need to first change the way you handle the back navigation. You will have to memorize data about what is before the current view, so when the back button is pressed you can decide to simply go up one folder in the hierarchy or show again the (previously saved) results of a search. My suggestion is to keep this data in a graph, starting at the first folder you show at startup and ending at the current folder/search results shown in the folder view. Remember that I am assuming that the search results include only files and folders bellow the current folder in which the search was performed.

An important thing, as noted in the previous answer given by @Poyi, is to present the user with a feedback about where she is. The suggestion about using breadcrumbs is perfect, in my opinion. You could use what yourself suggested:

/folder1/folder2/SEARCH1/folder3/folder4/SEARCH2/folder5
(/folder1/folder2/folder3/folder4/folder5)

This means that the current folder is "folder5"; it is displayed in the breadcrumb (first line) as the steps the user did in the navigation; it is displayed completely (second line) as a complete path. At this point, when the user presses the back button, the result becomes:

/folder1/folder2/SEARCH1/folder3/folder4/SEARCH2
(/folder1/folder2/folder3/folder4)

and the folderview presents the previously results of search2, which includes children bellow folder4.

Answer 2

With a spontaneous browse/search design like you described, one possible way to enable back navigation is to introduce some type of breadcrumb (you might have to use a vertical one since it can be really long). Therefore users will be able to go back as many level as they want just by clicking the folder's name they were viewing.

Below is merely an idea and feel free to ignore it:

If you already have a good hierarchy setup for the folders, instead of allowing the users to browse from a search result and the folder explorer view separately, I recommend you make the search page to be simply a page of results matching the query(folder name). And when the users click on a particular search result then it directs them to that folder view (can be any point in the hierarchy) so users can start browsing from there. In other words, search is merely a way for users to enter this hierarchy tree more efficiently.

Answer 3

Any UI approach that employs back/next navigation is prone to confusion, especially in cases of multi-level page navigation. However, there are some usability benefits for back navigation simply because users are not enforced to navigate to the associated entry point from scratch. On the contrary, deep-navigation stacks have the inherit problem of making out what is displayed and on how the UI comes up to that state.

In your case, navigation between folders, search results or any other view types should be carried out from a single UI(no tabs) in which users should have a sense of what is displayed (a breadcrumb control) while back and forth buttons should navigate to the previous and next views with exactly the same state.

Answer 4

The backward navigation experience is probably best implemented following the conventions of the web browser. That is to always navigate backward, and never forward, to previous visited pages. This means that if the experience was like your last example going forward:

[Folder] -> [Search results 1] -> [Folder A] -> [Folder B] -> [Search result 2]

Backward should be absolutely the same.

[Folder] <- [Search results 1] <- [Folder A] <- [Folder B] <- [Search result 2]

Real Search Behavior

However, if a user after [Search results 1] is presented goes back and forward three times before deciding on [Folder A], the backward navigation should be the same as in previous example.

Forward (with two wrong routs).

[Folder] -> [Search results 1] -> [Folder X]
            [Search results 1] <- [Folder X]
            [Search results 1] -> [Folder Y]
            [Search results 1] <- [Folder Y]
            [Search results 1] -> [Folder A] -> [Folder B] -> [Search result 2]

Backward

[Folder] <- [Search results 1] <- [Folder A] <- [Folder B] <- [Search result 2]

Why only backward to parent?

The resoning behind only going backward to parent is that the extra trails are considered as a wrong path, since the user went back to the search result page. Even if it's not the best experience you imagine, your users will recognize this behavior.