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?

  • I really liked your question right up until the third paragraph. Unfortunately implementation questions are out of scope for the site. Your question is better suited for SO. If you have a question about the usability of faceted search, this would be the place to seek more information. – Charles Wesley Jul 8 '13 at 17:16
  • 2
    I understand what you're saying... but this is a grey area because I'm not looking for help with the actual code, but rather what the UX tradeoffs are for each implementation. I figured that the UX stackExchange is better for more high-level questions such as this. But if you are speaking in an official capacity for the site (i.e. you're a moderator), I can post this to StackOverflow instead, and hope they don't tell me that it's too high-level and should go to UX instead :) – Jordan Lev Jul 8 '13 at 17:24
  • I am not a moderator just my opinion :) – Charles Wesley Jul 8 '13 at 17:27
  • Thanks Charles. I edited the question to make it clearer I'm asking about the tradeoffs of various implementations, not the programmatic solution of how to implement it. – Jordan Lev Jul 8 '13 at 17:36
  • For cookies, isn't it possible to limit their lifespan, say for 20 minutes or an hour? Regardless, previous search criteria should be maintained during the user's time spent on the site. If they leave and come back, there should be no persistence. – wootcat Jul 9 '13 at 17:28

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!


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.

Your Answer

