Michael Raschke
email: michael.raschke@vis.uni-stuttgart.de

Tanja Blascheck

Thomas Ertl

Cognitive Ergonomics in Visualization

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

A key factor to assure success of a visualization technique is how efficiently users perceive information using this visualization technique. This efficiency is strongly correlated with visualization parameters which we will summarize in the following with the term cognitive ergonomics. In this chapter we will motivate the reader to study cognitive ergonomics in visualization using an interdisciplinary approach. This interdisciplinary approach is based on eye tracking data visualization, ontology based visualization models, and cognitive simulations. Figure 1 shows the chapter structure, and the interdisciplinary approach we suggest. Many user experiments have been conducted to study perception of visualization techniques. Apart from measuring accuracy rates and completion times, eye tracking experiments provide an additional technique to evaluate visualizations. Due to eye tracking devices becoming cheaper, eye tracking is a promising approach to study visualization parameters that are relevant for cognitive ergonomics. The results of eye tracking experiments allow researchers to investigate scan paths of eye fixations on the stimulus. Thereby, researchers can measure which areas on the stimulus have been focused on in which order, by which participants, and with how many fixations. Overall, eye tracking metrics allow evaluating cognitive stress by statistically analyzing fixation durations, distributions, and sequences, or cognitive workload by studying changes of pupil size of participants.

Besides using statistical algorithms to compare eye tracking metrics, visualization techniques allow to visually analyze fixation durations, distributions and sequences of several participants at one glance. However, only state of the art visualization techniques are usually used, such as scan path or heat map visualizations (cf. Figure 2). For this reason, we are motivating readers to develop further visualization techniques for eye tracking data analysis in the first part of this chapter. We will analyze the structure of eye tracking data, and the visual analysis process of eye tracking results from an information visualization pipeline perspective. This systematic approach will help visualization developers to find new visualization techniques for graphical representations of eye tracking data. We will conclude this part with the presentation of the parallel scan path visualization technique which we have developed following this systematic approach.

Today, the development of visualizations is mostly driven by a technical perspective. The main goal of visualization research is to visualize as many data points in real time on high resolution screens as possible. However, there are now tendencies towards a user centered design of visualizations. The user centered design takes effects into account such as perception of graphical representations and cognitive workload. The second part of this chapter demonstrates how this user centered design paradigm can be applied in a visualization scenario. In this scenario we annotate visualizations with semantic information to allow viewers to customize their visualizations.

The discussion of cognitive ergonomics is strongly related to the question if metrics such as fixation durations, distributions, and sequences can be modeled and then be simulated? If this question can be answered positively, the high effort which is required for the preparation, and conduction of eye tracking experiments could be reduced. In the future, interesting visual tasks and visualization parameters could be selected in advance by running a simulated experiment without conducting any experiments with real participants. This approach is mainly inspired by the successful application of cognitive simulations in human computer interaction (HCI) research. The third part of this chapter will give a brief motivation for using cognition simulations to test visualization designs. Therefore, we will discuss interesting aspects of CogTool from HCI, and the cognitive simulation framework ACT-R.

Finally, we will conclude the chapter by bringing together approaches, concepts, and techniques presented in this chapter to formulate a road map to study cognitive ergonomics of visualizations in future work.

Eye Tracking Data Visualization

To study the readability, efficiency, and cognitive workload of visualizations, controlled experiments, usability tests, longitudinal studies, heuristic evaluations, or cognitive walkthroughs can be performed [START_REF] Tory | Qualitative analysis of visualization: a building design field study[END_REF]. Standard metrics to evaluate visualizations are accuracy rates and completion times. Since the recording of eye movements became easier during the last decade, many user study designers additionally use eye tracking techniques. Eye tracking data provides information about eye movements of a participant during a user experiment. In most cases the participants' fixation positions on the screen, the fixation durations, and the sequence of fixations on the stimulus (in the following scan path) is of interest. Usually, the goal of eye tracking experiments is to find common eye movement patterns. One approach is to use visualizations which show the eye movements of several participants in an appropriate way to support finding common structures. Classic techniques to do this are heat maps and traditional scan path visualizations (cf. Figure 2) [START_REF] Spakov | Visualization of Eye Gaze Data using Heat Maps[END_REF]. Enhancements to these classic techniques have been presented by Aula et al. who developed a non-overlapping scan path visualization technique [START_REF] Aula | Eye-Tracking Reveals the Personal Styles for Search Result Evaluation[END_REF]. Another technique is used by eSeeTrack which combines a time line and a tree-structured visual representation to extract patterns of sequential gaze orderings. Displaying these patterns does not depend on the number of fixations on a scene [START_REF] Tsang | eSeeTrack-visualizing sequential fixation patterns[END_REF]. If areas of interest are available, transition matrices( [START_REF] Ponsoda | A probability vector and transition matrix analysis of eye movements during visual search[END_REF], [START_REF] Goldberg | Computer interface evaluation using eye movements: methods and constructs[END_REF]) or string editing algorithms can be used ( [START_REF] Privitera | Algorithms for Defining Visual Regions-of-Interest: Comparison with Eye Fixations[END_REF], [START_REF] Duchowski | Scanpath comparison revisited[END_REF], [START_REF] Heminghous | iComp: a tool for scanpath visualization and comparison[END_REF]). A relatively new approach is presented by Andrienko et al. [START_REF] Andrienko | Visual Analytics Methodology for Eye Movement Studies[END_REF]. In their work, the authors discuss the application of visual analytics techniques for the analysis of recorded eye movement data. As a follow-up work, Burch et al. demonstrate how visual analytics techniques can be used to analyze an eye tracking experiment [START_REF] Burch | Visual Task Solution Strategies in Tree Diagrams[END_REF].

One example of an eye tracking study in visualization research is the comparison of different types of graph layouts such as radial, orthogonal, and traditional by Burch et al. which will later be used in this paper for a demonstration of our approach [START_REF] Burch | Evaluation of Traditional, Orthogonal, and Radial Tree Diagrams by an Eye Tracking Study[END_REF]. Another example is the eye tracking experiment by Huang et al. Their results show that graphs are read following a geodesic-path tendency. As a result, links which go towards the target node are more likely to be searched first [START_REF] Huang | A graph reading behavior: Geodesic-path tendency[END_REF]. Another experiment by Kim et al. investigates the influence of peripheral vision during the perception of visualizations [START_REF] Sung-Hee | Does an Eye Tracker Tell the Truth about Visualizations?: Findings while Investigating Visualizations for Decision Making[END_REF].

However, fundamental questions of using eye tracking to test the cognitive ergonomics of visualizations remain. The most important issue about using eye tracking techniques to measure cognitive ergonomics is the question, if the recorded eye movements reflect mental processes, what often is called the "Eye-Mind Hypothesis"? We think, that this question cannot be answered with a definite "yes" or "no", and refer to the literature [START_REF] Just | A theory of reading: from eye fixations to comprehension[END_REF], [START_REF] Anderson | Eye Movements Do Not Reflect Retrieval Processes[END_REF]. Our opinion is, that the answer depends on the complexity of the visualization, the visual task and the required mental processes. Another relevant point for visual analysis of eye tracking data is, that scan paths can have completely different shapes for different participants performing the same task. The question of how these different eye movement patterns could be compared with each other is still not sufficiently answered. However, we think that new visualization techniques for eye tracking data can bring benefit to scan path comparison.

In the following sub chapters, we will analyze the structure of eye tracking data from the information visualization pipeline perspective to motivate the reader to develop further visualization techniques. In a second sub chapter we will present the parallel scan path visualization technique as a result of this analysis.

New Visualization Techniques for Eye Tracking Data

The visualization pipeline defines four steps for deriving a graphical representation from raw data. In the original work of Naber and McNabb these four steps are: data analysis, filtering, mapping, and rendering [START_REF] Haber | Visualization idioms: A conceptual model for scientic visualization systems[END_REF]. In the following, we will formulate a concept for developing new visualization techniques for visual eye tracking data analysis.

Step 1: Analysis of Eye Tracking Data Current eye tracking software systems generate large amounts of data representing the output of eye tracker sensors. The most important types of the data sets are: various types of timestamps, fixation point information for left/right/both eye(s), pupil size for left and right eye, software meta data.

Step 2: Filtering The raw data is filtered depending on research questions which will be answered using the new visualization technique. Usually, usability researchers are interested in: timestamp of a fixation, fixation coordinates on the screen, and validity of this fixation. Handling a large number of fixations can be impractical. To alleviate this effect, areas of interest (AOI) can be defined to group fixations. Step 3: Mapping The data selection from step two has to be mapped to geometrical shapes. At first, we have to choose a visualization concept. Even though it seems to be too simple, we can visualize eye tracking data with one dimension using a number line. In this visualization scenario one number line could represent the temporal characteristics of this data. If we want to visualize more information about participants' eye movements on a screen, two dimensional diagrams can be used. For example, heat map and scan path visualizations use Cartesian coordinate systems to display the positions of the eye movement elements. We can get inspirations from visualization collections like http://www.visualcomplexity.com or http://infosthetics.com/ to find an adequate visualization technique.

Besides geometrical dimensions of visualizations, colors can indicate additional characteristic of the eye tracking data. Scan paths from different participants can be distinguished using a color table, or can be colored differently when intersecting with areas of interest. Alternatively, interesting characteristics of the eye movements, like high eye movement frequencies, can be displayed using color gradients. Other data dimensions can be mapped to different types of symbols.

