Author Archives: Rowan Wilson

Lessons Learned

  • Technical issues with the APIs upon which the project relied caused some delays, but it would have been impractical to have done a complete functionality audit during the bidding phase. In retrospect we would have benefited from structuring the development work in such a way as to build in contingency for this kind of problem solving, and also included a work package that could be achieved if the contingency development time went unused.
  • As a result of the open development approach that we took, we tasked ourselves with implementing interface usability requirements at the same time as implementing code that was simple for developers to reuse in other development projects. This brought to the fore the oft-cited (for example here: observation that open source development practices do not often deal gracefully with usability concerns. In the case of this project’s outputs we feel that we managed to address both usability and reusability within an open development environment. The project team intends to look more closely in the future at how best to generalise the lessons learned to help reconcile general open development methodologies with diligent usability design and implementation more easily.
  • We had greater success in engaging interest in a more general software community space (Apache Wookie) than we did in engaging interest in the smaller academic communities that were the focus of the bid. It may be worth exploring the idea that software development to benefit the UK HE/FE community or a subset of that community might nevertheless benefit from being initially pitched into the widest applicable global project. From there, it may be easier to gain external developer support, achieve sustainability and thereby gain the time needed to properly engage the narrower academic community’s requirements.

PDF of edited blogs posts

Measures of success

In our project proposal, we set forth three criteria for judging success of the project: i) acceptance by users, ii) uptake by three specific communities and iii) acceptance into upstream projects.

i) Acceptance by users during our three user evaluation activities

We planned three face-to-face user evaluations, but for time and organizational reasons were able to hold only two. We received a great deal of positive feedback and useful advice in both events. The specifics and outcomes are recorded on the project’s Google Code web site and are linked to from the Usability Evaluation Plan here:

While most of the feedback was positive, outstanding usability issues were raised and these were recorded formally within the issue tracking systems associated with the software, both in the Rave in Context project site and in the Apache Wookie site. We feel that this method of finishing a relatively short project by recording and transitioning outstanding suggestions and requests greatly facilitates the ongoing life of the code, and indeed some of these issues have been resolved since the formal completion of the project.

ii) Uptake of our widgets by users of myExperiment, Simal and openDOAR

Although we have made contact with the communities associated with the projects whose functionalities we were seeking to generalise in producing the Rave in Context templates, the templates themselves have yet to receive significant uptake by any of those communities. To some extent our work has influenced work that was already taking place within MyExperiment to refine the user interface with particular reference to mobile access. Although we were unable to initiate extensive contact with OpenDOAR during the life of the project, we will continue to keep them informed of the ongoing development of our code. In the case of Simal, technical issues meant that in order to test the widgets functionality in a timely fashion we had to integrate them instead with the JISC’s project management registry PIMS. The fact that this was successful indicates that use of our widgets within Simal is entirely possible, because Simal similar to PIMS in that it records and displays data about software projects. We are keen to pursue this further in the future.

To some extent these issues can be attributed to the fact that it is still ‘early days’ and therefore too soon to assess the impact of Rave in Context. The ongoing support of our code within the Apache Wookie project should ensure that the code is available for those communities, and for reuse in other research-driven web sites, going forward.

iii) Acceptance of our templates and recommendations into upstream projects

Here we have achieved more uptake in a shorter time than we expected. The widgets have been enjoyed further refinement and expansion by the Apache Wookie development team. Indeed, they will be used in an ongoing project to replace the administrative interface to Wookie itself. The aim of this project is to standardise the interface across Wookie and another widget server project, in an interesting reflection of the aims of our project. They have also been adapted to create a widget for accessing Twitter, and will shortly be adapted to provide access to Facebook. The widgets are also to be used as a basis for the onward development of the MAAVIS (Managed Access to Audio Visual and Information Services) software developed at the University of Sheffield. Finally the Wookie team has also enhanced the templates to produce widgets that have no dependency on Wookie itself, thus making the templates useful in a broader range of use cases, such as being served from other widget servers and compiled into native mobile applications using development toolkits such as Phonegap.

Project Recap

The Rave In Context project has created W3C widgets and widget templates that provide a user interface to common functions of the MyExperiment, Simal and OpenDOAR web sites. We concentrated on usability and reusability, both in two distinct senses: the interfaces themselves needed to be simple and effective for users to make use of across a range of client devices, and the code which presented the interfaces needed to be simple to use and reuse for downstream developers.

