Slideshare.net (beta)

 

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 0 (more)

Six Principles of Software Design to Empower Scientists

From dder, 4 months ago

Keynote talk for Workshop on Managing for Usability: Challenges a more

961 views  |  0 comments  |  0 favorites  |  10 downloads  |  3 embeds (Stats)
Embed
options

More Info

This slideshow is Public
Total Views: 961
on Slideshare: 950
from embeds: 11

Slideshow transcript

Slide 1: Six Principles of Software Design to Empower Scientists David De Roure and Carole Goble

Slide 2: Our e-Science context 6 principles of design for adoption 6 principles of user engagement The myExperiment experience Reflections

Slide 3: The e-Science Pilots, OMII-UK and myExperiment

Slide 4: myGrid platform my Grid Taverna OMII-UK myGrid myExperiment CombeChem CombeChem platform CoAKTinG Memetic CREW

Slide 5: My Chemistry Experiment Box of Chemists

Slide 6: Iconic CombeChem Picture Video Simulation Properties Analysis Diffractometer Structures Database X-Ray Properties e-Lab e-Lab Grid Middleware www.combechem.org

Slide 7: The social process Virtual Learning Environment of science Undergraduate Students Digital Libraries scientists Graduate Students Reprints Peer- Reviewed Journal & Technical experimentation Conference Preprints Reports Papers & Metadata Local Web Repositories Data, Metadata Certified Provenance Experimental Workflows Results & Analyses Ontologies

Slide 8: Smart Tea www.smarttea.org

Slide 9: Iconic myGrid/Taverna Slide  Workflows are the new rock and roll  Machinery for coordinating the execution of (scientific) services and linking together (scientific) resources  The era of Service Oriented Applications  Repetitive and mundane boring stuff made easier Carole Goble

Slide 10: Recycling, Reuse, Repurposing  Paul writes workflows for identifying biological pathways implicated in resistance to Trypanosomiasis in cattle  Paul meets Jo. Jo is investigating Whipworm in mouse.  Jo reuses one of Paul’s workflow without change.  Jo identifies the biological pathways involved in sex dependence in the mouse model, believed to be involved in the ability of mice to expel the parasite.  Previously a manual two year study by Jo had failed to do this.

Slide 11: Triana Kepler Ptolemy II BPEL

Slide 12: The Taverna Superclient • Run on your laptop – no sysadmin required • Access independent third party world-wide service providers of applications, tools and datasets – 850 databases, 166 web servers Nucleic Acids Research Jan 2006 • My local applications, tools and datasets. In the Enterprise. In the laboratory • Easily incorporate new services without coding

Slide 13: Taverna downloads per day 40 2003 2004 2005 2006 2007 taverna.sourceforge.net

Slide 14: OMII-UK provides free Open Source software and support to enable a sustained future for the UK e-Research community. Our software includes Software Solutions, which are easy-to-use and easy-to-install software packages that solve common e- Research problems, and the Development Kit, which is a set of inter-operable software components that can be linked together to provide bespoke functionality. OMII-UK supports Open Source software development by commissioning developers to produce software with the functionality required by our user community. omii.ac.uk

Slide 15: e-Science Value Chain Infrastructure Component Solution e-Science Provider Provider Provider End User OMII OMII-UK © 15

Slide 16: myExperiment.org is... myExperiment.org is…  “Facebook for Scientists”...but different to Facebook!  A community social network.  A gateway to other publishing environments  A federated repository  A platform for launching workflows  Publishing self-describing Encapsulated myExperiment Objects  Mindful publication  Started March 2007  Closed beta since July 2007  Open beta November 2007 703 users, 67 groups, 146 workflows, 24 files

Slide 19: Virtual Learning The social process Environment of science 2.0 Undergraduate Students Digital Libraries scientists Graduate Students Reprints Peer- Reviewed Technical experimentation Journal & Conference Preprints Reports Papers & Metadata Local Web Repositories Data, Metadata Certified Provenance Experimental Workflows Results & Analyses Ontologies

Slide 20: Our Six Principles of Design for Adoption

Slide 21: 1. Fit in, Don’t Force Change • No obligation on service providers to change their services to fit into Taverna • Early users tolerated less-than-perfect interfaces because their favourite service was available • myExperiment motto is to bring myExperiment to the user – Wikis, iGoogle, etc – www.myexperiment.org

Slide 22: 2. Jam Today and more Jam Tomorrow • This is about incentives • The activation energy required by users to adopt a feature must be matched by the reward gained • Get some core capability and quick wins out there as soon as you can • Our scientists and developers travelled on the journey together

Slide 23: 3. Just in Time and Just Enough • This is about delivery • Be better not perfect • Solve the problems users already know they have – don’t make them wait for solutions to problems they don’t yet know they have and perhaps never will! • With websites it’s easier to be incremental and to involve a distributed and disparate community of users in the design process

Slide 24: Carole Goble

Slide 25: 4. Act Local, think Global • We targeted a community we know really well, picked a few close ‘friends and family’ and just built it for them • Experience suggests that customisation outvotes genericity, extensibility outvotes comprehensivity, and scruffy and flexible outvotes smart but rigid • As Don Wells said, “Don’t Solve a Problem Before You Get to It”

