Posted by admin on September 9, 2008 | No Comments
Perhaps most of you learned readers consider yourselves Internet savvy. When you end up at a web site with way too much content — or if you simply want to fnd something quickly — you look for the Search box, enter your search term, press ENTER and off you go. No worries, and probably 90 percent of the time, no second thoughts either.
Now consider this conundrum: Surrounded by people who think that being able to find stuff on Google should be a manadatory job skill, I was tasked with revising the search feature for a human resouces (HR) related web application.
What’s the big deal? Well, for starters, the typical end user is not too computer literate, aged somewhere between their late 30s and 50s, and eight out of 10 are female HR directors.*
* Before you complain to me and accuse me of being a completely biased male chauvinist, let me make absolutely clear that I, as a person, have nothing negative to say about the demographic sampling I just described. And I am in no way insinuating that everyone who falls into this category is experiencing technical difficulties. However, as several years on the job have taught me and my fellow-workers (the majority of whom are female, by the way), seven out of 10 clients who call in about technical issues a) fall into the category I just described and b) are having “higher than usual” technophobia. That, however, is another story altogether.
Back to the subject at hand: How do you revise a web application’s search function without intimidating the people who pay to use your product? We used to have a straightforward and simple process to search either by first or last name. You enter the name, then you select one of two radio buttons (first or last), and then you click Search.
However, as people progressed in their use of the web application, they also realized that this was limiting their abilities to search for specific employees in other departments or locations.
So in the process of re-designing and re-programming the entire web application, I came up with something relatively Web 2.0 (see screenshot below). The idea was to provide an extended set of search options (first name, last name, department, division and location) into one compact search box.
Those end users who aren’t too familiar with this kind of approach are supposed to click the info icon for more information. And if you’ve changed your mind about doing a search, you can close the search box by clicking the “X” in the upper right. (By the way, simply clicking anywhere outside the search box will hide the search box, too.)
So far so good: It’s a great improvement over the previous version, that’s for sure. Yet as simple as it seems, there is some serius opposition to change within the organization. “What about the Search button?” they ask.
Hmmm, good question. Personally, I think we could easily cram something into the search box, if we wanted to. Then again, we’ve wanted to avoid having too many controls in an already densely populated area of screen real estate.
Other people have even implemented search features that start crunching and returning results as soon as you start typing text into the search field. For example, Peter deHaan at the flexexamples blog uses the “type and wait to search” approach:
Although I’ve gotten used to that kind of funky-ness, I have to admit that it used to creep me out when I first encountered it. Am I doing the same thing to the end users who will be using my web application?
