DigitalFriend Blog

September 2008

Human-Centred Software Engineering 2008, Pisa, Italy

Mon, 29 Sep 2008 22:10:36 +1000

By: gosh'at'DigitalFriend.org (Steve Goschnick)

Human-Centred Software Engineering as opposed to traditional Software Engineering, strikes me as about as different as the Venetian masks in Images 1 and 2 below. The second conference on Human-Centred Software Engineering (HCSE-2008) was one of two excellent events, that together made up Engineering Interactive Systems (EIS) 2008 conference in Pisa, Italy, on the 25th and 26th of September, 2008. The other, which has a longer history, was the 7th International TAMODIA (Task Models and Diagrams) workshop - heavily oriented towards modelling interactive systems in the Analysis and Design phases of a new technology, and the only International conference that has such a focus.

I presented a paper in each, both co-authored with my two PhD supervisors, Sandrine Balbo (expert: Task Models) and Liz Sonenberg (expert: multi-agent systems - MAS), covering some research I've been doing in (and central to) my PhD on agent meta-models...( I just couldn't go past a conference titled "Human-Centred Software Engineering" - with my DigitalFriend focus on building software applications for peope, rather than specifically for the corporation that employs people.)

There were 26 papers presented over the two days, all of which I found very interesting (you don't need to take my word for it, Larry Constantine said as much during the second day), a first for a conference in my experience.

Think of these robot-inspired Venetian masks as representations of traditional Software Engineering.

Image #1: Think of these robot-inspired Venetian masks as an analogy of traditional Software Engineering (with heavy lashings of UML).

The keynote speakers were both well-known and very good: Alan Dix on day one; and Larry Constantine on day two.

To my mind Alan does a good keynote (last time I saw him keynote was at OzCHI'03 in Brisbane). His talk and paper (13 pages) were titled: 'Tasks = data + action + context: automated task assistance through data-oriented analysis' (note: when he says 'data', he is largely referring to 'environment'). He started off a bit hairy, with routine everyday experience (eventually pouring milk in his cereal, after almost pouring it in his bowl of fresh grapefruit by mistake), numerous same-day/trip anecdotal tangents, but by the end of the hour-long presentation, it all came together as a clever choregraphed performance. It was about tasks in real life (24/7), the sort that don't fit those neat textbook hierarchical task models that are typically used to describe a routine UI task, such as getting money out of an ATM. However, he did group these real tasks into four types: habitual, reactive, considered and situated - which "some say are too subtle and too manual to model. I say, in humility try (a limited account), but if its too hard for a human analysis, use automated analysis for task assistance (in some of these things)."

Now think of these traditional Venetian masks as representations of a fresh new , but early version of a Human-Centred approach to Software Engineering.

Image #2: Now think of these traditional Venetian masks as representations of a fresh new, but an early take on Human-Centred approach to Software Engineering. [ A side-issue: Come to think of it, I wonder if anyone is investigating a parallel between the role that masks played in Venetian society, and that of avatars in Second Life as it stands today? It would be a tough assignment for a PhD student, needing to put a few months at least, in situ.]

He characterised human everyday activity as that of 'an embodied human' (in the sense of the embodied mind theorists). And the things we do, as either:

  pre-planned environment driven
Explicit known-plan action means-end analysis
Implicit proceduralised/habit stimulus-response/reactive

and we move between these tasks, often seemingly at random, as we go about our environments (work, home, real, virtual, etc), observing, reflecting, acting and interacting. When somebody asked if 'do people really use plans (in everyday life)?', he answered: Yes, the sort that people "can often externalise, if asked... (while) we tend to embed long-term tasks into the environment".

[Think of a 'proceduralised/habit' as you making yourself a cup of coffee in the morning, in your own kitchen. Think of a 'known-plan action' as you making yourself a cup of coffee, in someone elses kitchen. Think of 'means-end analysis' as you wanting a cup of coffee, when you are in some unfamiliar town, in your foodless campervan. The 'goal' is a cup of coffee. After every action that you take, you re-evaluation how much closer to the goal you are, before deciding on your next step. E.g. 'The search for a cafe or Starbucks was fruitless, so, do they have a supermarket that sells bottles of instant coffee?' Think of 'stimulus-response/reactive' as: you are walking down Lygon Street minding your own business, heading for a book shop, for a book, when right in front of you a waiter delivers a pizza and a freshly brewed coffee to a customer at an outdoor table - the smell of the coffee hits you with a visible affect. You suddenly decide to find yourself a seat and order a coffee too.]

He went on to talk about 'Designing for the embodied person' by: enabling people to do tasks (e.g. providing them with timely data); prompting them; etc.

He described some recent work where he was using personal ontologies, then spread 'activation' on them directed by the links between them, whenever an external event (e.g. "Going to Pisa for a conference ") or an environmental stimuli, provoked it. The strength of the activation diminishes, the further away that a related term was in the personal ontology (e.g. "I have an old acquaintance in Pisa - I could look them up") from the initial activation. The level of activation was then used to generate user task assistance (this part reminded me a lot of Ron Sun's work on consciousness that he presented when he passed through our department a few years ago).

He drew on a large body of research (his+colleagues) over an extended period of time (15+ years).

His lessons were:

Larry Constantine (perhaps best known as the inventor of the DFD - data flow diagrams) is currently most into Activity Theory, and has a research group at University of Madeira, Portugal. [He described Activity Theory as a reaction to the bourgeois individual-oriented psychologies that were rising at the start of the 20 th century ... a great lead-in to my work based on adaption of evolved versions of those same psychologies;) - i.e. ShadowBoard draws strong direction and computational insights from the Psychology of Subselves, which itself, is derived from Jungian Psychology. While ShaMAN is an acronymn of Shadowboard Multi-Agent Networks.]

He started by saying his recent work is characterised by 'usage centered design' rather than user-centered design, along the lines of Donald Norman's relatively recent rethink on User-Centred Design (i.e. 'Human Centered Design Considered Harmful', www.jnd.org ), with a focus on 'what the user is doing' (activity); and by presenting himself as a card-carrying designer first and foremost - "because that is the community that have been most accepting of my work".

He has a new methodology (Activity Modeling) and a new notation (see Image3 below) which he was keen to promote through a detailed explanation. It was devised after re-examining 15 case studies, which consisted of substantial 'real-world' projects that he himself had designed/was involved in the design, over a 9-year period (I may have the 9 and the 15, the wrong way around), projects that consumed thousands of man-years, in what he called an exercise in 'project archaeology'. His perceived foot-in-the-door for a new notation against UML, was the oft cited fact that standard UML sees no difference between 'actor' and 'role', where there should be one in the notation, as there is a difference in those things, when we model. In drawing an overlap between his work and that of the task modelling community, he equated task models to his 'essential use cases', which he then morphed to 'task cases' for this audience. His take home point was that " usage centered-design provides the methodological scaffolding for applying ActivityTtheory in practise ", via his Activity Modeling methodology. He was at pains to point out that Activity Modeling did not involve ethnography. While he didn't have a paper in the proceedings, he has one in the pipeline coming out in a journal "in 2008 some time", on the aforementioned Activity Modeling.

Larry Constantine's Activity Modeling notation.

Image #3: Larry Constantine's Activity Modeling notation.

The overarching message I got from both keynotes, was that they were both presenting results from a deep body of work (one research-oriented, the other practise-oriented), and were both putting that work forward as a significant footprint in this newish domain of research interest under the banner of 'Human Centred Software Engineering'. My impression was that Alan Dix's work was more generally applicable, while Larry's was more focused upon those 8 hours that people often work within the 24-hour day (but my impression may be wrong here - as Activity Theory has wider application), and upon practising designers as his target audience.

I could write about any of the other 26 other papers with near-equal enthusiasm, but I'll just pick two:

Paper 1:

Title: MuiCSer: A Process Framework for Multi-disciplinary User-Centred Software Engineering Processes.

Authors: Mieke Massink, Karen Coninx, Jan Van den Bergh and Kris Luyten

Affiliation: Hasselt University, Belgium

This paper was about a conceptual framework (but one they are endeavouring to build tools around) of the processes that can be brought to bear, upon a multi-discipline team intent on analysing, designing and developing technology (specifically focused on the user-interfaces and functionality). In particular, their team consisted of HCI Experts and Software Engineers, but it also included graphic designers, domain experts, marketers, social scientists and end users (they reported on two case studies, one updating a legacy system, the other a greenfield product). The HCI aspects are really concentrated on Task modelling and goal elicitation, although end-users are used in verification and in field testing advanced prototypes.

It's a fourteen page paper with some interesting insights and confirmations. They also examined the applicability of various new tools that support (two or more of) task modelling, interaction design, interface prototyping and development (e.g. Teresa, SketchiXML, CanonSketch, Damask, Gummy, CTTE, TaskSketch, GrafiXML) to the various roles of stakeholders in such multi-disciplinary design teams.

In their take-home lessons, they were specific about not trying to unify the process with some new over-arching analysis design tool, but instead they do see value (to the efficiency of the process, and the acceptability by the team) in a central storage repository of the artefacts (e.g. scenarios, personas, task models, goals, mock-ups, low-fidelity prototypes (paper-based), high-fidelity prototypes, software engineering models such as UML diagrams, etc) that are used at each stage, developed at each stage, and that pass into the next phase of the analysis and design process. They also see value in storing something of both the manual and the system-guided transitions between the artefacts, and therefore also see value and future direction in the XML-based user-interface description languages, that have been declared in recent years and are still evolving.

Paper 2: Note: Many of the papers at these two conferences involved or at least referenced ConcurTaskTrees (CTT) [Paterno et al, 1997] in one form or another, perhaps due to the good set of tools that support it, probably also to do with the complexity of the modern application program and CTT (and variants) meeting much of that complexity. The following paper description, is about one such paper.

Title: Task-Based Development Methodology for Collaborative Environments

Authors: Maik Wurdel, Daniel Sinnig and Peter Forbrig

Affiliations: University of Rostock, Concordia University, University of Rostock.

This paper outlines a step-wise iterative process that takes a collaborative system under developmental consideration, from analysis, through requirements, to design level models. Collaborative ConcurTaskTree (CCTT) are a common tool used in the analysis of collaborative systems. CCTT has a task model for each role involved in the cooperation, then involves a 'coordination model' to tie together the temporal dependencies. However, CCTT assumes one actor can only fill one role simultaneously. The approach taken in this paper overcomes that limitation, and it does so with a language called the Collaborative Task Modeling Language (CTML). A CTML model is a set of tuples as follows: a set of actors, a set of roles, and a set of collaborative task expressions (which are task models, with pre and post conditions), where each actor can have one or more related roles - not unlike the Roles, Agents and Task entities/heirarchies within ShaMAN, the large meta-model I presented in the papers linked below). The CTML model can be developed and animated within their own recent tools: CTML Editor and Simulator.

CTML models are used in all three stages of development (as they see the development cycle), in: analysis, requirements and design, and the iterations happen between these phases. The iterative changes to the model can be achieved with structural refinement (i.e. changes to the task hierarchies) and behavioural refinement - the validity of behavioural refinement depends on the usage of 'meta-operators', allowing for either 'shallow binding' (sub-tasks may be omitted during refinement), 'deep binding' (sub-tasks need to be preserved) and 'exempt binding' (newly added sub-tasks need to be preserved here on in). A case study is used to illustrate how these different meta-controls can be used effective during an iterative development process.

An interesting thing about this paper is that to some extent it addresses issues of sub-task model specification, which need to be interrelated in various ways across time, and under certain conditions. And even though they focused here on collaborative applications across different actors fulfilling different roles, it could have been used to some extent, to represent many of those similar fragments of goals and plans that Alan Dix was discussing in his opening keynote, those in a normal 24/7 life, the ones that the environment evokes from time-to-time, both routinely and randomly.

Coming away from this conference, my only regret was missing Tamodia'07 and the very first HCSE, the year before.

Tamodia 2009 is in Cambridge (not sure about HCSE'09 but I assume it will be co-located again with Tamodia), and to any researchers currently involved in modelling interactive systems, I recommend you give it consideration when presenting such a research contribution.

Note: The papers thatI presented are now available at Springer Online, here:

From Task to Agent-Oriented Meta-models, and Back Again published in Engineering Interactive Systems 2008 of Lecture Notes in Computer Science . If your organisation has access to this publication, you may view the paper at: http://dx.doi.org/10.1007/978-3-540-85992-5_4

And:

ShaMAN: An Agent Meta-model for Computer Games published in Engineering Interactive Systems 2008 of Lecture Notes in Computer Science . If your organisation has access to this publication, you may view the paper at: http://dx.doi.org/10.1007/978-3-540-85992-5_22

[Earlier draft copies will available on this web-site soon]

If you or someone you know is interested in meta-models, specifically about human and/or agent goals, activity, available resources and situated locales, then please point them in the direction of those links:) Thanks.

taking the autostrada via a stopover in Florence, is a great way to get to Pisa.

Image #4: Taking the autostrada via a stopover in Florence, is a great way to get to Pisa from Rome.

Postscript: If you like driving, hiring a car from Rome and taking the autostrada via a stopover in Florence, is a great way to get to Pisa. My only regret was not paying attention to the fineprint in the Europcar agreement via the Internet booking - I thought I was getting a Lancia (as in: "When in Italy ..."), but they lumbered me with a GM car of some sort ("approximate equivalent"). You need horsepower in the hills and tunnels on the autostrada as the sweetspot (not passing too many cars and trucks, not being passed by too many cars, is about 130kph - its meant to be the upper speed limit, but many drivers go way over that, and there doesn't appear to be any enforcement of the 130 limit) - but the car I had struggled in the hills. I found it slightly ironic that the advised slower speed signs on some of the tighter corners was 110 kph, which is the maximum speed limit on some Australian freeways or tollways, while its 100 on the others. Oh for my XR-6 on these roads.

Home | Site Map | Privacy Policy | Contact Us | ©2008 Solid Software Pty Ltd