Step 4: Rendering Finally, the filtered and mapped data is rendered to the screen. Thereby, existing rendering libraries for information visualizations can be used.

Parallel Scan Path Visualization (PSP)

As a result of our analysis we have developed the parallel scan path visualization (PSP) technique [START_REF] Raschke | Parallel Scan-Path Visualization[END_REF]. This visualization uses areas of interest. It maps gaze durations and fixations to vertical axes. The top left picture of Figure 4 Key feature of the parallel scan path visualization (PSP) is the visualization of eye movements of many participants in a single visualization with a parallel layout containing various levels of detail, such as fixations, gaze durations, eye shift frequencies, and time.

Figure 4 top right shows an example stimulus together with AOIs of an experiment where participants had to answer the question "Why is the road wet?". Figure 4 bottom left shows one fixation sequence using the parallel scan-path visualization, Figure 4 bottom right the traditional scan path visualization of the same fixation sequence. A fixation sequence could be to first focus on the road (1), then on the puddle (2), on the cloud (3), on the sun (4, and on the fire hydrant [START_REF] Ponsoda | A probability vector and transition matrix analysis of eye movements during visual search[END_REF]. Finally, the attention would move to the puddle again [START_REF] Goldberg | Computer interface evaluation using eye movements: methods and constructs[END_REF]. Using the PSP visualization changes of participant's attention can be studied by following the fixation sequence line in the visualization.

Ontology Based Visualization Models

Visualizations often don't have a unique meaning. They can be interpreted differently by several viewers due to different start conditions of their interpretation, such as cultural or intellectual differences. Also a different context of use can lead to different interpretations of the information which is represented graphically. To avoid these misunderstandings this chapter describes a method to annotate visualizations and their graphical elements with semantic information 1 . We annotate visualizations on two levels: the visualization concept level and the graphical elements. Every graphical element represents a piece of graphically encoded information. We propose to link every graphical element with a semantic web resource. This concept will allow viewers to customize their visualizations and thus, to close the user viewer gap discussed by Norman [START_REF] Norman | Some observations on mental models[END_REF].

Graphical representations often don't have a unique meaning. This chapter describes a method to avoid these misunderstandings. Therefore, we propose to annotate visualizations on the visualization concept level and on the graphical elements level. Finally, we will show how this annotation will allow users to individually optimize their visualizations.

Our literature research has shown that one of the most applications of annotated visualizations is to better find graphical elements inside a visualization [START_REF] Ferecatu | Semantic interactive image retrieval combining visual and conceptual content description[END_REF]. Only few approaches deal with the question how semantic annotations can improve the understanding of visualized information. For example, Janeck and Pu show how annotations can be used to find related information about the presented graphics [START_REF] Janecek | Searching with Semantics: An Interactive Visualization Technique for Exploring an Annotated Image Collection[END_REF]. Other approaches use annotations to allow a semantic filtering [START_REF] Kalogerakis | Coupling ontologies with graphics content for Knowledge Driven Visualization[END_REF] or an intelligent zooming [START_REF] Patel | Knowledge-assisted visualization of seismic data[END_REF].

User Viewer Gap

Norman has described how the designer of a visualization transfers information into a graphical form for the viewer (cf. Figure 5) [START_REF] Norman | Some observations on mental models[END_REF]. The designer creates a design model of the visualization. The user conveys a user model from the visualization. This user model is based on the interpretation of the graphical elements, their shapes, colors, and spatial relations. In an ideal case the design model is equivalent to the user model. The designer can achieve this equivalence by paying attention to the task, requirements of the visualization, and by adapting the visualization to the user's skills. A user viewer gap emerges from a deviation from the two mental models of the designer and the viewer. This leads to a misunderstanding of the visualized information.

Interaction Model for a User Centered Visualization Optimization

We propose to use resources from domain ontologies, and resources from graphical ontologies of the semantic web for the semantic annotation of the visualization concept, and the graphical elements. The designer as well as the viewer both use semantic web resources for the user centered optimization. The annotation with domain ontological information describes the meaning of the graphical elements. References to graphical ontologies define the restrictions and dependencies of the properties of graphical elements, and of the visualization concept. Graphical ontologies allow the designer and the viewer to find alternative graphical elements with the same meaning which can replace an existing graphical element in a visualization. The interaction model is divided into two parts, one for the visualization designer and one for the visualization viewer.

Visualization Designer:

The visualization designer annotates both graphical elements and the visualization concept with resources from domain ontologies and resources from graphic ontologies (cf. Figure 6 left side). Every graphical element is assigned one or more URIs (Unified Resource Identifier).

Visualization Viewer:

The visualization viewer can explore the visualization using the assigned annotations (cf. Figure 6 right side). The viewer can replace graphical elements or change the visualization concept. Dependencies and restrictions of the ontologies guarantee a simultaneous persistence of the meaning of the visualization and its graphical elements.

Future Questions

The annotation concept seems to be very simple and useful. However, we identified the following questions for future work during the implementation of our prototype that are crucial for a successful implementation of the concept:

-As described in section 1.1 the visualization process can systematically be divided up into several steps. The last step of every visualization presentation is the rendering step. Thereby, the rendering is always based on parameters such as the geometrical layout, shapes, and colors from the steps before. These parameters are defined by the visualization designer. During the implementation we asked ourself how a renderer which is based on semantic information could look like? What are important input parameters from the semantic models to the renderer algorithms? How can a visualization layout be described in a semantic model? -We developed a WIMP (Windows, Icons, Menus and Pointer) prototype, where different visualization concepts and graphical elements could be chosen via pull down menus. Due to that, the prototype provided a very simple interaction concept, the question remains how more powerful HCI concepts can be used to improve the user center optimization of visualizations?

-One important drawback of our ontology based concept is, that there does not exist a well defined comprehensive ontology for visualizations and their graphical elements. How could an ontology look like? What are important semantic elements of a visualization? What are their relations? One starting point could be the VISO ontology [25]. -And finally, what are other possible applications of semantic annotated visualizations?

Cognitive Simulations

Cognitive simulation frameworks provide a promising simulation technique to study formalized cognitive processes during the perception of visualizations. In general, cognitive scientist who are using cognitive simulations aim at using results of psychological experiments to develop models for mental processes which are processes by these simulation frameworks. Cognitive simulations are used to model a wide field of human behavior from problem solving, planning, learning, knowledge representation over natural language processing, perception, expert systems, psychological modeling, to robotics, and human computer interaction. This section motivates using the simulation framework ACT-R in visualization research to model visual search, and the perception of graphics. This section concludes with a brief presentation of results from the successful application of ACT-R in the HCI simulation tool CogTool.

This section presents the basic concept of the cognition simulation framework ACT-R and motivates for using this framework to study aspects of cognitive ergonomics in visualization.

Brief Introduction to the Adaptive Control of Thought-Rational Simulation Framework (ACT-R)

ACT-R is a modular cognitive architecture, using a production system to operate on symbolic representations of declarative memory1 [START_REF] Anderson | The atomic components thought[END_REF]. In its core the ACT-R system comes with a visual module for the identification of objects in the visual field, a manual module for hand control, a declarative module for retrieving information from the memory, and an intentional module for the current action goals and intentions. All modules are coordinated through a central production system, which can respond to a limited amount of information in the buffers of the visual, manual, declarative, or goal module. This central production system can recognize patterns in these buffers, and make changes to theses buffers. The buffers form one of the fundamental parts of the ACT-R framework, and are noted to cortical regions.

The ACT-R architecture divides knowledge up into two categories: declarative knowledge and procedural knowledge. The declarative knowledge represents factual knowledge. For example, declarative knowledge describes what the parts of a bicycle are. Declarative knowledge is processed with so called chunks. The procedural knowledge describes actions, for example how parts of a bicycle have to be used in order to drive it. Procedural knowledge is describe by production rules. Pattern matching algorithms allow the production system to find appropriate production rules for declarative knowledge chunks in the retrieval buffer considering a given goal in the goal buffer.

The framework is mainly written in a LISP dialect, and uses several modules which represent different brain areas. The modules are connected via buffers. Information between the modules is exchanged trough these buffers. ACT-R uses several metrics to measure cognitive activities. These metrics allow the comparison of the simulation results with results from psychological experiments or fMRI images. A comfortable graphical user interface allows to set up all simulation parameters, and to view the simulation results.

Additional to the built-in visual module of ACT-R Salvucci et al. have developed the "Eye Movements and Movement of Attention" (EMMA) module [START_REF] Salvucci | A model of eye movements and visual attention[END_REF]. This ACT-R module is used to calculate fixation positions during processing a visual search task. EMMA extends the built-in visual module by taking into account effects of fixation frequencies and foveal eccentricity when encoding visual objects. EMMA can predict timings and positions of when and where eyes move, and hence serves to relate high-level cognitive processes with low-level eye movement behavior.

CogTool -Simulation of Human Computer Interaction

Besides the application to model basic intelligent capabilities, cognitive simulation frameworks are used as a basis to model human computer interaction. One example of a tool which models human computer interaction processes is Cog-Tool2 which is based on ACT-R [START_REF] John | Predictive human performance modeling made easy[END_REF]. CogTool provides a framework to design user interface prototypes, and to test their usability. Thereby, CogTool models the execution of prescribed human computer interaction steps, and presents simulation detail results such as timings for vision processes, eye movements, cognition, and manual actions such as hand movements (cf. Figure 7).

CogTool describes the graphical user interface of applications by frames which are views of an application (this could be a dialog or a complete window). Changes between different frames are called transitions which describe interactions leading to a transition. Standard transitions are keystrokes or mouse actions. Therefore, CogTool uses an enhanced keystroke level model (KLM) [START_REF] Card | The keystroke-level model for user performance time with interactive systems[END_REF]. Perception and visual search is modeled via EMMA. CogTool provides operators for eye movement preparation, eye movement execution, vision encoding, system wait, cognition, key presses, cursor moves, mouse clicks, and simple hand movements. These operators are lined up in parallel. For example, the user can move the mouse and can think in parallel. The computation of the duration times of the single operators is done via ACT-R. Thus, duration times are not fix like in the KLM model. They can be different depending on their point in time during the interaction process.

Bringing Everything Together -Roadmap to Study Cognitive Ergonomics of Visualization

In contrast to HCI, modeling of visual search strategies is not yet a widespread tool for evaluating visualization with respect to their cognitive ergonomics. Analogue to arguments in HCI research by John et al. [START_REF] John | Predictive human performance modeling made easy[END_REF], we believe that the cost of constructing models of visual tasks, even simple ones, is perceived to be too high to justify the advantages of modeling visualization tasks. We think that by combining results from eye tracking data analysis, semantic models, and cognitive simulation frameworks the cost of constructing cognitive models and running simulations of visualization perception can be reduced.

Once valid models are available the overall effort for conducting user experiments can be reduced by running simulated pre-studies. To reach this goal, we propose to develop a simulation tool similar to CogTool in visualization research. Figure 8 shows a sketch of how the three presented topics can be combined. Eye tracking is used to analyze scan paths from user studies. This analysis is done both with respect to the fixation distribution on the screen (WHERE space) and with respect to the semantic structure of the scan paths (WHAT space). The analysis in both spaces leads to results in two different directions: first, time durations of different visual tasks, and common visual search strategy patterns of participants; second, a model for knowledge processing of visual elements by the temporal order of focused semantic entities, their relations, and meanings. Based on these two results, ACT-R or other cognition simulation frameworks can be used to simulate cognitive and perceptual processes that lead to visual search strategies.

We propose to use results of eye tracking experiments in the WHERE and WHAT space to formulate cognitive models for simulating visual search strategies. These simulations will lead to a better understanding of visualization parameters leading to optimize cognitive ergonomics of visualizations.

We conclude this chapter with the following remarks and questions formulating a road map to study parameters of cognitive ergonomics in visualization:

1. Most visualization techniques as well as the parallel scan path visualization technique allow to analyze eye movements in the WHERE space; they graphically represent participants' scan paths on the screen. We proposed to annotate graphical elements of a visualization with semantic information. Using this annotation the "WHAT" space of scan paths can be studied. 2. To study the WHAT space, a sufficient visualization technique of semantic attention, and declarative knowledge processing has to be developed. 3. We proposed to use results from eye tracking experiments in the WHAT and WHERE space to formulate both a cognitive model of visualization perception, and to simulate visual search strategies. How could such a model look like? What are the development strategies for such as model? Would it be based on a KLM approach with operators [START_REF] Card | The keystroke-level model for user performance time with interactive systems[END_REF] or on a declarative knowledge processing simulation? Would it be possible to combine both approaches? 4. And finally, will it become possible to formulate a unified theory of cognition in the domain of visualization based on tasks as proposed by Newell [START_REF] Newell | Unified Theories of Cognition[END_REF]?

Fig. 1 .

 1 Fig. 1. This chapter presents an interdisciplinary approach to study cognitive ergonomics in visualization based on eye tracking data visualization, ontology based visualization models, and cognitive simulations.

Fig. 2 .

 2 Fig. 2. Most prominent visualization techniques for eye tracking data: Heat maps are time aggregated density based representations (left), scan paths are line based visualizations.

Fig. 3 .

 3 Fig. 3. The visualization pipeline defines four steps for deriving a graphical representation from raw data. We applied the model of the visualization pipeline on eye tracking data to systematically develop our parallel scan path visualization technique.

  shows a sketch of the PSP visualization, where three areas of interest are defined and are mapped to three vertical coordinate axes. The leftmost axis indicates time, starting from the bottom of the diagram with the start time of the eye tracking recording. The orientation of the parallel scan path visualization is arbitrary. In the following we use a vertical time axis from bottom (start of the eye tracking recording) to top (end of the eye tracking recording) as introduced in the original work. The horizontal axis displays all selected areas of interest as in-dependent values. Saccades between areas of interest are indicated with dashed lines. Ascending lines indicate fixations outside given areas of interest.

Fig. 4 .

 4 Fig. 4. The PSP visualization maps fixation durations inside areas of interest and single fixations to vertical axes (top left). The leftmost vertical axis indicates time. Thereby, areas of interest (top right) are mapped to vertical coordinate axes in the diagram (bottom left). The corresponding traditional scan path visualization is shown at bottom right. Both the PSP visualization and the traditional scan path visualization show an exemplary scan path for the question "Why is the road wet?".

Fig. 5 .

 5 Fig. 5. Different mental models from the visualization designer, and the visualization viewer can lead to misunderstandings of the visualized information.

Fig. 6 .

 6 Fig. 6. We propose to annotated visualizations on two levels: the visualization concept level (left) and the graphical elements level (right).

Fig. 7 .

 7 Fig. 7. CogTool visualizes interaction tasks in a time line diagram. Each row of the time line diagram represents a category of perceptual, cognitive, or motor activity such as vision, eye movement preparation, eye movement execution, cognition, and motor activities of the hands.

Fig. 8 .

 8 Fig. 8. We propose to use results of eye tracking experiments in the WHERE and WHAT space to formulate cognitive models for simulating visual search strategies.

We firstly presented this concept during the workshop "Interaktion und Visualisierung im Daten-Web (

IVDW 2011)" (Interaction with and Visualization of Data in the Semantic Web) at the Informatik 2011 conference[START_REF] Raschke | Interaktive verständnisorientierte Optimierung von semantisch-annotierten Visualisierungen[END_REF].

