Archive for the 'search' Category

Search isn’t king anymore: Google recognises browsing

Earlier this week, I was doing some Googling and I noticed something weird: Google now has facets that are visible all the time:

Google search results showing a range of left-hand facets and an updated interface, for example a new button shape.

Google with facets

You might also notice that the interface appears more modern–the shape and appearance of the button has changed, for example.  You can read more about that at the Google blog, but it’s notable that a lot of what they have done is good for users; the new logo is more readable and will likely be faster to download for example.

The thing that really excites me is that Google has recognised that search is no longer king: by including always-visible facets on the Google results page, they have recognised that browsing, refining, and manipulating results sets are part of the natural human information seeking process.

Larry Page (one of Google’s founders) once said that “the ultimate search engine would…always give you the right thing. And we’re a long….way from that”. I don’t think he’s right, and the reason why I don’t think he’s right is that it is not always readily apparent, even to the information seeker themselves, what they want. Sometimes, it’s easy to figure out what information will answer our questions; when we want to know what the formula is to convert degrees fahrenheit to degrees celsius, for example, information seeking in the information age is straightforward and requires only a simple search ( ‘how to convert from deg c to deg f‘will get a perfectly serviceable answer, and in fact if all you want to do is convert a temperature you can use Google’s ‘in’ operator by typing ‘16 C in F‘, for example).  Sometimes, though, you don’t know exactly what you want; “a good present for my brother” or “a good book” or “how users search the library shelves” are information needs that can’t be met by typing a simple phrase into Google; they require a process that includes searching, browsing, and refining.  Take the “good book” example from above; you might feel like a mystery or modern literature, and once you;ve decided on that you might like a certain author or subgenre, but who or what that might be might also require some digging around to discover, and once youv’e decided what you want to read you have to figure out how to get it–as an ebook? from a library? from a bookstore, either online or physical? This example shows how we search out there in the real world when there isn’t a straight answer (and sometimes not even a straigth question), and how important it is to have the option to browse; again taking the book example, browsing might also show you other books that seem like you might enjoy them.

This isn’t the first time I’ve talked about Google and browsing–I’ve discussed before what a great thing it is that Google is incorporating browsing (and you can read more about how important browsing is in that post), and how their choice of facet location has influenced where we put the facets in our library search (and I’m really glad we went with Google on this one now). This is the most exciting time I’ve talked about it, though; Google’s results pages now reflect a truly natural information seeking process (without destroying the interface for “quick searches”), and thus represent a much better user experience than they have in the past.  Not only that, but this development will have a feedback effect: because Google has them, facets are more likely to be used in other information seeking interfaces (because users are used to them), and thus the experience of many of these interfaces will be improved as well.


Kartoo was clearly not for many users at all

Phil Bradley posted on Saturday that Kartoo, the visual search engine I blogged about as part of the 23 Things programme, is gone.

Back when I posted about Kartoo the first time, I mentioned a number of reasons why it might actively alienate some users, including its treatment of culture and gender–this isn’t a good start for a search service trying to break into a market that already has such clear dominance (Google accounted for about 70% of all searches in December, and is working to expand its range of services and thus its market share).  Had Kartoo really offered something interesting, then it could have attracted continuing use from those it didn’t offend at first sight, but like I and many of my fellow travellers on the 23 things program discovered back in 2008, Kartoo also didn’t offer anything interesting or useful in its interface or its results (and in fact it was downright hard to use).  Given how much you have to offer to break habits that work for users, Kartoo fell far short of the mark, and while I’m not so convinced that it had nothing to offer that I’m glad its gone, I’m not surprised either.

Why users like federated search (even though they shouldn’t)

‘Federated Search’ is a library term, it refers to search engines that search a variety of library databases (things that contain journal articles, conference papers and the like) and combine the results in some way to be presented to the user.

Federated searching is a somewhat fraught topic in libraries; many librarians don’t like federated searching and are hestitant to recommend it to library users.  This reluctance is not without good reason–federated search is inferior in many ways to using native database search interfaces, including problems with relevance ranking, the false appearance of comprehensiveness, and the inadequate de-duplication that many offer.  On the other side of this, federated search offers the holy grail of library searching: a single search box (well, almost–federated search usually doesn’t include the local catalogue, though sometimes it does, as in this example at UNSW).  The single search box is seen as being “like Google” in offering users a lot of different content from one search–and even has a slight edge over Google scholar in that search results will usually reflect more closely than Google Scholar which results a searcher can actually access.

