portals to interact with and combine library catalogue services across authorities and sectors
There is a mobile app on the Google Play store that combines many library services into one for users to view loans, receive notifications, and renew items - across all their library accounts.
The app currently covers around 300 UK college, health, university, and public libraries. Library systems do offer integration options that are used by third parties, but these aren't available to public developers. In this case, the integration has been developed purely from automating publicly available web-based functions (using code to mimic the actions of a user on a website).
It's possible for the app to provide so many libraries because there aren't that many types of web catalogues. With a list of libraries, which portal they use, and code to interact with the different types of portal, code can be reused across multiple services. Not a bad prospect if a user is member of a number of different libraries and wants somewhere to manage all their accounts. Just enter the library credentials and let the app access the different sites. The app just needs to know the catalogue type, and URL.
|The College of Optometrists||Heritage||http://library.college-optometrists.org/HeritageScripts/Hapi.dll|
However, entering membership IDs and passwords into unofficial apps may not be too appealing for users. There's no guarantee the developer won't use those usernames and passwords for their own purposes, or that the credentials are stored/transmitted securely. This latter point is not guaranteed in official apps either, but there's an expectation of accountability.
The Sieghart report mentions a digital network that 'could include a single library platform and a national library card and catalogue'. Wales tendered for a single library system, but given the cost ('Range between 1,000,000 and 3,000,000 Currency: GBP'), it may be a while before seeing this across England.
What these apps, and other examples make clear is that underlying systems don't need to be the same to operate together, or to merge into a single service. Web services can provide the illusion of a single system, without necessarily procuring for one. Effectively then building a discovery layer (of which many already exist) that unifies the library service experience for users.
A merging together of all the above services could very quickly pull in enough libraries to create a single app/website to manage a library user's account(s).
Private web services also don't always lead to the best result for users. A recent moonpig API flaw exposed personal data of millions of customers. Private APIs are only private until they are discovered.
It would be interesting if England attempted to not develop a single LMS, but a set of open web services to provide public catalogue and membership services - integrating with existing systems rather than replacing them. Given the choice of free software people have for accessing various other accounts (Twitter for example) - within a short space of time there could be a real variety of systems (including open-source) that best serve user convenience.
As soon as systems are made open, usage potential is enhanced. Goodreads users can embed a widget on webpages to show what they're currently reading - the same could be available for library loans.
When considering whether such open web services present a security issue, a recent ProgrammableWeb article on private APIs included the notable point: 'APIs, like crypto implementations, are at their best when they’re developed openly and widely scrutinized'.