Chris Roast
email: c.r.roast@shu.ac.uk

Constraining and Creating Solutions -reflections on the analysis of early design

Keywords: user centred development, early design decisions, cognitive dimensions

This research explores how an existing analytic framework (the cognitive dimensions framework) for interactive digital design reflects knowledge relevant to exploring the design space. The work examines this idea through the analysis of the transcripts of three digital design collaborative workshops run as part of "Studying Professional Software Design" 1 . Expert deliberation within these workshops is assessed and related to the analytic framework. The cognitive dimension framework has not been applied to observational data of this sort before. However, the approach described in this paper appears to provide a viable means of analysis. In conclusion we demonstrate that approaching observational data in this manner is not highly complex but is sufficient to provide useful insights. Reflections from the resulting analysis shed light on the interests and tensions evident in early stages of digital product design.

Introduction

This paper describes an exploration of the design process for digital systems, motivated by the analysis of data taken from three professional digital design workshops illustrating early concept formation [1] and collaborative research with professional developers on a live commercial project [START_REF] Roast | The programming-like-analysis of an innovative media tool[END_REF]. We are particularly interested in the design space of interactive digital design and how well that space is navigated and understood during the process of developing a conceptual design. The motivation for this work is based on an interest in understanding expertise in the domain of interactive digital design, exploring the implications for how design might be improved or supported.

Here we consider design expertise to reveals itself in terms of being able to shortcircuit what would otherwise be time consuming problem-solving expeditions. It is very common for large scale design problems to be addressed through tackling components with them. Hence managing complexity is achieved through structures that modularize or scope specific challenges [START_REF] Simon | The Sciences of the Artificial[END_REF]. However the digital design space embodies a massive range of complexities. Jackson [START_REF] Jackson | Representing structure in a software system design in Design Studies[END_REF] provides a rich account of how abstractions and perspectives are core to managing complexity in contemporary software projects. Despite that, working with and effectively using such structures is non-trivial. The mechanisms to cope with the complexity are not comprehensive and they thus fail to deal adequately with some design requirements. One significant contributory factor is the persistent opacity of digital artefacts. The structures employed to manage complexity are intrinsically abstract and poorly understood by non-technical stakeholders. In addition, while abstractions and structures can enable constructive development they can always be usurped both technically and by the emergent user needs. System requirements of interactive devices are frequently realized via their behaviours and these are hard to both specify and comprehend prior to encountering them via experience. A sample of research in the area of the psychology of digital programming shows that the ambition of wishing to engineer digital systems can be undermined by the fact that even simple digital programs can be difficult to comprehend [START_REF] Ramalingam | An empirical study of novice program comprehension in the imperative and object-oriented styles[END_REF]. In particular specific highly promoted techniques aimed at addressing some elements of perceived complexity have been shown to undermine their overall rationale [START_REF] Khazaei | The influence of formal representation on solution specification in Requirements Engineering[END_REF].

The view taken here is that the need to structure and manage the complexity of the digital design space can be interpreted as a means of representing the space in a manner that is amenable for navigation and exploration. As such the manner in which the structure is imposed is attempting to serve to two purposes: (i) to make it easier for human designers to work with, and (ii) make it appropriate for technically meeting the requirements of a particular design problem. We are interested in the first of these -the fact that human factors plays a role in determining the way in which the design space is explored. Hence, when faced with a range of technical approaches in a design process, the choice of approach will not only be governed by the technical quality but also by the ease with it can be understood and applied. The quality of the representations employed and the experience and expertise of the designers will inform such a choice. It is interesting to see whether: expertise applied in a design setting demonstrates insights into the digital design space, thus reducing the likelihood of poor choices; how a design representation supports that process; and, the extent to which choices address the technical requirements or client needs.

An analytic framework

The chosen analytic framework for considering human factors and the exploration of digital design space is that of "cognitive dimensions" [START_REF] Green | Usability analysis of visual programming environments: a 'cognitive dimensions' framework[END_REF]. The cognitive dimensions framework provides a set of concepts that have been used as a means of capturing generic aspects of human interaction with complex information structures, with aim of emphasizing recurring factors pertinent to design quality [START_REF] Green | Cognitive dimensions: Achievements, new directions, and open questions in[END_REF]. This framework is unique in that: (i) it has been developed from the examination of the hard problems that arise with information systems such as the use of representations to define and comprehend complex behaviours, and (ii) it has been articulated in terms that do not presuppose human factors expertise. In doing so, the framework appears to be appeal as a means of easily capturing important observations about concepts are expressed and developed.

To illustrate this point we briefly introduce one of elements of framework -"hidden dependencies". As its name suggests, this refers to the fact that digital artefacts can manage masses of inter-related data items which means changing one item can influence many others. Despite users and developers being fully aware of such dependencies, they can still manifest themselves un-expectedly. Tools and notations used when designing and/or using a system can be judged in terms of how they form, expose and manage such dependencies. Design often uses diagrams and structures to capture and circumscribe both data and functional dependencies. While these make explicit some dependencies others can be hidden and still need to managed by, say, cross-checking design changes in each of a number of views. Our proposal in this paper is that digital design experts are likely to have experienced recurrent issues arising from working with concepts such as hidden dependencies and will therefore be prepared for dealing them. Designers with greater expertise may be more attentive to managing dependencies.

To date the concepts from cognitive dimensions framework have been used constructively to frame or drive reflections, hence "hidden dependencies" provides a way of seeing a particular problem [START_REF] Roast | The programming-like-analysis of an innovative media tool[END_REF]. By contrast, the work reported faces two challenges. First, whether the interesting features captured by the dimension framework relate to professional design expertise and experience, and second, whether such a relationship is evidence in "raw" observational data. To address the first of these, for this study, we are pre-supposing that expert experience based design behaviour will, in part, match the insights that the framework is designed to encourage. While this premise is speculative, it is not unrealistic especially since the framework is based on extensive research experience examining human behaviour in relationship to technology supported development. However, we'd not claim that such a match is a basis from assuming the framework reflects expert mental processes. The second challenge is to employ the dimension concepts in the analysis of observational data, and our approach is described below, see sections 3 and 4.

The workshop data

The data used for this work is from expert developers engaged in common a design task. This was developed as part of project aimed at generating an open research resource based upon collecting a foundational set of observations and insights into software design 2 . The task examined was to develop a preliminary user interface design and also data model and architecture for a given "brief". The brief was for a traffic simulation system explicitly for use in an education context. The simulation would used by tutors and students to explore the influence of different traffic signal protocols upon traffic flow. Rich contextual detail was provided regarding what can be assumed of the simulated traffic system and what functionality could be assumed to already exist. In addition, the set task required both the completion of technical and design details in limited time.

Three separate pairs of professional developers worked on the given task for between one to two hours with limited additional support. They were required to manage their own activities while completing the task and thus had to balance between technical concerns and those of design. Their discussion and use of a whiteboard was recorded and transcribed -this data is freely available from the project coordinators and other research exploring the same data sets is the subject of a special issue on Design Studies [1]. In summary: the workshops lasted between one hour and two hours and the transcripts of discussions being between 6,000 and 12,000 words long.

The Cognitive Dimension Framework

The Cognitive Dimensions Framework is a relatively informal means of examining the space of design alternatives from the perspective of exploring the factors that can influence utilization of an artifact -one such factor "hidden dependencies" was introduced earlier. The framework arose primarily from the fields of human factors and human-computer interaction, and the examination of users working with digital languages, notations and representations. This is of relevance to examining design and development since it has been motivated by the examination of languages and representations by which digital systems are themselves are defined. A common feature of the representation examined has been their use for defining activities in the future, such as: (i) expressing code that subsequently operates autonomously; or (ii) developing, say a, set of rules that subsequently auto-process unwanted emails. Unlike many more traditional user interface assessment and analysis approaches, the framework focuses upon important factors related to effective use, without presupposing their relative importance. This enables its use as a basis for discussion and reflection in a wide range of contexts. Hence, while the framework was initial motivated by examples taken from structured visualisations, it has developed to be applied to a broader range of information artifacts. Topics examined using the framework, include: textual and visual programming languages; APIs [START_REF] Clarke | Using the cognitive dimensions framework to measure the usability of a class library[END_REF]; specification notations [START_REF] Triffitt | A Study of Usability of Z Formalism Based on Cognitive Dimensions[END_REF]; spreadsheets [START_REF] Hendry | Creating, comprehending, and explaining spreadsheets: a cognitive interpretation of what discretionary users think of the spreadsheet model[END_REF]; musical notations [START_REF] Blackwell | Cognitive Dimensions and musical notation systems[END_REF]. Green et al. [START_REF] Green | Cognitive dimensions: Achievements, new directions, and open questions in[END_REF] provides a summary of the range of work employing the framework and its development. Recently we have employed a simple tabular format for reporting based on the framework that has been successfully used to facilitate co-operative assessment of complex systems [START_REF] Roast | The programming-like-analysis of an innovative media tool[END_REF].