ACT-R is available at http://act-r.psy.cmu.edu/ together with a large number of articles, conference papers, examples, and the programming documentation.

CogTool is an open source project released under LGPL. Executables, documentary, examples, and source code is available at: http://cogtool.hcii.cs.cmu.edu/.

Acknowledgements

We would like to thank our students for their contribution: Tanja Agapkin, Christoph Bergmann, Xuemei Chen, Alex Duscheck, Christian Dittrich, Tobias Eikmeier, Stephan Engelhardt, Dominik Herr, Paul Hummel, Michael Kircher, Andreas Neupert, Hannes Pfannkuch, Sven Plohmer, Nico Ploner, Edwin Püttman, Oliver Schmidtmer, and Stefan Strohmaier (in alphabetical order).


Gerrit C Van Der Veer¹

Dhaval Vyas²

Non-formal Techniques for Early Assessment of Design Ideas for Services

Designing systems for multiple stakeholders requires frequent collaboration with multiple stakeholders from the start. In many cases at least some stakeholders lack a professional habit of formal modeling. We report observations from student design teams as well as two case studies, respectively of a prototype for supporting creative communication to design objects, and of stakeholder-involvement in early design. In all observations and case studies we found that non-formal techniques supported strong collaboration resulting in deep understanding of early design ideas, of their value and of the feasibility of solutions.

In early stages of user centered design flexibility is required

In user centered product design a strong tradition exists of starting from a task model, subsequently developing a detailed design model (often structured along functionality, dialogue, and representation), model based prototyping and evaluation, ending in formal specifications [START_REF] Van Welie | Groupware Task Analysis[END_REF].

However, since increasingly design efforts focus on services (i.e., opportunities which often will be new including the context of use), the stakeholders of the new service are unable to precisely formulate and formalize their needs, ideas, and the context of the envisioned service [START_REF] Vyas | Remarkable Objects: Supporting Collaboration in a Creative Environment[END_REF]. Sommerville [START_REF] Sommerville | Integrated Requirements Engineering: a Tutorial[END_REF] points to the need of flexible requirements elicitation techniques, both for single user type situations in the phase of feasibility study, and for the current service context: stakeholders often do not know what they need, do not agree, and requirements change during the analysis.

Sommerville's elicitation techniques are viewpoint oriented, but the problem is how to identify future viewpoints. Stakeholders most of the time are not able to be explicit on what they need in relation to a new system that will change the context of use. Moreover, stakeholders often have different roles that result in different points of view on the requirements for a new system. And as soon as the concepts of a new system develop requirements change.

Ethnography alone does not work since any design aims at a new system that will be different from the existing system and which will change the structure of the related community of practice. In addition, we need to consider that not only the requirements but also the context will change through putting the novel services in practice. An obvious solution is the use of scenarios to envision, in collaboration with the stakeholders, how a new system may be used in practice.

Designers use their professional expertise to apply it on the domain they are designing for. Designers need tools and a design environment, in order to implement their design decisions. If these are not available, designers have to invest in additional types of expertise, or they have to cope with a suboptimal context. And all the time they need to communicate, with their colleagues in a design team and with stakeholders. Visualizing design ideas often is a main challenge. Keeping track of ideas, both for the individual designer and for the team, is another. Finally, when communicating with stakeholders, these need to be supported to understand, as well as to contribute their own ideas too.

