Re-factoring grid computing for usability

1. Re-factoring grid computing for usability Bruce Beckles University of Cambridge Computing Service

2. First things first: an apology • This presentation may seem “off-topic”: • All I had to work with was the workshop title: • Making e-Science Usable • That title implies that e-Science currently isn’t usable • So what’s the problem? • “Re-factoring for usability”: • Impossible • If usability not at heart of product design, tinkering with finished product cannot solve this… • “painting the corpse”

3. So what am I going to talk about? • Not: • a catalogue of usability complaints • lecturing you on the seriousness of the current problems • Instead: • Talk about how usable software might be designed, and… • How not to design unusable software

4. Some definitions • Usability: anything that affects the user’s ability to use the product for their stated purpose (also their perception of the product and their abilities in relation to it) • Computer science: The application of the scientific method to the study of computing and related activities

5. Designing for whom? • Only one group can say for certain whether a product is usable: • Users • (Not funding agencies, politicians, heads of departments, computer scientists or middleware developers) • So, who are the users? Users of what? • What: grid middleware • Who: application developers and the end-users of those applications

6. Why middleware? • Middleware underlies the grid effort: • “plumbing” • If plumbing wrong, bathroom design is irrelevant. • So, middleware developers need to design for usability • Considering application developers as their “users”, who are the arbiters of this usability • This also means considering the application developers’ users: • What are the application developers using the middleware for?

7. Designing for usability (1) • Usability: • Not a “feature” • An aspect of every part of the product that affects the user’s experience • So must be considered at every stage • Iterative design loop: Requirements => Analysis => Design => Prototyping => User assessment (At every stage of product development)

8. Designing for usability (2) • User engagement • API design • User interface (UI) design • Security • Documentation • Deployment

9. User engagement • “Programmers are people, too”: • Human factors • User-centred design methodologies • Requirements capture: • Who is the user community? • Large, diverse community = differing requirements • Requirements may conflict: • Partition user community into non-conflicting sets; separate design for each • Explain to user community that requirements conflict and let them make choose what takes precedence.

10. API design • APIs = “user interface for programmers” • Good APIs feature: • Suitability of functionality: • Functionality must be user-driven • Standards compliance (where possible) • Progressive disclosure • Simplicity: • Make common sequences of function calls atomic • Appropriateness of interface: • Language bindings • Development tool support • Error prevention: • Forcing functions • Literate design (after “literate programming”) • Support rapid application development & prototyping

11. User interface (UI) design • Hey, for middleware isn’t that just API design? • Not quite: • Every aspect of the middleware with which the user interfaces, so: • Installation procedures • Administrative procedures • Documentation, etc. • Must not force an adversarial conceptual model onto the user: • Abandoning the system in disgust because it is too hard to install and get working should not be a conceptual model of the grid we encourage…

12. Security • No conflict with usability • Unusable security is insecure • Meeting security requirements is a usability requirement: • If security requirements not met, will not be allowed to use system • If security compromised, cannot use system • Use a user-centred security methodology (e.g. AEGIS)

13. Documentation • Accurate • Appropriate level for intended audience • Literate documentation (after “literate programming”) • Progressive disclosure • Numerous examples • Templates for frequently used tasks

14. Deployment • Why consider deployment?: • Too hard to deploy = won’t be used • Rapid application development / prototyping has deployment implications • Good deployment features: • Re-use system libraries • Use existing packaging / installation mechanisms • Small footprint • Support incremental adoption • Able to run in user-space

15. What does usable middleware look like? (1) • Not like anything we have now • Domain specific: • A truly general grid middleware would be unusable • Maybe solution is multiple domain-specific middlewares • More like WSRF::Lite or Google’s MapReduce than the Globus Toolkit

16. What does usable middleware look like? (2) CONVERT DATA TO GRID FORMAT CONNECT TO GRID SEND CONVERTED DATA TO SERVICE GET RESULT WHEN AVAILABLE DISCONNECT CONVERT RESULT TO SENSIBLE FORMAT …should be just 6 API function calls

17. Conclusion • Two choices: • Hire professional software developers for every single project that wants to use grid computing • Design new, usable middleware from scratch and gradually retire the existing middleware to the museum of catastrophic failures • What’s hard about this?: • Admitting what we already know: • we have no “grids” worth the name, and • £250+ million, almost 5 years wasted • Not “designing usable software”, but making the paradigm shift that “only users can determine whether software is usable”

18. My challenge to you • e-Science should be “science”: • If you don’t agree with me, prove me wrong • Conduct your own usability trials of the current middleware (please let me know your results) • If you agree, at least in part, then: • Start demanding usable software. It’s your right as a user. • Let’s stop colluding and tell the Emperor that he’s naked… “Politics is the art of preventing people from taking part in affairs which properly concern them.” (Paul Valéry)