The dimensions of the framework are discussed and illustrated thoroughly in [START_REF] Green | Cognitive Dimensions of Information Artefacts: a tutorial" Version 1[END_REF], below we outline some of the dimension concepts and suggest their potential role in design. It will be clear from these brief introductions the concepts are closely associated and to some extent overlap.

Premature commitment -this concerns the idea that systems and notations can demand that users make decisions before they are ready to. Although this behavior may be "demanded" it might not in fact be technically necessary. By contrast while such behavior might be seen as unsuitable, it might be purposefully designed to promote a greater diligence or responsibility on the part of the user. An example of premature commitment might be in a formatting rule for inserting an image in a document, using the rule might demand that the image file is specified and exists, when in fact a placeholder could be provided. Viscosity -this concerns the relative complexity of changing information represented in a system. This relates closely to common notions of efficiency in usability. However a key reflective point promoted by the concept is that while a notation tends to make some changes easy, others may be purposefully made complex or hard. In the example of formatting rules, a relative positioning rule (align A with B) can be compared with an absolute positioning rule (find the position of B and set A to that position). Assessing their viscosity would encourage the consideration of what changes to rule uses are most likely to be supported by these two alternatives and whether they are both needed. Visualisation and juxtaposition -this concerns information outputs that the user may use in combination, and the difficulty or ease of combining them. In the simplest chase information needs are met by presenting information juxtaposed making human perceptual inferences easy, such as comparing values on a histogram. More often than not all possible information needs can be satisfied and the user might then have to navigate between sources, possible even switching between applications. Using the example of formatting rules, we can envisage the benefit of being able to see the rules that influence the same element juxtaposed with one another. Abstraction -this concerns the potential to employ abstractions within a systems and the ease with which they can be used. Abstraction normally supports working with general classes or groups of entities and not specific individuals. It is used productively in many settings within software engineering. By contrast some systems impose pre-defined abstractions that users then have to assimilate. As with viscosity, the concept of abstraction is used as a means of reflecting on the nature of support that is provided. An example of abstraction with formatting rules would be how groups of rules serving a collective purpose might be managed as a single composite entity. Hard mental operations -this concept has close associations with Abstraction, it is concerned with whether the operations available to users of a representation are easy or hard to understand. For this it is necessary to envisage the manner in which a user will think about achieving a particular objective and whether the operations provided by the system match them. In the case of a set of formatting rules a hard mental operations would reveal themselves when updating a single rule rarely serves a meaningful purpose. One can envisage a number of updates to different rules being needed in order to achieve a required effect. Provisionality -this concept focuses upon how speculative or incomplete work is supported. In system supported activity it is frequently the case that the user is constrained to completing specific operations or procedures, while this can be helpful, it can impair speculative activity or experimentation. Provisionality thus promotes the consideration of what might benefit from being transient or incomplete in order to encourage effective use. In the case of formatting rules, high provisionality could mean ill-formed, incomplete or inconsistent rules do not "break" the system but are worked with.

Applying the framework

To employ the concepts from the cognitive dimensions framework in examining observational data, it is necessary to identify how features of the observational data related to the concepts of interest. To achieve this we rely upon the premise that points in the workshop discussions where decisions are made are likely to provide explicit indications of participants' expertise. Such "decision points" were urged to be locations where expertise and insight are most likely to reveal themselves and thus be appropriate candidates for finding relating to dimension concepts. Hence, specifics of deliberations at these points would be mapped to concepts provided a focus for the more detailed assessment of the data. Following a preliminary assessment of the workshop resources a prior assessment of the dimensions was conducted mapping them to rationale topics that likely to be directly evidenced in design deliberations. In summary, table 1 indicates the relative relevance of factors for each of dimensions considered. This provides a means of relating what is being discussed during design deliberations to the dimensions that are potentially applicable. The different strengths of mapping shown in table 5 were determined from the critical assessment of cognitive dimensions framework and its prior use. For instance, the dimension of 'Viscosity' focuses upon the complexity of making changes and thus we'd expect this to be evidenced in discussions of the physical effort required to when making changes for specific purposes. Thus discussions focused upon the modification of application data are likely to also be highly relevant. Less relevant will be user navigation since changing data in realistic setting can incur navigation. Similarly, when assessing 'Abstraction' it can be argued that it is predominantly concerned with support for managing aggregates and groupings. Evidence of this concept in design discussions would include: discussion of the meaningfulness of categories; discussion of the physical and mental effort associated with operations upon and navigating abstractions especially user created abstractions; less closely related is the influence of abstraction when acting on or navigating application data. This type of assessment was conducted for each of the dimensions, linking them to broad topic categories that are more likely to be evidenced in design discussions.

The rationale for creating and using the mapping in table 2 is predominantly to provide a method for managing unstructured observational data. This benefit is qualified by the fact that the mapping could itself weaken the association between observed data and its interpretation. Although this mapping may serve as a guide as to what dimensions are "evidenced", the key indicator of expertise relates to the extent to which a discussion embodies some reflection upon alternatives and an awareness of the longer term consequences of particular decisions.

Analysis and outcomes

Following the initial review of the resources, a strategy to identify significant points in the workshop was developed. The primary rationale for this was to provide a focus for more detailed assessment. The approach taken was to read through the workshop transcriptions and highlight segments of the discussion at which it appeared that constructive decisions were made -i.e. decisions add detail or substance to the design based upon rational assessment. Key points in the transcripts where explicit alternatives were being articulated and assessed were taken to be of highest potential relevance; followed by, points involving the implicit assessment of alternatives (these might even be where workshop participants make unilateral assertions about a design option).

Selected foci were each assessed in terms of the reflective depth of the consideration of the topics. This involved reading the relevant section of transcript and also viewing the video record of the same section. At this stage of the analysis it became clear that the motivation for the decisions fell into two broad categories based upon the primary intended beneficiary of the decision: 'external users' -the intended users of the final design (tutors and students using the simulation tool for educational purposes); 'internal users' -those involved in subsequent technical development (software developers and designers). These two categories were used to factor the initial assessment of decision points.

Internals

The outcome of the assessment of the decision points and their mapping to cognitive dimension concepts is summarized in tables 2, 3 and 4. Linking this assessment back to the cognitive dimensions framework the rationale supporting decisions has been assessed in terms the relevant topics used in table 1. Working backwards from that mapping, it is possible to associate specific decision points with the dimensions of most relevance. This has been an analytic process based upon the assessment of the workshop discussions at the point of interest and the relevance to the dimensions. Where possible a single dominant dimension has been identified, though on occasions the mapping and the workshop transcript could not be used to effectively to identify a single dimension. However as we have pointed out the potential for overlaps between the different concepts is high, and when necessary critical judgment was applied to identify a dominant dimension in specific cases. The outcome is indicated in Table 5.

Findings

An overall reflection on this the analysis shows that each workshop tended to have a predominant focus upon either "internal users" or "external users", and that the focus tends to relate to different cognitive dimensions. Design discussions focused upon the needs and requirements of end users appeared to be assessed in terms concerned with the immediate complexity of seeing information and working with it. This lead to a focus upon issues concerning: Visibility, Viscosity and Hidden dependencies. By contrast considerations of the internal issues, such as the suitability of a design decision for subsequent technical development, appeared to emphasize: Provisionality; Premature Commitment and Abstraction. This grouping of the dimension concepts is similar to that found in a earlier study conducted in which professional developers were engaged in co-operative assessment of one of their software application's with motivating questions derived from the same framework [START_REF] Roast | The programming-like-analysis of an innovative media tool[END_REF].

General observations

The briefing for the workshop asked for the development of both technical details (such as a data model) and a user interface design within a limited time frame. This created a tension in the workshop of meeting both aims. Despite this, the interplay between the technical and user perspective was only rarely considered. In particular there was one occasion of an unforeseen conflict between technical design and probable user needs. The technical design provided an abstract model of traffic flow, while user needs were judged to demand a fine grain simulation.

Table 5. Outline mapping of cognitive dimensions to workshop data indicating the focus upon internal or external user needs.

Mental operations Provisionality i i

Premature commitment i i i e

Abstraction i i i e

With the discussions in two of the workshops focusing mainly upon the internal requirements, it is of interest that the participants frequently referred to themselves as engaging in future work on the project. They were positioning themselves as "developers". It appears that participants in these cases had a mutual understanding of the implications of a number of decisions -in-depth discussions were not common and summary justifications appeared to be adequate. For instance, on occasions there was consensus that a particular decision would "simplify" a solution, without a need for further explanation. Hence, it seems that workshops with a good common knowledge of technical possibilities pursued that route, and in doing so did not need to openly deliberate about specific technical choices. This can approach also go handin-hand with a reticence to explore factors that are unfamiliar or not well understood. Hence, the openness of the brief could be seen as providing too much freedom. In particular the lack of a detailed user perspective meant the workshop was more reliant upon speculatively envisaging users. A dominant illustration of this for the workshop was the response to the lack of detail about the educational context set-up in the brief. The specific teaching and learning style to be used is not articulated, and hence the brief does not promote design decisions impinging on teaching and learning. Expertise in that area may breed the innovative exploration of learning styles, however pedagogic factors were only addressed partially and indirectly. This is an illustration how design options are not thoroughly explored.