That is what the last section of this paper is about. IT supported services are new, and in many cases are meant to be new, stakeholders will only have vague ideas if at all, and mostly have no clue about other stakeholders, about differences in context and culture, nor about relevant functionality and opportunities. The traditional and well grounded tools and techniques are not sufficient for this emerging domain of design.

We will illustrate our observations and emerging approach by providing illustrations from ethnographic studies of design practice in academic design contexts, after which we will discuss two case studies in design education where we were able to introduce some new elements in the situation and to observe and analyze (again, in an ethnographic way) the outcomes, featuring: (1) co-design merging ethnography with rough prototyping; and (2) bootstrapping service design techniques in collaboration with stakeholders.

Ethnographic impressions of student design practices

We will first illustrate some observations from a series of ethnographic studies reported in [START_REF] Vyas | Collaborative Practices that Support Creativity in Design[END_REF] that triggered our interventions in the case studies that will be discussed below. We had the opportunity to observe work in progress in several industrial design studios in polytechnics and to follow projects of design students. Observations in sections 1-4 are from two different Industrial Design Departments in Dutch Polytechnics (in total 6 teams of 3-5 students).

These students worked in teams, as was required by their supervisors, and as seems standard in current industrial design practice. Their teachers did not stress specific design methods or the use of specific tools and techniques. In almost all cases it was the final design and the story told with it that was subject to assessment, quite similar to what clients of design tend to look for.

Our focus was on the process, on the techniques and tools applied and on the artifacts and representations created and used during the process. We detected several phenomena that seem "natural" for (student) design studios, which we like to share:

Exploration utilizes multiple media and multiple types of behavior.

Students talk, gesture, sketch, and scribble (sometimes most of these at the same time, see figures 1 and 2).

The environment will be dressed to support

Our designers develop a creative ecology that they need to get inspired. To a certain extend this is personal and kept kind of private (figure 3), but there seem a strong need for a shared environment developed and used as a team (figure 4). These environments are for "just be inspired", (figure 5) or to create artifacts like personas to share understanding (figure 6), and they join each other in adding annotations. Ongoing projects required shared awareness of what has been considered (figure 7 and8). The physical space is used to develop structure, to compare and understand development, and to develop and share visions and concepts.

Communication may develop into impromptu performances

On several occasions we identified communications that went far beyond single gestures, where a performance was staged to communicate the meaning of concepts or interaction with artifacts (figures 9 and 10).

Two case studies

In the case studies reported next, we tried to support the design process, by on purpose providing a simple prototype concept that might physically as well as conceptually enrich the design ecology (case study 1) or by pointing to tools and techniques that in fact are supposed to trigger enrichment of the design ecology (case study 2). Case study 1 (section 5) was performed in a Design faculty in a German University, including 3 design teams of 4 students each. Case study 2 in section 5 was performed in an Italian University in the Faculty of Architecture and Design, with 5 teams of 3-4 students. In both cases, we never mentioned or hinted at the actual phenomena that we just discussed, we just provided a simple tool, or we just suggested our design students to consider the various tools for their design projects.

Case study 1: from ethnography to prototype use

Team work is characteristic for industrial design. Teams are often multidisciplinary. Collaboration on design is often not a purely verbal activity. State of the art ICT seems to provide intriguing tools for motivated teams. Based on our prior ethnographic work in design studios and with student design teams [START_REF] Vyas | Collaborative Practices that Support Creativity in Design[END_REF], we developed a simple tool, CAM (Figure 16, from [START_REF] Vyas | Remarkable Objects: Supporting Collaboration in a Creative Environment[END_REF]).

Figure16. Architecture of CAM CAM stands for "cooperative artifact memory". It is in fact a prototype that currently runs on an iPhone. Cam uses 2D barcodes that can be stuck to any physical object, whether 2D (e.g., anything on paper) or 3D (e.g. mockups and physical prototypes). See Figures 17 and18 where design team members decided to tag their design artifacts. The iPhone can be aimed at a tagged object and the barcode will be read. Each tagged object has its own digital profile on the internet, associated with a twitter account. A JAVA web server has been developed to communicate through a Twitter API, to add information to any tagged object by sending a tweet to them (figure 19), and to read the tweet log of each object (figure 20). Another surprising way of using CAM was the opportunity to express emotions and aesthetics: e.g., a sketch for a night lamp triggered several "poems" by different "authors" (originally in German, figure 24).

Figure 24. Two short poems tweeted to a tagged sketch In general, the tryout of CAM learned us that non-formal contributions to design were appreciated and we consider this a potential support for collaboration and shared creativity. Discovering new opportunities and functionality just "happened", though the tool seemed to systematically trigger certain new types of functionality in the design ecology, including abstract reference objects, and a stage for esthetical and emotional creations and performances.

Case study 2: bootstrapping service design techniques

When developing a brand new course on service design, there were no course books available, and only a single repository for techniques [START_REF] Tassi | Servicedesigntools[END_REF]. Our students, worked in design team for real clients to develop services with many different types of stakeholders outside the clients' business with clearly different corporate and geographical cultures (e.g., in tourism industry).

We pointed the students to Tassi's repository as well as to Hofstede and Hofstede's website [START_REF] Hofstede | [END_REF] and to the Cultural Survival Kit [1], as well as to design documents from the UK Government and to our visual design pattern wizard [START_REF] Moel | Design pattern based decision support[END_REF]. We additionally introduced them to the design approach by Tassi [START_REF] Tassi | Servicedesigntools[END_REF].

We asked our students to study these sources and to teach each other the different techniques and tools. During the design process we challenged them to decide for each phase which of the tools and techniques offered were relevant. The students' progressing projects showed how the various different non-formal techniques were applied to a co-design approach where different types of stakeholders (e.g., hotel owners, tourist information providers, and visitors; see Figure 25) collaborated in generating ideas, e.g., group sketching. We also found non-formal techniques being applied for assessing concepts before any services were actually implemented, like rough prototyping with 3D mock ups (figure 26), unpredicted initiatives that were accepted and actually supported by the stakeholders.

Conclusions

Based on previous ethnographic studies we identified several phenomena of nonformal techniques applied in the early design phases of requirements elicitation, modeling and early assessment: the use of multiple types of communication, the relevance of design ecology, the possibility for impromptu creativity and performance, the use of physical space and the physicality of collaboration. In two case studies with design students we provided two different potential supports for these phenomena, resp. a prototype system CAM to allow communication through design artifacts, and a set of techniques and tools that might be considered at will and taught by the design students to their peers.

The resulting design processes showed how these interventions spontaneously led to the students' choice of applying these facilities to support or create some of the afore mentioned phenomena.

We did not prove these interventions are the sole cause of the effects observed, but they certainly seem to help in providing a design ecology where the phenomena develop in a natural way, where students as well as stakeholders dare to embark on creative and multimodal behavior, communicate and collaborate on design meaning and create and maintain awareness of the process.

Our observations and case studies concerned University design student teams in several European countries (The Netherlands, Germany, Italy). Because we have experienced teaching Design in several other European countries (Spain, Romania, Belgium) we dare expect the phenomena we observed during ethnography and case studies) are typical for European student design teams. We are currently teaching design in a University in China, which will be an opportunity to validate our understanding for a rather different cultural context. Still, we should also validate our analysis for design outside of the University situation. Ethnographic observations, as well as case studies in industrial design practice will have to be a next step.

Figure 1 .

 1 Figure 1. Communication through a complex of channels

Figure 2 .

 2 Figure 2. Communication using artifacts and gestures

Figure 3 .

 3 Figure 3. Private work environment; Figure 4. Shared team design environment

Figure 5 .

 5 Figure 5. Elements in the environment considered to inspire

Figure 6 .

 6 Figure 6. Personas to share understanding, with annotations added by team members

Figure 7 and 8 .

 8 Figure 7 and 8. Poster boards created to maintain shared awareness

Figures 9

 9 Figures 9 and 10. Spontaneously developed performances to communicate meaning

Figure 11 ,

 11 Figure 11, 12, 13. Physical space used create structure; to understand development; and to share inspiration

Figure 14

 14 Figure 14 and 15. Collaborative physical activities to develop shared understanding

Figure 17 -

 17 Figure 17-20. Tagged mock-up and sketch; tweeting information to a tagged object;and reading the tweet log of a tagged object.

Figure 25 .

 25 Figure 25. Co-design with stakeholders

Figure 26. 3 -

 3 Figure 26. 3-D mock up (rough prototype) presented to, and discussed with, various different stakeholders .In two case studies with design students we provided two different potential supports for these phenomena, resp. a prototype system CAM to allow communication through design artifacts, and a set of techniques and tools that might be considered at will and taught by the design students to their peers.The resulting design processes showed how these interventions spontaneously led to the students' choice of applying these facilities to support or create some of the afore mentioned phenomena.We did not prove these interventions are the sole cause of the effects observed, but they certainly seem to help in providing a design ecology where the phenomena develop in a natural way, where students as well as stakeholders dare to embark on creative and multimodal behavior, communicate and collaborate on design meaning and create and maintain awareness of the process.Our observations and case studies concerned University design student teams in several European countries (The Netherlands, Germany, Italy). Because we have experienced teaching Design in several other European countries (Spain, Romania, Belgium) we dare expect the phenomena we observed during ethnography and case studies) are typical for European student design teams. We are currently teaching design in a University in China, which will be an opportunity to validate our understanding for a rather different cultural context. Still, we should also validate our analysis for design outside of the University situation. Ethnographic observations, as well as case studies in industrial design practice will have to be a next step.

