Orbital notes, 24 May 2012

The Orbital project team met today (24 May 2012) and agreed the following:

  • Documentation
  • User documentation will focus on the “why”s of Research Data Management, rather than being a point-and-click guide to the Orbital UI (which should not require detailed explanations).
  • JW will create a changelog (human readable text file) for each major release of Orbital, so that documentation for each feature is review if that feature is updated.
  • PS will lead on writing documentation (as HTML pages, stored in the GitHub repository), with documentation for release v0.N completed and available by the launch of v0.N+1
  • PS will email colleagues from the Library and Research/Enterprise for assistance on writing documentation.
  • Training
  • JW will invite Melanie Bullock and David Sheppard on to the Orbital working group. He is meeting Annalisa Jones to discuss RDM training for staff.
  • Releases/development
  • Orbital v0.1.1 (including bug fixes) met all of the initial ‘minimum viable product‘ requirements specified by Dr Tom Duckett, and also includes the basics of project administration.
  • v0.2 will include improvements to the file upload/management, project management, and license management interfaces, as well as clearer distinction between language files and operating code.
  • NJ demoed the current version of Orbital to Siemens staff. He now has access to Siemens machine data for testing within Orbital.
  • The group discussed the LNCD plans for internal servers/private cloud, and about the disk space requirements and costs.
  • Integration
  • The current version of the DMPOnline tool has been installed on a test server. The group discussed our approach to integration between external tools/software (such as DMPOnline, R, Gephi) and Orbital.
  • NJ is going to email Adrian Richardson at the DCC to ask when the DMPOnline APIs will become available.
  • RDM policy
  • JW presented the draft policy to the University RIEC committee. The committee have been asked to send comments to Joss. (One comment at the committee meeting was that our having a policy too geared around the requirements of the Research Councils may not be appropriate for Lincoln, which generates a lot of non-RC income. However it was noted that the good practice specified by the RCs is good practice for management of all research data, whatever the funding source.)
  • Conferences and meetings
  • The group discussed the recent DAF survey which we conducted at the University of Lincoln.
  • JW will convene a sub-group to consider the responses in detail, and plan follow-up interviews.
  • Business case
  • JW is currently gathering costs for long-term data storage. This will form the first strand of the Orbital business case, which will be presented to University SMT (along with the agreed RDM policy) in September 2012.

A Minimum Viable Product for Research Data Management?

I’m at a meeting at the University of the West of England, focussing on RDM for post-92 universities. I briefly presented the Orbital project, focussing specifically on how we approached the first release of the Orbital software and how software development, and the learning that takes place in that process, is one way to learn about and understand the RDM domain. I am in no way advocating a technologically determined approach – far from it, as this is very much a user driven development project, as is evidenced in the use case I outline.

User testing with Orbital v0.1

Orbital v0.1 was released on 16 May 2012. Every two weeks, staff working on Orbital meet with Dr Bingo Wing-Kuen Ling and Dr Chunmei Qing to discuss their research and RDM practice. Until now these meetings have been all about requirements-gathering – today was the first opportunity for some real, hands-on user testing with the alpha release of Orbital.

The notes below have been turned into tasks on the Orbital project Pivotal Tracker site.

BL = Bingo Wing-Kuen Ling.

  1. BL successfully viewed Orbital v0.1 in Internet Explorer 7 on the UoL corporate desktop and was able to sign in and grant access to the application using his UoL credentials. BL was able to create and describe a new project.
  2. BL tried to upload a file from his desktop to Orbital using IE7 and received an error (this is a known bug with Orbital in Internet Explorer). He was then unable to delete this file.
  3. Switching to Firefox, BL uploaded multiple files from his desktop to his project in Orbital (it wasn’t clear from the page that this was possible). This completed successfully: but because the files sizes were small, he did not receive any feedback on his upload.
  4. Returning to the original file upload screen, BL had to manually refresh the page to view the changes made (files uploaded). Files scheduled for processing are marked as ‘queued’ however this status does not update automatically without refreshing.
  5. Joss Winn demonstrated the file and project metadata pages, citable URLs for files, and Google Analytics on projects. The display of file metadata needs to be more complete, and G.A. needs a better explanation and links to sources of help.
  6. The group discussed BL’s requirements around project calendars/timelines. BL wants to be able to view project events (meetings, deadlines, etc.) for each project (but not aggregated) and is not particularly concerned about notifications on activity/changes to files. The group discussed this and will explore ways of presenting timelines made up of three sorts of events (project events, activity stream, and comments) with each type of event suppressible in the timeline. A timeline overview will be displayed on the Orbital ‘front page’ once a user has logged in.
  7. BL also would like to be able to organise project and data files in all Orbital workspaces using folders/tags, and to allow bundled file download by organising files into collections.