Another distinction between workshops and their user focus are the apparent development styles. Those who focused upon internal user requirement worked consistently with the attitude that: (i) the right technical decisions are needed to ease future work; (ii) subsequent technical develop would follow good practice. By contrast the opportunity for adopting an "agile" or iterative development approach to refining a solution was only alluded to in the externally focused workshop (workshop 3).

Framework based assessment

The relationship between the cognitive dimensions identified in our analysis and the design deliberations can be examined in more detail. In particular we can assess the extent to which factors implied by the dimensions are evident in the discussions in the workshops.

Internal assessment Premature commitment, provisionality, hidden dependencies and abstraction are significant in the internal requirements discussions.

The workshop requirement of developing a data model was clearly considered as a point of high commitment, and significant effort went into getting it right. There were a few occasions when the technical details were in effect deferred by embodying a general structure in the model -an example of this is the adoption of a software engineering patterns. In terms of the cognitive dimensions framework this suggests that a data model in itself is too committing, promoting technical deliberation prior to full understanding overall needs.

Hidden dependencies appear in the discussion of technical decisions when the discussion uses mini-scenarios to illustrate complexity. The features of hidden dependencies and ways of managing them were not explored directly by the participants. Were this style of justification by illustration not adopted, the discussion could easily be classed as being focused upon premature commitment as opposed to hidden dependencies.

Abstraction stands out as being a moderating force when considering "simple" models -a key factor being the "meaningfulness" of a proposed alternative. In the data analysed two domains of meaningfulness are employed: meaningful in terms of external requirements (such as the realisation of "traffic queues") and meaningfulness in terms of familiar software engineering approaches (such as data models and software engineering patterns).

In conclusion the demands of developing a data model appear to be highly committing and potentially disruptive to the balancing of internal and external considerations. On the basis that a data model is needed it appears that concepts such as software engineering patterns provide a means of delaying commitment to technical details. While this could have provided a solid technical approach from which external factors could be explored but this opportunity was not taken.

External assessment Visibility, Viscosity and Hidden dependencies are the dominant dimensions mapped to when considering external users needs. The inter-relationship between viscosity and visibility is close with the main distinguishing factor being whether the requirement concerns users passively examining information or actively engaged in changing data or configurations. In the majority of cases the discussion focused upon possible user interface options, to ensure particular tasks are easily performed and required data is visualised usefully. What these two dimensions would bring to such discussions is a focus upon the side effects of particular solutions in order to encourage critical reflection. So in the case of visualising data, screen area is a limiting factor which naturally promotes the consideration of exactly what, and how much, information can be realistically be simultaneously displayed in a coherent manner. On a few occasions the consideration of such side effects are evidence. This is most obvious in workshop 3 where the whiteboard was used to draw a composite of display design details and application data. In this case the board provided a limiting factor of sorts.

The mapping to hidden dependencies arises in one case from the domain topic of the workshop. The simulation system being envisaged serves an educational purpose, and the workshop participants recognize that learning in that setting often arises from finding inter-relationships.

The other case of hidden dependencies is related to other dimensions and arises when the configuration of a simulation is being considered. Here the motivation was to ease the management of the data structure needed to define a simulation. The visual approach to addressing this problem, by using the whiteboard extensively, encourages the consideration of solutions where the complexity is visually evident and thus potentially less hidden.

Recommendations

Having examined early stage software design workshops and identified potential links with the cognitive dimensions framework. A number of conclusions can be drawn about the exploration of the design space. Some arise from reflections on the workshops themselves while others are the consequence of examining how the cognitive dimensions framework could inform this type of design activity.

Get into problems Early stages of development suffer from often being too open.

This lack of constraints means that design details can be proposed and agreed with little consideration. Only when enough detail is established do decisions demand a more thorough and careful examination and justification.

Approaches to avoiding decisions in a vacuum encourage inherent problems to be confronted early. Two examples of this in the workshops studied are: (i) to promote the consideration of the problems arising from different perspectives (such as internal and external); (ii) exaggerate factors to constrain the problem space, such as requiring a specifically small screen size.

Feed creativity Initial design concepts lack details. For a design team to work effectively with them they must be confident to work creatively in order explore a design space. This requires the setting to be one in which the ethos is to find interesting ideas and avoid "solutions".

Design representations should enable provisonality or variablity so as to limit their treatment as definitive representations. Similarly representations should be understood as being part of a process of iterative exploration, and hence they are best viewed as transient representations.

Too much common knowledge within a team can discourage the exploration of alternatives. This is exacerbated if they are exploring aspects of system use and operation outside their collective expertise.

Less selectivity One of the factors that appears to limit effective exploration of the design space is a tendency to focus on some facets of a problem and ignore others. The potential to provide support for exploration that discourages this can be considered. This could include techniques such as systematically reviewing decisions and their implications from different stakeholder perspectives.

Visualising The use of visual sketching is a useful means of implicitly managing and experimenting with design alternatives. This appears to be particularly valuable when considering user activity at the device, as it goes some way towards bringing competing issues together in a single representation. Other low fidelity prototyping methods such as paper prototyping serve a similar purpose.

In general we cannot claim these points to be in any way comprehensive, since the focus of analysis within the workshops has been selective, and similarly there is no claim regarding the adequacy of the dimensions examined.

Conclusions

We have argued that the early stages of software design have distinctive features that are not supported by a wide range of software engineering practices which focus upon development once a design concept is well established. As such early concept design is a process that is complicated by its openness and the unbounded opportunities and promises associated with it. Establishing sufficient details for design decisions and technical assessment to be grounded is core to exploring the design space. Hence, it is valuable to understand how effective exploration takes place, and thus how productive design arguments and development proceed. This problem has been addressed by endeavoring to apply the cognitive dimensions framework as a means of analysing how the design space is explored in three software design workshops involving professional developers engaging with the same given design brief.

The cognitive dimensions framework has generated a lot of interest as a tool for analysis and assessment of complex interactive systems. The frameworks, and derivations of it, have predominantly been the instruments to conduct analysis. By contrast, in this work we have employed the framework for assessment of observation data gathered with no specific analytic setting. Our approach has been to develop a rational basis for focusing upon and interpreting specific points in the data from the workshops and thus map observed data to concepts in the framework. Future work in the area would hope to develop this analysis approach further. One particularly interesting direction would be to focus more on the visual representations used to articulate and support the design deliberations.

Reflecting upon this interpretation of the data and what appear to be common features of the analysis as a whole we have been able to develop some recommendations for improving the productiveness of early stage software design. The recommendations while based upon the research and analysis identify features of productive design and development that not uncommon to inter-disciplinary group work. Thus while the use of the cognitive dimension framework in this manner is novel the resulting insights are closely reflect elements of good practice.

Table 1 .

 1 Relating deliberation topics to the framework concepts (*** = highly relevant; **=relevant; *=possibly relevant)

			Viscosity	Visibility	Dependencies	Hidden	operations	Hard mental	Provisionality	Commitment	Premature	Abstraction
	Mental effort		*		**	***	***	***	**
	Physical effort		***	***	*			***	**	**
	Actively -	Creating		*	***	**	**	**	*
	doing things	Modifying	***	*	***	**			*
	Non active (ie. navigating)		**	***	*					*
	Meaningfulness				**	***	*	**	***

Table 2 .

 2 Assessment of workshop 1 focused upon discussions at selected key points:

	Locus of
	decision	What participants discussed and basis for their argument	User focus
	timestamp
	[12:01.1]	Participants agree on there being no need to model road traffic
		lanes. Argument based on avoiding complexity, dependencies
		and whether lanes are required by the brief.
		Rationale: avoiding physical effort and implicit mental effort,
		making code creation easier.	Internal
		Dominant framework concepts: Provisionality and Premature
		Commitment
		The implications for tutors and student users discussed.
		Rationale: mental effort and physical effort, especially when
		creating a configuration.	External
		Dominant framework concepts: Provisionality and Premature
		Commitment
	[23:02.8]	Revisiting the modelling of the lanes with a focus upon the
		integrity of the simulation (e.g. traffic queuing).

Rationale: reducing mental effort and physical effort and meaningfulness Dominant framework concepts: Abstraction and Premature Commitment Internal Rationale: meaningfulness for the tutor Dominant framework concepts: Abstraction External [49:33.4] Revisiting more details about the operation of the lanes model. Rationale: the "perfect" simplification reducing mental effort. Dominant framework concepts: Premature commitment