Federated search has some issues that would normally be pretty big rpoblems from a user perspective too:

  • The relevance ranking doesn’t really work. Because federated search is pulling in material from a range of sources, each of which use different approaches to relevance ranking and different metrics to express a rank.  Any combination of these results is likely to produces flawed relevance ranking.  This means that often, the most relevant results will not be in the magical first couple of pages.
  • Federated search is very, very slow.  Again, because federated search is searching a number of remote databases and then applying some metric to combine results before these are presented to the user, federated search is very slow. Typically users are unhappy with slow response times, so this should be a real problem for users.

So, we know librarians are often hesitant about recommending federated search, and that users have every reason not to like it…and yet study after study shows that users do like and use federated search.  So why is federated search so popular?

  • One stop shopping: Federated search offers users a one-stop shop, and even though they know it isn’t as good, they will often use it anyway.
  • Time saving: Despite the long load time for search results, users know they will save themselves time (and likely frustration) by visiting only a single site.
  • Search syntax: Search syntax varies slightly from site to site, and federated search allows users to forgo learning the variationson syntax required by individual databases.  Given that we know boolean searching is hard (sorry, paywall), it is easy to surmise that learning less about it is considered a good thing by users.
  • Low user expectations: Users expect library systems to be slow and clunky, so their expectations of federated search are lower than they would be for other web-based services.

Users’ willingness to use a system we don’t expect them to like is an object lesson in how usability principles are not entirely universal: Occasionally users will tolerate unusable systems over more-usable ones because the end result is still a faster and easier user experience.

So, does users’ willingness to put up with the limitations of federated search mean we should stop striving for anything better? I don’t think so.  I think that as web technology improves, users will have less tolerance for slow and clunky systems.  We’ve already seen this at Swinburne with the library catalogue–while it hasn’t changed our users surveys show increasing levels of dissatisfaction as a result of user expectations that have been raised by their interactions with other systems.  I don’t believe that users are going to be willing to individually visit library databases in the future any more than they are now; even Google is meshing different kinds of data in its search results.  I believe there is real benefit to be had for librarians and library users alike in making headway in one-stop searching, I’m very much looking forward to seeing Primo Central and Summon (the next generation of federated search, where metadata is locally indexed making search faster and relevance ranking better) in action.  In the meantime though?  Users still like federated search, even though it is slow and awkward.

How to deal with ‘too much information’: where should we put search refinement facets?

Swinburne Library is in the process of making some changes; we’re replacing our library system with a fancy new one, and as the user-experience-person-in-situ it is up to me to make suggestions for the search and discovery interface our users will see.  Some of those decisions I will blog about here, and search facet placement is one of them.

Search facets are one of the search tools that I think will be most instrumental in making stuff easier to find (and the OCLC report (PDF) on user expectations vs. librarian expectations suggests library users feel the same way). Facets are the little categories you see on search interfaces that let you narrow down your search results to things that are more relevant to you; they started out in tools with well-defined metadata (like eBay and Amazon, and even some of the newer library systems) and they are slowly working their way into searches with less-well-defined metadata, like Google.

With anything new like this, though, you have to figure out where in the search interface to put it.  So far I have seen facets placed to the left of search results:

facets to the left of search results

to the right of search results:

Facets to the right

and below search results:

Facets below search results

At Swinburne, we talked a bit about facet placement, and in all likelihood ours will be on the left.

So, what are the arguments for and against each position?

  • Facets below search results: When facets are below search results, they don’t distract the user when they are viewing search results, which is a good thing.  However, given that the vast majority of users don’t scroll all the way down, and only look at the first couple of pages of search results (and they look more at the first results on these pages), placing facets below search result is pretty likely to mean that users don’t see them or use them.  This likelihood is reinforced by the fact that this is a significantly uncommon location for facets, so users won’t think to look for them here.
  • Facets to the right of search results: From a user-centred-design purist standpoint, in my opinion the right-hand position for facets is probably the best in an interface where the language is read from left to right.  This position means that user see search result first, and then facets if the search results don’t contain anything immediately useful.  Given the number of commonly used interfaces that put facets on the left, however, this could be a risky proposal.
  • Facets to the left of search results: This is what Google have gone with (possibly because their advertising is on the right).  It is also common in other commonly-used information seeking interfaces, such as eBay, Dymocks (in Australia) and Amazon (for the US and the UK). Use of these interfaces will train users to look to the left for facets; and it would seem that at least a small sample of users have already developed this preference for left-hand search facets.

