Best approach for maintaining/persisting search criteria/filters when user returns to a search page?

Question

Say I have a basic "search" page on my site that allows user to enter filters and keywords. Then a list of results appears, and the user can click on a result to go to a "details" page about that one item. (For example: vehicles for a car dealership, houses for a real estate agency, employees for a law or medical practice).

I want the search criteria that the user entered to be re-populated when the user navigates back to the search page (either via the browser's "back" button or by clicking a "back to results" link on the details page).

My question is about the UX tradeoffs of different implementations. In the past, I've done this in one of two ways:

1. store search criteria in the session and read the session when the search page is viewed
2. use HTML5 pushState (along with a polyfill like history.js for compatibility with older browsers) to write each new search criteria / filter combination into the URL querystring (so the search results re-appear when user clicks browser "back" button), and also pass along the search criteria to the "details" pages (so the "back to search" links on those pages can link back to the search page with those same criteria/filters).

The problem I run into with solution #1 is if the user has cookies disabled then it doesn't work. Also, it can sometimes be over-aggressive... for example, if the user comes back to the search page a day later, they most likely do want start a new search with new criteria and filters (and not just see the same criteria from yesterday). I've run into this myself on several forum websites I frequent -- where I hit the main page and it's already restricting the forum posts it shows me to a limited amount based on a search I did earlier (but I forget about this and get confused).

The problem I run into with solution #2 is that it is a lot more work to implement. Also, if the user clicks around to another page on the site (where the nav link to the search page doesn't have the prior search criteria embedded in its url querystring), then the criteria are lost.

So... any ideas? How do people generally implement this pattern? Are there other approaches besides the 2 I've mentioned above? Or perhaps I'm barking up the wrong tree and shouldn't even be doing this?

Answer 1

From a UX perspective, I think that a user generally wants to search again if they go back to the search page.

In this instance, would it be better to have three steps, similar to Google's approach? Search > Results > Details. If you hit back from the details page, you are directed to the search results again. Back again would get you to a new search. This is easier to implement as well, since you can put the search query in the url. Granted the search would be done again, but that shouldn't be a performance issue if your search is efficient enough.

Furthermore, you could load the relevant filters on the Results page from the url parameters.

Hope this is helps!

Answer 2

Query 1 can be resolved by setting the saved cookies to expire, if that's the desired action.

Often recipients of cookies can be assuaged by letting them know the reason for the cookies i.e. "Making search easier" etc.

The way we have tackled this situation in the past is by having a tab on the screen, in our situation it was desired to have it fixed to the bottom right, but you would need to investigate your own best location depending on your users and your site.

As users searched, the search and the criteria were appended to a list, which was brought up by clicking the tab, the last 20 were saved with the oldest dropping off as more searches were performed, a simple star next to each saved search allowed a user to "save" it and that search would never drop off the list.

The list showed the search term and any criteria, and clicking it would instantly perform that search. As a "saved" search these types of search would not add to the list, as it was already performed from that location.