This wasn’t evident until I tried to implement a “unified” search-and-filter box. The plan was to submit a search once the user typed 3 characters, then filter that search result set as the user continued typing. Brilliant, right? It turned out not to be so simple.
What happens if the user corrects a typo in those first three characters? We would have to recognize it as a new search.
What happens if the user backspaces into the first three characters? By default, the filter code would see we had a search active, and continue to display all of the results.
What about the default state? Do we display all our results, removing the idea of search (and its conservation of client memory), or do we display recently modified records? Can we filter those recently-modified results without causing a search to wipe them out? When do we go back to displaying recently-modified items as the user deletes text?
Would the user be surprised and dismayed if they crossed an invisible boundary, and their search results vanished, replaced by a filter of that default view?
There’s another potential optimization missing: if the user adds a character at the beginning of the string, then we could theoretically be filtering the already-available search results. However, this means we would need to track the “search window” as it wandered around in the word. That would make it even harder to know, as a user, when the result list was going to jump around.
Thinking about all of these details made me really appreciate the thought that went into NewEgg’s design, where “search terms” act as individual filters, exactly like product attributes. (The difference is, NewEgg doesn’t have live filtering of the results; the “search within” UI reloads the page with an additional text term included.)
PHP & Perl Web Development, and the Craft of Programming