Swinburne has a real opportunity with this project to provide a search interface for our users that is not “slow motion search, typical library“; however, to do this we must pay as much attention as we can to our users.  Putting the search facets to the left is just one of the decisions we will make with the users in mind, and I hope to blog about more in the future.

Google search isn’t just search anymore

I know I’m a bit lot late to the table with this, but Google search isn’t restricted to just searching anymore!  They’ve introduced some browsing tools as well (see the video below for more):

Now, it’s easy to figure out that I am very pro-browsing, and therefore I think it’s great that Google has included these things into their search experience, but I’d like to unpack just why I think browsing is such a good thing (and make a couple of suggestions for extensions of what Google is doing) along the way.

Google has been very pro-search as an information organisation and finding strategy for a long time, their search-don’t-sort appraoch to gmail being one obvious example of this.  It’s completely understandable that this has been Google’s whole approach for so long, after all, search is what they do (and they do it very well).

Search isn’t always the answer though (and if you watch this video of a Google user experience researcher talking about the search options, it is evident that Google knows that).  For one things, humans employ more than just search in their information seeking strategies: the research (PDF) shows that information seeking is generally an interative process that includes searching, browsing, and refinement.  Not only is search not the only approach we use for finding information, but sometimes search isn’t enough on its own: with all the information on the web, it can be hard to know when someone types ‘Placebo’ into a search box whether they want to know about the psychological effects of sugar pills, or whether they’re interested in the British based rock band (this ambiguity applies to any number of terms). Similarly, information seekers may want a particular type of information (for example reviews, or places where a product can be bought), or information from a particular geographic location, time or author, or general subject field.  Also, even with known-item searches (those where the searcher knows exactly what they are looking for, and that it exists somewhere, because they have found a pointer to it or seen it) if the searcher doesn’t remember the exact words that occur in the document, they might not find what they are looking for.

Google’s ‘more search options’ are beginning to deal with this problem.  They allow people to find three specific types of content (reviews, forums and video), they provide suggested search terms, they allow the user to look at results from a specific time, and also see how the search terms popularity has changed over time.  I’m not entirely sure what value the ‘wonder wheel (see below)’ adds, given that the related search terms provide all the wonder wheel terms and more, but  I suppose some people may find the visual presentation useful.

Google's wonder wheel, a visual display of related search termsIt certainly is heartening, for someone as vested in browsing as I am, to see Google incorporating browsing into their search.  All I want now is to see it expanded:  I want to filter news by topic and country (and standard search results for that matter); when I use Scholar, I want to be able to browse by author or year.  What Google has provided is an excellent start, and I look forward to seeing where this goes in the future.

Culture, gender, and why Kartoo’s interface isn’t inclusive.

I’m not going to write about Kartoo’s interface in general in this post, beyond saying that the clustering is poor, the seaqrch results are uninspiring, the visual cues are unhelpful at best (and an accessibility problem at worst–those little moving stars could trigger seizures in someone with a seizure disorder).  Basically, Kartoo isn’t a very good search engine, ad it doesn’t have a very good interface.  Many of my colleagues have said much the same thing, and I don’t need to re-hash it here.

Since the 23 Things has started, however, the interface has changed.  Many weeks ago, when I looked at Kartoo, there was a graphic of a windsurfing genie, which I found to be uncomfortable at best: It had no relation to anything else to do with the site, and played on cultural stereotypes, which potentially alienates large groups of users either by offending them, or by playing on a metaphor they do not understand and cannot engage with (in this case I think the metaphor was supposed to mean that this magical being could help you surf the web).

With the change in interface, however, the genie has been moved off his windsurf board and into the corner of the interface, and a new character has been introduced:

Kartoo's female character in skimpy clothing

Yes, that’s right, an exoticised image of a woman with a figure designed to be appealing to the male gaze, and wearing very little clothing.  What you can’t see from this still image is that the light behind her torso pulsates as you wait for your search results to load.  This is insensitive at best, and sexist and racist at worst.  It is likely to offend a wide range of users, from feminists to those who see the female body as sacred and something that should be covered modestly (as is the case in many religions). I’m sure it is supposed to be ‘fun’, but in fact a large number of users (including yours truly) will see it as a sign that Kartoo was not designed to appeal to them, and has little to offer them.  Given that it does not add anything helpful to the user experience (for example the pulsating light does not pulsate faster to tell you your results are nearly ready), this can be seen as a serious misstep by Kartoo in terms of the user experience (unless they only want to appeal to a certain demographic).