Table 3 .

 3 Assessment of workshop 2 focused upon discussions at selected key points

	Locus of
	decision	What participants discussed and basis for their argument	User focus
	timestamp
	[0:47:49]	Debating how best to implement the propagation of traffic flow
		information.
		Rationale: referring to patterns of processing, meaningful	Internals
		software engineering concepts.
		Dominant framework concepts: Abstraction
		Rationale: an architecture offering users an easy link between
		changing configurable elements and seeing the consequences.	External
		Dominant framework concepts: Viscosity
	[1:01:10]	Discussion of where best to position behavioural rules in the
		data model.
		Rationale: size and complexity of alternative options imposing
		mental effort making modifications hard to manage. Software	Internal
		pattern approaches considered as meaningful concepts.
		Dominant framework concepts: Hidden dependencies
	[1:17:36]	Discussing a conflict between cars initiated with a behavior
		when in that behavior might get modified. [Unresolved due to	Internal
		time limitations]
	[1:26:45]	User interface design discussed, considering providing: pause,
		fast forward and re-set style controls, and showing actual cars
		and their movement. Rationale: prior decisions regarding technical model dominate	External
		considerations.
		[Unresolved]
	[1:31:56]	Discussing various other interaction design options.
		Rationale: mental and physical effort when a viewing simulation (passively exploring simulation as it runs).	External
		Dominant framework concepts: Visibility
	[1:41:44]	Discussing how intersections can inferred from overall road
		grid (and the implications) of that.

Rationale: mental and physical effort when creating the tool to cope with the problem. Dominant framework concepts: Hidden dependencies Internal

Table 4 .

 4 Assessment of workshop 3 focused upon discussions at selected key points

	Locus of
	decision	What participants discussed and basis for their argument	User focus
	timestamp
	[0:21:09]	Discussion how junctions are created and configured by users.
		Rationale: reducing physical and mental effort when creating a
		road layout.	External
		Dominant framework concepts: Premature commitment and
		Provisionality
		Discussion how junctions might be manipulated by users.
		Rationale: reducing physical effort and mental effort when
		manipulating and when viewing a road layout.	External
		Dominant framework concepts: Hidden dependencies and
		Visibility and Viscosity
	[0:41:13]	Discussing junction behaviour in detail with an emphasis upon
		the representation and configuration of traffic light behaviour
		Rationale: Modifying and passively viewing configurations considered, as well as meaningfulness for users and the physical	External
		effort involved.
		Dominant framework concepts: Hidden dependencies
	[1:14:03]	Discussing how to show and edit junction details (popping-up
		versus in side bar).	External
		Rationale (as above) some choices deferred to "prototype".
	[1:27:48]	Discussing differentiating modes of use: configuring;
		experimenting and running. Rationale: High level concepts of purpose (meaningfulness).	External
		Dominant framework concepts: Abstraction
	[1:31:05]	Discussion of feedback and visualising feedback and providing
		tabular results.
		Rationale: reducing mental effort and allowing results to be	External
		navigated with little physical effort
		Dominant framework concepts: Visibility
	[1:33:49]	Considering the potential of real-time configurable simulation
		and value of seeing immediate cause and effect.
		Rationale: allowing modifications and passively interpreting the results to infer meaningful relationships	External
		Dominant framework concepts: Visibility and Hidden
		dependencies
	[1:47:53]	Summarise points requiring clarification	Internal

For more information on these resources the reader is direct to: http://www.ics.uci.edu/designworkshop/videos.html.

Comprehensive details of this project, the developer tasks and the data are available at: http://www.ics.uci.edu/design-workshop, also see[1].

Acknowledgements

The author is grateful for being able to access to the workshop resources that served as a basis for this paper. It should be noted that the results described in this paper are based upon videos and transcripts initially distributed for the 2010 international workshop "Studying Professional Software Design", as partially supported by NSF grant CCF-0845840. For more information on these resources the reader is direct to: http://www.ics.uci.edu/design-workshop/videos.html. The author is also indebted to reviewers' comments on earlier drafts of this paper.


Malte Ressin
email: malte.ressin@uwl.ac.uk

Cecilia Oyugi
email: cecilia.oyugi@uwl.ac.uk

José Abdelnour-Nocera
email: jose.abdelnour-nocera@uwl.ac.uk

David Lee
email: david.lee@vocalink.com

Dharam Panesar
email: dharam.panesar@uwl.ac.uk

Exploring Local Cultural Perspectives in User Interface Development in an Indian Offshoring Context -a view from the UK

Keywords: offshoring, outsourcing, culture, software development

In this paper, we present the results of an exploratory case study on the impact of culture on software development in an offshoring context in India. Our research aims to understand the role of culture in outsourced software development. We interviewed human-computer interface professionals such as frontend developers, user interface designers and usability specialists working for a software development outsourcing vendor in India. The interviews were analysed for occurrence of common themes. Thereafter the cultural models of Hofstede and Hall were used to make sense of these emerging themes.. Our results indicate that cultural influence occurs and has an overarching influence in software development. Three proposals are made in response to the cultural issues highlighted.

Introduction

Offshoring has been an attractive option for some western countries mainly due to the lower costs involved. PricewaterhouseCoopers carried out a research establishing that 79% of the companies in western countries indicated that lower transactional costs were their main reason for offshoring [START_REF]Offshoring Set to Double in the Financial Services Sector by 2008[END_REF]. Other important reasons that have driven the developed nations to offshore include the shortage of skilled workers and the continued improvement of the global transport and communication network. Initially, the IT industry started by offshoring services that are low cost, such as IT help desk call centres. However, development in offshoring has seen the IT sector expand to offshore complex high-end skills and knowledge work activities such as software development. It is predicted that this type of activity will continue to grow. For instance, NASSCOM predict Indian IT business process outsourcing revenues of USD225 billion by 2020 [START_REF]NASSCOM: IT-BPO Sector in India: Strategic Review 2010[END_REF]. Since cost is a central consideration while making a decision to offshoring, it is possible that other issues such as cultural differences between the offshoring client and the offshoring vendor are easily overlooked. Cultural differences have the potential to affect not only the software development process but also the product itself (for example in the cases where localisation is involved).

The study of how culture relates to ICT development is a growing discipline in the Human Computer Interaction (HCI) community. However, most of the current work in this area has been on how culture affects the user interaction with the end product (e.g. [START_REF] Yeo | Global Software Development Lifecycle: An Exploratory Study[END_REF], [START_REF] Vatrapu | Culture and Usability Evaluation: The Effects of Culture in Structured Interviews[END_REF] and [START_REF] Oyugi | Evaluation methods and cultural differences: studies across three continents[END_REF]). The focus of this paper is the importance of cultural implications for offshoring which have not been extensively researched. This report is a follow-up of a larger research where an on-line questionnaire was implemented to investigate the effects of culture on the quality of software in an offshoring context [START_REF] Lee | An investigation into the relationship between quality, national culture and cost in offshore software development[END_REF]. The web based survey attracted 436 responses representing 44 declared nationalities. The regional / country groups represented were West (UK, US and Australia), Eastern Europe (Hungary, Moldova and Romania) and Asia (India, Bangladesh and China). The data analysis of the online questionnaire suggested that there is a significant difference in attitudes occurring between the western clients and the offshoring vendors. Consequently, this can lead to misunderstandings between the two players which can in turn manifest in terms of poorly developed software.

Cultural considerations within offshoring

Culture is a difficult and elusive concept to define partly because of the pluralistic interest that it has gained from various academic disciplines with each of them having its own focus [START_REF] Williams | Keywords: A Vocabulary of Culture and Society[END_REF]. As a result of the varied understandings of the concept of culture, authors such as Honold propose that researchers should select the definition of culture that best suits their context [START_REF] Honold | Culture and Context: An Empirical Study for the development of a Framework for the Elicitation of Cultural Influence in Product Usage[END_REF]. Therefore, the definition that will best suit the scope of this research is the one based on shared value patterns across individuals and within groups. Specifically, Hofstede's definition of culture will be adopted during this investigation: "Culture is the collective programming of the mind which distinguishes the members of one group or category of people from another" ([9], p. 9). This computer programming parallel implies that all people have comparable brains and refers to culture as the 'software of the mind'. This means that the patterns of thinking, feeling and acting are as a result of culture which acts like 'mental programs'. Further, these 'mental programs' become part of people's lives during their interactions with the environment when growing up.

In order to better understand customs and practices in a target culture, researchers have used the concept of cultural models. These models are based on the assumption that cultural differences are a result of social learning through interaction with the environment which has taken place for long periods of time. Two of these models, Hofstede's [START_REF] Hofstede | Culture's consequences: Comparing values, behaviors, institutions, and organizations across nations[END_REF] and Hall's [START_REF] Hall | Beyond Culture[END_REF], will be considered in this study.

Hofstede [START_REF] Hofstede | Culture's consequences: Comparing values, behaviors, institutions, and organizations across nations[END_REF] proposes that culture varies along relationships with people (individualism vs. collectivism), the extent to which a culture embraces social inequality (power distance), the extent to which members of a culture tend to stay away from uncertain situations (uncertainty avoidance), the degree to which people prefer values of success and competition over modesty and concern for others (masculinity vs. femininity), and finally their relationship to time horizon (long term vs. short term orientation).

