Ajax and Autocompletion
Update: This isn’t something it’s easy to stop tinkering with. Now it will give you “x” and “Journal of x” listings (e.g. try typing “academic”), and it can handle ISSNs (try typing 0039). The latter still gives you a list of titles, but the ISSN is appended so you can see what you’re getting.
I’ve been playing with the
Ajax-based autocompletion features
of the latest eXist release. The code
is simple, and all it needs is a dynamic page it can hit, which
generates an HTML
ul with a bunch of
li’s containing the search
terms. Simple to do from any database, such as an ejournal title list.
So, here’s an experimental
typing a journal title; once you’ve got a few characters, pause to get a
drop-down of titles you can select.
The CSS needs work, and the search page that this points to needs to be updated to accomodate exact title searching, and no doubt there are issues around accented characters, but it’s still very nifty.
A couple of other Ajax implementations to investigate are Flexac and momche. The code I took from eXist lacks a couple of features, such as the ability to select from the drop-down using the arrow keys instead of the mouse.
There are obvious questions around scalability; but of course, the db that serves the Ajax requests doesn’t have to be the same one that serves actual searches; it just has to be in sync. If performance turns out to be an issue with this interface, we could have a separate db containing nothing but journal titles, for optimum performance.
Now, which ILS vendor will be the first to offer this in their OPAC?
Very cool, Peter! I hope vendors will take note.
Peter, this is really nice! I like the (17 more... keep typing!) bit. We implemented something similar a couple of weeks ago: http://www.library.gatech.edu/search_locate/electronic_journals.html but I need to add the user friendliness of yours. Ironically, I "stole" our design from a vendor (or sorts). LibLime's implementation of Koha does autocompletion (http://opac.liblime.com/). I'm not sure they were the kind of vendor you were referring to, though.
I should have known you'd get there first. Are you running the microqueries directly against your SFX server, or against a db with extracted data? It's very quick. I notice there are duplicate titles, based on what SFX does with accented characters etc.; I wonder if there's a way to eliminate them (e.g. if you type "journal de", the first two are dupes). I'm finding that all the complexity in this arrangement is in the SQL query to retrieve the entries for the dropdown, not in the client- or server-side code.
We are running it in a separate database; we run SFX off of a consortial server and don't have access to the SFX db. So, I take the reports and load all of the journal titles and alternate titles into a DB table. The reason why it's quick is because it's cached to the filesystem. The KB only changes once a month, so when it's updated we'll wipe out the cache and start anew. Like you, the hardest part were figuring out the best SQL queries. It's a bit of a compromise, but what we're doing is: 1) Left anchored 2) Phrase 3) Keyword AND It iterates through that until it gets 20 matches (or runs out). It then writes the results to /tmp and if that file exists the next time it's queried it uses that. The duplicate title part is included for abbreviations. The funny part of that is that I was trying to make sure "JAMA" would work, but now I see we don't even subscribe to that! "AIAA" will get the point across, though.
[...] ode for keyword searches should be easy. This spell check combined in some way with the AJAX auto complete stuff that Peter was playing with last week should allow us to provide some inter [...]
Impressive! I'm looking to implement something similar in one of Temple's document databases. Do you have any links to a tutorial or could you provide me with a simple way put together a similar live search.
I'm tagging AJAX packages in my del.icio.us account as I run across them. Lots of good stuff out there, and too little time to evaluate it all...