Just thought I’d post an update on our work since we have given the ok for our library administration to start internally testing the tool.
Lets see, new enhancements to the API/backend server:
- New session manager. This allows the software to capture and cache all user data over the life of a session which is generically useful in terms of allowing users the ability to quickly move back and forth between search results (i.e., once a query has been done, it is never redone for the life of your session) — more interestingly, it forms the foundation of eventually allowing the software to provide users with saved session results, saved queries, saved search histories, saved citation lists, etc. We won’t implement this fully in the first release (too bad — Jeremy has been cracking the whip lately to prevent feature creep –something I’m notorious for since some of my best ideas come to me after I’ve had a chance to visualize them within a realized application), but I’ll push to have it included in our next development cycle.
- Citation services added. Allows users to email themselves citations. At this point, citations are emailed simply in HTML to an email client — but we’ll look to add more robust citation services in the future so that citations are email in a user-defined citation format.
- Ranking algorithm has been refined. I’m always looking for ways to improve this. Currently, the algorithm uses a 1000 pt. scale, utilizing close to 52 match points.
- I’ve added LDAP authentication — though its not being implementated at this point.
- Our custom OpenURL implementation has been tweak to allow direct resolution of resources during the federated search process. This way, if you see a link on the results screen — you can feel confident that its going to get you to the resource.
New enhancements to the UI services:
- I’m sure Jeremy is continuously thankful that I’m not responsible for the graphics or look of this service. The other day, we were discusing icons/names for the tool. I suggested, somewhat tongue in cheek, “Ask Benny” and provided this icon:
He was remarkably quiet concerning this suggestion — I think he’s hoping it would all just go away. 🙂
- So actual improvements. First, we’ve done some work splitting results into more logical groups. A general search to query our most widely used resources, an image search that will eventually query close to 15 million harvested items and a books and more search which is limited to our ILS.
- The Results themself are very clean. I think our two UI folks (Tami Herlocker and Seikyung Jung) have done a fabulous job of capturing our vision for a clean, minimalist UI. If you look at the example (below), you can see that they’ve setup filters, there’s pagination (at the bottom of the page) and the list of databases which have returned results — in addition to the ability to go directly to the targets website and filter all the results by a particular target, materials type, etc. Results are deduped by default by title and date. The beauty of this UI is its pretty much all XSLT generated. Our UI folks and myself have collaboratively designed the XSLTs (my role has been mostly to provide examples of how to interact with the results API and setup things like the deduping/pagination — I claim no credit for the look and feel of the UI — that’s all them) setting up what is essentially a middleware between the user and the API xml. I love it.
Anyway, lots of cool stuff going on with this project. I image the UI will continue to change in the next few days/weeks before we look to cut this over to our production environment — but at this point — I’m pretty happy with the results. And hopefully our patrons will be as well. Given that our current vendor supplied metasearch tool has set such a low-bar, I don’t think we have much to worry about. In fact, I’m more concerned about too much success. Given federated searchings fairly large footprint — I’m thinking we will have to carefully monitor resource useage for a while to make sure our current systems can handle expected load.