Huw and I (Dan) went to Glasgow to the JISC LMS meeting.
So, if the joys of two nights spent catching sleep on the Caledonian Sleeper are the downside, what were the benefits?
Many actually. In three important ways.
First, we heard a lot of ideas. We plan to implement a fair few of them in our project. For example, another JISC-funded project, ConnectedWorks, has led to us investigating a browser plugin called iCite. When someone mentioned the idea of adding a "find in my library" button to amazon searches, we realised we had just the tool for the job. So we're going to add a web-assistant browse widget to the project. There were many other examples, some we will have time to do, others will have to wait for future projects.
Secondly, we learnt about other projects in the programme, including projects we could work with. The Wolfie project at UEA is a standout there, as is us using some of LSE's earlier work. Generally, lots of good networking went on.
Finally, we were helped to develop our arguments and pitches for our projects, to help us describe them to each other, and the various people who might be able to help us in their execution.
There was also some excellent discussion around UX, and how we might be better at pooling the outputs of our user research (to avoid duplicating effort) and be better critical consumers of UX research (we all know how much poor-quality UX research is there: how do we wind the diamonds amongst the glass?).
Monday, 20 September 2010
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.
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.
Monday, 6 September 2010
Back to school, off to Glasgow
After a typically fragmented August (if you're not on holiday yourself then everyone you need to speak to is) it's back to school for the CULWidgets team, starting with a trip to Glasgow for the JISC LMS Programme Meeting. As we draw slowly towards the end of the project it's a great opportunity to focus on what we've achieved and what we still need to achieve as well as a chance to see what everyone else is doing!
One thing we have made progress with over the Summer is getting the student data we need to give our widget services relevance. We have one minor technical hitch to get over, and then we should be able to get a test version of our Exam Papers Widget up and running.
This really is a key strand of the project for us. It involves institutional collaboration - the University Library, CARET, DSpace@Cambridge (institutional repository) and the Management Information Services Division (who run the student registry) are all integral to the project. It involves a new kind of material - the Library has traditionally only dealt with exam papers in paper form. It involves the provision of relevant services in relevant places. And it involves direct engagement with the student and academic community. Finally, we hope it will be a blueprint for the course-based delivery of teaching and learning materials across the University.
One thing we have made progress with over the Summer is getting the student data we need to give our widget services relevance. We have one minor technical hitch to get over, and then we should be able to get a test version of our Exam Papers Widget up and running.
This really is a key strand of the project for us. It involves institutional collaboration - the University Library, CARET, DSpace@Cambridge (institutional repository) and the Management Information Services Division (who run the student registry) are all integral to the project. It involves a new kind of material - the Library has traditionally only dealt with exam papers in paper form. It involves the provision of relevant services in relevant places. And it involves direct engagement with the student and academic community. Finally, we hope it will be a blueprint for the course-based delivery of teaching and learning materials across the University.
Subscribe to:
Posts (Atom)