We found three different teams of design students not only tagged and communicated to (a) 3-D mock-ups; (b) sketches, textual descriptions on paper, and combinations of these; but also (c) abstract references, like an empty sheet of paper only marked with, e.g., "vote on this", or "Planning" (figures 21 and 22). Subsequently these spontaneously created tagged objects became related to a history of tweets on votes and opinions about a proposed design decision, resp., a history of tweets regarding a planned process and its actual deviations and updates (figure 23).


Brigit Van Loggem

Gerrit Van Der Veer

A Documentation-Centred Approach to Software Design, Development and Deployment

In this paper, we argue how a documentation-centred approach to systems design and development could provide the different roles involved in this activity with a common ground. A large heterogeneous development team can be seen as a Community of Interest, consisting of individuals brought together from different Communities of Practice. Each group brings to the CoI not only their own skills and experience but also their own values, mental models, working practices, and communication styles. Re-shaping documentation into a boundary object offers a solution to the dual problems of (1) heterogeneous mental models within a software development team and (2) the user support role being peripheral to the team. Documentation that evolves dynamically, changing shape as the development process proceeds, can support communication both internally (between members of a software development team) and externally (between developers and end users).

Keywords. Documentation, systems development, communities of practice, communities of interest, boundary objects, shared mental models.

backgrounds. In order to work together towards a common goal, they must reconcile their different views on the system that they are building: a process that is not without difficulty. We then look at how the creation of user documentation such as manuals and online Help fits in with the overall development efforts, noting that this process is not without difficulty either. In the second section of this paper, we investigate how the notion of "boundary objects" may be applied to begin solving both areas of difficulty at the same time, and conclude by mentioning some of the challenges involved in implementing such an approach.

2

Co-operation and information exchange in large software development teams

.

A quick and by no means exhaustive inventory of a number of IT-related job sites on the Internet conducted on 19 July 2012 revealed that it is no longer sufficient to open a can of programmers to have a software system built. Software engineering calls for project teams to be formed which may include not only programmers but analysts, application administrators, application programmers, application specialists, business analysts, business architects, documentation analysts, enterprise-wide information specialists, HCI designers, information architects, internet engineers, IT consultants, multimedia architects, network designers, network engineers, operations analysts, product specialists, requirements analysts, software analysts, software architects, software engineers, software test specialists, solutions specialists, support analysts, system administrators, systems developers, systems analysts, systems engineers, technical authors, technical consultants, technical designers, technical support engineers, test engineers, testers, trainers, usability designers, usability engineers, web designers, web developers, web producers and many, many more. All these bring to the work their own skill set, which may be any combination of some 75-100 skills directly related to software development 1 .

Introduction

In software design, documentation is an object of neglect. While recognized as one of the deliverables of a software engineering project, very little of it is created with any degree of enthusiasm. User documentation is routinely shrugged off as "there mainly to make up for bad interaction design" and "never read, anyhow" [START_REF] Mehlenbacher | Documentation: not yet implemented, but coming soon[END_REF][START_REF] Van Loggem | User Documentation: The Cinderella of Information Systems[END_REF]; and systems documentation is seen as a necessary evil that developers prefer to avoid.

Yet forms of communication other than documentation are engaged in without complaint. In this paper, we highlight the core characteristic of documentation as a form of communication. We propose a documentation-centred approach to organizing the work in software development teams. This approach allows for documentation to do what it is best at, which is supporting communication: internally (between members of a software development team) as well as externally (between developers and end users).

First, we discuss a number of issues related to large heterogeneous development teams, noting how these consist of individuals brought together from different This list does inevitably contain synonyms; especially as there exists no generallyaccepted taxonomy of IT-related professions. In an attempt to steer clear of the bewildering array of job titles, we have opted to highlight the widely divergent backgrounds, interests, and skills represented in software development teams by distinguishing the following roles, each responsible for a different aspect of the to-bebuilt system: -Functional analysts (FA). These are responsible for eliciting requirements and defining a functional specification of the system. -System architects (SA). Based on the functional specification delivered by the analysts, the architects are responsible for defining a technical specification of the system. -Interaction designers (ID). These are responsible for the usability of the system.

-Software programmers (SP). Based on the technical specification delivered by the architects, the programmers are responsible for writing the code. -User support (US). These are responsible for supporting the end users of the system after it has been built, through user manuals and Help systems. This simple description of a software development team is, of course, a gross oversimplification. It does, however, have the virtue of allowing us to acknowledge and discuss fundamental differences within such teams, without losing ourselves in subtle detail that is not pertinent to the line of our argument.

Communities of Practice and Communities of Interest

The different roles within a software development team are set off from one another not just by having different responsibilities and different skill sets, but also by belonging to different "Communities of Practice". A Community of Practice or CoP is made up of "practitioners who work as a community in a certain domain doing similar work" [START_REF] Arias | Boundary objects: Their role in articulating the task at hand and making information relevant to it[END_REF]. Any particular CoP has its own standards, values, and ways of doing things. Members of a particular CoP join that CoP's professional organization; read that CoP's professional literature; and learn "on the job" what is "relevant" and what is not. FA sees the to-be-built system in terms of its alignment to business requirements. SA sees it as an intricate construction of interrelated components. ID is involved with the user interface of the system, while SP's interest is with the way the system consists of blocks of code. US, finally, is set apart even further by focusing on a mental construct, known as the "User Virtual Machine" or UVM; which is defined as "not only everything that a user can perceive or experience (as far as it has a meaning), but also aspects of internal structure and processes as far as the user should be aware of them" [START_REF] Van Der Veer | The Human-Computer Interface is the System: A Plea for a Poor Man's HCI Component in Software Engineering Curricula[END_REF]. The visible part of the UVM is what these authors refer to as the "perceptual interface" and what is more commonly referred to as the user interface (created by ID); but the UVM as a whole is a much larger conceptual machine that presents itself to the end user.

These different views on the to-be-built system become entrenched over time. Within each CoP, sustained engagement and collaboration leads to boundaries, based on a shared history of learning which is set off against that of other CoPs [START_REF] Wenger | Communities of Practice: Learning, Meaning, and Identity[END_REF]. Knowledge remains localized, embedded, and invested in practice, so that it is difficult to share with outsiders [START_REF] Carlile | A pragmatic view of knowledge and boundaries: Boundary objects in new product development[END_REF].

When members of multiple CoPs are joined together in a team, with a view to jointly realize a particular well-defined result, they are said to form a Community of Interest or CoI. This is defined as a group of people "from different backgrounds coming together to solve a particular (design) problem of common concern" [START_REF] Arias | Boundary objects: Their role in articulating the task at hand and making information relevant to it[END_REF]. A software development team is such a CoI. The members of the CoI that is a development team bring to the efforts their own ideas as to what the system is about and how it works. They have different mental models of the system.

Mental models

