How do I indicate that clicking a button will remove their search results?

Question

This is about a complicated application that holds 50 years of archived data. Some things are illogical and we can't change it because it's stuck in 50 years of rusted customs. But slowly I'll try and make it better.

There are tons of items ordered in a hierarchical structure. And sometimes the user will have a list of, for example, items which the user has found through a search action and has to do something with an item. At that moment the user will have no idea in which maps that item is ordered. So we wanted to give them some kind of map or breadcrumbs so they will know what the higher lying items are.

So the programmer says: "Why not give them links in those breadcrumbs so they can inspect the higher items?" But when the user decides he wants to inspect that higher item, the original search action will not be applicable anymore and be lost.

How do I design those links that they know the action is not reversible? He suggested an icon that indicates an external link (like wikipedia has ). Since there are no other external links in the application it won't conflict designwise. But I'm not sure it'll send the right message to the user.

Edit: One extra detail: There are external links. When a user wants to open a documentation/drawing about that item, the documentation needs to be opened in another program. They have an indication what kind of document it is, so they know what program will start. And they will get a warning pop-up screen about what's going on. They can cancel the action there. But the standing screen with the search results won't be affected.

Edit 2: At the moment the URL for the whole application is the same, which makes it hard to go back. I know the developers want to change that, but I/we don't know when that'll change.

Edit 3: I'm thinking of two solutions now. 1. Stop trying to make difficult links, the screen where the links are in is just an pre-information box. When an object really is selected the user can find out more about the objects parents in a more logical way. The conclusion is here that there is a reason not to add the links: It's less user friendly than it sounds. 2. Open the information directly in a overlaying screen. The user can open and close the screen without losing the search results. What the user wants is most likely to know more about the object they've found in the search.

Answer 1

It sounds like your real problem isn’t designing how to show a link is non-reversible. Your real problem is your app has committed the cardinal sin of breaking the Back button, which is an issue going beyond how you mark links in each list item.

Solving the Real Problem

Solutions, from most to least preferred:

• Fix the Back button. Okay, you say that the developers are getting around to that.

• Add your own home-made history functionality and UI. Keep the user’s search history with your own data structure and have an on-the-page “Back” button. If Search is a single blank, then it may be relatively simple to add a dropdown for the Search blank (i.e., use a combo box) and use a script in the page to add search strings to the combo box list as each is executed. Okay, maybe in your case making homemade history is just as much work for developers as fixing the Back button, so why bother?

• When the user clicks the link, open the result in a new window or tab as Tomaž Tekavec suggested in his second comment. Tab or window --whatever the users are most used to using. The user can return to the original results by clicking on the underlying tab/window or closing the current tab/window. Not a great solution given users have to realize they’re in a new tab/window (text or maybe an icon beside the links could help with that) and maybe they also have to figure out how to get back if they don’t already know. However, it’s better than having no way back. This solution will also tend to leave behind abandoned search results windows/tabs cluttering the UI. Oh well.

• If none of these are feasible, then, yes, the best we can do is try to warn users that they’re lose their old search results when they click a link. It's the least preferred solution because it puts users in a bind: they have to choose between going forward with a new search (via breadcrumb) or sticking with the search results they have. Which will be less work ultimately? Often they won't know until they see the results of the new search but by then it's too late.

No Icons

For warning users on this, forget about icons. There is no standard icon for “the Back button doesn’t work” and no easy way to illustrate it in a small space. As for the external link icon, the Back button does work for external links, so, assuming users recognize your icon, using it in this case is inconsistent with it's normal use. My rule for determining if an icon is intuitive or not: If you have to ask, it isn't. You need to use text.

No Messages Boxes

Forget about using an OK-Cancel warning message box after the user clicks the link. First of all, it wastes user’s effort: some users go through the trouble of clicking link only to find out they really shouldn’t have, and now have to click again to Cancel. For the rest of the users, many who already know from experience that they’ll lose the search results, the message box is just one more thing to click to get to what they really want. A "don't show again" checkbox helps, as Tomaž Tekavec suggests in his comment, but isn't enough IMO. The second problem with message boxes is we UI designers have succeeded in training users to not read them, so they’re next to useless.

Text with the Links

Such unconventional and externally inconsistent behavior as a broken back button requires clear explicit text to explain the situation to the users before they commit the action. Keep the text as terse as possible –if it’s too long, users won’t read it. Put it right where the users click so they almost have to at least glance at it before clicking. Try something like “Overwrites search results” after each item’s breach crumb link list.

In addition, if the users regularly use the app, then they probably are aware that each Search replaces the previous search results –they know Back doesn’t work for that (and they curse you blasphemously for it). If so, you can include the text “Search on:” in front of each item’s breadcrumb link list. By labeling them as a “Search,” users will hopefully realize that clicking the link does a search like any other and thus one cannot go back.

Test it, Train it

Given this lack of Back is unconventional behavior, you’ll probably need to do usability testing to get the right text in the right place. If your users are regular users, you probably also have to emphasize the lack of Back in the training and/or documentation (if any). Of course, when you add up all that effort, it might be better to fix the Back button.

As for the original developers that broke the Back button, may God have mercy on their souls.