1. No category

Document title: Project Document Cover Sheet
Last updated: April 2007
Project Document Cover Sheet
Project Information
Project Acronym
EGRET
Project Title
Engaging Responses to Emerging Technologies
Start Date
June 2008
Lead Institution
University of Cambridge
Project Director
John Norman
Project Manager &
contact details
Laura James
[email protected]
Partner Institutions
n/a
Project Web URL
Programme Name
(and number)
Egret-project.blogspot.com (blog)
www.caret.cam.ac.uk/page/egret
Institutional Respons es to Emerging Technologies
(JISC0108)
Programme Manager
Rob Bristow
End Date
July 2009
01223 765 377
Document Name
Document Title
Final report
Reporting Period
Whole project
Author(s) & project
role
Laura James, Project Manager
Date
20 August 2009
Filename
URL
Access
 Project and JISC internal
X General dissemination
Document History
Version
1
Date
20 August
2009
Comments
Submitted version
Project Acronym: EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
JISC EGRET Final Report
Author:
Dr. Laura James
Contact:
Dr. Laura James or John Norman
CARET
First Floor, 16 Mill Lane
Cambridge
CB2 1SB
Date:
20 August 2009
Page 1 of 25
Document title: JISC EGRET Final Report
Last updated: 20 August 2009
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Table of Contents
Acknowledgements........................................................................................4
Executive Summary........................................................................................5
Background.....................................................................................................6
What is Talks.cam?
6
A new approach to institutional system development
6
A brave new world of user-generated content
7
Social Networking and Groupware
7
Aims and Objectives......................................................................................8
Methodology and Implementation.................................................................8
How Talks.cam came into being
9
Handover
9
Operations, hosting and support
10
Software development
11
Social networking within the university
13
User-generated content
13
Institutionalisation guidelines development
13
Engaging stakeholders
14
Extending to other institutions and funding and models
15
Outputs and Results....................................................................................16
Institutionalisation of software
16
Learning around institutionalisation: software versions and language choices
16
Learning around institutionalisation: conclusions
18
Talks.cam usage figures
19
Talks.cam usage study: Lent Term 2009
19
Page 2 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Talks.cam software
21
Reports
21
Outcomes......................................................................................................21
Conclusions..................................................................................................22
Implications...................................................................................................23
Connecting administrative systems
23
User-generated content (UGC)
23
Institutionalisation
23
Talks.cam into the future
24
References....................................................................................................24
Page 3 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Acknowledgements
The EGRET project was funded by JISC as part of the Institutional Responses to Emerging
Technologies programme (IRET). It was ably supported by Rob Bristow (programme manager) who
provided guidance and flexible support which was invaluable to the project. In addition, the support
team were terrific and always encouraging and enthusiastic.
EGRET also thanks the project team: Verity Allan, Will Billingsley, Raymond Chan, Daniel Parry; and
those who have helped along the way: John Norman, Ian Boston, Dan Sheppard, and all the IRET
programme participants.
The Talks.cam creators who contributed to the EGRET project were: Alan Blackwell, Duncan
Simpson, David MacKay and Tom Counsell, and all provided great assistance with our work.
We also thank the other original creators and supporters of Talks.cam without whom none of this
would have been possible.
Last of all, thanks to the many seminar organisers, talks attendees, departmental administrators,
computer officers and webmasters, and others, who have used the Talks.cam system over the years
and by doing so proven true demand for a grassroots IT system built on user-generated content,
before many people even knew what that might mean.
Page 4 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Executive Summary
The EGRET project sought to institutionalise Talks.cam, a novel system at the University of
Cambridge created by academics, but with potential value to the whole institution. Talks.cam was
designed as a clearing house of user-generated event information, to help academics easily publicise
seminars they organise, and to learn about scholarly events which they might be interested in.
From its origins as a grassroots software experiment created by academics, Talks.cam now has been
successfully and completely absorbed into CARET, an innovation unit within the University which
supports teaching, learning and research activity. This is the first such service handover within
Cambridge and as such is a great achievement for this modest project. The example of Talks.com is
being used as an exemplar project in discussions concerning the general approach of the University
to fostering IT innovation. The potential ramifications are considerable, but not yet fully explored,
possibly leading to reorganisation of the IT units of the University. The learning from EGRET about
the detailed stages of institutionalisation will be invaluable to future efforts, for which system and
process evolution and handover is an essential process to ensure success and sustainability for
valuable technology projects.
Talks.cam is now heavily used throughout the University and beyond in the Cambridge area. Using
June 2009 to illustrate Talks.cam usage at the end of the EGRET project, we see almost 100,000 user
logins during that month, with an average of 101,664 site hits per day. The importance of the system
(and its successful integration into the institutional IT infrastructure) is illustrated by Talks.cam events
information being included in over 40 different websites within the university, including high profile
departmental webpages.
Interdisciplinary and thematic research is of ever-growing importance within the university, and with
external partners, and is well supported by Talks.cam, which enables relevant events to be drawn
together. Researchers across conventional departmental and group boundaries can find seminars
they are interested in where ever they might occur within the university, and through this can meet
and get to know other academics with related interests. This is a huge improvement over the previous
methods of publicising talks and lectures, which were rarely able to attract anyone outside the
immediate department where they were held. The added value of Talks.cam to research is
substantial.
At the outset of the project, we anticipated integrating Talks.cam into the wider IT infrastructure of the
university through the use of OpenSocial. This would have involved various individual IT services
being able to connect to each other in a “social” way via the OpenSocial APIs, supporting an
increasingly people-centric and integrated environment within the university intranet. While an
OpenSocial gadget remains on the roadmap for Talks.cam, it has become clear that a better path for
full institutional integration of Talks.cam into an academic networking context might be through
building Talks functionality into the institutional virtual learning and research environment (CamTools/
Sakai). The details of how this will work have yet to be finally resolved, and may involve the complete
reworking of Talks.cam functionality within the CamTools platform, a continuing standalone system but
with new interfaces to CamTools, or a mixture of the two. The prospect of CamTools integraton was
not expected, but has been adapted to by the project team and it promises a rich and interesting
future for Talks.cam within Cambridge and potentially beyond.
The EGRET project has also fostered interest and confidence in user-generated content at
Cambridge. Talks.cam is the first large scale system to rely on end users supplying accurate and
useful information, and has shown that this can work well and effectively. It has given credibility to the
idea of letting users take the lead on content creation, and this is reflected in a number of new local
initiatives, including projects by the Office of External Affairs and Communications where university
staff and students are empowered to create short films about the university for public distribution on
institutional websites.
Outside Cambridge, the EGRET project has spurred interest in events syndication and the benefits
this can bring to researchers and research outputs as a whole. As well as other universities and
organisations (such as the British Neuroscience Association) who are now working with CARET to
Page 5 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
explore how best to get a Talks system for their own use, we are continuing to investigate how a
national research seminar listings system might work. This could be a larger scale Talks system with
events tagged with locale information, or a gateway to a number of federated Talks instances in
individual institutions. We look forward to potentially working with JISC and others to bring the power
of Talks.cam to a much wider audience in this way, and to expand the area within which researchers
can find events and people with the potential to enhance their work.
Background
The EGRET project aimed to institutionalise a user-generated content events syndication and
publicity system (Talks.cam) which had been created by a group of academics, and to look into
adding social features to Talks.cam as part of this process.
What is Talks.cam?
Talks.cam is a lecture publicity and syndication service. Organisers of lectures or seminar series can
submit details of their events, which are put online in a public website, and which are shared via
various methods including RSS feeds, Calendar feeds, email reminders, embeddable website
widgets, and so on. Users who wish to attend talks can subscribe to “lists” of talks on certain topics,
arranged by specific groups, in certain venues, etc, and these lists are then supplied to them in the
various syndication methods described. Because anyone can join Talks.cam, whether to view talks or
set up lists of talks series as talks organisers, the system is fully user-generated content, with no
centralised control or hierarchies.
Readers of this report can play with Talks.cam by visiting the website 1 and signing up as a user. The
full development history of Talks.cam is detailed in the “Methodology and Implementation” section
below.
A new approach to institutional system development
Cambridge has a range of admin systems (as do many other universities) including:
• CamSis – student information and records system
• CamTools – virtual learning environment
• CamRis – Research Administration System
• CHRIS - Human Resources Information System
• Talks.cam - event information system
• Pfact – Project costing system
• CUFS – University Finance System
• Lookup – email directory for individuals
• RAM – Resource Allocation Model
Although many of these now have web front-ends, most have been built as monolithic stand-alone,
functionally oriented, applications using well established software design and development principles
that pre-date web technology. They have been initiated and developed within centralised IT systems
organisations within the university as a rule.
Talks.cam broke this model, being a grass-roots development project initially, created by academics to
meet a need they themselves perceived. As such, it broke several of the traditional tenets of
institutional software design and development; it was not built by a central IT provider or with thought
to an eventual place within institutional systems; it was not built following traditional “large IT system”
planning and processes; it was not launched as a short formal pilot before a careful evaluation; it had
no concepts of hierarchical authorisation or fitting into university structures: instead it allowed all users
to be equal. Unlike how a similar system might have been constructed by a centralised IT provider in
the university, Talks.cam used software platforms designed for rapid web system prototyping, the
development methodology drew on advanced concepts in user centred design and development, and
1
http://www.talks.cam.ac.uk
Page 6 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Talks.cam did not integrate institutional single sign on from day one - this was added in at a later
stage.
Instead, Talks.cam’s creators identified their personal needs and rapidly prototyped a system which
met them, deploying it on local computers which they had access to through their departmental
computer officers. They shared the existence of the software with colleagues within their departments
and the university, allowing others to try the system out, give feedback, and therefore the system to
be improved. There was no official support for the system, only that provided by the creators in their
“own time.”
Usage grew through word of mouth, and Talks.cam was adopted by more users as the creators
evangelised their system - a great deal of the takeup was simply because Talks.cam began to hold
valuable information, and shared it in a very easy to use manner. Some departments and thematic
research initiatives began to use Talks.cam wholeheartedly and provided some modest and fairly
informal support to the system in terms of staff time.
In the long term, this was found not to be sustainable as Talks.cam grew popular and people began to
depend on it, without realising in many cases that it was not a fully official and supported system. The
EGRET project began shortly after the baton of Talks.cam was passed to CARET so that Talks could
be institutionalised - a first for the University of this kind of process.
EGRET investigated the implications of this handover process, and proposes a framework to better
support such handovers in the future - framework guidelines for stages of institutionalisation of
software projects of this ground-up type.
A brave new world of user-generated content
Talks.cam and the EGRET project therefore took a fresh view of the development of university
administrative systems in terms of the processes use to develop software and roll it out to users. But
Talks.cam also represented a first foray into the world of user-generated content systems for the
university; a paradigm perhaps more familiar in the consumer systems of Web2.0 such as Flickr,
YouTube, and so on.
The EGRET project has examined the implications of this system as Talks.cam moves from an
unsupported system to an institutional one. As well as investigating the impacts of user-generated
content on an “official” university system, the project also took the somewhat unusual step of
considering the needs of the role of departmental administrators (as well as students and academics)
who currently need to interact with a range of administrative systems for effective performance of their
day to day tasks such as event and meeting organisation, diary management and scheduling.
Social Networking and Groupware
As at 1 July 2009 there were over 44,000 users of Facebook that declared themselves to be part of
the ‘Cambridge’ Facebook network (a smaller, but significant, number is believed to belong to the
LinkedIn network). This is up from approximately 33,000 in September 2007. The figures suggest that
the phenomenon of interacting through social networking software is expanding rapidly and becoming
commonplace amongst university academics, students and graduates. Indeed this is supported by a
recent research carried out by the University of Cambridge as part of its Higher Education Academy
Pathfinder project 2. This investigated the student experience of teaching and learning, in particular
with reference to the use of various technologies including email, the web, mobile phones and social
networking software. This study found that many students access social networking applications
several times a day and use it as a primary mechanism for facilitating interactions. Facebook and
similar applications are being used as a platform to support informal learning and interactions
between students with particular study interests.
2
http://www.caret.cam.ac.uk/blogs/llp/
Page 7 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Concurrent with the growth in social networking is a growing use of institutional groupware for
collaboration and learning support. Within the University of Cambridge the use of CamTools, the
virtual learning environment based on Sakai, has increased rapidly in the last few years and the
system currently supports more than 6,500 unique users per week.
These trends provided an exciting opportunity to integrate social, research, and study networks with
event diaries (and possibly resource collections) so that users can manage these currently disparate
elements of their lives in one place. However, the convenience of a more integrated user interface
must take into account other issues such as ownership and control of data, privacy and security. It is
not yet clear how users would want to partition their information from the point of view of other people
being able to access it. There is also functional overlap between different social networking
environments and institutional information systems and it is not clear why users currently choose one
platform rather than another to service particular needs.
These aspects provide context for the EGRET project and although for timing reasons (see below) it
was not possible to fully investigate how social networking concepts could be used to link institutional
systems as part of a more person-centric set of university administration tools, this work will continue
in other projects at CARET and the University in the future.
Aims and Objectives
The aims and objectives at the start of the project were as follows:
1. To extend the current pilot use of the Web2.0 “Talks.cam” application to full-scale use across the
institution, including adoption by an institutional IT group for sustainability and sharing of the code
under an open-source licence. The application is written in Ruby.
2. To provide integration between “Talks.cam” and legacy institutional systems in identity
management and groupware as well as a variety of popular social networking platforms such as
Facebook, Myspace and LinkedIn.
3. To provide example illustrations of the utility of Talks.cam, and integrated legacy systems and
social networks, to departmental administrators
4. To provide generalised framework guidelines for emergent software project development to
enable eventual institutional adoption, with Talks.cam and other projects used as examples at
various stages of development
Objectives 1, 3 and 4 have been met. Objective 2 was not completed in the anticipated form, but
additional work took place instead, and it is expected that through the JISC Academic Networking
project and other work at the University of Cambridge, the original aims of objective 2 will be delivered
on a larger scale.
Methodology and Implementation
The EGRET project had several strands. One was the adoption of the Talks.cam system by CARET,
an institutional IT provider and innovation unit, and its development into a supported system. Another
was development of Talks.cam itself, including adding social networking features, in parallel with
operating and hosting Talks.cam and setting up support systems. Another was a research strand into
how university administrators use Talks.cam, what features they need, and the impact of social
features on privacy/convenience tradeoffs; an unanticipated component of this work was an
examination of the challenges of a fully user-generated content system within the university. Finally,
Talks.cam was used as an exemplar of a project going through a process from initial idea to full
institutional service, and based on our experiences with this and other projects, we propose a
framework which will guide future projects through this process.
To describe the stages of institutionalisation undertaken within EGRET, we must start with a little
background: the Talks.cam story.
Page 8 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
How Talks.cam came into being
Talks.cam was originally a joint project of Cambridge University Research Exchange3 the Inference
Group4, The Department of Physics Cavendish CTA 5 and Crucible 6.
Talks.cam was created by Alan Blackwell (Computer Laboratory), Phil Cowans (Department of
Physics), Tom Counsell (Department of Engineering), David MacKay (Department of Physics), Mike
Rose (Department of Physics) and Duncan Simpson (Cambridge University Research Services
Division). Version 1 of Talks.cam, which was live from February 2005 to 14th April 2006, was written in
PHP by Phil Cowans. Version 2 of Talks.cam, which went live on 14th April 2006, was written in Ruby
by Tom Counsell.
This group identified some needs which were not being met at the time. Cambridge enjoys a wealth of
seminars and lectures on interesting topics, organised by societies, departments, research groups,
and individuals. (When we mention lectures in the context of Talks.cam, we refer to all lectures other
than those associated with taught courses, which generally are not listed; we mean special seminar
series and guest lecturers and reading groups and more) How could a curious person – a graduate
student or postdoc new to Cambridge, say – find out about these excellent lectures? Some
organisations printed posters or flyers and circulate them to departments. Some advertised their
lectures in publications such as the Reporter, Varsity, and The Cambridge Student. Many circulated
announcements by email. Most organisations had, and have, websites on which their lectures are
listed. But there was no simple way reliably to find out `what’s on?’; nor, the more important question,
`what’s on in my areas of interest?’
A few organisations attempted to fill these gaps, collating lists of interesting seminars and circulating
them by email - a time-consuming task, and in any case email is not an ideal format for long lists of
talks. Some departments had a web-page containing links to all their seminar-list web-pages (such as
Engineering); but it is still a laborious process to click through to all those pages while hunting for a
particular seminar. If the user wants to know `what’s on this afternoon?’, he had to visit every seminar
webpage.
Talks.cam is the service that enables people to find information about seminars and lectures in
Cambridge, allowing all organisations in Cambridge conveniently to publish their lecture information,
and enabling anyone to search through the database in a manner suiting their interests. Talks.cam
also serves syndicated `what’s on’ information directly into the webpages of many organisations in
Cambridge, with each syndicated information stream tailored to that organisation’s interests.
Talks.cam is intended to be the premiere listings service for intellectually stimulating events in
Cambridge.
In creating talks.cam, the aims were to help all research groups and societies throughout Cambridge
to advertise their lectures; to reduce the labour involved in organising talks and maintaining webpages
associated with seminar series; to enhance cross-disciplinary and serendipitous interactions in
Cambridge; to help new societies in Cambridge to publicise their events; to help student-run
organisations to maintain continuity as their committee memberships fluctuate; and to provide, in our
database, an intellectual overview of the activity of the University, unconstrained by the conventional
boundaries between organisations. Talks.cam has always been open to all organisations that put on
talks in the Cambridge area to share talks, and to anyone at all to view talks.
Handover
Talks.cam was built, then, by the aforementioned group, who felt the important principle was to build
something and to put it in front of people, to see what was useful and what wasn’t, and then to modify
3
http://www.cure.group.cam.ac.uk/
4
http://www.inference.phy.cam.ac.uk/is/
5
http://www.cta.phy.cam.ac.uk/
6
http://www.crucible.cl.cam.ac.uk/
Page 9 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
it. It was hosted informally, and the interface and backend software went through a few iterations, and
many people in the University heard about the service through word of mouth.
As usage increased, the original creators of Talks.cam, particularly David MacKay, Alan Blackwell and
Duncan Simpson, began trying to find a proper home for it within the University. This proved
challenging, as many departments and IT groups turned them down. Eventually, however, they came
to CARET, who were willing to take on Talks.cam and secured the JISC EGRET funding to work with
it.
We established a project board, comprising David MacKay, Alan Blackwell and Duncan Simpson
representing the original interests of Talks.cam, plus the Director of CARET, John Norman. This met
regularly throughout the project and will continue to exist and meet as a steering group for the
Talks.cam service after the end of the EGRET project.
The handover process was new to all parties, and so although some aspects were planned, many
more were issues which had to be handled as they arose. We used several approaches in parallel:
✦
✦
✦
Regular meetings of EGRET project board (comprising 3 original creators of Talks.cam plus
CARET’s director). These were used to address issues that had arisen in the project in the
previous period, that needed discussion between the group and which were not sufficiently
urgent or well-defined to be suited to an email resolution.
A takeover of the basic service Talks.cam onto CARET servers, plus a redirect of the
“webmaster” email address which was used for almost all correspondence with the service.
Then CARET simply attempted to run the service and tackle problems as they arose, either
internally where possible, or by reference to the board via email or in the next board meeting.
Two “JIRA” ticket tracking systems were used, one for helpdesk requests and one for
development and operational issues related to Talks.cam. As part of our normal operations, we
began to review helpdesk and error logs regularly to extract bugs and feature requests which
needed review and prioritisation, as well as bringing in the development ideas and plan for the
EGRET project.
Official technical training handover formally agreed with the original authors of the software
Areas which required handover discussion at a project board level, particularly those we would not
have anticipated, included:
✦
✦
✦
✦
✦
✦
Software development (bug fixes, feature requests, overdue work)
Helpdesk functions
Background to decisions made
Philosophical and practice drivers for future decisions
Service governance and ownership
authority to control the domain
In the following sections, particular areas which needed tackling in our handover (whether through
problem solving, board discussion, or other work) are highlighted.
Some issues which might challenge other, similar projects, but which posed no significant problems or
surprises for EGRET, included IPR around software source, and the agreement around the initial
handover, as the creators were all ready and happy to hand the system across.
Operations, hosting and support
There were a number of cultural issues in the operational side of things, where CARET needed to be
able and ready to compromise and to relax what could have been perceived as “official” CARET ways
of doing things. One example is that Talks.cam is written in Ruby on Rails, a system in which CARET
had no expertise, and no hosting experience. We had to be able to figure out the requirements of
putting a Rails system into production - not as a pilot or experiment, as might be expected given
CARET’s status as an innovation unit, but as an increasingly mature system.
Page 10 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
CARET also took over the “webmaster” email address from Talks.cam, redirecting this to a proper
helpdesk ticketing system rather than simply a small distribution list. This enabled us to begin to build
a proper support structure for Talks.cam. Because we had no archive of previous emails to the
webmaster, we had no knowledge base of what issues commonly came up, or how to answer
frequent questions. As such, the project team members operating the helpdesk and supporting faculty
users directly had to be creative, quick thinking and supportive, figuring out how to help users, and
also the bounds of “reasonable” help, as issues came in. They also had to capture some of this
knowledge, in either the helpdesk ticket system, the main bug tracking ticket system, or the project
internal wiki.
As we ran the service, we soon realised that it was not as “install and forget” in nature as we might
have anticipated. In fact, Talks.cam produced a fairly large volume of error messages. We set up a
ticket-tracking system to log the messages so that we could store, analyse and consider them
properly. Errors were commonly found, for example, in some form entries in the web interface; as we
established these, we fed them through to our main bug tracker for development prioritisation.
Another challenge related to recapturing governance aspects of the project in operational terms. For
example, the control of the domain name (DNS) and email (MX) control did not initially rest with
CARET, and indeed these systems had been arranged so long ago in the past that it took detective
work to identify where they were held, and how to arrange and authorise handover to CARET. We
also found a range of varied email lists for differing purposes, all with different subscribers, usage
levels, and staff able to administer them. As Talks.cam had already gone through several iterations
over a reasonable time period, some lists were managed by people who had since left the University
or forgotten that they held any responsibility, and contacting them and agreeing handover required
diplomacy and persistence.
Software development
Our initial plan was that we would add some social networking features to Talks.cam within the
EGRET project, using OpenSocial 7, which would allow us to connect Talks.cam to CamTools8 ,
Cambridge’s Sakai 9 - based virtual learning and research environment. OpenSocial defines a
common open API for social applications across multiple websites; with standard JavaScript and
HTML, developers can create applications that access a social network's connections and update
feeds.
We encountered a number of issues with this plan. Firstly, it soon became apparent that Talks.cam
had a number of bugs which were causing large numbers of error messages. Whilst we could have
ignored the errors, even a cursory examination of some showed that a good number were being
generated when a user was trying to input form data, and that users were probably encountering
problems with the software - even though we were not generally receiving bug reports from the users.
We felt it was important to address some of these issues.
Secondly, during the course of the project we found that the Talks.cam system was not operating as
smoothly as we would have liked; some of the late-night batch jobs, such as sending out email
notifications of talks to users, were failing due to the large size of the tasks. Again, this pointed to
bugs we wanted to fix to make the system more robust.
Through monitoring and responding to emails to the webmaster address, we also identified a range of
issues which were troubling our users to varying degrees. Additional bugs were also raised by the
original creators of Talks.cam who had known of various existing issues, but had not had the
resources to address them.
7
http://code.google.com/apis/opensocial/
8
http://www.caret.cam.ac.uk/page/camtools
9
http://www.sakaiproject.org
Page 11 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
We also hit a number of timing issues to do with our integration with CamTools. Our intent was to use
OpenSocial to connect Talks.cam to an Apache Shindig 10 module within CamTools, which in
development at the time of the project kickoff was based on Sakai 2.5. Apache Shindig is an
OpenSocial container and helps developers to start hosting OpenSocial apps quickly by providing the
code to render gadgets, proxy requests, and handle REST and RPC requests. A deployment of
CamTools using Shindig was due in early Fall 2008. However, CamTools development during
mid-2008 was challenging with a great many user interface improvements and related server end
changes required, and the addition of Shindig proved impossible in the timescale available. As such, a
new version of CamTools was launched, based on Sakai2.5, but without Shindig or any OpenSocial
container. We could not connect Talks.cam to this new CamTools via OpenSocial. We hoped that the
next round of CamTools development would bring in Shindig; this development was to move forward
from Sakai2, and to begin work on the whole new project of Sakai3, written from scratch by a group of
universities spearheading a new round of innovation in this area. Sakai3 was to include Shindig,
which was great news for EGRET in that social features would be incorporated into new institutional
software from day one, allowing strong social integration, and features which were crafted, rather than
retrofitted. Unfortunately, the development of Sakai3 did not proceed as rapidly as was initially hoped,
and the integration of Shindig was pushed out during the development cycle; in the end, at the time of
the end of the EGRET project, Shindig integration had still not been accomplished.
In light of these issues, we re-prioritised our work somewhat. We identified several phases of bugs
which needed fixing, from error messages, user bug reports, and steering group requests, and
undertook development to address these through the project. These bugs and requests included
items such as malformatted feeds, unclear data entry fields and settings on the website, confused
navigation structures for the website, new output types (such as a departmental poster) and so on.
Each round of development was preceded by a prioritisation phase, during which steering group and
project team input was gathered to capture the demand for each item, and the list of tasks for each
round was decided by the project manager following input from these stakeholders. The development
work was undertaken using version control at all stages and quality assurance was carried out using a
staging server independent of the deployed production system. Before deploying a successful round
of features into production, we reviewed the system documentation to ensure it stayed accurate and
updated it at deployment time if required.
The codebase is now substantially improved. One outstanding item, which has not been carried out
due to concern about the stability of the deployed system, is a Rails version upgrade. We are now
somewhat “behind the curve” with our Rails version, and a substantial upgrade could affect our
production system adversely. We hope to undertake this in the future when a sufficient allocation of
production and Rails expertise is available for an appropriate length of time to embark on the work.
Although we were unable to integrate with CamTools via OpenSocial, we did spend some time
evaluating what this would require; one of the prerequisites would be the Ruby on Rails upgrade of
the previous paragraph. We also explored the different functionality and interfaces that would be
needed to support various options. We also felt that we should attempt to connect Talks.cam to
CamTools, in the short term, before OpenSocial or other full social networking support comes
onstream. As such we are now developing a Google gadget which enables CamTools users to
interact with their Talks.cam events via our institutional single sign on system. This will make the
migration to fully social events listings easy once CamTools moves to Sakai3 with social networking
and OpenSocial built in.
An additional challenge to our development plans was that the nature of Talks.cam is such that we
cannot easily contact all our users. Although superficially it may seem that we have a fixed list of
users - of account holders - this list is not much use to us. Firstly, it incorporates a great many people
who would not consider themselves Talks.cam users - people who have made an account and used it
only once, or whose accounts were created “automatically” when they came to speak at Cambridge.
Secondly, many users of Talks.cam may rarely log in, but use the system daily via email alerts, RSS,
iCal feeds and so on. Finally, users who benefit from Talks.cam may be separated via another layer of
indirection - for instance, a regular viewer of a website which has embedded talks listings within it.
These latter two categories of user interact with Talks.cam so rarely that they are sometimes unaware
that they use the system; the project team has had conversations with people who say they have
10
http://incubator.apache.org/shindig/
Page 12 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
never heard of Talks.cam, but when the system is described, they realise that it’s what sends them
email alerts of biochemistry seminars.
As such, when we are planning an upgrade, with new features or downtime, we are unable to
reasonably notify our users. An email to account holders would confuse more than anything else; a
message on the website front page would not be seen by many users; an insert into daily events
feeds would be unsightly within websites using Talks.cam syndicated content.
Social networking within the university
The original intent of EGRET was to use OpenSocial as a socially- and user-oriented glue to connect
Talks.cam, CamTools, and potentially other institutional IT systems. During the course of the project,
it became clear that this was perhaps not the best strategy. The evolution of other institutional IT
systems and also IT strategy within Cambridge suggested instead that the kind of social eventoriented information of Talks.cam might be better offered within CamTools as a central institutional
system.
This is an alternative path to institutionalisation for Talks.cam, where rather than sitting within a
somewhat federated system of sites, connected via OpenSocial, the functionality instead becomes
embedded within another established institutional system. The details of how this might work are not
yet fixed; Talks.cam could remain as a standalone system in addition to “talks.camtools”, or it could be
fully subsumed or replaced. These issues remain to be explored as the next stage of Talks.cam
evolution.
This points to the challenges of identifying an institutionalisation path in advance of the actual
process; this was not foreseen by the project team, but now seems like a clear direction for some or
all of the functionality.
User-generated content
The original intent of Talks.cam was that it should be a freely available, open system. The design
should be simple, easy to use, requiring a minimum of effort to get data into the system or find what
you are looking for.
There are some tensions between this design philosophy and a desire to grow the service and extend
its reach. For example, the simplicity of account creation has lead to challenges as institutional singlesign-on had to be retrofitted, and we now have a number of users with multiple accounts, and a great
many helpdesk requests involving people confused by whether they should use an automaticallycreated email-based account, their own email-based account, or the institutional single-sign-on
system.
Institutionalisation guidelines development
When considering how software projects might undergo institutionalisation, it is important to realise
that this does not mean that all projects will become fully adopted, university-wide deployments.
Indeed, a key part of the guidelines we propose is that projects go through a gating process, and
some or possibly many will "block" at a gate for one reason or another.
This does not by any means imply that these projects have failed. Instead, they are simply
acknowledged to be of a scale and support level which is below that of a fully institutionalised system.
They may be heavily used within some niche, or used widely; they may be beloved, essential day to
day tools for some users; they may be useful but little-noticed tools; but they may not have all the
attributes of an institutional system - a helpdesk, an understood level of service in terms of uptime, a
process by which new features are added, backups, and so on.
The guidelines were developed throughout the project; as we addressed each individual part of the
work, we made a point of observing whether this bore upon the process of institutionalisation, and
later reviewing the issues in batches according to topic; this drove forward the team’s thinking around
Page 13 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
institutionalisation and eventually lead to the draft guidelines, which at the time of writing are in
internal review.
Engaging stakeholders
Balancing the needs of the various stakeholders of this project, and keeping them informed in
appropriate ways about the Talks.cam system and the project, was a key part of our work. In our
original project plan, we identified the following groups:
•
•
•
•
•
•
•
•
•
•
Other pilot projects in the call and supporting projects
Creators of Talks.cam
Users of CamTools
Users of social networking systems
Users of Talks.cam
University of Cambridge
CARET
JISC
HE community of VLE and VRE developers
HE community of “hackers” and independent developers
In addition to this, the project helped us realise that “users” of Talks.cam was not a single, well defined
group, but a very varied community with varying degrees of visibility to the Talks.cam operators; this is
described elsewhere in this report. We also received more interest from other Universities around the
UK (see next section), whose webmasters and academics we had mistakenly not initially considered
as stakeholders.
Different perspectives on the project mean that stakeholders may have very different and even
incompatible expectations. Just to illustrate this, and not as an example of an expectation clash, here
are two views of Talks.cam:
Alan Blackwell, one of the creators of Talks.cam, recently described the project:
Talks.cam turns the university inside out, accumulating research across disciplines, publicising and
archiving current research without requiring 'knowledge transfer' intermediaries such as publishers
and research funding offices.
This is clearly an (intentionally) more provocative view than the way we currently describe the system
on its own website:
Talks.cam is the service that enables people to find information about seminars and lectures in
Cambridge. Our web-based service allows all organizations in Cambridge conveniently to publish
their lecture information, and allows anyone to search through the database in a manner suiting their
interests. Talks.cam also serves syndicated `what’s on’ information directly into the webpages of many
organizations in Cambridge, with each syndicated information stream tailored to that organization’s
interests. Talks.cam is intended to be the premiere listings service for intellectually stimulating events
in Cambridge.
The stakeholders have different (and changing) expectations, and the ways in which they expected to
interact with the project team also varied. Balancing their needs and priorities with those of other
stakeholders and the project itself required a great deal of sensitivity, empathy, cultural understanding
and communication skills across the project team. It is worth noting that although deeply technical
staff may not expect to deal with external stakeholders directly, during institutionalisation some
stakeholders retain a strong interest in the technical details, and may expect to be able to learn about
the details or even influence decisions at a very low level.
Page 14 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Extending to other institutions and funding and models
We believe that a centralised list of academic events for an institution is a powerful tool, and this is
clearly not an interest exclusive to Cambridge. We have seen that MIT are running a graduate
student competition to develop an automatic email parsing system which will derive information about
academic seminars from emails, and will populate a central database11. One outcome of this project
has been a substantial number of expressions of interest in getting Talks systems into other academic
organisations. These have ranged from university departments, whole universities, scholarly and
learned societies, and thematic research groups. These were unexpected, and caused some
resource to be diverted from other parts of the project onto investigation and response to these
enquiries.
At a superficial level, these engagements are very appealing. In principle there is nothing to stop other
groups taking the Talks.cam source code, changing the branding for their own, and deploying it to run
their own Talks instances. In practice, things have not proved quite so straightforward. There has
been interest from people and organisations of different kinds. For example, we have met with the
British Neuroscience Association who were interested in extending their use of Talks.cam, where a
number of local neuroscience lists exist, into a national events system. It would be easy to set up a
“talks.neuroscience” within the UK, totally detached from Talks.cam. But to have Cambridge talks
appear within the national list, without entering them twice, would require a degree of advancement in
the software and usage practices. For example, talks.neuroscience could perhaps include the
Cambridge neuroscience lists via a feed, but talk information would need to be entered through the
Talks.cam portal, so that users would have to think where the right place for a new event to be added
would be.
The case of UCL, various departments of which have also expressed an interest in Talks, might be
simpler; they could use a totally standalone system similar to Talks.cam but configured for a new
domain (“talks.ucl”), with new logos etc and their own login or single sign on system. Nonetheless,
challenges remain if those who are interested are simply academics rather than IT providers, as
domain registration, server set up, etc, must all be arranged, and interested academics do not always
have the skills or resources to put such things in place.
Once a Talks system existed in a number of institutions, the thought immediately turns to a
nationalised system. “Talks.ac.uk” could work in one of several ways. It could be a single events
listing system for the UK, with its own account system for user management, and anyone able to
enter events; each event would use the current data model of Talks.cam but with the addition of a
location field, possibly utilising one of the web location systems appearing today, based on postcode,
or city, or “near University of Foo”, or on a click on a map to derive a lat/long reference. Users would
be able to subscribe to events in one or more geographic areas - defining these areas in a userfriendly and useful way could be an interesting challenge! This system would be large, would need
central support of some kind, and would need to be robust and scalable.
An alternative would be to imagine that each University or similar institution could have its own Talks
system, similar to Cambridge’s, with its own account system and so on, and that “Talks.ac.uk” instead
took a role as a centralised gateway, offering the ability to search and subscribe to events on a
national scale. The gateway in this case would consume “all events” feeds from each institution, tag
them with locale information, and present information for users who wanted to browse or search
national events, and potentially to subscribe to events outside their usual home institutions.
Although we have carried out initial investigative work, the creation of such a nationalised system
would require resources beyond the scope of this project. We will continue to seek opportunities to do
this in collaboration with JISC and others.
11
http://mailman.mit.edu/pipermail/gsc-hca-offcampus/2009-February/000197.html
Page 15 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Outputs and Results
Institutionalisation of software
The Talks.cam system has been institutionalised through adoption by CARET, an institutional IT group
(innovation unit). CARET now offers operational running and maintenance of Talks.cam along with
trained helpdesk staff, updated and maintained user documentation, and user training when required.
We have also helped support new institutional users of Talks.cam including departments and
industrial research labs.
Learning around institutionalisation falls into several categories, and is discussed in the following
sections.
Learning around institutionalisation: software versions and language choices
Talks.cam was written in php, and then rewritten in Ruby on Rails before the EGRET project began.
As such, the project team displayed a great deal of maturity and common sense. The language or
platform which may be a suitable choice for prototyping or experimenting is likely to be based on the
familiarity which the developer has, and any rapid prototyping functionality in the platform. This is
exactly as it should be, but it must be understood by the developer that this may not be an appropriate
language for a growing system: production systems may require levels of reliability and scalability that
platforms best for prototyping cannot offer easily (without specialist tuning, for example).
For example, some platforms may be less amenable to scaling up to larger numbers of users - this
points to a potential need to rewrite when moving from a small scale deployment to a large one. In
other cases, as a system is adopted and has a greater need for reliability, it may migrate to a new
hosting organisation (an institutional IT provider, or a departmental computing facility, for example)
where certain platforms are mandated, or alternatively banned for production reasons. If early
developers are excessively attached to one language, or unwilling to contemplate reworking the
system, this is likely to cause problems.
In the EGRET case, CARET had no experience of hosting Ruby on Rails systems, but was able to
train staff and gain the relevant expertise. Nonetheless, it took a certain level of flexibility on our part
to accept such a system, and this may not be the case for conventional larger scale IT organisations
with established and less flexible practices.
Learning around institutionalisation: helpdesk systems and documentation
Helpdesk systems are often one of the things which users will notice changing most as a software
project grows. Initially, when all users know the software author personally, there is no formal
helpdesk, just casual requests for features or bug reports, in email or in person (or other unrecorded
forms). This may set in place poor expectations for the future: users expect quick responses to their
requests, and may also anticipate that their every request is met. This may be the case whilst an
individual user forms a substantial fraction of the user base, and whilst a software creator is
enthusiastic about their development, but it may not continue.
In addition, such informal requests are usually not logged or archived anywhere, and bug reports or
support requests are similarly lost. When the software is handed over to a new support team, there
may be little or no information on what to expect users to ask, how to respond to queries, and so on,
and there may also be users who expect a very different service level to what can then be provided.
This can present challenges to the new helpdesk team, who must be able to troubleshoot technical,
policy, and user issues whilst thinking on their feet about what might be needed. This is unlike the
traditional helpdesk model, where staff can be relatively untrained, with a basic set of responses and
help documents to guide them. The support team for software in its early stages - whether pilot, early
production, or simply experimental, must be able to think for themselves and have a strong
understanding of the technical and policy environment, and whom to call on for escalation or help
when required. At the next stage, the “pilot” stage helpdesk team should work to develop a knowledge
base about the system and its support needs, as the final stages of institutionalisation are more likely
to require a “traditional” helpdesk system and clear documents and policies will be wanted.
Page 16 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
The helpdesk also need to be able to handle a maturing data security environment. Whereas a lone
software developer almost inevitably has access to the database, and will expect to use it to debug
software and solve user problems, as that software matures, database access will become more
privileged and restricted. In the case of fully institutionalised software, it might be the case that senior
system administrators have access to a database, but would not use this without authorisation and
good reason, and even then with a clear understanding of data protection and data security issues.
The stages by which this happens need to be clearly understood by the teams involved - and that
includes helpdesk, as an option which was previously available may not be. For example, a user
might find that a new helpdesk team refuse to “go in to the database and update something” whereas
their previous help contact - the software creator, say - was happy to do this occasionally.
The documentation for a system is closely linked to helpdesk functions. In the case of Talks.cam, the
original documentation took the form of a wiki, which is a great way to create some easily-editable
content, and one to be recommended to early stage projects. It also permits early adopters to add to
or to enhance documentation (if open editing is available, or linked to user logins for the system being
documented in some way). This can lead to problems later, as open wikis can be vulnerable to abuse
if not monitored and moderated.
As user populations grow and change, from early adopters to larger groups of the majority, it may be
necessary to review and change documentation. Early adopters may not refer to basic user
documents much, and they may have familiarity with terminology and systems which are alien to
other users. Some users will be less comfortable with technology and may require the reassurance of
clear documentation which they can review before trying something new out (unlike early adopters,
who may not refer to documentation even when stuck, preferring to experiment). We had to update
our documentation a number of times during EGRET; a mixture of small changes and page rewrites,
and one major restructuring and rewrite in response to user queries. Note that this was on top of any
changes required to keep the documentation in step with new software version releases, which is
another important component of an evolving software project causing new documentation to be
required!
Learning around institutionalisation: licensing and IPR
In our case, there were no IPR issues around the software, as the original creators were happy to
place the code in the public domain under a BSD-style licence. Also, the code was standalone and
had no connections to other software or libraries which might have created a more challenging IPR
environment. However, it is to be expected that this is a potential area of difficulty for other projects. It
is valuable for software creators to think about suitable licensing from early on in their projects, as this
is something which can have long term repercussions. This can be challenging, and having
institutions provide clear guidance to academic and non-academic staff and students as to what the
“default” rights and expectations are in their institutions is a good start.
Learning around institutionalisation: governance and security
Some of the issues in this area have already been touched on in this report. This is a particularly
interesting category, as expectations of what might be reasonable governance and policies around
security are often viewed very differently across an institution, and the types of people one might
expect to encounter at various points as a software project matures and develops may be expected to
represent the entire range of views.
The use of user-generated content also affects the dynamics around privacy and security, as
discussed elsewhere in this report.
This area encompasses challenges such as deciding what bugs or feature requests to address; who
controls the domain; who has access to servers and to user data stored there; who can set up and
administer email lists which refer to the system.
Page 17 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Learning around institutionalisation: user expectations
Users of software at different stages of maturity will expect different things of it. This may be obvious,
but the impact of this on the software and the environment in which it is offered is great and may be
easily overlooked.
Once software seems to be adopted by a department or other organisation, and is no longer the
purview of only one single developer, it is easy for users to assume that unlimited resource is
available for changes and support. Explaining to a user who has a strong wish for a certain feature to
be added, or bug to be removed, that this is not a priority at this time or cannot be achieved within
available resources, is always difficult, and can be demoralising for the user-facing team. Clear and
transparent policy in this area could help, so that users can see that they are being treated similarly to
others.
Learning around institutionalisation: priorities
Selecting what features to add, or bugs to fix, is a difficult process at the best of times, requiring a
project team to balance out the needs of different user groups (which may be expressed via helpdesk
tickets or requests, or may have to be inferred indirectly), technical feasibility, and also the wishes of
whoever is controlling the project - a manager, a steering group, etc. In the case of a system
undergoing institutionalisation, there is an additional dimension of changing priorities over time. As the
number of users grows, and they perhaps become more representative of a majority, and less like
tolerant early adopters, there may be tensions between desires for more advanced user interface
features, and simple improvements to make life simpler for a non-expert user. Balancing such
priorities, and tactfully keeping early stakeholders engaged even when their wishes may have to be
handled after other requests, was a crucial part of the work.
Learning around institutionalisation: hosting & helpdesk
As software projects become widely adopted, they may grow such that one original developer cannot
handle all the development, hosting and operations, and support that may have been possible in the
early days. Part of the rationale for institutionalising Talks.cam was to find a centre which had the
facilities to offer, such as helpdesk staff already employed to support other systems, who could devote
a fraction of their time to a new system easily - this is easier and cheaper than finding a new full or
part time helpdesk person for a single project.
Nonetheless, estimating the effort required to support a service may be challenging. Even late on
during EGRET, we found occasionally that the creators of the system were still doing support tasks,
unbeknownst to us, as people were still contacting them directly, and also they were coming across
issues themselves. Indeed, some of these tasks were not perceived as support - Talks.cam also has
an editorial component, which could be viewed separately - and so they would not mention this work
even when asked.
Learning around institutionalisation: conclusions
Institutionalisation is by necessity a staged process, with software advancing step by step over time and at a variable pace. Every instance of institutionalisation will be different, even within the same
institution, and as such should be handled as an individual case, not as something which can be
generalised. At each stage, there are challenges left over from the transition from the previous
incarnation of the software systems, and also preparations to be made to smooth the next transition.
One key challenge for Talks.cam which will reappear for other systems which are suitable for full
institutional adoption is that it must be possible for software systems to be handed over to new homes
as they grow. This requires two things: the current “owner” to have a willingness to part with a system,
with it in a fit state to be passed on; and the inheritor to have a willingness and ability to accept a new
system, which has been developed elsewhere, according to different principles and methods. This
Page 18 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
requires a great deal of openmindedness and flexibility, and the utility of an agile organisation such as
CARET in assisting this process is clear. Nonetheless, this cannot work in isolation, as other more
established and large scale IT organisations must also be prepared to step up to the challenge for
innovative IT systems to reach their full potential.
Nonetheless, we hope that the learning we have had, and the synthesis of this into guidelines (to be
provided in a fuller form in a separate report) will be of use to others who are steering new software
tools through this process, or to those who need to work with new software projects at any stage of
the process.
Talks.cam usage figures
In June 2009, Talks.cam received 101664 hits per day on average. Bear in mind this does not
represent people, as Talks is also used by automatic systems via RSS and other feeds! In June 2009,
we had an average of 4236 hits per hour, with a maximum of 9686. Our greatest ever monthly hit total
occurred in March 2009 with 4211498 hits.
From more detailed logs, we might infer that almost 100,000 of our hits for June 2009 were people
logging in (over 55,000 hits on one login page, and over 46,000 on the other). However, it is also
worth bearing in mind that many people use Talks.cam without realising it, and certainly without
logging in. They get RSS or iCal feeds, or receive email reminders, or view departmental webpages
where events listings are embedded and skinned to look like the departmental site, but are in fact
hosted by Talks.cam.
Talks.cam usage study: Lent Term 2009
We present here some data for Lent Term 2009 (12th January - 15th March) mostly derived from raw
log data. It would seem that Talks.cam traffic is probably a bit more complicated than an average web
site, so neither Webalizer nor Google Analytics really gives an complete picture. (Webalizer doesn't
know how to distinguish the types of traffic; Analytics is generally known to be conservative, and can't
pick up non-HTML feeds for example).
Raw hits per day: an average of 135,814 - comprised of:
* search engines crawling our site make up 57% of the raw hit count
* images, stylesheets, scripts etc make up 30% of the raw hit count
* this leaves the remaining 13%, which is actual "pages", broken down below:
Actual "pages" per day: an average of 18,471 - comprised of:
* direct use of website: 43% = 7912 hits/day
* non-web formats (see below): 44% = 8115 hits/day
* "embedded" page fragments in other sites: 13% = 2444 hits/day
For comparison, Google Analytics reckons there were only 3945 "pageviews" per day during the
same period, somewhat lower than the 7912 "direct use" figure above; however, Google Analytics is
known to be conservative. The "real" number is probably somewhere in between. Google Analytics
does not track non-web formats nor embedded page fragments.
Talks.cam content was "embedded" (e.g. included on a departmental homepage) in over 40 different
sites this term, for instance:
http://www.cl.cam.ac.uk/seminars/
Note that "syndication" is actually quite a broad term, which not only includes the non-web feeds
(iCalendar, RSS etc) and the embedded page fragments, but also includes simply linking to a page
hosted by Talks.cam with extra parameters to customise the page layout - this last and most simple
method of "syndication" is included in the "direct use of the website" count above, as it's much harder
Page 19 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
to distinguish these hits from just general linking and browsing. Suffice to say that more than half of
the "actual pages" served by the site are some sort of "syndication".
Breakdown of "non-web formats":
* iCalendar12 : 3929 hits/day
* RSS: 2596 hits/day
* XML 13 and other: 1590 hits/day
Google Analytics reckons that 52% of the web traffic comes from Google Search Results - we rank
surprisingly high in Google, perhaps due to Talks.cam being a fairly mature system, well-constructed
for indexing, and coming from a trusted academic domain.
Finally, here are two interesting graphs from Google Analytics:
A few deductions may be made from this study.
Whilst most of our traffic arrives between 9am and 6pm, a significant proportion of the remainder
arrives in the evening. The most common weekly peak is on Mondays - this probably corresponds to
when a weekly reminder email is sent out to users who have chosen to subscribe to particular Talks
and Lists. The least busy days are Saturday followed by Sunday. Usage decreases slightly as the
term goes on.
the "iCalendar" standard is not to be confused with "iCal", the Apple calendar software; iCalendar
is supported by a variety of software, including Apple iCal, Microsoft Outlook (plugin), Mozilla Sunbird,
Google Calendar etc)
12
"XML" denotes a simple custom XML format devised by Talks.cam, which is more detailed than the
RSS feed, but non-standard
13
Page 20 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Talks.cam software
The software for Talks.cam has been shared on a public SVN repository under an appropriate open
source software licence (New BSD14 ). We have offered basic support to a number of external
institutions who have been interested in getting started with Talks at their own institutions.
The Talks.cam system has been substantially updated during the 2008-2009 academic year, with
more robust policies and bug fixes, and also new features and a completely revised documentation
system. New Talks releases are subject to full CARET QA procedures and documentation practices,
to bring them in line with local institutional practices for other innovative IT systems.
Reports
A set of illustrative vignettes, showing the utility of Talks.cam to university staff, has been produced
and is available on the project blog15.
The Talks.cam architecture and features have been documented with a view to integration into other
institutional systems in some form. A paper about this is available on the project blog16.
A briefing note on the implications of systems such as Talks.cam or other events systems when
integrated with social networking within universities, in particular tradeoffs between privacy, security
and convenience, has been produced and is available on the project blog 17.
Outstanding outputs:
A set of framework guidelines detailing processes and practices for institutionalisation of software
systems is outstanding but will be completed shortly.
A full report on the implications of systems such as Talks.cam and social networking within
universities (on privacy and convenience tradeoffs) is outstanding; however, given the scope of
development work during the project it seems more appropriate that this report is undertaken in light
of the greater user experience data which is being uncovered by the JISC Academic Networks
project. As such, it is replaced with a short briefing note as above, which more reasonably reflects the
understanding developed in the EGRET project.
Outcomes
Talks.cam has been completely and successfully integrated into the institutional IT fabric of the
university. The usage of Talks.cam has grown and flourished during the EGRET project and has been
helped by software improvements, documentation improvements, and also clear helpdesk assistance,
all funded by the EGRET project. Talks.cam is now a reliable and well-understood system in operation
in a university department dedicated to innovation in technology support of learning and research; as
such it is in a strong position to be fully sustainable either in its current form or through a further stage
of institutionalisation.
14
For an example, see http://source.caret.cam.ac.uk/talks.cam/tags/20090408/LICENSE
15
http://www.caret.cam.ac.uk/wp-content/uploads/2008/12/egret-vignettes.pdf
16
http://egret-project.blogspot.com
17
http://www.caret.cam.ac.uk/wp-content/uploads/2008/12/socnetissues-1.pdf
Page 21 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
The code and documentation for Talks.cam is now available fully open source for those who wish to
use it in other institutions, and indeed through the EGRET project we have received many
expressions of interest in this and a number of code downloads. The enhancements made to the
system, particularly including documentation, will substantially assist others who wish to try the code
out or deploy it in their institutions. We are also continuing to seek further sustainable models to
extend the usage of Talks.cam including potential expansion to a national, federated system (possibly
“talks.ac.uk”); this work will continue past the end of the EGRET project as part of CARET’s
contribution to the institutionalisation and long term support of Talks.cam.
The EGRET project has enhanced the understanding of the benefits and challenges of usergenerated content and social networking features within academia, which will greatly assist projects in
these areas, both those already underway at the University of Cambridge (eg JISC Academic
Networking, JISC Modular e-Administration of Teaching) and those in other UK HEIs into the future.
The EGRET project has enabled us to investigate in detail the issues surrounding institutionalisation
of software projects. This knowledge and the framework we are producing will support projects of all
sizes in the University of Cambridge and in other UK HEIs where similar issues may arise. This work
will allow more novel and useful software projects to be developed in ways which support eventual
institutionalisation, permitting universities to benefit from their own innovations (as well as the more
normal models of university innovations being channelled into spinout companies!).
The framework will benefit users in several ways. Firstly, users will be empowered to make better
decisions as to what non-institutionalised software tools to choose to use; this will reduce the risk that
a much-loved tool may “disappear” (through, say, the author leaving the university), potentially taking
valuable data with it. It will also push software and systems which users find useful and helpful into a
path where they can be gradually institutionalised, bringing their utility to yet more people.
It is worth noting that a well understood institutionalisation process does not guarantee success of
projects. The gating system within it means that although some projects will successfully meet the
criteria and move “onwards and upwards”, other software tools will fail to move through the gates.
This does not mean that these tools are lost; merely that they will remain for the time being in a less
supported state, potentially with a set of happy users. It is important to see that this is part of a
healthy evaluation of tools; not all software, even if much-loved within a niche, will be suitable or
appropriate for full institutionalisation, perhaps due to a particularly niche application area, a user
interface targeted to a particular group, or an architecture which would not scale to support many
thousands of users. Software tools proposed for institutionalisation will always include a range of
those which, with work, may make it; those which may look suitable but which settle at a lower stage
of growth; and those which although their authors are passionate about them, may never achieve the
requirements needed. A robust process framework is a key part of ensuring that universities are
supporting the best applications only, and not wasting resources on those of limited utility, high
running cost, and so on.
The framework will reduce risk and increase efficiency of software innovation within universities,
focussing attention and effort where it is deserved, and helping the best projects reach success.
Conclusions
EGRET explored the topic of institutionalisation with reference to the Talks.cam system, and during
the project Talks.cam was fully absorbed by CARET, an institutional IT provider.
Greater
understanding of the issues surrounding institutionalisation has resulted, along with increased utility
and use of Talks.cam itself. One unanticipated consequence of the project has been interest in
Talks.cam from universities and learned associations outside Cambridge, who would like similar
systems for their own requirements.
Page 22 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Implications
Connecting administrative systems
The EGRET project was perhaps somewhat ahead of its time, in that it anticipated social support in
the VLE/VRE somewhat before that was ready. However, projects looking at how university
administrative systems could benefit from a more person-centric view of the world, particularly
through the use of social networking principles (such as using personal information of various kinds to
connect together different systems, or using common interfaces such as OpenSocial to link them)
continue within our university and will undoubtedly arise in others. We believe there are benefits to be
had through this kind of approach and although the privacy and authorisation controls which may be
required for some administrative systems are not trivial to get right, it is likely to be worth the effort of
experimentation and piloting to fulfil the potential of this kind of interconnect.
For the CARET team at the University of Cambridge, this idea will be taken forward with at least the
JISC Academic Networks project, which has followed best practice in commercial user research and
user centric design to investigate user needs for social communication to support teaching and
learning. This will primarily be implemented within CamTools, our institutional VLE/VRE, offering a first
social system for the University, and is likely to extend to other social interfaces in the administrative
computing space in the future.
User-generated content (UGC)
The success of Talks.cam stems from its rapid uptake and ongoing high usage figures within and
without the University. To a great extent this is due to the simplicity of getting started with Talks.cam,
whether as a talks attendee or a seminar series organiser - anyone can do this, there are no tedious
authorisation checks, etc. This is assisted by strong user-friendly interface design, focussed on
supporting basic tasks being completed quickly.
For a seminar attendee, though, or someone who is browsing the site to figure out whether it might be
of use, the appeal of Talks.cam is the richness and completeness of the information on the site. The
ability of anyone, even a lowly research student organising a simple group seminar, to enter their
event on the site, means that Talks very rapidly became a useful and detailed and full resource. The
UGC nature of Talks.cam was a strong motivator of this and this kind of benefit should be a positive
driver for rapid uptake of other projects which have UGC.
Nonetheless, UGC is not without its challenges and projects which intend to produce UGC systems
need to be aware of the complex issues which could arise, and the governance/control systems
which, whilst being flexible to adapt to new situations as they occur, need to be sufficiently well
defined to provide a forum for discussion and decision making in this regard.
The EGRET project has fostered interest in UGC around the University of Cambridge, showing that it
can work and bring great benefits. New projects have appeared within the institution which support
university staff and students in creating UGC which in some cases is then showcased at a high level
and visible externally.
Institutionalisation
The institutionalisation of Talks.cam highlighted a number of areas where thought needs to be given in
advance if at all possible. The guidelines framework we propose will help other projects go through
similar processes, but even with this, projects need to be aware of potential pitfalls if they wish to
pursue a path to full university official adoption.
Nonetheless, the EGRET project demonstrates that it is possible to take a project from small roots to
a substantial, heavily used system which is close to a fully institutional system. This shows that this
new model of software development within higher education has the potential to deliver genuinely
useful and powerful applications, getting functionality to users more quickly than via conventional IT
Page 23 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
systems development, and also meeting more specific needs which might not fall within the purview
of common IT provider organisation or university IT decision-makers.
Although software projects which start small are correct to focus on small pilots, on getting a
functional system built quickly rather than meeting every small concern that might be desired for long
term sustainability, forward planning is very useful to avoid difficulties later. For example, within
EGRET we have observed a great many helpdesk issues arising from the separate login systems (of
university single sign on, and Talks.cam specific logins). The latter login is the original, and is powerful
and useful enabling those not connected to the University to use Talks.cam and therefore extending
our reach into local industry, funding bodies, local people, potential students and more - a very
powerful and compelling demonstration of widening participation and connecting with other
organisations. However, the combination of both systems was not cleanly constructed and there is no
migration system for users who mistakenly end up with two or more accounts. More thought put into
this at an earlier stage would have made things much easier later on.
It is worth noting that although the institutionalisation process which we suggest for future projects of
this type attempts to address many of the issues we came across during the EGRET project, it is
inevitable that other issues will exist and that flexibility during this process will be essential for
success. Even with extensive planning at all stages of the development and “gating” of a new
software system, things will come up later which are unanticipated and which will require careful
handling and flexibility when working out how to deal with them.
A unit such as CARET, which does not have to fit within the standard teaching and research practices
of an academic department, and which also is not constrained by the conventional practices and
customs of administrative organisations within an institution, but which can instead operate in a truly
innovative fashion, with creativity and flexibility, might have a great deal to offer during the
institutionalisation process.
Talks.cam into the future
As the project has received a variety of expressions of interest, and is being promoted on an on-going
basis by CARET and the original creators of talks.cam, it is likely that Talks will appear in some new
formats in the future.
Firstly, the use of events systems (in terms of recommenders, calendar/scheduling, seeing what
events colleagues are attending, publicising events) in scholarly networking systems will be taken
forward by CARET and built into future iterations of Sakai 18 as part of Sakai3 19.
Secondly, Talks.cam itself will continue to operate in the University of Cambridge as the institutional
academic events listing and syndication service, either as a standalone system, or integrated into
other systems, or both.
Thirdly, we will endeavour to identify models to support Talks systems at other institutions and/or a
national Talks infrastructure, contingent on identifying resources and a suitable model for this.
References
Talks.cam service
http://www.talks.cam.ac.uk
18
http://www.sakaiproject.org
19
http://www.sakaiproject.org/portal/site/sakai-home/page/89473b2c-31dd-4261-9823-c31a79e55532
Page 24 of 25
Project Acronym: JISC EGRET
Version: 1
Contact: Laura James, [email protected]
Date: 20 August 2009
Talks.cam source code repository
http://source.caret.cam.ac.uk/talks.cam/
Talks.cam documentation
http://talks.cam.ac.uk/document/documentation
Page 25 of 25