Developing for mobile devices

Good article in UKOLN's Ariadne on developing for mobile devices http://www.ariadne.ac.uk/issue63/massam-et-al/#16 Lots of useful links and tips, and some nice quotes from students

Basically reaffirms that students will use mobile devices for the web when it's cheap enough, quick enough, and when screens are big enough to let them see what's going on ... and popular wisdom suggests that we are reaching this point.

Students also seemed to be saying that they would use the mobile internet to check (and possibly discover) rather than to consume (or possibly create). My hunch is that users will want to be able to duck into mobile interfaces to perform a distinct task - checking a reference, renewing a book, finding a library - and then duck out again.

The minimal startup time for mobile devices compared to laptops/desktops means that I often check something on a mobile even when I have access to a "proper" computer. For fact checking, the advantages of a proper keyboard/big screen don't outweigh that interminable wait for the whole thing to get going.

I use a laptop/desktop if I need to write anything longer than a tweet, or read anything longer than a (short) article - which I may have discovered on my mobile.

Providing library content on mobile devices is another matter, particularly as most of our electronic content is accessed via third party interfaces.

Integrating our own service

We've talked a little about collaboration and integration of services between institutions - but sometimes the need for integration is closer to home. At the UL we have two sources of library data - our Voyager library management system, and a local database holding specific information about each library in Cambridge. This ranges from opening hours to location, staff details to system information. The two databases are linked by common identifiers so they can "talk to each other".

This local database is used to drive interfaces such as the Cambridge Libraries Directory and Libraries Map. It's also the foundation of a number of services we provide for Cambridge librarians - web based reporting from Voyager, course booking, record enrichment, staff management and stockchecking being just a few. Essentially, we have used development based around this local database to fill in the gaps where Voyager either has no slot for the information we want to store, or doesn't provide the service we need.

Widgets provide the perfect opportunity to start tying this data together more closely. We're already doing this to a certain extent in the CamLib mobile interface - Voyager knows which library a book is in, our local database knows where that library is, allowing us to link out to a map.

But there are all sorts of other possibilities - from simple ones like including library opening times in searches, to more complex functionality like "show me the nearest copy of this book", or "only show me books which are held in libraries which are open now". Another example of how bringing data together to get an idea of context allows you to provide relevant services for your users.

Collaboration with DSpace@Cambridge

This is a quick hello from the CARET-based developers on the project, Raymond and Bert!

So far in our portfolio of widgets we have Huw's "Library widget", we have CamLib, a mobile version of that widget currently in beta release - and a prototype version of an Exam Papers widget written by Harriet, a previous Arcadia fellow.

As Huw explained in an earlier post, there are two main types of widget - those that retrieve data, and those that alter data. All of our widgets so far are primarily about the retrieval of information - the next new widget will be one focussed on alteration: a DSpace Upload Widget. This will make it easier for users to contribute content to our institutional repository: DSpace@Cambridge.

To facilitate this, we'll be collaborating with the DSpace@Cambridge team, who are based at the UL. Bert and I met with the DSpace team last week to kick this off.

Writing Web Services for widgets

In a previous post I outlined the importance of web services to widget development, and pointed to two kinds of web service - proprietary ones which you can't alter, and locally written ones which you can. Today, I'm going to concentrate on locally written web services, and talk about some of the issues involved in writing your own web services. We're going to be making our code available towards the end of the project, so you should be able to pick up some complete examples soon. In the meantime, here are some of the basic ingredients of a home-baked web service.

1. Getting started

• Programming language: we use Perl (and occasionally PHP).
• Data source: the database or dataset you want to interact with (i.e. Library Management System).
• Query language: the language you will use to retrieve or alter the data in this system. Usually SQL.

2. Finding a home

• Your web services will need to live somewhere on your web server. In theory they can go anywhere, but it's best to have a separate directory for web services in general, and then distinct sub-directories for each system or dataset you want to interact with.
  