In his cultural model, Hall [START_REF] Hall | Beyond Culture[END_REF] proposes that a culture is either high or low context, is monochronic or polychronic in its orientation to time, decodes and acts on messages slowly or quickly and has differences in its sense of space dimensions.

The cultural dimensions proposed by Hofstede have been extended and applied in offshoring for example by [START_REF] Carmel | Offshoring information technology: sourcing and outsourcing to a global workforce[END_REF]. However, the extent to which these theoretical cultural dimensions continue to be relevant and extendable has been questioned (e.g. [START_REF] Mcsweeney | Hofstede's Model of National Cultural Differences and their Consequences: A triumph of faith -A failure of analysis[END_REF], [START_REF] Baskerville | Hofstede Never Studied Culture[END_REF], [START_REF] Ratner | Theoretical and Methodological Problems in Cross-Cultural Psychology[END_REF] and [START_REF] Kruger | Hofstede's VSM-94 Revisited: Is it reliable and valid[END_REF]). Nonetheless, Hofstede has aptly responded to some of this criticism and his work remains highly influential in the area of cross-cultural research [START_REF] Hofstede | Dimensions Do Not Exist -A Reply to Brendan McSweeney[END_REF]. This paper will therefore use the theoretical underpinning of the cultural models of Hofstede [START_REF] Hofstede | Culture's consequences: Comparing values, behaviors, institutions, and organizations across nations[END_REF] and Hall [START_REF] Hall | Beyond Culture[END_REF] to understand how cultural differences can and do impinge on global software development.

Methodology

To gather data for the study, we got an opportunity to conduct interviews with employees of an Indian offshoring software development company. As contact to our host companies prior to our field work was informal, we decided to use semistructured interviews for our data gathering to account for the unknown range of access we would have on location. We therefore developed a solid interview script which would allow us to explore the subject area (cultural influences on the development process in offshoring projects), yet retain flexibility in branching out into the specialist areas of knowledge of our unknown interview partners.

The interview script was developed iteratively, taking as a starting point the survey questions from [START_REF] Lee | An investigation into the relationship between quality, national culture and cost in offshore software development[END_REF]. The interviews started off by asking the interviewees about their exact role, work experience and education. They then continued with questions about the interviewee's perceptions of quality in software, both absolutely and in relation to schedule and budget constraints, as well as in relation to client's and the host company's interests. Further topics discussed in the interviews included requirements gathering, specifications and documentation, the working relationship to clients and the employed development methodologies.

In some questions, we asked interviewees for their opinions and judgement. For example, question 14 was:

Consider the three targets Schedule, Budget and Quality. Which one is the most important for you personally? In your opinion, which one does your employer (the offshoring vendor) value most? Which one do your clients value most?

We also allowed interviewees to simply relate to previous experiences. For example, questions 5 and 6 were:

Tell me about the most successful outsourcing project that you were part of. How did you know it was successful? What do you think were the reasons for its success?

Tell me about an outsourcing project you were part of that did not go well. What were the major problems? What do you think caused the problems? How could the problems have been corrected or avoided? If that didn't happen, why do you think it didn't happen?

Last but not least, we gave interviewees the opportunity to hypothesize. For example, question 16 was:

If you could change anything in the way your software is developed, what would that be and why?

Depending on the answers, additional questions were inserted at the interviewer's discretion to deepen or clarify a point, etc.

Our host company has more than 10.000 employees working on outsourcing services across the whole range of software development services. Development is mostly done in several locations in India, but subsidiaries in several overseas countries exist. Fifteen interviews were conducted over six work days at two of our host company's sites in Mumbai and Pune. They took between 35 and 55 minutes (average 43:16). Interviewees worked on user interface development for website and software development offshoring projects in the roles of frontend developer (5), user experience specialist [START_REF] Honold | Culture and Context: An Empirical Study for the development of a Framework for the Elicitation of Cultural Influence in Product Usage[END_REF] , and project manager [START_REF]NASSCOM: IT-BPO Sector in India: Strategic Review 2010[END_REF].

In addition, one additional interview with a user experience specialist and a group session with ca. 30 HCI professionals at another offshoring company in Pune. This second company also offers offshoring for software development projects with development centres in several locations in India and additional offices overseas.

Data Analysis and Results

To analyse the data, the researcher who collected the data from India and one other independent researcher listened to the audio recordings of the interviews independently. The goal of this exercise was for each researcher to independently hand-pick important themes from the interviews and then compare the recurring themes between the two researchers. This structure was used to mitigate for individual bias and increase reliability. Therefore, the interviews were examined for common or contradictory themes indicated in the answers of the interviewees. Behaviour and implications as interpreted by us were also considered. The discovered themes were compared with cultural models of Hofstede and Hall, and pre-existing categories derived from previous cultural research were also underpinning the higher-level analysis. To mitigate for individual bias and increase reliability, analysis was conducted independently and in a parallel fashion by two of the authors. After comparing notes, the authors used their agreed results to create a number of conjectures how cultural differences manifest themselves in offshoring development.

Following is a highlight of the most important but expected cultural dependencies from the interview analysis. For example, interviewees regularly deferred questions on their own views or opinions to the authority of their superiors and loyalty to their company. In another example, many interviewees went out of their way to avoid statements which could be interpreted as criticizing others. When asked about it, they elaborated that criticism on the work of others were demeaning and therefore ethically questionable.

Most interviewees had BSc or MSc degrees in a software engineering discipline and had changed into HCI or a usability-related job role at a later date. Often, this change had been motivated by personal interest. However, almost no interviewee had received formal education in the HCI field. As far as their knowledge around HCI and usability was concerned, they were essentially self-taught. This is hardly surprising since HCI as a discipline is comparatively young and at the time many of today's professionals were studying, the number of HCI-related studies on offer was more limited than today.

During our interviews, the criteria comprising quality in software products was strongly influenced by the role of the interviewee. Those in an engineering role, e.g. frontend developer, considered quality in code-related terms like absence of bugs or fast execution speed/short application reaction time. Interviewees in a role related to classical usability, e.g. usability specialist, considered quality in terms of user-related terms like intuitive use and easy learnability. This is not particularly surprising: admittedly, an individual's role and its associated aims influence the perception of quality, and respective criteria must be informed by one's own discipline. Otherwise, a confounding impact on project and work aims would follow. However, the strong apparent dependence on role is surprising insofar as, as previously discussed, most interviewees have a code-related background and can be expected to have a certain knowledge in associated technical quality criteria. In that light, we would have expected code-related quality criteria to feature in each interviewee's answer to at least some extent. It is also noteworthy that at least to some extent, quality goals seem to be handled on an individual basis and no project-or company-overarching mantra or guideline was mentioned.

The actual development methodologies used at the host company in the user interface development were difficult to determine. Interviewees' statements did not always align in that regard. Some interviewees identified the development methodologies as linear or even categorized it specifically as Waterfall model. Other interviewees on the same project or even the same team described the development methodologies as agile. Unfortunately, as we did not consult additional documentation, we cannot be sure what methodology is or was actually in use in the respective projects.

A number of interviewees mentioned that they found Western clients easier to deal with than Indian clients because of the explicit nature of the work assignment. Interviewees stated that Western clients usually have a very clear idea what they want and communicate their expectations, often in relation to their budget. Indian clients on the other hand, on top of usually having stricter budget limitations, seem to keep project scopes more flexible and negotiate it together with the vendor, often in conjunction with project costs.

Discussion

We found clear indications supporting Hofstede's views on authoritative hierarchy, and reluctance to criticize in collectivist cultures. In addition to that, we came up with a number of conjectures relating our observations with Hall's cultural dimensions, in particular High Context vs. Low Context, and India being a high-context culture:

• Quality criteria are not necessarily elaborated explicitly. Instead, it is left in the interpretation of each individual on the project. • Work processes are not explicitly specified or described. Individuals instead find their role and their work processes through interpretation. • Qualification is considered less dependent on formal education, and is instead seen in personal interest and effort. • Implicitness, possibly in combination with local negotiation customs, conflicts with the explicitness in software development, in particular writing code.

Summarized and re-phrased, the general relative nature of high-context cultures means that virtually everything can be subject to vagueness and/or post-hoc interpretation. This does not stop in software development.

There is evidence to certain collectivist traits as well. Further, at a lower level of practice, there seems to be evidence that IT professionals are converging culturally in certain attitudes to quality and management [START_REF] Lee | Cultural differences affecting quality and productivity in Western / Asian offshore software development[END_REF].

Consequently we propose three points of action as a result of this exploratory investigation. First, the issue of quality of software needs to explicitly be defined at the start of the project especially from the western client's perspective. Second, the methodologies used during the software development process as well as code documentation need to clearly be addressed at the start of the project. Third, in-house training could be encouraged to standardize the software development process because of the lack of formal qualification among the software vendors.