Although "mental model" is a term traditionally reserved for the understanding that a user constructs of a software artefact during the process of applying it to real-world tasks over a period of time, lately it has been extended [e.g. [START_REF] Latoza | Maintaining mental models: a study of developer work habits[END_REF][START_REF] Levesque | Cognitive divergence and shared mental models in software development project teams[END_REF]. By removing the condition of application to a real-world task from the definition, a user becomes any human actor who interacts with a software system over a period of time. Interaction then includes the interaction involved in the construction of the system.

It is not our intention to provide a complete review of the mental models literature. For a wide-ranging and multi-disciplinary overview of mental model theories and their various applications, see [START_REF]Models in the Mind: Theory, Perspective and Application[END_REF]. An older seminal work is [START_REF]Mental Models[END_REF]. Finally, [START_REF] Schwamb | Mental Models: A Survey[END_REF] provides a thorough overview of mental models theories. There is little consensus on what the term "mental models" means exactly [see also 13, p.73, and 14, p.109-111]. We can, however, distil a common narrative leaning most heavily on [START_REF] Norman | Some observations on mental models[END_REF] and [START_REF] Van Der Veer | On the interaction between system and user characteristics[END_REF].

According to theory a mental model is continuously being constructed in the mind during interaction with a complex system, during all stages of learning from the very beginning all the way to the highest proficiency. Like any model, it is a simplified abstraction that is used to predict behaviours of the referent (the target system). In order to predict what the target system will do under certain conditions, the user will mentally apply those conditions to the model, "run" it, and (still mentally) observe the outcome. The model is seen as viable if running it results in reliable predictions about the behaviour of the target system. In situations where the target system is man-made, we can identify on the one hand the user mental models held by end users and on the other the internal models, held by the system's makers. Information on how the communication between end user and system unfolds may contain a conceptual model, which is any model that is explicitly worked out by the User Support role to stimulate meaningful learning in those being instructed. As we have seen, the different roles within a software development team interact with different aspects of the system. Therefore, there is not just one internal model but rather a multitude. Rather than converging, team members' understanding of the system, the work, and other team members' expertise has been found to diverge over time. As time goes by, their mental models become increasingly dissimilar [START_REF] Levesque | Cognitive divergence and shared mental models in software development project teams[END_REF]. This is related to a decrease in interaction: the further into the project, the less team members engage in meetings and other such forms of communication.

Communication and co-operation

Where many people work together towards a common goal, they need to communicate: if they don't, then achieving the goal will be very difficult if not impossible [START_REF] Barthelmess | A view of software development environments based on activity theory[END_REF][START_REF] Curtis | A field study of the software design process for large systems[END_REF] and the CoI will be unsuccessful. It is a sad fact of life that this does indeed happen. Complex software projects regularly fail to meet expectations.

Face-to-face communication is natural and often found to be the preferred channel for information exchange within a software development team. LaToza et al. found that programmers prefer face-to-face communication over every other method for obtaining an understanding of code written by somebody else [START_REF] Latoza | Maintaining mental models: a study of developer work habits[END_REF]. However, face-toface communication goes unrecorded and has spatial and temporal restrictions. Geographically distributed development teams are increasingly common and the system, once built, must be maintained and supported by others than those involved in the original development efforts [START_REF] Stettina | Necessary and neglected?: An empirical study of internal documentation in agile software development teams[END_REF]. For these reasons, most software engineering approaches call for extensive documentation of the development process. A potentially very large number of documents is created in the course of developing a software system [START_REF] De Boer | Writing and Reading Software Documentation: How the development process may affect understanding[END_REF].

Unfortunately, all this paperwork does not necessarily serve the desired communication. Programmers have been shown to conform to stereotype and go to great lengths to develop an understanding of the code; but they turn to its documentation only when everything else fails. Internal design documents are mostly read by newcomers to a team [START_REF] Latoza | Maintaining mental models: a study of developer work habits[END_REF]. Furthermore, programmers have a strong sense of personal ownership of the code and hold enormous amounts of knowledge on the system in their heads. Their concept of "team" is limited to a very small number of direct colleagues, working on the same part of the code; and it is within these small teams only that achievements are documented. LaToza and his co-authors further found that for programmers the documentation serves not so much for information exchange as for information protection; for digging, as the authors call it, a "moat" around the work that has been done. Rather than describe the internal workings of a particular piece of coding, the documentation delineates the code by providing detail on its interface with other code.

To know which document to turn to in order to satisfy a need for information, an understanding is required of all that is available. The closer people are to each other in the team, the more they have the same understanding of what a particular document is good for; to such a degree that it has proven possible "to reconstruct an approximation of the development process based on statements solely about the documentation" [START_REF] De Boer | Writing and Reading Software Documentation: How the development process may affect understanding[END_REF]. As design documentation documents are read as well as written within the team, it follows that most of the internal documentation is well understood only by those whose work is closely related to that of the author. Communication within the CoI is severely hindered by the different representations that the different CoPs use for external cognition [START_REF] Arias | Boundary objects: Their role in articulating the task at hand and making information relevant to it[END_REF], and for actors to reconcile the different meanings is labourintensive [START_REF] Star | Institutional ecology, translations and boundary objects: Amateurs and professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39[END_REF].

User documentation

Thus far, we have discussed the documentation produced by the User Support (US) role only tangentially; and paid attention mostly to the documentation produced and used by the other roles in the development team. Where the latter's function is one of internal communication within the CoI, be it distributed or co-located and concurrent or over time, the former embodies communication with stakeholders outside the team: the end users of the system. For US documentation is an end rather than a means. This sets US off from the other roles in the CoI even more than the other roles are set off from one another (see Figure 1). US's primary responsibility is to produce user manuals and Help systems. They describe the system after it has been completely built rather than during its construction; and indeed, frequently they are not even part of the development team but called in at a later stage, when the CoI is about to be or even has already been disbanded. US do not create that aspect of the system that they describe (the UVM) but identify the UVM as it emerges from the other roles' efforts. A software system is a self-contained "world" with its own objects (think of the Clipboard in many operating systems; of templates, style sheets and fields in a word processing environment; or of layers in an image editor). These software-specific objects, with their mutual dependencies and the rules governing their behaviour, are as much part of the UVM as is the interaction layer through which they are accessed. A user needs a thorough understanding of the UVM to gain complete mastery of a particular software tool, and apply it successfully to every task it can possibly be applied to. Such understanding is fostered through meta-communication in the shape of documentation or training [START_REF] Van Der Veer | On the interaction between system and user characteristics[END_REF]. As a "correct" user mental model is crucial to the end user's gainfully applying the system to real-world work, US strives to guide the formation of such a correct model; by explicitizing established misconceptions and subsequently eradicating them [START_REF] Uzuntiryaki | Effect of conceptual change approach accompanied with concept mapping on understanding of solution concepts[END_REF], or by presenting a conceptual model as depicted in Figure 1 [START_REF] Mayer | When Is an Illustration Worth Ten Thousand Words?[END_REF][START_REF] Allbritton | Metaphor-Based Schemas and Text Representation: Making Connections Through Conceptual Metaphors[END_REF].

In order to create a conceptual model for end users to learn from, US first need to develop their own correct mental model of the UVM. They do so by studying the internal documentation left behind by the development team and by holding formal or informal interviews with those of the development team who are still available. Then, they apply their knowledge of documentation and instruction to the scattered knowledge gleaned. This is a rather haphazard process, the result of which is often unsatisfactory. There is a strong need for US to be truly part of the CoI that creates the system. Only then will they be able to create user support materials that are genuinely helpful to end users.

Documentation as a boundary object

All design efforts, including the design of complex software systems, require the sharing of work artefacts [START_REF] Barthelmess | A view of software development environments based on activity theory[END_REF]. Incremental creation of external representations is a strong mechanism for negotiating a shared understanding of the task at hand [START_REF] Arias | Boundary objects: Their role in articulating the task at hand and making information relevant to it[END_REF][START_REF] Stettina | Documentation Work in Agile Teams: The Role of Documentation Formalism in Achieving a Sustainable Practice[END_REF]. In a seminal article [START_REF] Star | Institutional ecology, translations and boundary objects: Amateurs and professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39[END_REF], Susan Leigh Star presented the concept of boundary objects binding together heterogeneous groups of actors. Star's own words cannot be surpassed in describing the concept, as follows: "objects which inhabit several intersecting social worlds […] and satisfy the informational requirements of each of them. Boundary objects are plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. These objects may be abstract or concrete. They have different meanings in different social worlds but their structure is common to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is a key process in developing and maintaining coherence across intersecting social worlds" [20 p. 393].

The current approach to documentation, in which every CoP within the CoI develops their own documentation separate from the others, is unsatisfactory; for a number of reasons: -It further reinforces existing barriers (or "digs moats") between the different groups [START_REF] Latoza | Maintaining mental models: a study of developer work habits[END_REF], as always one CoP is forced to discuss a document written in another CoP's language.

-It leads to information being lost, as translations have to be made between the different perspectives on the system. -It is resource-intensive, as the different documents are all created from scratch.

-It is wasteful, as the separate documents have a limited life-span that is restricted to a particular development stage. -It offers no guarantees for providing an exact description of what has been actually built at any given moment in time, as documenting and designing/developing are separate activities. -It backfires, as people lose track of what has been documented; in which document a particular information item can be found; and where the different documents are stored [START_REF] De Boer | Writing and Reading Software Documentation: How the development process may affect understanding[END_REF]. In this paper, we propose a solution to the dual problems of (1) heterogeneous mental models within a software development team and (2) the user support role being peripheral to the team. The solution we propose is based on re-shaping documentation into a boundary object.

A revised role for documentation

When carefully thought-out, one and the same set of documents could fulfil the roles of internal design documentation and user documentation. A semi-formal structure can be envisaged in which user requirements are laid down, after which the resulting documents are at every step further refined so that they become first the design specification and finally the user documentation.

A semi-formal description is one that combines the rigidity of a formalism with the flexibility of narrative. Within a pre-described framework, where building blocks are identified by (for example) fixed headings, a document's required content can be assembled at any given stage. Such a document is accessible to and can be a base for discussion between FA, SA, ID, SP, US and end users, who can then co-operate throughout the development cycle without loss and without spending any time or other resources in duplication; developing an ever-more detailed shared mental model over time.

Figure 2 gives a schematic overview of what such a revised approach could look like. Requirements are collected by the prospective end users together with FA; through whichever method is deemed appropriate. The resulting requirements are then recorded in a semi-formal document. This is agreed on by all those involved, and handed over to SA and ID for transformation into a functional description of the User Virtual Machine or UVM. Before SP starts working on its implementation, the UVM may be evaluated together with the users by means of any prototype-based method. Whichever form the prototype takes, however, the final, agreed-on version will become part of the documentation. SP then designs the implementation details and builds the tangible product. Finally, the documentation is worked up into an As Built description. Parts of this will now function as user documentation, while other parts will serve as systems documentation to be referred to for maintenance and updates. The documentation will now always exactly mirror the current state of the system. As a result, significantly higher quality should be achievable at significantly lower cost. In this approach, the documentation is at all times a boundary object in the meaning of the term defined by Star, inhabiting the worlds of all CoPs involved in the CoI. Being developed incrementally by all, it will satisfy the informational requirements of all parties, maintaining a common identity yet allowing for local detail. Bridging boundaries rather than digging moats, the ever-elusive quest for consensus is made redundant. "When participants in the intersecting worlds create representations together, their different commitments are resolved into representations -in the sense that a fuzzy image is resolved by a microscope. This resolution does not mean consensus." It is important to maximize not just the communication between worlds, but equally well their autonomy [START_REF] Star | Institutional ecology, translations and boundary objects: Amateurs and professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39[END_REF].

A revised role for User Support

In the revised workflow described in the previous paragraph, mental models development is concentrated in the co-creation of documentation. Internal mental models as depicted in Figure 1 are aligned as they develop. Moreover, the desired mental models of the intended end users are taken into account from the beginning. It follows then that there is no longer a need for User Support to separately develop their own mental models and then translate these into conceptual models to instruct end users (see Figure 3). However, this does not mean that User Support has become superfluous. On the contrary, the particular expertise held by this role is indispensable now: not at the end of the development process, but rather throughout.

For boundary objects to function as such, standardization of methods is required [START_REF] Star | Institutional ecology, translations and boundary objects: Amateurs and professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39[END_REF]. As the process now hinges on one set of documents, any flaws in these will have repercussions at every subsequent stage. The semi-formal structure underlying the documentation must therefore be very carefully designed in its own right, to be tightly incorporated in the methodology that is applied. If this approach is to yield the desired benefits, a number of requirements must be met: -The FA, SA, ID and SP roles must be supported in their endeavours to write in such a manner that the result is of value not only to themselves but to all other roles as well. This can be expected to require a major effort. Software developers are not known for either their willingness or their capacity to write and they will need to be motivated to do so. Then, they will need to be provided with instruction, guidelines and templates and most of all, they will need continuous monitoring and coaching. -It must be clear who "owns" the documentation at any given stage. Transfer of ownership of the document marks the transition from one stage to the next.

-At every stage, the documentation must be able to incorporate additional new content such as requirements and features, systems logic and user interaction, and the nitty-gritty of coding solutions. -Not only must the documentation provide room for all the content, it must also clearly prescribe the nature and scope of the content that is needed at every stage.

A document set that is owned by different groups of people at different moments in time must be self-explanatory and self-directing: its contents cannot be left to chance or the personal preference of whoever happens to be working on a particular section. Whereas initially the documentation consists of little more than a structure allowing for requirements and features to be recorded, the requirements analysis is concluded by creating "slots" for the design of the UVM by the SA role. This stage in turn is completed with not just production of the prototype, but also that of "slots" for the implementation design details that will be added by the SP role. Consolidation of all the information into an As Built deliverable that truthfully reflects that which has been delivered, finally, must be executed with a view to the final task of the documentation: that of supporting users on the one hand and providing a starting point for maintenance and further development on the other.

All these requirements mean that existing methodologies are no longer applicable and must be re-invented. Making software engineering documentation-centred can succeed only if the software development team includes a documentation specialist from the very beginning. User Support, with its core competence of documentation, is perfectly placed to truly make documentation into a boundary object.

Conclusion

Documentation has long been regarded as a necessary evil and treated accordingly. Internal design documents are discarded when the next stage of development begins. Development is often not documented beyond comments in the code, which tend to be few and far between. End user documentation is produced, if at all, at the very last moment by someone not involved in the design or development of the system. A recently proposed methodology for software engineering known as agile development calls for as little documentation as possible, and suggests internal communication is best carried out face-to-face. (Yet although agile developers on the shop floor may not be keen to produce documentation, they do feel that there should be more of it than there is [START_REF] Stettina | Necessary and neglected?: An empirical study of internal documentation in agile software development teams[END_REF].) Documentation is recorded communication; and communication is what allows people to work together, creating something that one single person could not possibly achieve. Without communication, we cannot expect to build an interactive system that genuinely meets people's needs. The multitude of written documents produced between an interactive system's inception and the day on which it is last used, represent a missed opportunity for effective communication. All are written in their own language: some formal, some informal. Rather than facilitating the exchange of ideas and insights between different roles and across different stages of the system's life cycle, they scatter knowledge to such a degree as to make it effectively inaccessible.

The proof of the pudding is, of course, as always in the eating. Applying the approach described in this paper, in which one semi-formal, continuously evolving set of documents forms the focal point for everybody's contribution, will not be trivial. To test the approach in a real-life environment where a complex piece of software is developed to a real-life end, a large number of people need to believe in the concept and have enough faith in it to actually see it through. We believe that this will be an extremely rewarding and constructive exercise.

Figure 1 :

 1 Figure 1: Overview of mental models developed by different roles in the software engineering process.

Figure 2 :

 2 Figure 2: One document, different stages, different uses.

Figure 3 :

 3 Figure 3: Documentation as a boundary object.


Marie Cottrell

Smaïl Ibbou

Patrick Letrémy

TRAITEMENT DES DONNEES MANQUANTES AU MOYEN DE L'ALGORITHME DE KOHONEN

Keywords: Analyse de données, cartes de Kohonen, Données manquantes

Nous montrons comment il est possible d'utiliser l'algorithme d'auto organisation de Kohonen pour traiter des données avec valeurs manquantes et estimer ces dernières. Après un rappel méthodologique, nous illustrons notre propos à partir de trois applications à des données réelles.

INTRODUCTION

Le traitement des données avec observations manquantes est un problème concret et toujours embarrassant lorsqu'il s'agit de données réelles. En effet dans les applications, on est très souvent en présence d'observations pour lesquelles on ne dispose pas de l'ensemble des valeurs des variables descriptives, et ceci se produit pour de nombreuses raisons : erreurs de saisie, rubriques non renseignées dans des enquêtes, valeurs aberrantes qu'on préfère supprimer, données recueillies difficilement, statistiques officielles non disponibles, etc.

La plupart des logiciels statistiques (comme SAS par exemple) suppriment purement et simplement les observations incomplètes, mais si cela n'a pas de conséquences pratiques lorsqu'on dispose de données très nombreuses, cela peut supprimer tout intérêt à l'étude si le nombre de données restantes est trop faible.

Pour éviter de supprimer ainsi les données, on peut remplacer une valeur manquante par la moyenne de la variable correspondante, mais cette moyenne peut être une très mauvaise approximation dans le cas où la variable présente une grande dispersion.

Il est alors dans ce cadre très intéressant de constater que l'algorithme de Kohonen (ainsi que l'algorithme de classification de Forgy) supporte parfaitement la présence de données manquantes, sans qu'il soit nécessaire de les estimer préalablement. Nous nous intéressons particulièrement ici à l'algorithme de Kohonen, puisque qu'il généralise l'algorithme stochastique des centres mobiles (version stochastique de l'algorithme de Forgy), et qu'en raison de ses propriétés de visualisation, il sera plus simple de « voir » les résultats.

On trouvera dans la thèse de Smaïl [START_REF] Ibbou | Classification, analyse des correspondances et méthodes neuronales[END_REF] un chapitre consacré à cette question, mais cela n'avait pas donné lieu à publication jusqu'à maintenant. C'est pour cette raison que nous avons pensé utile de présenter l'état de l'art sur cette question. Les exemples sont traités à l'aide du programme écrit par Patrick Letrémy en IML-SAS et disponible sur le site du SAMOS (http://samos.univ-paris1.fr).

ADAPTATION DE L'ALGORITHME DE KOHONEN A DES DONNEES INCOMPLETES.

On suppose que les observations sont des vecteurs à valeurs réelles de dimension p Lorsqu'on présente un vecteur de données incomplet x, on détermine d'abord l'ensemble M x des numéros des composantes manquantes. M x est un sous ensemble de {1, 2, ..., p}. Si (C 1 , C 2 , ..., C n ) est l'ensemble des vecteurs-codes à cet instant, on calcule le vecteur-code gagnant

) (x i O C associé à x et sa classe, en posant ( ) i i C x Arg x C i - = min , 0 où la distance ( ) 2 2 ∑ ∉ - = - x M k k , i k i C x C x
est calculée sur les composantes présentes dans le vecteur x.

On peut utiliser les vecteurs avec données manquantes de deux façons. a) Si l'on souhaite les utiliser au moment de la construction des vecteurs-codes, à chaque étape, une fois déterminé le numéro de l'unité gagnante, la mise à jour des vecteurs codes (le gagnant et ses voisins) ne porte que sur les composantes présentes dans le vecteur.

2) Si l'on dispose de suffisamment de données pour pouvoir se passer des vecteurs incomplets pour construire la carte, on peut aussi se contenter de classer, après construction de la carte, les vecteurs incomplets en les affectant dans la classe dont le vecteur code est le plus proche, au sens de la distance restreinte aux composantes présentes.

