New Search Interface

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’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:

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 ( 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.

8 thoughts on “New Search Interface

  1. Kristen

    Just some things I noticed (they’re pretty minor, and chances are you’ve already thought of them already):

    If I type in “admissions”, 4 results appear that are almost indiscernible from one another. I assume this may be fixed by re-titling pages during the redesign, but I just wanted to point it out. In addition, the first directory result if you type in “admissions” is — which is great for those of us in Monterey, but you will probably want to separate the 2 institutions’ directory results.

    This is probably a minor thing, but wouldn’t it be cool if you typed in a course (i.e. “Italian 101”) and the directory results that popped up were the entries for faculty members that teach that particular course? This may be happening already, but if I type in “Italian 101” right now the directory results also include students and miscellaneous staff (including the president of MIIS) who I don’t think have anything to do with Italian.

    Also, you are right about the search being slow. I’m no expert but I am definitely in support of exploring methods to get the search running faster. I’d be interested in hearing more about the accessibility issues associated with JavaScript.

  2. Ian McBride

    Thanks for the comments Kristen. I have a request in for a configuration change to our Directory that will improve search response time, so I’m going to hold off on further revisions to the Directory search until I get a reply back on that item. If it goes through, I expect a significant improvement in the response from the Directory. Role account emails like “admit-MIIS” also shouldn’t be showing up in the Directory results, but again I’ll change that when/if I make the other change to Directory search.

    That’s a good suggestion for course information. Adam Franco is working on a Course Catalog application that he’s just finished the first version of categorized search for. Once he gets simple search and a web service working for it, I’ll add that to this prototype. The challenge here is that the course name like “ITAL101-F09” actually isn’t stored in one place in our database. “ITAL” is in one column, “101” is in another, and “F09” is an assumed inference from term code 200990 and not stored anywhere in the database. When you add in names, descriptions, sections, and professors, you’re left with a ton of columns to search across, so Adam’s working on developing an indexing scheme for the application.

    As for accessibility and JavaScript, there’s the obvious downside of people coming to the site without JavaScript enabled and then having to change their browser configuration to make our search work. But if that were the only issue, I’d go ahead with it. The problem is that screen reader applications for the blind update the page content unpredictably. A JS enabled search interface would update the page with results, but the screen reader might not pick up that the page had been changed and the results wouldn’t be shown to the user. The Trustees tasked the college last year with trying to guarantee 100% accessibility on our physical and virtual infrastructures, so where we can we try to ensure that there’s a usable version of the application available. That’s not to say that we can’t have a search interface that uses JavaScript features to improve usability while also retaining an accessible version without JS enabled, but the latter is far easier to build for prototyping.

    On another note, it turns out that our library catalog doesn’t always return properly encoded XML through its XML export feature. This was causing some error messages to be displayed on certain queries. I’ve changed the application to intercept the response from the library catalog, properly encode its XML and then parse the result.

    Thanks to all who’ve sent me notes thus far. Keep them coming!

  3. Jason Mittell

    Nice work, Ian! Some sample (self-centered!) searches I ran that worked effectively were Mittell, Film, and American Studies. Searching for American yielded bad results, not too surprisingly given the broad footprint. AMST returns hits from the course schedule, which is a problem – we definitely need departmental codes to ping the departmental sites.

    It would be nice if we could have one of the modules return searches for the most appropriate units from the Midd org chart – acad depts, admin divisions, schools abroad, etc. That would be a way of targeting the top-level sites for each unit. I also think a Course Catalog search return would be fabulous.

    I think more-than-4 results would be great – I’m not knowledgeable enough to know the implications of JS vs AJAX issues, but the end goal should be a broader array of results.

    Another interesting option would be a box returning a straight Google of whatever the search term is plus Middlebury (not URL tied, but just as an additional term) – this could be labeled as “from the web” or “outside Midd.”

  4. Ian McBride

    Thanks for the feedback Jason. Remember that searches for departments like “American Studies” or “AMST” will (probably) not actually land you on the search results interface as per White Whale’s proposal, but on a hand-crafted result page that gets you to the content for that department or discipline.

    My proposal for implementing this is to have a special wiki on our Mediawiki instance named “Search” where each wiki page is one of these search landing pages. So there’d be an American_Studies page. Each time someone searches, the search engine first checks to see if the corresponding wiki page exists and, if so, forwards the user there without searching the rest of the result sources.

    My more radical proposal is that after the initial launch of these wiki search result pages, we turn over editing on them to the entire college community. There’s been some concern that these pages would be too hard for one group to maintain. Well then why not make it so they can be maintained by our community? Whomever has an interest in ensuring that good information appears on the result pages can make those changes. The group that would then otherwise have been tasked with maintenance of the result content can simply moderate it.

    As for your suggestion about returning org chart results from the Directory search, this is an idea that’s come up recently in thinking about how we could improve the Directory to make it possible to eliminate the print version of the Directory, a significant cost saving for the college. I’ve added my thoughts on that subject as a new post on this blog.

    Lastly, I’ve made a change to how the Directory search works this morning that slightly improves the response time, though its not as fast as I’d like it to be yet. I’ll also be splitting the Directory into two so we’ll have the Middlebury and MIIS versions of it listed. I’ve further removed the non-person results that Kristen noted, so that general MIIS admissions mailbox no longer appears at the top of admissions results.

  5. Adam Franco

    Here are a few interesting articles on the AJAX accessibility front:

    Ajax Accessibility (April 29th, 2008) by John Resig — talks about ARIA support in screen readers for updating them about content changes. Looks promising.

    Fire Vox A new screen-reader plugin for Firefox that includes ARIA support.

    JavaScript Resources — “A collection of resources for Javascript developers who want to write modern, accessible, portal-safe JavaScript.” More info on using ARIA to develop accessible dynamic web applications.

    AJAX and Screenreaders: When Can it Work? (May 5th 2006) By James Edwards — in 2006, updating the reader of content changes just didn’t work. This article includes tests on a number of readers available at that time.

  6. Ian McBride

    Good find, Adam. Looks like we’ll be able to make the dynamic regions accessible using ARIA as it’s supported in FireFox 2-3 through the FireVox plugin as well as JAWS 9, the latest version of that reader and many of the open source screen reader applications.

  7. Ian McBride

    I’ve improved the prototype’s performance by using the jQuery JavaScript library to do asynchronous searches on the different search sources.

  8. Ron McKinnon

    This will be a very useful tool Ian. Thank you.

    I like that when I searched for “emergency” the text in the first result was from the top of the Emergency Response page rather than the middle as is from the GSA.

    The only issue that I have is that pressing the back button after visiting a link returns me to the search screen rather than to the search results page.


Leave a Reply

Your email address will not be published. Required fields are marked *