Conclusion

We believe that these conjectures provide an interesting insight into the offshoring vendor context. Unfortunately, we have to acknowledge limitations to the scope of our study. The number of individuals interviewed, as well as the fact that almost all of them worked for the same company and exhibited similar career paths, impacts the applicability on the larger group of HCI professionals.

In future research, our data and results might be put in comparison, for example by comparing HCI professionals from India to HCI professionals from other countries, particularly those with low-context cultures. Quantitative data gathering and statistical analysis should be employed to test those conjectures which can be operationalised, e.g. the correlation between quality criteria and role despite constant education/background. Future qualitative data could include formal project documentation where available. Focus groups could discuss items which were ambiguous in the interviews, for example regarding the contradicting statements about development methodologies.

There is a certain amount of criticism in the researcher community to the general concept of trying to "measure" culture along dimensions [START_REF] Hall | The Cross-Cultural Web[END_REF], or to apply such classifications to software development [START_REF] Abufardeh | The Impact of Global Software Cultural and Linguistic Aspects on Global Sofware Development Process (GSD): Issues and Challenges[END_REF]. We believe that a comparison with Hofstede is legitimate, though, since both his and our participants are technologists.

Offshoring will remain an important aspect of software development. The dependency between client and vendor cultures continue to be in the spotlight, especially considering that it is not inconceivable any more that the direction outsourcing has been taking in the past, from West to East, might eventually reverse.


Adrian Fernandez
email: afernandez@dsic.upv.es

Emilio Insfran
email: einsfran@dsic.upv.es

Silvia Abrahão
email: sabrahao@dsic.upv.es

José Ángel Carsí
email: pcarsi@dsic.upv.es

Emanuel Montero
email: emontero@dsic.upv.es

Integrating Usability Evaluation into Model-Driven Video Game Development

Keywords: Video Game, Usability Inspection, Model-Driven Development

The increasing complexity of video game development highlights the need of design and evaluation methods for enhancing quality and reducing time and cost. In this context, Model-Driven Development approaches seem to be very promising since a video game can be obtained by transforming platformindependent models into platform-specific models that can be in turn transformed into code. Although this approach is started to being used for video game development, there is a need for usability evaluation methods specifically tailored to this type of development process. In this paper, we present a usability inspection method that can be used along all the stages of the modeldriven video game development. The method relies on a Usability Model that is aligned with the ISO/IEC 25010 (SQuaRE) standard and decomposes usability into measurable attributes and metrics specific for the video game domain.

Introduction

The video game development industry is a strong economic sector that deals with the development of highly interactive software, i.e., video games, for a wide variety of technology platforms such as PCs, consoles, Web browsers, and mobile devices. The interaction between the game and the players is a critical factor in the success of a video game. Usability and playability are considered to be the most important quality factors of video games [START_REF] Nacke | From Playability to a Hierarchical Game Usability Model[END_REF]. Usability is defined as the degree to which the video game can be understood, learned, used and is attractive to the user, when used under specified conditions [START_REF]Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models[END_REF]. Playability is defined as a collection of criteria with which to evaluate a product's gameplay or interaction [START_REF] Järvinen | Communication and Community in Digital Entertainment Services[END_REF]. Playability is often evaluated by using early prototypes and iterative cycles of playtesting during the entire video game development cycle. However, the evaluation of usability in current video game development practices is often deferred to late stages in the game development cycle, thus signifying that usability problems from early stages may be propagated to late stages of the development, and consequently making their detection and correction a very expensive task.

A model-driven video game development approach could provide a suitable context for rapid iteration early in the development cycle. Platform-independent (or platform-specific) models (i.e., PIM or PSM) can be evaluated during the early stages of video game development to identify and correct some of the usability problems prior to the generation of the source code of the final video game application. We are aware that not all the usability problems can be detected based on the evaluation of models since they are limited by their own expressiveness and, most important, they may not predict the user behavior and preferences. However, as suggested by previous studies [START_REF] Andre | Determining the effectiveness of the usability problem inspector: a theory-based model and tool for finding usability problems[END_REF], the use of inspection methods for detecting usability problems in product design (models in our context) can be complemented with other evaluations performed with end-users before releasing a video game to the public.

The contribution of this paper is a usability inspection method that can be integrated in early stages of model-driven video game development. This method relies on a Video Game Usability Model which decomposes the usability characteristic proposed in the ISO/IEC 25010 (SQuaRE) standard [START_REF]Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models[END_REF] with new usability attributes for the video game domain. These attributes are quantified through their association with generic measures that can be operationalized by establishing a mapping between their generic definition and the specific modeling primitives of the software artifacts to be evaluated.

This paper is organized as follows. Section 2 discusses usability evaluation techniques for video game development. Section 3 discusses our strategy for integrating usability into model-driven video game development. Section 4 describes the Video Game Usability Model while Section 5 proposes a strategy to apply this model for performing early usability evaluations in model-driven video game development. Finally, Section 6 presents our conclusions and further work.

Related Work

The state of the art for game development in Software Engineering has been recently summarized in a systematic literature review [START_REF] Ampatzoglou | Software engineering research for computer games: A systematic review[END_REF]. The results of this review show a significant lack of studies in the key dimensions of video game quality: playability and usability. However, some efforts have been made to integrate current usability evaluation methods into the game development industry and game research, and a brief review of current game usability techniques has been provided in [START_REF] Nacke | From Playability to a Hierarchical Game Usability Model[END_REF].

Some usability evaluation methods (usually referred as empirical methods) are based on capturing and analyzing usage data from real players. Some representative examples are think-aloud methods and focus group [START_REF] Greenwood-Ericksen | Usability Breakthroughs: Four Techniques To Improve Your Game[END_REF]. In think-aloud methods, the player sits down to play the video game and narrates his experiences while a user experience evaluator sits nearby listening and taking notes. In focus group methods, game designers gather a small group of potential game players together to discuss their opinions of the design of the interface, along with the game mechanics and story.

Other kind of usability evaluation methods (usually referred as inspection or analytical methods) are performed by expert evaluators or game designers and are based on reviewing the usability aspects of software artifacts (which are commonly game user interfaces) with regard to their conformance with a set of guidelines. The most representative example is heuristic evaluation, which is a common inspection method for evaluating the usability of video game interfaces in both early and functional game prototypes. Examples of heuristic evaluation methods were presented in the work of Federoff [START_REF] Federoff | Heuristics and Usability Guidelines for the Creation and Evaluation of Fun in Video Games[END_REF] and Pinelle et al. [START_REF] Pinelle | Heuristic Evaluation for Games: Usability Principles for Video Game Design[END_REF], in which a set of guidelines for creating a good game were defined, based on the experience of a game development case study, and PC game reviews, respectively.

In this paper, we focus on inspection methods since they do not involve the players' participation and can be employed during the early stages of the game development process. Specifically, our method extends previous approaches by providing specific video game usability attributes and measures that can be quantified by means of model-transformations. The objective is to reduce the subjectivity of existing methods that are mainly based on plain checklists of desired features with no specific guidelines on how they can be applied. Model-driven development provides a suitable context for early usability evaluations since traceability between high-level artifacts (models) and source code is maintained throughout the development process [START_REF] Abrahão | Usability Evaluation of User Interfaces Generated with a Model-Driven Architecture Tool[END_REF]. Finally, approaches based on usability models have been successfully employed as inspection methods in other domains, such as model-driven software development [START_REF] Abrahão | Early Usability Evaluation in Model-Driven Architecture Environments[END_REF] and model-driven Web development [START_REF] Fernandez | Integrating a Usability Model into a Model-Driven Web Development Process[END_REF]. However, as far as we know, no usability model has been proposed for model-driven video game development.

Usability in Model-Driven Video Game Development

The usability of a video game application obtained as a result of a transformation process can be assessed at several stages of a model-driven development process. We propose the use of a Video Game Usability Model which contains a set of usability attributes and measures that can be applied by the video game designer in the following phases of a MDA-based development process: i) in the PIM, to assess different models that specify the video game application independently of platform details (e.g., screen flow diagrams, screen mock-ups, screen navigation diagrams); ii) in the PSM, to assess the concrete design models related to a specific platform; and iii) in the code model, to assess the generated video game application (see Fig. 1).

Fig. 1 Integrating a Video Game Usability Model into model-driven development processes

It should be noted that the process is driven by the PIM, which is automatically transformed into a PSM, and this PSM into source code. Therefore, the evaluations performed at the PIM produce a platform-independent usability report that provides a list of usability problems with recommendations to improve the system analysis stage (Fig. 1 (1A)). Changes in the PIM are reflected in the CM by means of model transformations and explicit traceability between models. This prevents usability problems to appear in the generated video game application (CM).