By providing useful templates for common interfaces across devices, we hoped to contribute to reducing the learning overhead required to access complex functionality on research-focused sites. As well as reducing the overhead of learning many different interfaces, providing templates can also facilitate the building of unified means of access to multiple research-focused sites. Finally, by providing templates that encompass best practice in usability it will be much easier for template users to provide this best practice in their own widgets.

We adopted an open development methodology to achieve this, starting a project on Google Code and placing the code and our reports there as the project proceeded. By doing this we hoped to make what we were doing as transparent to observers as possible. We also believed that the process of interacting via open development methodologies would ease another important aspect of completing the project: the transitioning of both the code and its development status and history into a live third party open source project at completion.

As with any project, there were some unanticipated departures from our original plan. Staff changes within OUCS meant that management of the project moved from Sander van der Waal to Rowan Wilson, with a concomitant overhead in transferring knowledge and planning. In addition some staff timetabling issues meant that work on the usability strand of the project began later than was originally envisaged. As we proceeded, we also experienced what would probably be best characterised as cultural difference between the practices of the usability community and the software development community. This again highlighted the distinction drawn above between the use that users make of code and the use that developers make of code.

Finally we encountered problems with the uniformity and functionality of the APIs which we sought to connect across the projects. It would have been difficult to have predicted these at bid stage without an impractical time investment to fully test the implementations of the APIs’ feature sets. As a result we had to simulate some aspects of the operation of the widgets during usability testing.

Despite this, all the templates were developed, tested and completed on time, and all the reports were produced, including two user experience reports for the Usability UK website. Engagement with the communities around the various academic projects in the JISC Usability and Learnability programme was less active than we had hoped, although we acknowledge valuable input into accessibility considerations provided by EA Draffan of the ALUIAR project. This low level of engagement with the programme was to some extent mitigated by the much greater than expected uptake and use of the templates in the software project (Apache Wookie) to which we contributed. This in turn means, we hope, that the templates will continue to improve and that they will remain up to date and available for use both within the academic community and without. Indeed, ten template-related issues have been worked on within the Apache Wookie project since Jan 1st 2012 – by developers other than team members from this project:

Rave in Context Project Plan

Aims and Objectives

The Rave in Context project will build a new user interface for the popular eScience tool myExperiment. Our new interface will focus on usability, accessibility and adaptability to user experience and device form factor. Furthermore, we will build a uniform search feature across myExperiment, Simal and OpenDOAR repositories in order to make it easier for researchers to learn how to use these research tools together. All user interface components will be delivered as reusable W3C Widgets, allowing features of myExperiment to be embedded in other widget enabled tools such as Drupal, WordPress, Elgg and Moodle. We expect the ability to embed discrete units of myExperiment functionality in common dissemination tools will help myExperiment expand its user community. Finally, by providing open source widget templates for progressively enhanced user interfaces we intend to make it easier for future projects to build similar user interfaces.
The overall objectives of the project are to:

  1. Build new progressively enhanced , usable, accessible, learnable and adaptable user interfaces for myExperiment, an e-Science tool for building communities to find, use and share scientific workflows and other research objects.
  2. Demonstrate how, by adopting a W3C Widget-based user interface, features of myExperiment can be embedded within other tools, and features of other tools can be embedded within this new interface to present a consistent user experience (UX).

The areas of functionality within myExperiment for which we are building and evaluating widgets are:

  • Account creation
  • Finding workflows
  • Sharing workflows
  • Creating and finding packs
  • Finding people and making friends
  • Creating, joining and monitoring groups

To demonstrate progressive enhancement, we are developing the widgets to run on two broad, overlapping classes of platform: smartphones and tablets.

Success criteria

The success criteria defined in the project proposal are:

a) Acceptance by users during the user evaluation activities conducted within the remit of the JISC-funded Rave in Context project. This is considered an initial approval of the user interface approach implemented in the widgets;

b) Uptake of the widgets by users of myExperiment, Simal and openDOAR. Since each widget will be operational independently of all other widgets, the developers hope to see users embedding appropriate widgets in their chosen dissemination tools, such as blogs;

c) Acceptance of the templates and recommendations into subsequent open-source projects. This will indicate approval from a broad community seeking to reuse the work of the Rave in Context project.

