1 / 39

Improving Design for e-science

Improving Design for e-science. Russell Beale Advanced Interaction Group R.Beale@cs.bham.ac.uk. e-. &. The problem with e-science. “e-science is…”. “ONLY connected HPC” “mainly distributed astronomy” “Science, but on the internet” “Existing science, but with more computers”

liliha
Download Presentation

Improving Design for e-science

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related