Thursday, September 7th, 2006

Live Filter Pattern

Category: Articles, LiveSearch

>Peter Forde has written a piece on re-inventing search with a Live Filter pattern.

The article talks about his reasoning behind filtering vs. alternatives like Live Search, and ends with a Live Filter demo.

Implementation

Many of the concepts in this article would be very difficult to implement without Ruby on Rails. Rails introduces the concept of Partials. Partials are nothing more than snippets of fully formed XHTML which get inserted into the innerHTML of objects in a browser’s DOM by JavaScript. The specifics of this process are outside of the scope of this article. While you can update the innerHTML of a DIV or SPAN using any Ajax-capable scripting language such as PHP, there is an architectural elegance that enables this filtering system that we believe would be difficult to replicate.

Implementing a filter system that works across all common browsers is a real challenge, full of gotchas and necessary hacks. While nothing here is offensive, you might be surprised at how involved it can get. The reason being that it is of paramount importance to maintain the function and behaviour of the browser’s built-in Back button.

There are two main issues to solve. First off, if you modify the contents of your DOM with Ajax and JavaScript, move to another page, and then return to the form submit page, each major browser seems to corrupt the state of elements on the page in subtle and different ways. For example, Firefox will corrupt the selection state of checkboxes generated at run-time! The second problem is that if a user returns to the search interface with the Back button… what is the user going back to? Suddenly our flow diagram just got a lot more complicated!

The first revelation is that you should be prepared to write client-side functions to persist, restore, and clear the visual state of your filter. When you render the interface, all of your elements will be in their default state. During your document’s onload event you will want to execute an initialize function that can then “hydrate” the state of your elements from a hidden form. Likewise when submitting a query, you will not want to process the data associated with the form elements you see. Instead, “de-hydrate” the state of your interface into data on a hidden form that can be easily passed on.

During the initialization process, you will need to generate a new key value that could be assigned to a query request should one be submitted. You will use this value to build the action attribute of the hidden form that they might submit! This does need to be performed dynamically, in case the user has returned to a previously rendered page with their back button. Browsers can simply not be trusted to clear their page caches, no matter how many META directives you push down in your HTTP header.

One behaviour we’ve evolved while iterating this filter pattern is to remember the state of the last search when returning to the search page via navigation — unless the user specifically clicks on a major site navigation link to go to the search page. We interpret this behaviour as expressing a desire to start a new search from scratch. You’ll want to experiment and see what feels right for your project. These sorts of decisions are subjective and might change with feedback.

Live Filter Demo

Related Content:

  • Advanced packet filtering
    In this article, Laura Chappell shows you the steps required to build an advanced filter using the Sniffer...
  • Web filtering
    The legal and logistical implications of employees surfing the Web in company time for unrelated work issues have finally...
  • The builder pattern
    The builder pattern allows a client object to construct a complex object by specifying only its type and...
  • Geek humor: Dating design patterns
    What if everything you knew about design patterns, or elements of reusable object-oriented software, was a...
  • Spam filters with Postfix
    Check out these resources on how to configure Postfix with multiple spam...

Posted by Dion Almaer at 10:50 am
5 Comments

+++--
3 rating from 49 votes

5 Comments »

Comments feed TrackBack URI

Talk about taking a step backwards.

You might wonder whether the end result is worth the trouble. My opinion is an enthusiastic “NO!”

You should review Google’s success with their non-ajax 1 input box simplicity..

Comment by Jonathan Bond-Caron — September 7, 2006

This is an interesting pattern… but I don’t think its appropriate for all situations. The authors should have explored when it should be used and when the traditional approach would be better.

Comment by Sandy Bremer — September 7, 2006

I think if I got “live search” on googles homepage, I would stop using it is as my portal, and finally switch to Yahoo. I load Google because it’s fast and doesn’t crowd me with Javascript.

Comment by Ivan — September 10, 2006

Live Filter, Guided Search, and User Experience

An interesting post at Unspace discusses how for many applications, a filtering paradigm is more appropriate than traditional search. To use Pete Forde’s words: With a search, you start off with nothing and potentially end up with nothing. Counter to…

Trackback by kylescholz.com :: blog — September 10, 2006

This is just great. Seems to be pretty much the only tutorial on live filtering out there!

Comment by Timo K. — December 15, 2006

Leave a comment

You must be logged in to post a comment.