When faced with a single search box on a page, from the user's point of view, it makes sense to just try to see what it does by keying in queries in the search box as opposed to trying to figure out what the search box is supposed to do by reading text.
I'm a bit dense so it took me a long while to figure it out. It all began when my institution started on LibAnswers - a Knowledge Base/ FAQ system by SpringShare. This allowed me to track what was been searched and what they clicked or did not click, in response to the results.
This frustrated to me no end (and no this wasn't just because I had a personal target to ensure x% of searches were successful!) surely they didn't think there would be a FAQ answer on that specific book or article they were looking for did they?
And given that they had to come to this page from the main homepage that did embed the library catalogue (not withstanding those who googled in directly) they shouldn't be confused that this was the library catalogue or search right?
A few months later, I realized part of the puzzle. We were embedding FAQ search boxes on our research/subject guides.
As users were in a state of mind looking for resources to help them with their assignments, they saw a search box and they assumed it would find them resources. This accounted for a lot of the article and book searches I saw.
I was naive enough to think this could be fixed by adding text to explain it was for FAQs (mostly on library rules). But no amount of text added
a) above the search field
b) below the search field
c) In the box header
d) In the search field
helped. People still searched for resources.
In the end I resigned myself to the fact that the user was not broken. A guide that was supposed to help with assignments/research was supposed to have search boxes that search for articles or books. It was the natural to expect this!
It made sense, since this was where people were searching for books and articles and while Summon wasn't quite the perfect one-search for every article accessible , it was close enough, so it was a no-brainer to add it there.
Did it help reduce the number of searches for books and articles in the FAQ search?
Yes, by quite a bit and they now all went correctly to Summon, but here's the thing... I still saw searches for book titles, articles titles and other content titles in the FAQ. And they came from the FAQ pages (not subject/resource guides) itself.
In particularly digging down I noticed they were on the FAQ pages "How do I find masters and phd thesis?", "How do I find full text of a article" and similar FAQs relating to resources, which gave detailed instructions on how to search.
To help users, I pretty much used the same idea and embedded Summon search boxes in such FAQs when appropriate, so they could search directly from there and reduce the temptation to search books and articles or theses in the faq search.
Of course, in some cases I couldn't do anything. For instance from the FAQ page "How do I get impact factors for journals?" , searchers reached that FAQ page then decided to type in journal title names in the search at the top of the page presumably they were hoping the impact factors would appear.
And I guess you won't be surprised to note even after all these efforts there are still a fair number searching for book titles and journal titles in the FAQ box including those carried on the homepage of the FAQ. And I wouldn't even be so hard on them if it was for items we didn't actually have (so this could be a last ditch search just in case), but the fact is most of them were for searches that would have succeeded if they searched the right search system.
I am not sure when it was I got this epiphany but it was this
When faced with a search box on a page, from the user's point of view, it makes sense to try by keying in queries in the search box as opposed to trying to figure out what the search box is supposed to do.
And if you think back to the above example where people are searching for journal titles on the FAQ page which shows them how to find impact factors, is likely to be used by research and academic staff rather than undergraduates, this affects even our "serious" users.
Which is easier? Type in a book title and see if the results gives you what you want? Or read the often wordy explanation (sometimes even having to go off-page via a link) to try to figure out what the search box covers?
I would argue it's a smarter strategy to just spend 30 seconds typing in the query and looking at the result, then spent cognitive effort trying to understand what the search box covers.
In many ways, it's obvious when you look at the company that is now a verb for searching
Notice, any attempt to explain what is been searched? :)
I would add that this is one reason why I argued in the need to have a "true" one search box that covered not just books and articles but also faqs, library rules and every sort of library related content.
As related in that article , many libraries are now moving towards a "bento style" box moving in content from different silos showing a few selected results for each, and allowing the user to select which type of results he wants.
This requires quite a lot of expertise to integrete different APIs together, so a simple but less sophisticated system would be one that detects zero or few results and follows a link which when clicks searched other systems with the same keyword. Eg. if the libanswers system detects zero answers, it would offer a link that when clicked searches Summon with the keyword.
What about tabbed search boxes?
In the above example, we are talking about single search boxes where there is usually no choice what-so ever to switch to another mode. This makes the temptation to just try it out and see what happens even stronger, since
1) You have nothing to lose but seconds of your time
2) What other choice do you have? You only have one search option!
But what was multi-tab boxes, that gives you options? And hence it makes more sense to try to figure out which one to search with?
As detailed in my recent analysis of Summon using libraries, such designs are fairly popular making up slightly over 50% and I suspect they are even more popular among libraries without a web scale discovery solution as there is no decent one search box solution.
The good new is , based on past research on the subject and my own experience of usage of our multi-search boxes, many users do not blindly search using the default tab, a fair minority switch tabs - the figure varies , about 20-30% usage results from switches from the default tab
It's less clear though whether this implies most are searching with the correct tab (this varies I guess on a number of factors having to do with user base) but at least search tabs do encourage users to switch search modes more than other methods such as pull-down menus.
I suspect given options that are easy to activate ie search tabs, a fair number would indeed make an effort to figure out what each search tab does, at least more than when there is only a single search box.
So this effect is lessened, though I would think most would still be biased to try out the default tab, look at the results, if its totally wrong, go back and switch to another promising tab rather than spend minutes reading the descriptions trying to figure out which tab to use. Without a lot of analysis this is hard to check.
After all, what does the user have to lose if he is wrong the first time?
BTW If you want to keep up with articles, blog posts, videos etc on web scale discovery, do consider subscribing to my custom magazine curated by me on Flipboard.