Cela donne d'excellents résultats, dans la mesure bien sûr où une variable n'est pas complètement absente ou presque, et aussi dans la mesure où les variables sont corrélées, ce qui est le cas dans la plupart des jeux de données réelles.

On pourra voir de nombreux exemples dans la thèse de Smaïl [START_REF] Ibbou | Classification, analyse des correspondances et méthodes neuronales[END_REF] et aussi dans [START_REF] Gaubert | Segmented Real Estate Markets and Price Mechanisms : the Case of Paris[END_REF].

ESTIMATION DES VALEURS MANQUANTES

Quelle que soit la méthode utilisée pour utiliser les données avec valeurs manquantes, une des propriétés les plus intéressantes de l'algorithme, et qu'il est possible d'estimer a posteriori les valeurs manquantes.

Si M x est l'ensemble des numéros des composantes manquantes de l'observation x, et si x est classé dans la classe i, pour chaque indice k de M x , on estime x k par :

k i k C x , ˆ= .
Comme la fin de l'apprentissage de l'algorithme de Kohonen se fait à « zéro voisin », on sait que les vecteurs codes sont asymptotiquement proches des moyennes de leur classe. Cette méthode d'estimation consiste donc à estimer les valeurs manquantes d'une variable par sa moyenne dans la classe.