The video game designer should select the set of relevant usability attributes and measures from the Video Game Usability Model. There are some usability attributes (e.g., degree of attractiveness) that can only be evaluated on a specific platform and taking into account the specific components of the video game UI (PSM) or the components that build the final application (CM). Evaluations performed at the PSM produce a platform-specific usability report. If the PSM does not allow obtaining an application with the required level of usability, the report will suggest changes to correct the following: the PIM (Fig. 1 (2A)), the transformation rules that transform the PIM into PSM (Fig. 1 (2B), and/or the PSM itself (Fig. 1 (3B)). Nevertheless, the evaluations at the PIM or PSM level should be done in an iterative way until these models allow generating a video game application with the required level of usability.

Finally, evaluations performed at the CM level produce a final application usability report. Rather than suggest changes to improve the final application (CM), as is usual in other approaches, this report will suggest changes to correct the PIM (Fig. 1 (3A)), the transformation rules (Fig. 1 (3C)), and/or the PSM (Fig. 1 (3B)).

Defining the Video Game Usability Model

The term usability has several definitions. In this work, we use the ISO/IEC 25010 (SQuaRE) standard [START_REF]Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models[END_REF] as the basis for defining our Video Game Usability Model. In this standard, three different quality models are proposed: the Software Quality Model, the Data Quality Model and the Quality in Use Model.

The goal of our Video Game Usability Model is to extend the Software Quality Model proposed in SQuaRE, specifically the usability characteristic, for specifying, measuring, and evaluating the usability of video games that are produced throughout a model-driven development process from the end-users perspective. The SQuaRE standard states that the usability of a software product can be decomposed into the following sub-characteristics: Appropriateness Recognisability, Learnability, Ease of Use, Helpfulness, Technical Accessibility and Attractiveness. However, these subcharacteristics are too abstract to be measured in a video game development context.

We therefore propose the decomposition of these sub-characteristics into more representative and measurable usability attributes of video games, and the association of each one of these attributes to specific measures, which can be calculated depending on the characteristics of the software artifact to be evaluated.

Usability Attributes for Video Game Usability

The decomposition of the aforementioned sub-characteristics into usability attributes is presented as follows, and is summarized in the second column of Table 1. These attributes have been defined by considering and adapting ergonomic criteria for user interfaces [START_REF] Bastien | Ergonomic Criteria for the Evaluation of Human-Computer Interfaces[END_REF] as well as knowledge from other domains such as Web development [START_REF] Fernandez | Integrating a Usability Model into a Model-Driven Web Development Process[END_REF], and the underlying usability principles from the existing body of literature in the video game domain [START_REF]Microsoft: Best Practices for Indie Games 3.1[END_REF][START_REF]Nokia: Top Ten Usability Guidelines for Mobile Games[END_REF].

Appropriateness Recognisability contains all the attributes of the video game that ease the understanding of the game. This sub-characteristic is decomposed into the following attributes: Visibility, which focuses on visual recognisability, and legibility by measuring the ease of perception of the game's graphic information; Interface Simplicity and Control Simplicity, which evaluate the complexity of the graphical user interface and the game controls, respectively; and Consistency, which focuses on the degree of similitude and coherence between the elements of the video game.

Learnability contains the attributes of the video game that allow players to learn how to play the game. This sub-characteristic is decomposed into the following attributes: Feedback support, which focuses on the game capability to provide information about the current state of the game and its players; and Tutorial Support, which verifies whether the game offers a tutorial to teach the players how to play it.

Ease of Use contains all the attributes of the video game that facilitate players' control and operation, both inside and outside gameplay. This sub-characteristic is decomposed into the following attributes: Control Consistency, which refers to the degree of semantic similitude of the players' actions with regard to the game controls; Internal Navigational Simplicity, which refers to how to navigate between the menu options of a single screen; and External Navigational Simplicity, which concerns how to navigate between game screens.

Helpfulness contains the attributes of the video game that provide help when the players need it. This sub-characteristic is decomposed into the following attributes: Hint Support, which refers to the game's capability to provide useful hints with which to guide the players; and Goal Support, which refers to the video game's capability to provide clear goals for the players to pursue.

Technical Accessibility contains all the attributes that allow physically impaired users to play the video game. This sub-characteristic is decomposed into the following attributes: Subtitle Support, which refers to the game's capability to provide adequate subtitles for hearing impaired players; and Magnifier Support, which concerns the game's capability to provide adequate sized subtitles for visually impaired players.

Attractiveness contains the attributes that make a video game more appealing to the players. This sub-characteristic is decomposed into the following attributes: Customization, which refers to how players can alter the game's graphical user interface and controls to fit their preferences; and Wait Reduction, which refers to the degree of inactive waiting the players are forced to undergo. It is worth to mention that we cannot guarantee that our usability model covers all the possible usability attributes for the video game domain. Our model is an attempt to operationalize subjective heuristics, usability guidelines and recommendations into usability attributes that can be quantified by means of measures. We focused on a set of usability attributes identified by the domain experts.

Generic Measures for Video Game Usability

Once the measurable usability attributes have been identified, generic measures are then associated with these attributes in order to quantify them. The measures are generic in order to ensure that they can be operationalized in different software artifacts (from different abstraction levels) from different model-driven video game development methods. For the sake of simplicity, only one of the proposed measures from the Video Game Usability Model is presented in Table 2. All the generic measures are summarized in the third column of Table 1.

Table 2. An example of measure from the Video Game Usability Model

Measure

Shortest Return Path To Gameplay (SRPTG) Attribute Ease of Use / External Navigational Simplicity Description Minimum number of screens that players have to navigate in order to restart the game when the game is over Formula Minimum number of steps between the game over screen and the gameplay screen Scale Integer greater than or equal to 0 Interpretation A value of 0 signifies that the game has no menu screens, and players can directly restart when the game is over. Higher values indicate that the players have to navigate many screens before restarting the game.

Applying the Video Game Usability Model

In order to apply the Video Game Usability Model to a specific model-driven video game development, we follow a usability evaluation strategy. A typical video game development process consists in the following activities: requirements specification, game design, implementation, and playtesting, along with the usability evaluation. The usability evaluation is conducted by applying the following steps:

1. The Establishment of Evaluation Requirements. The purpose of the evaluation as well as all the factors that will condition the evaluation of the game are determined in this phase. Evaluation profiles are chosen in order to specify which model-driven game development method is employed, which type of video game is developed, what the target technological platform is, and at which target players the game is aimed. Given a specific model-driven game development method, software artifacts (models) and usability attributes from the Video Game Usability Model are selected to perform early usability evaluations. The measures associated with the selected attributes are operationalized.

2. Early Usability Evaluation. In this phase, each selected video game software artifact (model) is evaluated according to a set of measures. Each measure provides a numeric value within a specific threshold that indicates whether there is or not a usability problem in the video game. A usability report is consequently generated.

3. Usability Evaluation In-Use. Even when early usability evaluation is performed on video game software artifacts (models), the game should also be further evaluated from the end-users (players) perspective in a specific context of use. This usability-centered playtesting is well documented in the game community [START_REF] Greenwood-Ericksen | Usability Breakthroughs: Four Techniques To Improve Your Game[END_REF]. Since this paper focuses on early usability evaluation in model-driven development, usability evaluation in-use is not within the scope of this work.

After usability evaluations, game designers should perform changes to the models in order to solve the usability problems. Early usability problems detected in the game design can be corrected in each model of the corresponding development stage (e.g., PIM, PSM) prior to the code generation.

Conclusions

This paper presented a usability inspection method that can be used in early stages of model-driven video game development. The method relies on a usability model that has been developed specifically for the video game domain. This model is aligned with the SQuaRE standard and allows the evaluation of the usability of video games developed according to a model-driven development process.

The inherent features of model-driven development provide a suitable context in which to perform usability evaluations since usability problems that may appear in the final application can be detected and corrected at the model level. Model-driven development also allows automating common usability evaluation tasks that have traditionally been performed by hand. The proposed usability inspection method can also be integrated into any model-driven video game development processes by establishing the relationships between the generic measures from the usability model and the modeling primitives of the different software artifacts of the selected development process.

Nevertheless, we are aware that a further comparison with the users' perception on the usability of a video game obtained by applying a model-driven development process is needed. For this reason, we are currently performing an empirical study to compare the predicted usability of two video games measured using a set of measures from the Usability Model with the perceived usability of these video games measured using a modified System Usability Scale (SUS) [START_REF] Brooke | SUS -A quick and dirty usability scale[END_REF].

Future works include the empirical validation of the proposed measures with the participation of game software developers, and the empirical validation of the usability model's use in a real industrial model-driven game development project.

Table 1 .

 1 Decomposition of the SQuaRE into measurable attributes and generic measures

	Sub-characteristics Attributes	Measures
	Appropriateness	Visibility	Percentage of Screen Usage
	Recognisability	Interface Simplicity	Total Number of GUI Elements
		Control Simplicity	Total Number of Control Mappings
		Consistency	Ratio of Similitude Between Screens
	Learnability	Feedback	Total Number of GUI Elements Displaying
			State Changes
			Ratio of GUI Elements Highlighting State
			Changes
			Ratio of Meaningful Messages
		Tutorial Support	Tutorial Interactivity
			Tutorial Coverage
	Ease of Use	Control Consistency	Ratio of Similitude Between Colliding Game
			Actions
		Internal Navigational	Internal Menu Navigation Depth
		Simplicity	Internal Menu Navigation Breadth
		External Navigational Shortest Path To Gameplay

Acknowledgments. This research work is funded by the MULTIPLE project (MICINN TIN2009-13838), the FPU program (AP2007-03731) from the MEC-Spain.


Amin Rasooli
email: amin.rasooli@uni-rostock.de

Peter Forbrig
email: peter.forbrig@uni-rostock.de

Fattaneh Tagivareh

Collecting Users Profiles for Web Applications

Keywords: User Profiles, Web Application, Personalization, Web Design

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

Introduction

Most of the time, standard solutions provided by web design techniques have limited personalization ability. Owners would like to have their website usable, aesthetic and attractive according to their personal feeling. Any point such as design and user friendliness, content, services offered to the customer and etc. can play a significant role to make a website succeeds. The first impression the user gets of a website is through its appearance. She/he may like the website at his/her first view and finally be loyal to it while churn probability will be minimized. Many modern techniques have been presented in data personalization in order to collect behavioral information of the users; for example: suspension time in user interface, ratio of the observed links to the total number of links and user interaction on any accessible data [START_REF] Mobasher | Automatic personalization based on Web usage mining[END_REF], [START_REF] Schiaffino | User-interface agent interaction: personalization issues[END_REF]. These new inputs can be employed to understand the hidden interests of users in order to choose the best personalized data for them. We started by introducing the goals of our work and now we present our experiment in Section 2. Finally, we will summarize the main contributions of our work in Section 3. Because of lack of space we focus on our experiment. A discussion of related work can be found in [START_REF] Rasooli | Categorize Websites based on design issues[END_REF].

Experiment

Based on the analysis of popular web sites different designs were collected. These designs have been clustered in 30 different types. These types were presented to users of social networks and their votes were collected according to the following rules. Three choices were displayed to a user. After a user selected his/her favorite design a new page provided more choices.

The system had announced to the users that the first choice they observe is not necessarily an optimized one and they have to declare their vote without looking at the presented order. 58% of the users have voted to the first choice, 26% to the second one and remaining 16% to the third choice. The software contains a learning system in such a way that it updates the design rating considering the positive vote and the user's cluster. Therefore, when the user gives his/her positive vote to a design, the ratio of votes given to a specific design toward the total votes was added to its rating. This value divided by remaining designs in a group will also be subtracted from the total number of designs. Similarly, designs will tend to be optimized which will result in a powerful learning system. The total number of the participants was 481 with 840 valid votes for the existing design templates, while 664 additional votes were added to first level votes taking into account the details.

Results

Color Preferences

Colors with darker tones such as blue and brown were more attractive to men, while designs having a color spectra such as pink, purple, red and yellow, in comparison with other colors, were a prevalent trend among women's choices. Designs with the desired tone for men were 48% of total designs, 67% of which were voted as the first choice and the remaining 33% were voted as second choices. Designs with the desired tone for women were 30% of total designs, 82% of which were selected as the first choice while the other 18% were voted as secondary choices. The sampling set was composed of 268 male and 192 female participants. Designs were also tagged such that they were sorted in four groups from the darkest to the lightest tone. It was observed that women show more interest in lighter colors, whereas men show more interest in darker colors. In Fig. 1, the horizontal axis of the diagram shows the average dark to light approximate tone scaled from 1 to 4 and the vertical axis of the diagram indicates the redundancy of each group.

Fig. 1. Sex towards color

Since most of the participants who have taken part are from Iran and some European countries, the results in the Middle East and 1 st level European countries (more prosperous) have provided the most accurate results. Fig. 2 compares chosen countries and favorite kinds of colors of the participants.

Fig. 2. Color toward User's Location

As shown in Fig. 2, lighter color designs have attained higher ratings in Asia and the Middle East compared to other tones; meanwhile European countries have experienced a rather reversed regime. Asian countries, especially those in Middle East, have chosen light colors. In Fig. 2, the horizontal axis of the diagram shows the average dark to light approximate tone scaled from 1 to 4 while the vertical axis of the diagram indicates the percent of designs chosen by individuals in each group.

Time spent in website with relation to user's education

According to Fig. 3 those who have a higher education spend more time on a website. Many participants with a higher education have spent 40-45 sec time using the website. In this diagram, the horizontal axis shows the education level while each color is indicative of the average time spent on the website. The vertical axis shows the percent of designs chosen by individuals in each group. The average time spent on web pages as reported by the literature was higher than the time we inferred based on our research. There could be a solution by combining links with help information. People, who live in 2 nd level European countries, are more interested in greater number of links.

Fig. 5. Location towards number of links

Considering the interest of people from various regions in the world in higher or darker tone colors, Fig. 6 reveals the relation between the color variety and the location of the participants. In this diagram, the amount of color variety has been determined for each region. People from North America show less interest in high variety of colors. As can be observed, users of lower ages have chosen the greatest number of links. The trend in this diagram is similar to the previous one and it is possible to interpret relations between age and education. One of the horizontal axes is education in which value "1" denotes lower education levels and value "4" denotes higher education ones; while the other one is the number of links. The vertical axis represents the redundancy. It can be seen that lower education has been accompanied by the greatest number of links.

Summary

The paper presented some aspects that were analyzed based on experiments with users that have been attracted from social networks. Thze results can be summarized in the following way.

Users with lower education level together with users of lower income are interested to be placed the overview columns at the right. It can therefore be concluded that they have been more related to the Persian websites whose exploring experience was limited to simple issues in Iran governmental websites e.g. websites of gas card, post, Housings and etc. which usually have their column at right. One conclusion made from these observations was that exploring experience of a user has direct impacts on his/her favorite styles.

People who have education level less than bachelor, prefer less than 8 links. Users having an education level lower than master show the least attention to page components. They are also interested in greater number of links.

Users who have low income level like to visit a website with light colored and busy header pictures. On the other hand, users with high income level are keen to visit websites with warm colored and nature header pictures. Individuals whose average time spent on various web pages is more than normal, are interested in third type of websites which do not have columns or busy design.

Users older than 31 years choose the header picture from busy ones. They use the darkest colors to design the website and prefer plenty of pictures in it. With respect to the limitations such as participation of users in all ranges under study, some of the specifications have adequate resources while others lack such resources. For example, majority of the sampling population are Iranian students who will affect education level and financial situation as well as other specifications One other drawback experienced was related to the difficulty to bring people of other countries to agreement. The least number of participants were from Africa and Australia while the number of participants from America was not enough as well. It seems that the income criteria have not been answered properly. The major limitation of the research was in social networks in which users hardly trust newly released applications due to incidence of virus worms. Therefore, it will be rather difficult to satisfy those users.

Achievements of this research can be further employed in the design of dynamic websites which requires much time and cost; to conform page patterns regarding the tags from page classification in which the users have shown interest and to develop results obtained from observing users' behavior toward other practical areas.

Considering greater number of characteristics with more details in addition to more users can certainly impose a positive effect on the model and tagging the designs, meanwhile it will make results more accurate. Furthermore, if user's exploring behavior is recorded in longer period of time, the results will be of higher accuracy. A number of parameters have been considered here for the voting system and page ranking. For example, receiving feedback from the user affects its class cluster designs in such a way that adds a coefficient for the positive votes and subtracts it for the negative ones. Modification of these coefficients can lead to higher performance. Coefficient mentioned for distinction of specifications for each part of the website can also be altered. Changing the normalizing parameters can have positive effects on the results. Some characteristics which have been collected from questionnaires may lack enough accuracy. Besides, some people may not allow their demographic information to be published through social networks due to security issues.

Applying techniques to make them agree to do so, (for example through trust let techniques) can have significantly influence the accuracy of data.

Fig. 3 .

 3 Fig. 3. Spent time in website towards user's education

Fig. 4 .

 4 Fig. 4. Location towards average time spent in websites Fig. 5 illustrates the number of links in web pages since the average number of links towards each region has been specified on the diagram. The number of links affects user's concentration and accuracy of his/her choice. Whenever the number of links is greater, it would be more difficult for the user to choose his/her favorite link.

Fig. 6 .

 6 Fig. 6. Location towards color variety

Fig. 7 .

 7 Fig. 7. Location towards page complexity 3.5. Age towards number of links In this diagram, the horizontal axis has 4 values: 1 for the age group presented on the X axis, 2 and 3 for the age group of presented on the Y axis (between 18 and 31 years old which has been divided into two sets), and 4 for the age group of presented on the Z. Loads of the diagram are the number of links and the vertical axis represents the redundancy.

Fig. 8 . 9 .

 89 Fig. 8. Age towards number of links Fig. 9. Education towards number of links