Criteria b) and c) are primarily technology-driven; however, for the widgets to be taken up by projects they need to be demonstrably usable by their target audience – researchers who share their workflows and maintain a professional social network within a virtual research environment (VRE) – as well as usable (in terms of quality and readability of code) by the OS development community. The usability evaluation that will be conducted with by the project’s usability specialist, therefore, is almost wholly focused on criterion a).

It is important to emphasise that we are not developing mobile versions of myExperiment itself: this has been done to some extent by the development team (e.g. an Android app and a Silverlight mashup). Rather, we are using certain functions within myExperiment as the basis for developing templates for widgets in specific areas of functionality that can then be customised and applied to other, similar, applications.

Equally, we are not seeking to redesign the desktop browser version of myExperiment; instead, we have used it as the baseline for deciding on the cut-down features and functionality that will be supported on the mobile devices through the technique of progressive enhancement.

Even though the developers of myExperiment report that they have designed the UX in close conjunction with users, and have subjected it to usability evaluations, a brief review of the application from the perspective of good usability practice leaves much to be desired, and it is questionable whether less IT-minded researchers outside the core community of scientists would find it particularly learnable or usable. Therefore, although consistency of look and feel across platforms is a desideratum of usability, in developing and evaluating the widgets consistency with the current interface is secondary to overall usability.

However, we have to be mindful of the desktop browser version as a ‘concept’: e.g. it is good usability practice to refer the user to the full desktop version if they wish to avail themselves of functionality that is not available in the mobile web version, even though, for reasons just explained, we will not actually do so.

For more details please see the project’s Google Code site.

Project Team

Liz Masterman has an MSc in Human-Centred Computer Systems from the University of Sussex and a PhD in Educational Technology from the University of Birmingham. She is currently a senior researcher in the Learning Technologies Group. Liz has 14 years’ experience in conducting usability and pedagogic evaluations of software for learning and teaching, and since 2004 has participated in a number of JISC projects in the Design for Learning and Learner Experiences of E-learning programmes. Liz will lead the usability work, conducting the initial review of literature and current practice, running the evaluation workshops and assisting with the design of usable and learnable user interfaces.

Steve Lee has both a passion for and experience of, combining open development and accessibility in order to bring the benefits of innovation and user engagement to those with specific accessibility needs. He is actively involved in several key accessibility communities, including Mozilla, GNOME, OATSoft and Project:Possibility, and has developed wide experience with many contacts in the field. He will address the accessibility aspects of our designs, evaluating each design and assisting in the continual improvement process. Steve will also liaise with TECHDIS and the REALISE project community.

Ross Gardler is senior consultant at OpenDirective. Ross was previously manager of OSS Watch and is Vice President of Community Development at The Apache Software Foundation. He is a committer on many open source projects, including Simal, Apache Wookie and Rave projects used here, and is listed in the top 0.5% of the world’s open source contributors at Ohloh ( Ross, will be responsible for the design and implementation of all the widgets and templates and will liaise with the upstream projects to ensure our code is maintained in the long term.

Rowan Wilson has been involved in web development using a variety of CGI languages since 1996. He was the co-creator of the earliest fully automatic domain-name ordering, DNS setup and virtual-server allocation software deployed by a UK ISP (FDD), using a combination of Apache-SSL, Sendmail, Perl and Bind. Since then he has developed web-based internal product management systems for the ISP Netscalibur, again using open source software (Postgres, Perl, Apache). He now works within the Research Technologies Service of Oxford University Computing Services.

Timeline and Work Packages

For details of the timeline and associated work packages please see the project’s Google Code site.

Risk Analysis

Risk P S P x S Action to prevent/manage risk
Lack of stakeholder engagement 2 5 10 Careful design of workshops with invited participants to cover a range of people and needs.
Widget template code refused by upstream projects 2 5 10 Ross Gardler is a committer on each of the upstream projects and will champion all code contributions. If donations are rejected, a new project will be created at where we will document the reasons for rejection and encourage contributions to resolve these issues.
Widget implementations not accepted by host projects 3 2 6 The Outercurve Foundation Research Accelerator would make an ideal alternative home. Should they also reject our code, we will create a project on and release the code under the open source Apache Licence v2.
Technical problems with projects not under our control 2 3 6 Project members are committers on most of the projects involved in this project and are therefore familiar with the limitations of each platform. In the event of unexpected difficulties we will reduce the scope of our final code deliveries and focus on the usability and accessibility aspects of the project, delivering robust templates and recommendations.