Il est clair que cette estimation est d'autant plus précise que les classes formées par l'algorithme sont homogènes et bien séparées les unes des autres. De nombreuses simulations ont montré tant dans le cas de données artificielles que de données réelles, qu'en présence de variables corrélées, la précision de ces estimations est remarquable. Voir à ce sujet le chapitre 5 de la thèse de Smaïl [START_REF] Ibbou | Classification, analyse des correspondances et méthodes neuronales[END_REF].

Pour augmenter la précision, il propose dans sa thèse de réaliser plusieurs versions de l'algorithme de Kohonen, et de prendre la moyenne des estimations obtenues dans chaque carte.

EXEMPLES PRESENTES

Dans la suite, nous présentons trois exemples tirés de données réelles.

Le premier exemple porte sur des données socio-économiques recueillies sur 182 pays en 1996. Les observations sont de trois sortes : 114 données complètes où chaque pays est décrit par 7 variables numériques, 52 pays avec une valeur manquante sur 7, et 16 pays où le nombre de valeurs manquantes est supérieur ou égal à 2. Les données correspondantes sont du domaine public et ont souvent été utilisées, à la suite du travail de François Blayo et Pierre Demartines (1991). Voir par exemple [START_REF] Cottrell | A statistical tool to assess the reliability of Self-Organizing Maps[END_REF], Dans cet exemple, nous montrons comment utiliser les observations incomplètes de deux façons différentes, comme précisé au paragraphe 2.

Le second exemple porte sur des données immobilières de 205 communes d'Ile-de-France, en 1988, représentées par 15 variables. Dans cet exemple réel, issu d'une étude commandée par la DATAR et traitée par Christian Tutin, Patrice Gaubert et Smaïl [START_REF] Gaubert | Segmented Real Estate Markets and Price Mechanisms : the Case of Paris[END_REF], seules 5 communes n'ont pas de valeurs manquantes, 150 communes ont moins de 12 données manquantes, et 55 en ont 12 ou plus (sur 15). Il était donc essentiel de pouvoir utiliser les observations AVEC données manquantes.

Enfin, le troisième exemple est un exemple classique en analyse de données, tiré du Que-saisje ? de Bouroche et Saporta , « L'analyse des données » ( 1980). Il s'agit de la structure de dépenses de l'Etat, mesurées sur 24 années entre 1872 et 1971, par un vecteur de dimension 11. Dans cet exemple, nous avons artificiellement supprimé des valeurs présentes dans les données originelles, d'une valeur sur 11 à 8 valeurs sur 11, choisies aléatoirement, pour évaluer la précision des estimations obtenues en remplaçant ces valeurs par les valeurs correspondantes des vecteurs codes associés, comme expliqué dans le paragraphe 3.

LES DONNEES SOCIO-ECONOMIQUES.

On a mesuré en 1996, 7 variables se rapportant à la situation macro-économique of 182 pays. Ce type de données a été utilisé pour la première fois dans le contexte des cartes de Kohonen par François Blayo et Pierre Demartines (1991).

Les variables mesurées sont : La croissance annuelle de la population en % (ANCRX), le taux de mortalité infantile (en pour mille) (TXMORT), le taux d'illettrisme en % (TXANAL), l'indice de fréquentation scolaire au second degré (SCOL2), lePNB par habitant exprimé en dollars (PNBH), le taux de chômage en % (CHOMAG), le taux d'inflation en % (INFLAT).

Ces pays peuvent aussi être classés a priori d'après une classification classique en économie fondée sur l'indice de développement humain (NIVIDH), variable qualitative à 6 niveaux codés par des libellés : faible1 (1), faible2 (2), moyen1 (3), moyen2 (4), fort1 (5), fort2 (6).

Parmi l'ensemble des 182 pays considérés, seuls 114 ne présentent pas de données manquantes, 52 ont une valeur manquante, tandis que 16 ont plus de 2 valeurs manquantes. Si on représente le niveau (de 1 à 6) de la variable NIVIDH sur la carte, on voit (figure 4) que les pays sont effectivement classés selon la logique de cet indice ; La classification n'est pas parfaite, ce qui est normal, car cet indice de développement prend en compte d'autres variables plus liées à la qualité de la vie (comme le nombre de médecins, de cinémas, la sécurité, etc.).

Figure 4 :Proportion des modalités de la variable NIVIDH classée en 6 niveaux selon la classe. L'échelle va de 6 (gris très foncé) à 1 (gris très clair).

On remarque que l'introduction de 52 pays incomplets ne produit aucune incohérence. En ce qui concerne les pays considérés en données supplémentaires, si leur positionnement sur la carte est logique (figure 3), il est difficile de les inclure dans le graphe ci-dessus, parce qu'on ne dispose pas pour eux de l'indice de développement humain.

ETUDE DU MARCHE IMMOBILIER FRANCILIEN

Il s'agit d'une étude pour le compte de la direction de l'habitat et de la ville de la Direction Régionale de l'Equipement d'Ile-de-France (DHV/DREIF), réalisée en 1993 par le laboratoire METIS de Paris 1, en collaboration avec le SAMOS.

On dispose pour 205 communes d'Ile-de-France étudiées en 1988, de données immobilières (loyers et prix des logements, anciens ou neufs, collectifs ou individuels, standard ou luxe, loyers et prix des bureaux, anciens ou neufs). Structurellement, certaines données sont absentes, par exemple le marché des bureaux peut être inexistant dans certaines communes.

Il s'agit de données où les données manquantes sont donc manquantes de manière structurelle, et où le nombre de communes se réduit drastiquement si l'on supprime celles qui sont incomplètes, on ne pourrait en considérer que 5 sur les 205 ! On représente dans la figure 5, la liste des communes (avec ou sans données manquantes) classées sur une carte de Kohonen. Remarquons que sur l'ensemble de la table des données, il y a environ 63% de valeurs manquantes. On voit dans cet exemple, pratiquement impossible à traiter avec un logiciel classique, que l'algorithme de Kohonen permet de classer malgré tout des données extrêmement « trouées » sans introduire d'erreur grossière.

Bien sûr, ces bons résultats s'expliquent par le fait que les 15 variables mesurées sont bien corrélées, et donc les valeurs présentes contiennent de l'information sur les valeurs manquantes. La table suivante contient la matrice de corrélation des 15 variables observées. On constate que l'erreur reste très faible lorsqu'on ne supprime pas plus 3 valeurs par année. Ensuite l'erreur plafonne, cela est dû au fait que le nombre de données (24) et de vecteurs codes ( 9) sont faibles tous les deux. Les composantes des vecteurs codes disponibles sont en nombre limité, et les estimations restent dans ce cas dans l'ensemble de ces composantes.

CONCLUSION

On a donc montré sur ces trois exemples comment il est possible et souhaitable d'utiliser des cartes de Kohonen quand les données disponibles présentent des données manquantes. Bien sûr les estimations et les classes obtenues seront d'autant plus pertinentes que les variables descriptives des données sont bien corrélées.

L'exemple 2 montre qu'il peut s'agir de la seule méthode possible lorsque les données sont extrêmement trouées. L'exemple 3 montre comment cette méthode permet d'estimer avec précision des données absentes. Les données ainsi complétées peuvent ensuite faire l'objet de tout traitement classique.

  On utilise donc les 114 + 52 = 166 pays complets ou presque pour construire la carte de Kohonen, et on classe ensuite les 16 pays restant. Les données sont centrées et réduites comme classiquement. La figure 1 montre la répartition des vecteurs codes après convergence de l'algorithme, la figure 2 montre le contenu des classes, en ne tenant compte que des 166 pays utilisés pour le calcul des vecteurs codes. On voit que les pays riches se trouvent dans le coin en haut et à gauche, les pays très pauvres en haut et à droite. Les pays à grande inflation sont en bas de la carte, à proximité des pays riches se trouvent des pays intermédiaires, comme ceux qui faisaient partie du camp socialiste, etc.

Figure 1 :

 1 Figure 1 : Répartition des vecteurs codes après convergence de l'algorithme (1000 itérations).

Figure 2 :

 2 Figure 2 : Classement des 166 pays ayant au maximum une donnée manquante.

Figure 3 :

 3 Figure 3 : Les pays ayant 2 valeurs manquantes ou plus sont classés comme données supplémentaires.

Figure 5 :

 5 Figure 5 : Classement des communes, on voit clairement à gauche Paris, puis la petite couronne, et ensuite la grande couronne. Les numéros des départements représentent les 55 communes ayant plus de 12 valeurs manquantes, qui ont été classées après coup, comme données supplémentaires.

  Il s'agit donc d'un petit exemple, avec 24 observations de dimensions 11, sans valeurs manquantes.Une analyse en composantes principales toute simple permet une excellente représentation même en deux dimensions (64 % de variance expliquée). Voir figure6, la représentation des variables et figure7, la représentation des années.

Figure 6 :

 6 Figure 6 : Représentation des variables sur le premier plan principal.

Figure 7 :

 7 Figure 7 : Représentation des années sur le premier plan principal. On distingue parfaitement les trois groupes.

Figure 8 :

 8 Figure 8 :Carte de Kohonen des 24 années, 1920 est classé avec le premier groupe.

Figure 9 :Figure 10 :

 910 Figure 9 : On voit que les super-classes restent homogènes tant qu'on ne supprime pas plus de 3 valeurs par année, soit 27% des valeurs. Ensuite les classes d'années se mélangent. Les années sont notées 1, 2, 3, suivant la période.