Slide 26: 5. Enable Users to Add Value • This is about empowerment • Extensibility and customisation are crucial to adoption • The small team associated with myExperiment means maximal reuse and reusability is a necessity as well as a nicety • As much use as possible of third party code and services, and our services available through a simple API

Slide 27: 6. Design for Network Effects • This is about community • Large number of scientists conducting the routine processes of science on a daily basis • Gathering usage data enables the community to benefit from usage without explicitly uploading new content

Slide 28: NB • Both projects are just as much – or perhaps even more – about content as software • We were reminded of this when we went open beta with myExperiment and the first bug report that came in was about a spelling error in a user-provided workflow description

Slide 29: Building Trust between Users and Developers Our Six Principles of User Engagement

Slide 31: 1. Keep your Friends Close • Local pioneers and external early adopters • OMII-UK operates a scheme of beta testers and ‘Product/Area Liaisons’ (PALs), who are not directly working for OMII-UK but are the eyes and ears in the communities they work in • Taverna has three very active PALs • myExperiment has community champions

Slide 32: 2. Embed • We embed developers with users and users with developers, getting them to sit side by side for long periods • We started myExperiment by embedding the developers in an end-user laboratory, to experience the work environment with respect to sharing and communication, and understanding non-functional requirements

Slide 33: 3. Keep Sight of the Bigger Picture • Tendency of developers to get hung up on some point that a user doesn’t worry about in the overall scheme of things • Our software is not the only software our users use, and they are only using it to do the research they really want to do • They daily use complex tools they are familiar and comfortable with – mimic these tools and link with them

Slide 34: 4. Favours will be in your Favour • Building trust is a two-way activity, requiring compromise and favours • For every pioneer, myGrid ‘sacrificed’ one developer in support – this was not wasted effort! • We still develop, or help partners develop, bespoke code • In myExperiment we prioritise tasks and allocate development effort based on the return in adoption

Slide 35: 5. Know your Users • Rarely is there one kind of user: – Scientists – domain expert developers producing applications – service developers – service providers – system administrators. • Don’t forget young postdocs and postgraduates!

Slide 36: 6. Expect and Anticipate Change • User needs and wants will change • Success will mean that scientific practice will change, and so will expectations • The choice of pioneering friends will need to change and new classes of user will emerge • When we started out, we replicated current scientific practice – two years later we were inventing new practice

Slide 37: The myExperiment Experience www.myexperiment.org

Slide 38: 24/5/2007 | myExperiment | Slide 38

Slide 39: Google Gadget

Slide 40: Ownership and Attribution

Slide 41: Snapshot map of resources with their relationships and versions HTML XML tags blobs users groups workflows descriptions friendships ` Enactor

Slide 43: Managing Developers • Web 2.0 developers vs CS Software Engineers • Core team + champions works really well • We’ve stuck to “only do what users ask for” – features then refactoring • For the project manager it’s like driving a very fast car! • Weekly update

Slide 44: The regime! • Daily 5pm developer chat chaired by PM, Co-PI or PM delegate • Weekly 10.30 management telephone conference • Monthly team Face to face • Monthly hackfest • Monthly (at least) user workshop • PM has daily contact with developers • Influencing myGrid team

Slide 46: Malcolm Atkinson The Arrow Problem e-Science Applications Research Pipeline NB This isn’t wrong! CS Research EE e-Science e-Science Mass Research Technology bespoke Use by Creators tailoring Researchers & Integrators Socio-economic & e-Science Commercial 10s of 100s of 1000s of Innovation integrators embedded research consultants users 5 years 5 years 5 years

Slide 47: Don’t think rollout of technologies... Mass Use by Researchers Think roll-in of researchers... Mass Use by Researchers Knowledge co-production vs Service Delivery!

Slide 48: Web Browser Mobile phone iPod Car Equipment PDA Scientists Software Companies Subject OeRC applications workflows ICT experts Workflow nesc mashups Computer Scientists ecosystem tools Software Ruby on Rails open source services Engineers Web Services RESTful APIs cmd lines ssh http P2P

Slide 49: N N2 N

Slide 50: N 2N One Middleware N

Slide 51: N Middleware Middleware ? Middleware Middleware Polynomial involving N1, N2 and M Middleware Middleware N

Slide 52: Take home Don’t think rollout of technology, think roll-in of users

Slide 53: Summary of Principles 1. Fit in, Don’t Force Change 1. Keep your Friends Close 2. Jam today and more jam 2. Embed tomorrow 3. Keep Sight of the Bigger 3. Just in Time and Just Picture Enough 4. Favours will be in your 4. Act Local, think Global Favour 5. Enable Users to Add Value 5. Know your users 6. Design for Network Effects 6. Expect and Anticipate Change

Slide 54: Contact David De Roure dder@ecs.soton.ac.uk Carole Goble carole.goble@manchester.ac.uk Thanks Malcolm Atkinson, Jeremy Frey, Savas Parastatides, The myGrid Family http://eprints.ecs.soton.ac.uk/15032/