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

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 isnt usable –So whats 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

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

Some definitions Usability: anything that affects the users 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

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

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?

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

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

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.

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

User interface (UI) design Hey, for middleware isnt 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…

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)

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

Deployment Why consider deployment?: –Too hard to deploy = wont 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

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 Googles MapReduce than the Globus Toolkit

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

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 Whats 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

My challenge to you e-Science should be science: –If you dont 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. Its your right as a user. –Lets stop colluding and tell the Emperor that hes naked… Politics is the art of preventing people from taking part in affairs which properly concern them. (Paul Valéry)