On Application Dev and Common Patterns – The Search System Part I

I’ve been building “enterprise web applications” for quite some time now and seen a number of recurring process/usage patterns evolve in my designs that I thought I might talk about.

Today’s pattern is the enterprise application Search System. Most application’s tend to have a global nav that’s broken up into a whole bunch of modules or entities. These are the base level menu items (for clarity I’ll use module here-in) of the application. Those modules are often directly tied to a fundamental business process, or a real life entity being operated on by a fundamental business process. Think the Customer module in a CRM (Client Relationship Management) system.

Then bellow these base level menu items you normally have a number of common operations; search, add, edit and show related. That is, search for or about a module’s primary entity, add a new entity in this module, edit an existing entity (involves engaging the search process), and show me related info to this module’s entity (another form of search), respectively.

Notice how the search system seems to be integral to second level menu items of all your system’s main modules. That there is an indicator that this thing called search is probably going to be an area to focus on when it comes to re-usibility, flexibility and agility of design and execution. Enter the Search System Pattern.

If you take this another step further, in most modules you often have a multiplicity relationship between two entities. In terms of a database, think about a foreign-key relationship beteen two entities.

In terms of an actual example, think the designated Customer of an Opportunity in a CRM system. For a given Opportunity you need to select a Customer that the opportunity is for, if both opportunity and customer are entities in the system then we have another prime usage for the Search System pattern.

From a usability perspective the Customer field on the Opportunity module’s detail screen should allow the user to do two of the 4 tasks in the main system nav; search for a customer or add one. Introducing yet another usability metaphor here is a mistake. The user’s already had to learn how to search for and sift through a list of results for Customer in the main nav. Why not re-use that metaphor again here when selecting the customer for this opportunity?

Not into the low level detail (that’s for a later posting) this is the essence of the Search System Pattern; a series of design decisions, architectural contracts and application interfaces that mean the user will be presented with the same metaphor anytime they need to select, add or find a related entity for a given operation.

It’s worth noting though, that in applications a “Search”, by it’s very definition, is very specific task. So you could waste many man hours trying to generalise and abstract the Search system resulting in an over-engineered, hard to understand system. You need to achieve a balance between delivering the specificity of an application search and doing it in a way that does re-use common code and user metaphors. In this respect, the Search System Pattern, is more than just a design pattern as it also involves usability aspects and metaphors as well as the underlying system design.

In the next article… Designing the Search System’s Data Access Layer