Showing posts with label userCase. Show all posts
Showing posts with label userCase. Show all posts

Tuesday, 1 December 2009

Sustaining Shuffl: the view ahead

Sustainability and related matters

This posting constitutes my reflections at the end of the Shuffl JISCRI project about matters relating to open source sustainability and near-term future development plans.

Sustainability plan updated

The sustainability plan at http://code.google.com/p/shuffl/wiki/OpenSourceSustainabilityPlan has been updated to reflect my views on the sustainability issues having reached the end of the project. This is not a fully-fledged, long-term sustainability plan, but I think it does indicate a direction of travel, and I feel this covers as much detail as is meaningful at this stage.

Due to funding of the ADMIRAL project (http://imageweb.zoo.ox.ac.uk/wiki/index.php/ADMIRAL), a level of continuing Shuffl development is expected to continue until 2011, during which time we intend to flesh out some of the functionality and focus more on the original goals of data curation.

CLA adopted

An Individual Contributor Licence Agreement, based on one approved by Oxford University for the Simal project, has been adopted for Shuffl: http://code.google.com/p/shuffl/wiki/Individual_Contributor_License_Agreement.

At some stage, we may wish to consider reviewing this if responsibility for actually publishing the software is transferred to an organization or person other than University of Oxford.

Changing requirements

During the course of this Rapid Innovation project, the requirements focus has shifted from data acquisition and curation to data visualization, in response to comments from a potential research user. This has seemed the right thing to do for a number of reasons, mainly to do with maximizing the potential for early user engagement, but it has meant that some of the original headline goals have been sidelined.

I have also not yet made direct contact with other research users, to gather their (possibly different) view of requirements. Jun Zhao and I have arranged to visit Helen White-Cooper in the very near future to resume our discussions with her about data habdling requirements and tools, at which time I plan to demonstrate Shuffl, and discuss with her the possibilities for an image annotation version, and other possible applications.

In its current state, Shuffl does appear to be a solid base for development of new functionality, with many (though not all) of the fundamental architectural features having been tested and stabilized.

Active deployment and ADMIRAL environment

As noted above, it is our intention that development the data curation aspects of Shuffl will be intensified for the ADMIRAL project, as a number of the work packages have been based on developments of Shuffl.

To this end, we will continue to work with Chris Holland, as well as other researchers, to create a deployed system including Shuffl that they will use on a day-to-day basis.

For ADMIRAL, we have the advantage that we will be creating an infrastructure service that can be enhanced with features we can use to overcome some of the usability limitations of the current browser-only version of Shuffl. For example, we will be able to provide an HTTP request proxy service so that data can be read from and written to servers other than the one from which the Shuffl application has been loaded. We can also tailor the storage services to better support file browsing for locating data files and Shuffl workspaces. We can also look to host useful data visualization and handling services,

Not YAAS (Yet Another Application Server)?

It has been noted on the Shuffl discussion list that some of the data visualization work, and the porting of a FlyWeb widget, might be seen as creating just another application server running in the browser. Such a direction could leave behind some more distinctive aspects of the original Shuffl concept, and end up reinventing facilities that are provided by other developments such as W3C widgets served by a Wookie widget server. Scott Wilson implemented an early proof-of-concept of a Wookie widget running in a Shuffl card, an idea that has so far not been followed through. One reason for this was a reluctance to get involved in implememting specialized server-side support as part of the original Shuffl project.

With the ADMIRAL project, we can review the option of using a Wookie server as part of the data sharing infrastructure to serve up standard data visualization widgets, rather than re-implementing them as Shuffl cards. We would need to understand enough about the Wookie API to hook it into the model API used by Shuffl to link information across cards. In this way, we may be able to reap the advantages of data visualization for user engagement without having to put effort into implementing them.

Thursday, 1 October 2009

Shuffl data visualization use-case updated

I now have permission to publicly post my full notes from a meeting with Chris Holland, a researcher for whom I am targetting an application of Shuffl (and one of the supporters of our bid). Notes of our meeting are here:

Monday, 27 July 2009

Can Pen and Paper Help Make Electronic Medical Records Better?

I spotted this item in ACM TechNews. I thought it interesting because it resonates quite strongly with some of the ideas that led to the formulation of Shuffl.


Can Pen and Paper Help Make Electronic Medical Records Better?

IUPUI News Center (07/20/09) Aisen, Cindy Fox Using pen and paper occasionally can make electronic medical records even more useful to healthcare providers and patients, concludes a new study published in the International Journal of Medical Informatics. The study, "Exploring the Persistence of Paper with the Electronic Health Record," was led by Jason Saleem, a professor in the Purdue School of Engineering and Technology at Indiana University-Purdue University Indianapolis. "Not all uses of paper are bad and some may give us ideas on how to improve the interface between the healthcare provider and the electronic record," Saleem says. In the study of 20 healthcare workers, the researchers found 125 instances of paper use, which were divided into 11 categories. The most common reasons for using paper workarounds were efficiency and ease of use, followed by paper's capabilities as a memory aid and its ability to alert others to new or important information. For example, a good use of paper was the issuing of pink index cards to newly arrived patients at a clinic who had high blood pressure. The information was entered into patients' electronic medical records, but the pink cards allowed physicians to quickly identify a patient's blood pressure status. Noting that electronic systems can alert clinicians reliably and consistently, the study recommends that designers of these systems consider reducing the overall number of alerts so healthcare workers do not ignore them due to information overload.