• Putting all your web services into one overall directory has the added benefit of making it easier for your system administrator (or you) to keep on top of the permissions and settings needed for web service files. Basically, if you're writing web services in Perl, the directory needs to be CGI enabled, and the files need to be readable and executable by anybody (usual octal permissions 755).

3. Do a bit of thinking

• If you're doing a lot of interaction with a dataset you'll probably have a range of questions/alterations you want to throw at it. Most "complete" transactions with datasets are made up of multiple smaller transactions (i.e. to book a train ticket, you might need to find the current time, find the next train, and book the ticket.)
• Instead of trying to write one huge web service to do everything, break each activity into its smallest distinct parts. This will leave you with lots of small, simple web services, each of which does only one thing.
• Now you can chain these simple services together into more complex transactions - but you can also reuse them in other transactions. This saves you asking the same question (i.e. "what's the time?") again and again in multiple web services.
  

4. What input do you need?

• Web services are triggered by requests. These requests (like web services themselves) can be of two types - questions for services that retrieve data or instructions for services that alter data.
• Requests are made up of the location of the web service, plus as many parameters as are necessary to either frame the question or perform the instruction. These parameters make up the input for the web service.
• The smallest amount of parameters needed is none. Think about a question like "what's the time?". If you had a web service which just gave back the current time when triggered, no further parameters would be needed.
• Most web services take at least one parameter. Taking the "what's the time?" service, if you introduced a parameter of "city" the web service could alter the query depending on the value of the parameter. So the service could ask "what's the time - in London?", "what's the time - in New York?", depending on the value of the parameter.
• The rule of thumb with parameters is that you should use as few of them as possible in order to ask the question/perform the alteration. You can always add more if required. Again, you should be thinking of small, simple services, each related to a specific task.

5. Checking input

• There are two things you need to check your parameters for - existence and content.
• For each parameter, you need to decide if it is compulsory or optional. Compulsory parameters are necessary for the web service to perform its function. For example, a service to book a train will need the train time in order to make the booking.
• But you might make the "city" parameter of "what's the time?" optional - if it exists, return the time in that city - if not, just return the current time in the UK.
• All parameters, compulsory or optional, need to be checked for content. Either the value will have to be in a limited range (i.e. if the parameter value isn't "Y" or "N" then it is an invalid value). Or it might need to be a type of value (i.e. a number, or a string). Even in the case of parameters which allow "free text" values, you will still have to check for "dangerous" characters. Web services (and all programs executable by the web server) are vulnerable to security attacks, and you will need to make sure that incoming parameters don't contain anything dodgy.
• A good rule is to decide what values or kind of values you will allow in parameter values and build from there, rather than trying to disallow all the possibly dangerous characters (you may miss one). So a rule like "the value must be a mixture of letters, numbers, commas and whitespace" is better (or more secure) than "the value must not contain semicolons).
  

6. Building the query

• Having gathered and checked parameters (if any) the web service now has to perform its function. To do this, it needs to talk to the dataset - and the usual language for doing this is SQL.
• Web services which retrieve data will use SQL to ask the dataset a question - such as "What's the time in New York?"
• Web services which alter data will use SQL to form an instruction. For instance "Book a seat on the 9.15 from Cambridge to London"
• If your web services use parameters for input, these will (usually) be interpolated into the SQL. So, for the train booking example above, "9.15" would have been the value of the parameter "time", "Cambridge" the value of the parameter "from" and "London" the value of the parameter "to". Parameters are a means of altering the question or instruction which gets sent to the dataset
  

7. Returning the response

• All web services should send a response back to whoever made the request.
  
• For web services which retrieve data, this will be the answer to the question - i.e. for question "What is the time in New York" the response might be "The time in New York is 10.30".
• For web services which alter data, the response will tell you what the web service has done. So for the instruction "Book me a seat on the 9.15 from Cambridge to London" the response might be "Seat booked" or even the more verbose "Seat no. XX booked on the 9.15 from Cambridge to London".
  
• The response should be tailored to how it's going to be used. Sometimes, you'll just want to know if the request was processed ok, sometimes you'll need much more detailed information.
• Your web services should always send a response, even if the request fails. A response of "your request has failed" is far more useful than nothing at all!

8. Chaining web services together

• A common way of using web services is to chain them together - which means using the response from one web service as part of the input for the next.
• Taking the (very simplified) example of booking a seat on the next train, the chain might go something like this:
• Request to "what's the time?" returns value TIME
• Request to "what's the next train?" with parameter TIME returns next train after time as value TRAIN
• Request to "book seat" with parameter TRAIN returns value SEAT BOOKED

Et in Arcadia ego

Avid followers of this blog will have spotted references to the Arcadia programme, a three-year programme funded by a generous grant from the Arcadia Fund to Cambridge University Library. The grant will enable us to explore the role of academic libraries in a digital age, create new programmes and services, particularly for undergraduates -- and also to improve the external environment of the library.

If this sounds like your cup of tea, you might also be interested in the Arcadia project blog, written by many of those involved in the project, as Arcadia Fellows or supporters. This includes a surprisingly large number of the CULwidgets team!

Project Plan Post 7 of 7: Budget

Here's our project budget! (and this is the last of the "project plan" posts, so, dear reader, you can relax as we return to our normally scheduled blogging about progress and things we've learned.)

