Re-factoring grid computing for usability

Bruce BecklesUniversity 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 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”

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

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

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

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

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

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

• 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”

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)