Improving Design for e-science

1. Improving Design fore-science Russell Beale Advanced Interaction Group R.Beale@cs.bham.ac.uk

2. e- & The problem with e-science

3. “e-science is…” • “ONLY connected HPC” • “mainly distributed astronomy” • “Science, but on the internet” • “Existing science, but with more computers” • “simply a bandwagon”

4. What am I going to talk about? • Changing contexts • Little and large • Art • Design • Put another way… • Issues, x3 • Solution, x1

5. Context is important • Once upon a time • Single users & single systems • Then • Multiple users & single systems • Now • Multiple users & multiple systems

6. Myriad influences • Users affected by • other users • Task • Political pressures • Publication pressures • Collaborators • Competitors • Etc.

7. And… • Systems affected by • Distributed nature • Quality of Service • Variable usage • Outages • Blah blah

8. And… • Science affected by • Distributed nature • Variety of researchers • Variety of results • Collated results • Science changing? • Looking for patterns -> looking for anomolies

9. Little Science, Big Science • E-Science can be about enabling widespread data collection and assimilation • Internet, mobile, in field, in lab, formal, informal • Collated results provide effective picture • E.g. weather, bugwatch, springwatch • Mass participation

10. Data collection • Non-scientists as sources • Need appropriate systems to collect data • Usability needs of collectors very different to needs of scientists • But systems often designed for the scientists…

11. Feedback • To engage and encourage further participation • Ethical duty (?) • But have to be careful • With raw data • Anonymity of participants • With results • Cancer near pylons etc.

12. E-art • Same definition problems exist • How can e-science be used in e-art? • Changing context for art • Individual artists, small audiences • Multiple artists, small audience • Multiple artists, multiple audiences

13. Individual artists, small audiences • New tools for creation, management, manipulation and presentation • New medium for experimentation • Proximity not necessary for experience, for example • Communication

14. E.g. newsart

15. Multiple artists, small audiences • Communication, collaboration, shared development • Many people working on one (or more) centralised or distributed offering • Challenges relating to authorship, nature of ‘finished’ work especially if it keeps evolving, etc.

16. Multiple artists, multiple audiences • Infrastructure for creative collaboration • Dissemination via wide route • Mass audience participation possible • Authorship? Ethics? Values? • New tools for artists and viewers • E.g. art could be controlled by the viewer

17. Design and Usability • Aim of design - usability • Is it? • “If ease of use was the only valid criterion, people would stick to tricycles and never try bicycles” • Doug Englebart • More to design than usability

18. Usable design • Only from embedding design in the wider context is it effective • C.f. security: a holistic thing • Physical • Technical • Human

19. New concepts • Slanty design • Design that purposefully reduces functionality • E.g. iPod • Makes it simple to do simple things • Makes it hard to do unwanted things • E.g. Gmail • I call it “Anti-usability” • Removes signs and restrictions • These stop the unwanted side-effects of usable design • I want “Clean usability”

20. Slanty design process • identify the user goals • identify user non-goals: the things that users don’t want to be able to do at all easily (e.g. deleting all their files) • identify wider goals held by other stakeholders, and identify where they conflict with individual ones • follow a user-centred design process to create a system that has high usability for user goals and high anti-usability for user non-goals • resolve the conflicts between wider issues and individual goals, and where the wider issues win out ensure that the design meets these needs

21. My slanty baggage carousel

22. Summary • Problems with e-science as well as problems with usability • Need to design for the complex situation from the start • Scientists and non-scientists working together creates new scenarios • Artists and non-artists working together creates new scenarios • Complex stakeholdings may have conflicting needs which have to be addressed • New design approaches needed - the future is ‘slanty’…

23. Questions? • E-questions: R.Beale@cs.bham.ac.uk

24. Finally • In Google: usability returns 73,500,000 results • E-science returns 1,560,000 results • E-science usability: 39,800 results - 2.5%... • 1st 3 are pdf’s

25. Pattern background • Patterns are solutions to problems in a given context • Derived from architecture • Christopher Alexander

26. Example Alexander pattern Alexander’s Pattern No. 176 Garden Seat: ‘Make a quiet place in the garden – a private enclosure with a comfortable seat, thick planting, sun. Pick the place for the seat carefully; pick the place that will give you the most intense kind of solitude’

27. Patterns in CS • Popularised for CS in Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Gang of Four) • From Sun: • “A pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.”

28. Why use patterns? • They have been proven • Patterns reflect the experience, knowledge and insights of developers who have successfully used these patterns in their own work. • They are reusable • Patterns provide a ready-made solution that can be adapted to different problems as necessary. • They are expressive • Patterns provide a common vocabulary of solutions that can express large solutions succinctly.

29. Patterns for HCI • Adopted for HCI in recent past • Pros • solution to problem in context • Usable by non-expert designers • Cons • Usable by non-expert designers • Too many, unstructured, need to know about them all

30. Overview-Detail pattern • Use when: You need to present a large amount of content - messages in a mailbox, sections of a website, frames of a video - that is too big, complex, or dynamic to show in a simple linear form. You want the user to see the overall structure of the content; you also want the user to traverse the content at their own pace, in an order of their choosing. • Why: It's an age-old way of dealing with complexity: present a high-level view of what's going on, and let the user "drill down" from that view into the details as they need to, keeping both levels visible for quick iteration. Overview Plus Detail breaks up the content into comprehensible pieces, while simultaneously revealing their interrelationships to the user. • […] the overview can serve as a "You are here" sign. A user can tell at a glance where they are in the larger context. In the example above, the scrollbar shows that the visible message is near the end of the mailbox. • How: The overview panel serves as a selectable index or map. Put it on one side of the page. When the user selects an element in it, details about that element - text, images, data, controls, etc. - appear on the other side. (Usually the overview panel is at the top or left.) • […] keeping both halves on the same page or window is key. You could put the details into a separate window, but it's not as effective. You want the user to be able to browse easily and fluidly through the UI, without waiting or messing around with windows. In particular, you don't want the user to jump back and forth between two pages (though it's usually necessary on tiny displays like PDAs; see One-Window Drilldown, which doesn't require the use of two side-by-side panels). Jenifer Tidwell, Common Ground

31. OPD examples

32. Approach to modelling • Want to capture design patterns more formally • Want to be able to apply them to current software designs • Would like CASE support if possible • Look at software systems • Model Driven Architecture • Abstract towards models • Remove dependence on technology • Platform Independent Model (PIM) • Apply device profiles • Platform Dependent Model (PDM) • Provides flexible development

33. Model View Controller Aside: map into MVC

34. Capturing the interactive elements… • Sequence diagram

35. Where are we? • Have a formalism for design patterns • Can capture structural and behavioural aspects • Represent interaction formally in UML and OCL

36. Working with formal patterns • Conceptual model -> represents the system • Design patterns -> used to refine that model to new one that implements the pattern • But which to choose? How does this improve things?

37. Need one more concept:Data signatures • Data suitable for refining via OPD or OWD is of the form: • Datatype A has list of items B • B’s are in 1:1 correspondence to data type C • i.e. A has selectable indices, each of which have associated detail • Or, data has at least one level of hierarchy in it - a series of headers and contents • Partition the model using signatures

38. Case tool

39. figures