Designers should present search results in a place and manner where the searcher can see them without needing to adjust her browser.
In other words, after I click “search” one of two things needs to happen:
- The click launches a new page and the search results are at the top, the first thing I see OR
- The search results appear directly below the search field or button and are immediately viewable and obvious.
For the moment, let’s forget about the psychology and cognitive friction (or greasing) in how that search came to be. I’m focusing on what happens after kicking off the search with a click or tap of the return key.
Search engines like Google and Bing follow option one.
Enter search terms (the query) and initiate the search, then read the page that repopulates your browser.
When you start typing a search query, Google and Bing will offer suggestions as you type, before you complete your query. Although the suggestions come from real people using the search engine, both try to guess what you might be looking for based upon your location.
LinkedIn search twists the auto-complete design metaphor by displaying search results in real-time, as you type your query.
LinkedIn presents matching results options in a dynamic fashion similar to the search engines. Notice that there is a hint of auto-complete with “interactive designer” being suggested as a search term. But immediately following that are search results.
We can argue about the effectiveness or depth of the LinkedIn search engine, but results presentation is immediate and obvious.
Not so with the City of Seattle’s job search, which is powered by NeoGov.
In both Safari and Chrome (Mac), after I initiated a search (that teeny tiny “Go” button at bottom left), the resulting display left me scratching my head.
Actually, it had me clicking “Go” a few more times, convinced that nothing was really happening on the backend.
This is what I saw on pages one and two of the search results.
No jobs are visible on either search results page.
The page suggested that there are job openings: “47 records found.”
But where were they?
I tried to scroll down, but there was nothing “down there.” I changed browsers. Same result.
Finally, and I can’t explain why I did this, I clicked “inside” the white area of the search result and then either tried to scroll or tried to page down. That’s when the search results appeared.
Scroll bars (a visual hint that there is more content below the fold) are still MIA, but it’s now pretty clear that there are search results to be seen.
At least part of the problem lies in how the NeoGov information is included on the page: it’s inserted as an iFrame.
<iframe src=”http://agency.governmentjobs.com/seattle/default.cfm” name=”neogov” width=”100%” scrolling=”auto” frameborder=”0″ ID=”neogov” style=”height:1600px”></iframe>
When we go directly to the page that has been embedded with an iFrame, we can see that it is designed to show all available jobs by default.
Ironically, this externally-sourced page is available via the Seattle Career Center primary navigation as “Job Opportunities.” But since the page that we are on is named “Job Opportunities” there is no reason to suspect the link goes elsewhere. Moreover, you have to right-click and select open in new tab or window to see the external page with all available jobs displayed by default.
Why no scroll bars inside the iFrame?
Modern browsers no longer show a scroll bar unless you are actively scrolling.
While I’m typing away in this WordPress compose box, there are is scroll bar on the main browser page or this box.
When this blog posts loads in your browser, there is no visible scroll bar until you click the page or press the spacebar. And even then, the scroll bar appears only momentarily, then disappear.
Browser designers seem to have been seeking a “clean” appearance as they implement HTML5. But the result, an unintended consequence perhaps, is less visible information for a first-time website visitor.
What’s a designer to do?
In the case of the Seattle jobs search, the designers may have no choice in how the filters and results are displayed. If the only option they have is to embed this set of code as an iFrame, their hands are tied unless they follow the example of King County and link directly to the externally-hosted page (which has no agency branding) or the example of the state of Washington (which does have agency branding).
If other NeoGov customers complain, maybe those designers will fashion an alternative.
Putting filters in a lefthand column fits current ecommerce filtering design and also matches how LinkedIn displays filters.
Given that scroll bars in modern browsers seem to toggle ‘on’ only when you seek to scroll rather than to provide a clue that there is a need to scroll, designers will need to provide other (verbal? visual?) clues when it is not obvious that content exists below the fold. Or the search box.
It means that horizontal blockers may be more troublesome than they were in the past.
Because everyone on the web hasn’t been here for years and understands that there might be hidden information.
And even when they have been around a while, they might be stumped.
