Widgets and Web Services
This document describes why you might want to use widgets and web services to solve some of the problems in your library.
The other documents in this collection are aimed at software developers. This introduction is for a more general audience of technically literate people, and describes motivation and general shape.
Whilst the remainder of these pages require software development skills, they do not require expensive engineers: a new graduate or a librarian with a sideline in software development should easily be able to get going with them to produce something useful.
Follow these links to find out more:
Why bother with widgets?
Often, the biggest obstacle to overcome when explaining widgets is to overcome the frivolity associated with the concept: the silly name; their ubiquitous use on social networking sites for producing pointless distractions, and so on. We encourage you to set such preconceptions aside, at least temporarily, and consider the following.
Widgets reduce the risk associated with experimentation
Widgets are small (we're talking person-hours or -days) and easily rewritten. This allows you to take risks in creating them. If some users have indicated that a widget might be useful, you can spend half a day creating one: much less time than it would take to perform a formal survey.
Think of how many projects there have been at your institution concerning integration of various computer systems. And think, nationally, how many projects there have been only to integrate catalogue and circulation information between VLEs with LMSes. Consider, particularly, their budgets. We have such functionality already, in production, against our enterprise sites, in use by academics and students, as a result of a small project, created by Huw Jones, a librarian. And that's just one widget.
Particularly at larger HE institutions, we are used to inter-departmental collaborations involving endless meetings, vague strategy, and nobody to arbitrate or direct the project below vice-chancellor level. So, what we offer to students simply ends up being disjointed.
Developing software with such a low overhead allows integrations to occur "below the radar", and "under the budget" of large, difficult projects.
No more "you'll need to login to another system"
Remembering URLs, usernames and passwords is difficult, and we seem to spend so much of our time logging into systems and finding our way from the front page to where we want to be.
As a user, widgets allow you to do things "from where you are". There's no "that's in another system" issues. A user can, effectively, design their own screens to fit the way they work. There is no need to login again (auth permitting), to remember a URL, or to navigate to the page you actually want through a maze of initial pages. A screen of widgets might contain some widgets derived from the LMS, some from the VLE, some from teacher-provided data (such as reading lists), and so on.
Many of these containers (for example, in a VLE) have rich knowledge of the current user, too. That means that you can present "zero-click" search results, for example for exam papers: there is no need for a student even to search for the papers they are taking because the results displayed by default are usually what the user is after. (However the opportunity is presented to change this, if the user wishes).
Both of these mean that the user spends more time interacting with the real content, and less time navigating.
Moving development towards specialists
Writing widgets, and particularly services, does require some development expertise, but it doesn't require much, and certainly less than most other approaches. This makes it much easier to keep control of the development. You might have a librarian who is handy with software development. Your library might have a website maintainer who can do it. You might be able to hire someone directly into your library on a short term basis. There's certainly no need to engage a big external organisation.
We'd particularly recommend widget writing to institutions which have struggled, technically or socially, with integration and development in the past, and where the students are faced with a confusing array of different systems to use.
Despite their silly name.
- Copyright 2010 Cambridge University Library West Road Cambridge CB3 9DR (01223) 333000
Information provided by Electronic Systems and Services