Scientific Software & User- Centered Design. Cmpt 479 Jessie Helfrich December 3, 2015

Transcription

1 Scientific Software & User- Centered Design Cmpt 479 Jessie Helfrich December 3, 2015

2 Context Experience: - Software developer at the Canadian Light Source. Problem: - Synchrotron facilities use software for beamline control and data acquisition. - Huge variability in the usability of existing software. Goals: - Research why some scientific software is usable, most isn t. - Better understand user needs at our facility. - Develop guidelines for a UCD approach to scientific software.

3 Methodology - Interviews Conducted some informal interviews with members of some user groups. Successes: - Clarified my understanding of the needs of different user groups. - Connection positively impacted relationships with interviewees. Problems: - Trouble looking at old problems/accepted methods in a new way. - My beamline is still under construction, no users other than staff. - Facility maintenance shutdown, restricted access to users.

4 Methodology - Research synchrotron software Reviewed online articles from peer-reviewed journals. Problems: - Articles are highly specific. Successes: - Lots of material available. - Learn about the software being developed at other facilities. - Identify trends in problems/needs addressed over time. - Many facilities have the same problems. - Compliment interview data.

5 Methodology - Research UCD Reviewed online articles from peer-reviewed journals. Problems: - Material specific to synchrotron projects is scarce/non-existent. Successes: - UCD for other scientific projects could be mapped to synchrotron projects. - Means of comparison between projects. - Articles could act as roadmaps.

6 Analysis - Many, many articles on the software developed at other synchrotrons. - System needs -- low-level hardware and software requirements, industry standards. - Scientific needs -- the requirements for running an experiment, collecting meaningful data. - A series of articles written by a group from Brookhaven National Lab. - User needs -- humanizing synchrotron experiments. - Articles on successful instances of UCD: - Museum informatics - Bioinformatics - Biological imaging

7 Results - The Problem Scientific software projects are traditionally developed by: - Professional scientists with some programming experience. - Professional programmers with some science background. The developer s skills and background dictate what needs take priority. The result is often an application that: - Is of high scientific merit. - Uses sophisticated hardware/software tools. - Is highly usable for select subgroup of users, not usable for others.

8 Results - System Needs Many software projects effectively begin as interfaces to available hardware. - Highly customized to available hardware. - Use industry standard systems (EPICS). - Portable, adaptable, modular design. - Open-source. A primarily system-driven software project has potential pitfalls: - Development limited by old assumptions, especially if project is inherited. - Incomplete understanding of the scientific impact of a particular decision. - Developer may never meet a user, makes decisions based on own preferences or stereotypes.

9 Results - Scientific Needs To fulfill the scientific objectives, the software must be: - Highly customized for the facility s scientific techniques. - Flexible enough to support upgrades/innovations. - Provide real-time updates for experiments as they re being executed. - Able to perform an experiment repeatably. A primarily science-driven software project has potential pitfalls: - Overrepresentation of the preferences of power users, the funding agents. - Lack of familiarity with common software tools. - Software tends to be a mix of custom modules and vendor software. - Incomplete understanding of the hardware requirements.

10 Results - Synchrotron User Context The missing component is consideration of users, from project start to finish. - At the facility for brief, intense, and infrequent visits. - May have shifts where they are unsupervised. - May be new scientists, not familiar with software, techniques, computers. - May not be familiar with hardware at this facility. - Often share data and collaborate on projects. - Prepare samples before arriving, and perform data analysis after leaving. - May want to run/view an experiment remotely. - May or may not keep log notes about a particular experiment. - Want to be the ones in control of hardware at all times--no interference.

11 Results - User Needs We can translate user context insights into needs: - Intuitive, reliable, easy-to-learn, streamlined, single point of entry. - Software that is similar/identical to controls at other facilities. - Abstract away hardware complications through process automation. - loading samples, optimizations, beam dump recovery. - Error-correction, prevents users from putting machines into bad states. - Persistent sample tracking/experiment logging system. - Use of standard data formats, data transfer protocols. - The ability to save and restore experimental conditions. - Ability to access and analyze data on-the-fly, or after experiment is run.

12 Results - UCD UCD approach makes user needs central to software development: - Build and regularly consult user profiles. - Design software interfaces/functionality around user workflows. - Regular workshops involving scientists and hardware/controls staff. - Regular testing periods integrated with development, involving real users. - Encourages collaboration, relieves responsibility/blame. - Clear objectives remove analysis paralysis.

13 Conclusion There are also potential problems with implementing UCD: - UCD represents a large culture shift. - Longer time to get up and running. - Difficulty preparing when building new system. The development of guidelines that drive software development in my field is incredibly useful. - immediately useful to me. - potentially useful to others struggling with the same issues.