Joe Antonioli recently asked the DMTs to evalute the search interface prototype I blogged about in a previous post. The responses I received from the DMTs were extremely thoughtful and helpful. I want to take this opportunity to provide some additional information about the search service and respond to their suggestions. First, there are two things about the new search service that may not have been entirely clear in the assignment.

1. The interface choices (colors, fonts, placement, images) on the prototype were chosen for expedience rather than good design. I reused several elements of past design to make something that would functionally work. Several DMTs responded and said they liked aspects of the design, which I certainly appreciate. However, we’ll be receiving new font, color and framing suggestions from White Whale as part of the Web Redo Project and when we do those choices will overwrite what is currently displayed on the search prototype.

2. The search engine is purposefully stupid and minimal. There will very likely be a box in the upper right hand corner of our new website where you enter search terms, click a search button and then are taken to a page with search results. This field won’t have additional selection boxes or drop downs or anything. That’s not to say that there can’t be an advanced search as well, but that the search needs to do *something* with very little information.

Those two things said, here are the main points I took from each of the DMT’s responses and my feedback on them.

You don’t always want to search all the search engines all the time. If I’m looking for a person, I might just want to search the directories and the website. If I’m looking for a book, I may only want to search the library catalog.

Excellent observation. There were two suggestions for improving this: (1) have the search results from each search engine appear in different tabs or pages so that you only have to look at one at a time, and (2) allow the user to select which search engines they want to use. I definitely want to do (2) and then see if that improves the experience enough or if we need to do (1) as well. We can implement (2) by adding a set of checkboxes under the search box that allows the user to choose which engines they want to use as one of the DMTs suggested.

There was also the suggestion that the labels of these selection checkboxes be hyperlinks that, when clicked, take you to the results from that engine. I would prefer not to do this because the suggested action for clicking on a checkbox label on a page is to check or uncheck the box associated with that label. This would break that design convention for sites. I’d rather add another row of labels under the selection area that act as these hyperlinks, if the navigation column on the left is insufficient to carry this action.

Show more results from Google, show fewer results from the library and the directories.

I agree that the Google results should list at least ten pages. I like the suggestion of limiting the results from the directories and the library by adding pagination to those results. I will not be able to effectively paginate the results from Google because their API only returns a small number of results to me – Google obviously doesn’t want you to be able to replicate their search engine on your site without displaying any of the ads they use to generate revenue. There are other restrictions with using results from Google: I cannot change the order of the results and I cannot intermix results from other search engines with results from Google. I will, however, change the script to show the top 10 results from Google, rather than the top 4.

Show more relevent results from the directory search. If I search from Ian McBride, I don’t want to have to scroll though all the Ians and all the McBrides to find him, I just want to see the information about the person I searched for.

As I said, the search is intentionally stupid. When you search for “Ian McBride” in the directory it doesn’t know if that’s a person’s name, job title, department, building location, or telephone number. So the directory search looks through an index of all those fields and spits back whatever it finds. Ideally, the directory search would list this information in order of relevence, so you’d see my entry at the top of the list, then the rest of the McBrides and then the rest of the Ians. This is really hard to do, but that doesn’t mean we shouldn’t try to do it.

Show fewer results from the library and tell me whether that resource is available or not and the branch location or whether it’s at another library.

The library search is really problematic. In order to search the current catalog system, I have to send a request to the catalog website with the search terms, parse the response looking for bibliography numbers and then send an additional request to the catalog for each bibliography number I found to get its author, title, etc. Our library staff has been looking at next generation library catalog front ends, like Scriblio, with the intention of providing a better search interface to the catalog. When we have a system like this set up that allows me greater programmatic access to the catalog information, I’ll be able to greatly improve the results from that system. I will change the current interface so that it only lists the first ten or so results, rather than the first 50.

Tell me what format the result document is in. If I’m opening a Word document by clicking on a link, I want to know.

Excellent suggestion. This should be handled by icons (with appropriate alt and tooltip text of course) for each file or media type.

Allow me to choose the number of results.

Absolutely, but with the recognition that this will be part of an advanced search interface.

The Back button on my browser doesn’t work with this search engine.

This is a usability issue which I need to correct. Clicking Back should bring you to the list of your last search results.

There were also two questions asked by the DMTs that deserve answers. The first was a compliment from one who liked the graphic of the mountains in the title background of the search result bubbles and wanted to know who came up with that design. The answer is Mark Zelis, the Web Producer for College Communications. Mark developed that design for the News Portal. You might also recognize Mark’s work on the new Institutional Diversity site and many email campaigns for the College.

The other question was, “I’m curious about Search. What is it, exactly? What search feature is in the works?” The answer to this can be found in the Strategic Recommendations Document from White Whale, which can be read by Middlebury community members at the Web Redo Blog.

I want to again thank the Digital Media Tutors for their feedback and encourage them to continue to test our systems and provide feedback on them. The more eyes there are on these interfaces, the more we can improve them and make them easier to use.

One of the strategic recommendations we’ve heard back from White Whale is that our search interface can be improved by incorporating search results from multiple search sources, rather than just the GSA’s internal index. Additionally, they’ve recommended that we use Google.com’s search results scoped to our site, rather than the on-campus tool. Joe Antonioli asked me to spend some time this week building out a rough prototype of how this system could work. The first version of the prototype is available (on-campus or via VPN only) at: http://chisel.middlebury.edu/search/

Please try out this prototype and let me know how it could be improved. Don’t worry about the look-and-feel right now since those changes will be delivered by White Whale as part of the design specification. Instead, try some different searches, examine the results, and think of things the service could do to make the results more understandable to you. If the results of your search are way off-base for the search terms you used, let me know about that too. And, of course, this is such a rough prototype that there are bound to be bugs, which I’d be happy to fix.

Here are some things I already know (but if you agree or disagree, let me know):

1. The Directory search is *really* slow. This is because we’re doing a simple search, rather than the advanced search you see on the general Directory interface. I don’t know if you’re searching for a name, a phone number, or a department, so I search all the fields for all the terms. As you might imagine, this isn’t a very fast search algorithm. What might we do to improve this?
2. You only get 4 Google search results. I’m using Google’s RESTful search API, rather than the AJAX search API. I wanted to avoid use of JavaScript on this interface so that it would be as accessible as possible for all users. The RESTful API is much less flexible in terms of what results you can receive. They’re only giving me four at a time and I suspect this is because its not really in Google’s interest to let us create a version of their search results page without any of their advertising. I could improve this by using the AJAX version, which would require using JavaScript. But if I start using JS for this, I could use it for all the searches and do them asynchronously, which would improve response time on the page (you wouldn’t need to wait for the Directory searches to load to see the library catalog results, for example). What are people’s thoughts on this?
3. I want to extend this to include other search sources. GO is the next up, but it doesn’t have a search interface yet, so I have to write that before I can include it here. What other services might we include in this search interface?

You can comment on this at my blog in the comments field for this entry (http://chisel.middlebury.edu/wordpress/imcbride/2009/06/02/new-search-interfacenew-search-interface/) or by emailing me directly. I’d prefer comments to be posted to the blog so that we can have a public discussion about this, but I’ll respect the confidence of anyone who would prefer not to have their thoughts published.