Multiple UIs for Our Catalogs

Richard Wallis at Talis has an interesting post on a possible solution to the ILS user interface design issue. Richard mentions the biggest issue (one we all know about – but can’t seem to solve) – library users are different! Lawyers are different then students who are different than senior citizens who are different from children who are different from scientists – and so on.

So what’s Richard’s solution?

In an ideal world we would have built the student User Interface; the researcher UI, the high school UI; the reference librarian UI; the enquiry desk UI; the library science UI; the children's UI; the general public UI; the plugged-in to my citation management software UI; my google-gadget UI – all supported by variations of a catalogue each tuned to deliver results most relevant for each target user group.

Pie in the sky? If you separate the user interface from the underlying cataloguing, indexing and searching capabilities of a solution I think not. If you design the "Ëścatalogue' to flexibly support the searching, indexing, and relevance ranking needs of all these user groups you will be able to lay many different [cheap to produce for a library, a vendor, or even a user] UI skins on top of it.

These thin UI skins, on top of a powerful platform, are much simpler and quicker to develop, in days/weeks as against the months/years of our traditional monolithic systems. Because of this we can consider not only user-cantered design, but also user centred development.

I agree that this isn’t “Pie in the sky” – I also submit that it’s already possible with systems like Koha. Koha is built on a powerful templating system already – this means that the interface can be changed to meet the needs of the users without sacrificing the needs of the library and librarians.

Now, I have to be honest, I have only seem two library systems front and back (and soon one more) and they are III and Koha – so I don’t know if there are others out there that can also do what Koha can – but the point is – the system Richard is talking about already exists and probably just needs a few more librarians and libraries to jump on board to help with defining the different user needs.

Technorati Tags: ,

Posted in


  1. For another example, you might want to look at Evergreen. Not only is the main OPAC completely templated (using client-side XHTML and JavaScript) but the text-only OPAC is built on top of an XML feed service, allowing relatively server-side XSLT templating and display logic.


  2. heh … That should read “relatively simple server-side XSLT” … that is all. 🙂


Leave a Reply

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