You can read about Orbital v0.1 in this blog post, and about the roadmap for development and release of future versions, here.

Keeping Research Data Safe and the benefits of Orbital

Note of apology: early in December 2011 we attended the launch event of the JISC Managing Research Data programme at the National College for School Leadership in Nottingham. I managed to blog day 1 of the event there and then. Unfortunately my notes on day 2 fell into an abyss. Here they are: late, but unscathed.

Aspire!

The first exercise (on this second day of the programme launch event) was to examine the benefits and metrics checklists provided by the KRDS frameworks project, and to identify the benefits that Orbital will provide & that we can measure. Then to blog a first statement of the benefits we expect Orbital will generate.

KRDS = Keeping Research Data Safe

Notes from Neil Beagrie‘s presentation on the benefits analysis toolkit (which I have already blogged about at the RDMF7 event, but noted here in more detail.)

  • There are two strands to the KRDS toolkit. These tools can be combined for maximum effect (and to reduce wasted effort); tools can also be customised to specific project needs:
    1. The KRDS Benefits Framework (guide + worksheet)
    2. The KRDS/I2S2 value chain and benefit impact tool (guide + impact statement + impact analysis worksheet)
  • Designed for use by wide audience over the full RDM project lifecycle.
  • Conisider the KRDS Benefits Framework ‘triangle’
    • What is outcome? direct/indirect
    • When is it received? near-term/long-term
    • Who benefits? internal/external
  • Tips: quantitative benefits must be measurable (“cashable“) – if not within the project lifecycle then longer-term benchmarking… qualitative benefits could take the form of case studies (working in a team can help to tone down the subjectivity of benefit assessments. Don’t go it alone!)
  • More information at: http://beagrie.com/krds-i2s2.php
  • Previous RMD programme produced benefits report & case studies which can be useful reference points.

Practical workshop

The KRDS benefits and metrics handouts provided here were extremely useful in developing this first statement of benefits for the Orbital project.

Points from the round-table discussion:

  • Checklist v useful brainstorming exercise – not a to do list!
  • Want to do everything and world peace too
  • But how make relevant to project? Target useful examples of top-level things
  • How evidence?
  • Lack of evidence/measurement not a reason not to do it – think of a way of measuring!”
  • Don’t rely on q’aires 🙂
  • Think of benefits from the programme as a whole into which orbital can feed in
  • Practical time & efficiency savings for researcher – i.e. not having to go to london with a USB in pocket
  • Similarities engineering with other applied – e.g. NHS
  • Case studies/user story – iterative method  – as user requirements change (become more mature) – that’s a way of measuring benefit!
  • Set actions for the steering group / RIEC

Benefits of Orbital

This is the list of benefits we came up with. Bear in mind, some of them are benefits specific to an MRD project, such as Orbital, but some of benefits of any large project where the institution has a vested interest. Note that some of these can also be found in the ‘Anticipated Outputs and Outcomes’ section of our Project Plan. As Joss mentions in the post on awareness of open source, not all benefits can be anticipated and there may be outcomes of the project, which are quite tangential to the original objectives. We especially look forward to those!

  • Very mention of Orbital attracting expressions of interest from research staff applying for funding. Researchers have to consider RDM when writing bids. We’re doing their work for them!
  • Knock on effect on other university services: authentication, repository, staff profiles, cloud computing, software development environment and methodology, open source awareness and guidance.
  • Supports the development of RDM plans and policies.
  • MRD programme activity is akin to staff training and development of a community of practice.
  • Combines and improves our understanding about research administration, research methods, research data and research outputs.
  • Changes to researcher practices. Improves RDM practices.
  • Should reduce institutional risk (legal liabilities of commercial contracts)
  • Simplifies collaboration among researchers
  • Produces open source software for re-use
  • Provides rapid access to results and derived data
  • Increases awareness of support among researchers. e.g. Aids grant writing.
  • Produces reliable citations of research data
  • Embeds institutional support and training
  • No recreation of existing data. Better security, greater efficiency.
  • Improved version control and transparency.
  • Improved understanding of research methods.
  • Further thinking about and planning for the sustainability of institution-wide services. Who pays?