We have some travel and other expenses included, to enable us to meet up with other jiscLMS projects and to share what we learn on the project, and to pay for food and incentives for users who are involved with our user testing.

Project Plan Post 6 of 7: Projected Timeline, Workplan & Overall Project Methodology

Our project has a number of overlapping stages. Given that we're developing a portfolio of widgets, with some common elements, some of these activities will be repeated for the different widgets; and some early activities will be "infrastructure" creation, such as developing links with the institutional repository, which will be needed for most of the widgets later on.

1. Setting up of a project blog, Google Code site etc. Allocation of staff time and resources.
2. Identification of a sample set of library materials for a usable and useful prototype.
3. Identify target student groups in liaison with faculties and departments.
4. Investigation of course and exam codes as used by the student registry. Adoption of file naming and storage strategy for course materials to allow retrieval by course code. Link up with student registry data to tie course codes in with student authentication in a widget environment.
5. Creation of routine to automatically retrieve library materials relating to a student's course into a widget. Design of clear and logical display for library/course materials retrieved.
6. Integration of course materials delivery with existing library widget.
7. Production of prototypes
8. User testing of interface.
9. Rollout of live version. Launch and marketing within and outside university.

Here's our project timeline - we're already well underway!



We will follow a lightweight, agile development model, aiming to deliver frequent rough prototypes for user testing with students where possible, and staff outside of term. This approach has delivered successful JISC projects before, and is closely linked to the JISC Users and Innovation Development Model. In addition, we will apply our expertise in user-centric design which derives from the JISC Academic Social Networking project.

Project Plan Post 5 of 7: Project Team Relationships and End User Engagement

Dr. Dan Sheppard will manage the project from CARET, and brings extensive software development expertise and also project management experience of cross-departmental projects, particularly with the University Library.

A project board, comprising representatives of Cambridge University Library and the University of Cambridge Centre for Applied Research in Educational Technologies will take responsibility for overseeing the project:

• Patricia Killiard, Head of Electronic Services and Systems, Cambridge University Library
• John Norman, Director, Centre for Applied Research in Educational Technologies
• Dr. Laura James, Chief Operating Officer, Centre for Applied Research in Educational Technologies

News flash!
Dan is this term's Arcadia Fellow at the University Library, so Laura is stepping into the breach as interim project manager. We look forward to having Dan back for the bulk of the project...


