One Minute Pitch

One of the requests which came out of the JISC LMS meeting was that we prepare a one minute pitch for our projects. (Commonly known as "elevator pitches". The idiosyncratic lift at the venue was very much the ghost at the feast on the first day of the meeting, having a tendency to steal the limelight by appearing on our floor unbidden and aimlessly chomping away with its doors throughout proceedings But, anyway,...).

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.

There are two reasons for using widgets for library services.

Number One: widgets make things happen in institutions with complex organisation and a tendency for long meetings and endless debate. That's one of their main advantages. Development is in three parts. The information provider provides an API (as they see fit). The consumer provides a widget container (again, as they consider appropriate). Neither of these two parts require extensive consultation. The final part, the widget itself, -- which is the only part which ties the two parts together, -- can be written in a day.

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. Think, nationally, how many projects there have been to integrate just catalogue and circulation information between VLEs with LMSes. Consider 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. And that's just one widget.

Number Two: 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. No need to login again (auth permitting), or remember the URL or navigating to the page you want from the front page of a particular site. A screen of widgets might contain some parts 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: no need even to search for them because the results displayed by default are usually what the user is after. Both of these mean that they spend more time interacting with the real content, less time navigating.

Both of these things excite us, and present an opportunity to improve the way we do things and make what we offer to students more compelling.

So we're producing example APIs and Widgets as might be used at other institutions, along with guidance of how to do so. We're putting our money where our mouth is by developing at least half a dozen widgets we anticipate being useful to students and academics (some of them have been repeatedly explicitly requested, some others are widget-ising of existing useful functionality), and writing up how you can go about it at other institutions.

So, we'd particularly recommend this approach to institutions which have struggled, technically or socially, with integration in the past, and where the students are faced with a confusing array of different systems to use, as widgets can help with both of these.

Despite their silly name.