This example really highlights the risks involved in using metaphors, particularly culturally loaded ones.  Many cultures understand metaphors quite differently than one would expect, for example the Maori (minority indigenous gorup in New Zealand) understanding of a ‘library’ is quite different to the New Zealand European understanding, and acts as a barrier to Maori accessing useful, relevant information ind a digital library (as reported in Duncker, 2002).  Metaphor can be very useful if used carefully, for example the desktop metaphor was one of the driving factors behind usable personal computing.  However, if ill-used, metaphor and cultural artefacts can confuse, offend, and actively drive away users.  Have you ever been offended or confused by a metaphor that didn’t fit your understanding or cultural values?

Boolean search made easy to understand?

Recently a colleague sent me a link to a little tool called ‘Boolify‘. Boolify is a visual representation of Boolean search and is meant to be an educational tool to help people learn how boolean search terms work together.

Boolean logic (and one of its common applications, Boolean search) is a common ground field between computer scientists and librarians, particularly those who try to teach it. Boolean search is hard to understand for most people, but if users could understand it it would be one of the most powerful tools in their search toolbox (particularly when they are using a search term that has more than one meaning). Good search engine interfaces try and get around it by offering a more ‘natural language’ advanced search interface that lets users do some Boolean searching (see for example the Google advanced search interface below), but the true power and flexibility of real Boolean searching is somewhat lost even in these interfaces.

Screenshot of Google\'s advanced search interface on May 27 2008

Google’s advanced search interface

Now it’s debatable whether the power users lose in an interface like this is even that much of a problem, given that the vast majority of users enter short queries and don’t use advanced search. Arguably there is a chicken-and-egg problem here; users may not use advanced search because (in many cases) it is too hard, meaning they never learn to use it, meaning it is too hard…Whatever came first, I think the answer is that users can usually (at least with Google) find the information they want (or something close enough) without having to get into Boolean logic, and therefore they don’t learn it.

There are some people, though, for who a good grasp of boolean logic is essential. Computer programmers are in this group, as are the librarians to whom people turn when their own searches fail. Potentially students and researchers should have some understanding of Boolean search as well, though I would generally argue for better search interfaces for these groups. So, given the difficulty of teaching Boolean logic (and having taught first year computer science I have first hand experience of this difficulty), anything that would help make it easier would be great.

At first glance, Boolify looks like just such a tool. It would be more awesome if it had a predefined results pool to play with (as well as providing an internet search), so students could see how query reformulation affects what is included in the results pool, but that is pie in the sky, and this thing looks like a good first step. It has puzzle pieces that show how you can interlock different bits of a boolean search, and the horizontal and the vertical can act like brackets in a real search term–the thing at the top is in the innermost brackets, and so on down.

Sadly, though, the promises Boolify makes are not delivered upon. Despite the puzzle pieces providing every promise of being interlockable, queries can only be developed in a linear fashion, and so the pciture below is what happens when you try to develop the query ((libraries OR museums) NOT gallerys) AND ( user experience OR usability). It simply isn’t possible to do, despite the puzzle pieces having every visual and logical affordance needed–you can on develop queries in a line, which means this tool does not represent the full power of Boolean logic. Attempting to make a complex Boolean query using Boolify

Trying to develop a complex Boolean query using Boolify

Usually I would not be so hard on a tool designed to teach something difficult in a novel way, but this tool is a poor teaching aid. It doesn’t allow users to do what it looks like they can do by clicking bits of puzzle in anywhere–thus not showing the true power of Boolean queries, and having a significant usability problem. It also (and I think this is more important) doesn’t let users reformulate queries by moving puzzle pieces around, thus denying a real opportunity to learn how Boolean operators work together by reformulating queries and seeing what happens to the results. I can honestly say that until this tool fulfilled more of its promise, I wouldn’t use it teaching–it is bright and colourful, but it doesn’t bring much more than that to the table.

So, what does everyone else think? Should we leave Boolean logic to the geeks and logicians? Who needs to know Boolean logc, and how should we teach it?



Some rights reserved.

Comment moderation

If it is your first time posting, your comment will automatically be held for my moderation -- I try get to these as soon as possible. After that, your comments will appear automatically. If your comment is on-topic and isn't abusing me or anyone else who comments, chances are I'll leave it alone. That said, I reserve the right to delete (or infinitely moderate) any comments that are abusive, spammy or otherwise irelevant.