We will follow a lightweight, agile development model, aiming to deliver frequent rough prototypes for user testing with students where possible, and staff outside of term. This approach has delivered successful JISC projects before, and is closely linked to the JISC Users and Innovation Development Model. In addition, we will apply our expertise in user-centric design which derives from the JISC Academic Social Networking project - this has shown us how to carry out really good user testing.

Project Plan Post 4 of 7: IPR (Creative Commons Use & Open Source Software Licence)

All software outputs will be released under an Apache2 licence, and all documents under a Creative Commons "BY" (Attribution) licence. This means that people can reuse our outputs, even commercially, which can support the creation of business models for more sustainable systems, including collaborative development across both nonprofit and commercial organizations.

You can see the CC licence at the bottom of this blog!

(Note I'm sticking with the British English grammar forms of licence/license :)

Project Plan Post 3 of 7: Risk Analysis and Success Plan

As all the resources we will produce (code and documentation) are hosted on servers elsewhere (primarily Google's) we are confident that success in terms of hits can be managed.

If the widgets we create turn out to be huge successes with users within Cambridge, supporting them will form part of the "day job" of some of the project team members. Support for a popular codebase within other institutions would be provided through the community and by the project team.

Here's our risk analysis:

Project Plan Post 2 of 7: Wider Benefits to Sector & Achievements for Host Institution

The integration of library resources and services with the University's VLE and social networking sites, particularly iGoogle and Facebook, is an institutional priority for Cambridge University Library. The Arcadia Fellowship Programme, based at the library, has already explored student information needs and identified the potential value of delivering library materials and resources to students in their workspaces in addition to conventional library-managed interfaces.

Through a partnership between the library and the Centre for Applied Research in Educational Technologies (CARET), which develops and manages the VLE Cambridge has made significant progress in this area, having developed the Cambridge Libraries iGoogle Widget. This already provides most of the example functionality outlined in the call, enabling students to view their library profile, view and renew loans, and view and cancel requests (it lacks only the ability to pay library charges). It is fully integrated with the University's authentication system, and is currently live in Facebook, iGoogle and CamTools, the University's Sakai-based VLE. One strand in this proposal would be to document and share the code for the widget in its current state.

The Library and CARET will build on this foundation, to provide a joined-up and relevant combination of library services and resource delivery outside the traditional library environment. We will extend the use of widget functionality to the delivery of other library materials - such as exam papers, reading lists, handouts, content from the institutional repository, and generic subject lists. It will make use of university identifiers to retrieve student course details from CAMSiS, the student registry system and this course information will be used to provide relevance in the delivery of library materials. The result will be a potentially powerful model of evaluating student profiles to provide relevant library services alongside appropriate teaching materials.


A further stage of development will focus on mining these course materials for links to library resources. This will enable us to start delivering relevant library content to students beyond the immediate library web environment. We envisage that one deliverable of the project will be a clear outline of the next steps in this area, and possible implications.



This project is a partnership between the University Library and CARET, a strong combination in terms of both skills and institutional roles. The University Library is the main provider of content for the support of teaching and learning in the University, and is repositioning itself to support the processes of teaching and learning more directly. CARET are leaders in the development of innovative educational technology, and are also the developers and operators of CamTools, the institutional VLE.

This project will produce a number of widgets delivering access to library content within social networking sites and VLEs in partnership with the Centre for Applied Research in Educational Technologies. It will explore opportunities for making content delivered through widgets relevant to the user by linking to course-codes held by the student registry. The project will assist the wider take-up of widgets for library-related content by making the code for the existing widget and those developed through the project openly available along with documentation and guidance.

Project Plan Post 1 of 7: Aims, Objectives and Final Outputs of the project

The project will build on the success of the iGoogle widget developed by Cambridge University Library to produce a number of widgets delivering access to library content within social networking sites and VLEs in partnership with the Centre for Applied Research in Educational Technologies. It will explore opportunities for making content delivered through widgets relevant to the user by linking to course-codes held by the student registry. The project will assist the wider take-up of widgets for library-related content by making the code for the existing widget and those developed through the project openly available along with documentation and guidance.

We will deliver a portfolio of fully documented widgets released under an appropriate open source licence, which will work across iGoogle, Facebook, and Sakai (our institutional VLE) as far as technically possible. We will aim to deliver as many widgets as possible which are found useful in user testing, and to open up as much appropriate and useful library content through the widgets as we can.



Our project outputs will be:

1. Widgets for: reading lists, past exam papers, lecture handouts and other course teaching content, and connections to other library content, delivered to students for their own courses using the student information system to create relevance information

2. Software code with full and clear documentation for the Cambridge University Library iGoogle widget
3. Guidance for libraries on code development for library widgets
4. Recommendations for future development path for library widgets
5. Project blog (which you are reading!)
   

Widgets and institutional collaboration

One of the reasons we became interested in widgets was that they seemed like a quick and easy way to start weaving together some of the disparate parts of University life. One of the truisms of working in large organisations is that service providers tend to focus on the boundaries between themselves and other groups (i.e. this is what we do) - despite the fact that for users these boundaries are either invisible or annoying.

The University Library has traditionally been seen as a provider of content. That content is then whisked off and used in the core processes of the University - research and teaching. The UL is now moving to support these core processes more directly - which means getting more closely involved with other bodies in the University.

Institutional collaboration, between the University Library and CARET, is at the heart of this project. Another important connection is with the Management and Information Services Division (MISD). They hold the student data (which courses students are on, which exams they are taking) which is essential to providing relevant services. We are hoping that our exam papers widget will provide a blueprint for using this data to retrieve learning objects - and also cement the working relationship between our institutions.

Our other initial collaboration is closer to home -with DSpace@Cambridge (the University's institutional repository) which forms part of the University Library. We're not just interested in getting valuable information out of DSpace (exam papers, theses, reading lists etc.), but also at getting material in. Part of the exam papers widget project will be to provide a widget for the deposit of material into the repository.

Collaborations tend to work best if there is something concrete to work on together, and widgets are a fast and lightweight means of providing that collaborative basis. Which makes widgets important for strategic reasons as well as for functionality.

library widget goes mobile

One of our project objectives was to take what we had learned when designing the original library widget - particularly about providing useful services in limited space - and apply it to mobile interfaces.

Today sees the Beta launch of CamLib - basically the library widget for mobile devices, with extra bells and whistles. Available here:

http://www.lib.cam.ac.uk/mob/camlib.cgi

Test login (for library card) is:

Barcode: VABCD
Surname: Bloggs

[do have a look around, try out the bookbag etc., but please don't use the request functionality if you can help it - not fatal, but will save some confusion at our end!]

It's been tested for iPhone, iPod Touch and Android devices - though not exhaustively, so please comment on this post and let us know if it's misbehaving.

We used jQTouch, a jQuery library for mobile development, which lets you write web interfaces which behave (to a certain extent) like native apps. There is a big debate in library circles about native apps vs web interfaces ... we decided on a middle path to get the best of both worlds.

We did some hard thinking about what people would want from a library mobile device, and apart from all the usual renewing/requesting/searching activities, we plumped for bookbag functionality - essentially the ability build up a list of items to look at later.

Viewing content on a smartphone is possible but awkward. And nobody wants to be finding books on their phone and then writing down classmarks on a piece of paper. The bookbag lets you build up a list of items as you search and then email it to yourself or others.

There's plenty of other functionality to explore, including links out to full text, Google Books, maps, floorplans etc.

For items in libraries other than the University Library (which locates onto a floorplan), the link to Google Maps will even use your phone's location system and tell you how long it will take you to walk/drive/bus to the book in question (click on Directions). Playing with this functionality over the weekend produced the surprising titbit that it would take 1 day and 10 hours of solid walking to get from my Dad's house in Bromsgrove to the issue desk of the English Faculty Library in Cambridge - quite a challenge for even the most committed scholar!