Our vision for Prism white paper
We have produced a white paper outlining our vision for Prism. We’d be really interested to hear your feedback on this, and welcome you to post any comments or questions below.
Abstract of the white paper:
“A lot has been written over the last five years about what a “next generation Discovery Interface” should look like. Whilst this is an interesting debate, we believe it’s asking the wrong question. We shouldn’t start from the vague perspective of how a current discovery interface should be improved, but instead focus on the needs of the people and institutions that use the discovery interface.
This is the philosophy we’ve taken during the inception and development of Prism. Wherever possible we’ve looked at empirical data that shows a unique need, looked at emerging market trends and investigated the type of information and data being managed by institutions. Throughout all of this, we’ve built a solid foundation on which to deliver a compelling next generation discovery interface.
Now that this solid foundation has been built, we have been crystallising our plans and ideas for the next phase of Prism’s life cycle.”
May 26th, 2011 at 9:58 am
I’ve read this several times now – and I’m still not sure what to say.
Aren’t these developments all things that have been discussed in webinars and at open days – some of them already on the road map? I’m surprised that I’m not surprised by any of it, is what I’m saying.
This isn’t a bad thing – I was dreading that it would turn out to be a revolutionary new start-all-over-again-from-the-beginning initiative – but is it the case that the paper is intended for new customers rather than hardened old lags like me?
Or am I missing something?
May 26th, 2011 at 3:05 pm
I agree that many of the features are not very new. Some are not necessarily things that all our users want to be prioritised. I wouldn’t want our OPAC to become too much like a social networking site, and lose sight of what it should be able to provide – accurate searching, helping users to find the Library resources they need.
As for new developments, here are some examples I’d like to see:
– html linking from anywhere in a record (e.g. class numbers, subjects)
– links to floormaps highlighting the location of a book.
Having said that…
perhaps my favourite part of the paper is the “personalised landing page” idea. Once visitors have this option, they should then be able to configure their Prism to have (or not have) features as desired.
For example, some of our users would use features such as reviews and suggestions; others would want to switch them off. It would also be good if they could customise their landing page with widgets, e.g. newly purchased books in a specific subject area? depending on their interests.
June 7th, 2011 at 12:38 pm
Hi Heather, Christine,
These are indeed things we have been discussing for some time, but we felt that getting them written up cohesively was a useful exercise – both for our customers and for us.
While I agree we don’t want to turn the discovery interface into a fully fledged social networking site, having user provided reviews can be a fantastic aid to making the decision “do I want to borrow this item or not?” and that is what we’re aiming for.
Kind regards,
Phil John
Prism 3 Technical Lead.
July 15th, 2011 at 11:32 am
Hi, have been meaning to reply to this for a while.
i think a long/medium term high level plan for prism is an excellent idea.
Generally good stuff! some notes (many build on things you already note):
– I like social, but it needs to be implemented carefully, and I think if anything the needs of public and academic libraries are diverging. When we have introduced recommendation services for scholarly articles, for example, the first question we get is how is it generated, ‘who’ fed in to the recommendations. students? Academics? UK? Worldwide? They want to hear “Academics from Harvard”, a selection of UK libraries across different markets may be a harder sell.
– Personally like tagging but experience in the library catalogue world has been poor, and there is often little take up.
– The biggest issue I see is the ability for users to make/edit/store lists. To export this to reference management systems and so forth, and maybe even share them (but the last is also the least).
– Things such as juice help create a flexible infrastructure, this is a key asset.
– I think Libraries in both markets will need more than one interface to their catalogue. i.e. multiple prism ‘tenancies’ pointing to one or more libraries/databases. A main catalogue. One just for a particular special library, one for a particular type of item (rare books/ dvds), one with another local library, one which incorporates archives/museum data, etc. Development should cater for such needs. Both in technical flexibility, but also in business decisions in clear direction as to what and what not are additional costs (or even new paid for services) and what can be included. I’d stress that while facets can often be used to slice/dice data, sometimes this is not enough. Sometimes libraries want a particular collection to appear to have a separate catalogue (even with a similar design), and not have to point to their main interface and tell people to refine.
– as you note, mobile is important, and for good reason, you can walk around the shelves with a mobile device (and it may be showing the records you found while you were on the bus to the library), with a catalogue terminal you have to write down shelfmarks, etc. I would focus on a great html experience. Apps… for iphone, android, windows, blackberry, palm, are a costly endeavour. (if our data is open, end users may create an app).
– talking of thirdparty apps. When a third party wants to create a search of our catalogue our users will want the same kind of search results as the main catalogue interface. It’s silly for other websites/apps to have to develop relevance ranking etc from scratch. Therefore, if not already, an SRU interface in to prism3 would be great. There is one to Alto, but that does not rank the results in the same way. For example we have CampusM and we tried using the Alto SRU interface and it just did not deliver any kind of meaningful result.s
– one of the things that always impresses me with google is it’s speed (so too with facebook, try typing a friends name in the search box at the top). Prism needs to keep speed as a focus.
Chris
July 25th, 2011 at 11:38 am
Hi Chris,
First of all thank you for your really comprehensive comments; this is exactly the kind of feedback we were aiming for when we launched this exercise.
We’re in a fairly unique (and fortunate!) position as an LMS vendor with a deep understanding of the needs presented by two distinct library sectors and we always put efforts in place to ensure that features we develop are either mutually beneficial, for example with our recent lists work, or balanced so that we don’t just concentrate on one side of our customer base to the detriment of the other.
You are absolutely right in pointing out that academics will want to ensure that only relevant data has been fed into recommendation engines, and we have planned to run two separate systems since we began scoping this roadmap theme. For public libraries we will be implementing a traditional “item to item” recommendation service which gives you results like “people who borrowed this also borrowed…” or “people who liked this also liked…”; for academic libraries we realised very early on that there are various patterns in the data that we can harness to create a far richer connection: “this item is similar to these items”. We’ll be running the two systems separately, so circulation data from public libraries will not make it into academic suggestions and vice versa.
With tagging, perhaps part of the problem is starting from a blank slate, do you think that pre-populating the tags with ones derived from the record, or licensed and imported from elsewhere would get the feature to the critical mass where users start creating them?
You’ll be pleased to hear that we recently released a new list building feature which, as well as allowing export to citation/reference management tools (EndNote, RefWorks, Zotero and Reference Manager) also allows lists to be bookmarked and shared. Full details are on the release notice http://blogs.librarymanagementcloud.co.uk/prism/2011/05/27/prism-release-preview-%E2%80%93-27-may-2011/
When we start surfacing multiple data sources (work underway now) you are correct that perhaps a different way into the data, without having to filter results out after the fact, would be useful. Perhaps a dropdown by the search box that selected all indexes, or specific indexes (i.e. “Search for x in [everything, journals, library holdings, archives and records]). There’s lots of different options and we’ll make sure we look into all of them when designing the feature. Another option is themed landing pages which offer a particular view into the catalogue (we’re already planning to do this for different formats, each having their own landing page).
With the mobile roadmap theme we’ve taken a deliberate decision to provide a great web-app experience, rather than a native app experience, for the very reasons you’ve outlined. We can also add new features much quicker to a web app without having to go through a sometimes lengthy approval process, meaning we can bring things to market much quicker. As you point out, we provide API’s to access the data underpinning the site, so the possibility is there of other people leveraging those (and we already have a few partners who we believe are going to do just that).
Third party integration is a high priority for us since we have a thriving partner ecosystem, and the functionality you’ve mentioned is already supported in Prism. We released the Linked Data API a few months ago which allows you to surface items as various flavours of RDF (as well as popular citation formats) as well as surfacing search results as RSS/RDF, for example:
http://catalogue.library.manchester.ac.uk/items.rss?query=operating+systems+author%3Agalvin
This means that not only can the exact same syntax be used to retrieve resources, but the relevance ranking is also the same, freeing API users from having to implement it themselves. We decided on this approach, rather than using SRU, because it’s much simpler for other people to tap into and doesn’t require the use of another search syntax (CQL) that is alien to a lot of users in the era of Google and Amazon.
Speed is always high on our priority lists and is something that we’ve worked very hard on over the last 18-24 months, with average response times getting progressively lower during that period. We continually review this, evaluating new software for our application stack and performing reviews of our current and projected capacity requirements.
Kind regards,
Phil John
Prism 3 Technical Lead.
August 1st, 2011 at 10:45 am
Hi Phil,
Thanks for the detailed response, all good stuff.
You asked:
“With tagging, perhaps part of the problem is starting from a blank slate, do you think that pre-populating the tags with ones derived from the record, or licensed and imported from elsewhere would get the feature to the critical mass where users start creating them?”
I think this is a good idea, pre-populating, and perhaps using a global tagging system rather than a tenancy by tenancy basis.
I can see two sides of the tagging debate. On the one hand we shouldn’t need to understand what exactly users will use it for, it is there and open to be used however they wish. On the other it can be hard to decide on functionality, i.e. if users are using it almost like a personal list system (things_I_want_to_read) then this might lead to different decisions to if they were largely used as a collaborative classification system. It’s interesting that even the BL has had limited take up of it’s tagging system.
My own thoughts are that while tagging should be a feature, it should be more there for those who want it, some what discrete, and not seen as a core feature.