Putting it out there


In a previous post, I wrote about publishing content in several formats, but how can this be integrated into a library webpage? Typically, you want your web presence to be managed and structured because this makes it easier to maintain, make accessible, make visible to search engines, etc. This sort of thing doesn’t fit into the free-for-all model I described.

Well, it does: I was talking about web services, about providing content in standardized ways, so that the information can be used in different contexts. One of the most important contexts will be library webpages, but including a service on a webpage shouldn’t be any worse than adding a link in the majority of cases.

An example here is adding RSS feeds of predefined literature lists from the OPAC by sending an http-request. This kind of web service is a useful way of providing high-level services to library staff with no programming skills, a web service can be accessed by building an http-request manually, or by providing a graphical interface that helps users to build an http string that does what they want by pointing and clicking. In many applications, this kind of web service is essentially middleware between the data storage and the library’s presentation layer.

Developing this kind of service shouldn’t be too serious; it’s difficult to judge the best way of providing services (and even if you figure this out, you find out that people don’t like it). Additionally, it’s important to have access to multiple tools, so that people can be creative with the skills they have, and that they can choose the right tool for the given job. On the other hand, the library webpages should be provided within a consistent, well-structured framework that provides stable, high-availability webpages. This will help admin, maintainers, designers and customers, but this level of expectation should not extend to web services, unless they prove to be popular. Then, these webservices should be reprogrammed and initiated as part of the framework.

What needs to be done regarding development of webservices is to fix a set of ground rules that make it easier to migrate those that are successful to the main framework. Ideas like common access methods, storage methods, naming conventions will help transitions, as will good documentation. In larger environments, common code libraries can be used that give developers access to common functions (and provide easier transitions).

On the side of the framework used for webpages, it should support the methods agreed upon, and provide flexible options for representing the data provided by output in various formats.

One of the important factors is making a simple, intuitive API for services. Too little effort is put into the APIs of web services; a lot of people are still frightened by copying and editing Javascript. Since library applications will typically support a few, specific functions, the APIs require less in the way of flexibility, which makes it easier to provide a truly simple interface for page maintainers.

It’s important to be creative with the technologies we have, in this way, we might better see what we really want. And then we start developing real, new technologies that work for libraries.



%d bloggers like this: