modular abstract prototyping as an instrument to

Proceedings of TMCE 2012, May 7–11, 2012, Karlsruhe, Germany, Edited by I. Horváth, A. Albers, M. Behrendt and Z. Rusák

 Organizing Committee of TMCE 2012, ISBN ----

MODULAR ABSTRACT PROTOTYPING AS AN INSTRUMENT TO DEMONSTRATE SOFTWARE TOOL CONCEPTS FOR MULTIPLE STAKEHOLDERS Els Du Bois Product Development Artesis, Antwerp [email protected]

Imre Horváth Faculty of Industrial Design Engineering TU Delft, the Netherlands [email protected]

ABSTRACT The objective of this research is to provide an instrument to aggregate stakeholders’ opinion in an early phase of software development processes. Since not only the end users, but also other stakeholders should be taken into consideration, we had a challenge due to the possible multiplicity of the different stakeholders. Therefore, in order to be able to demonstrate software tool concepts at operational principle and implementation resources levels to various stakeholders, we have developed a specific methodology for modular abstract prototyping (MAP). Modular abstract prototyping offers the opportunity to combine, even dynamically adapt, generic and specific modules according to the viewpoints and demands of the stakeholders. The paper presents a state-of-the-art review in early prototyping. The theory of MAP has been derived based on the results of some forerunning research and additional assumptions. To operationalize the theory, we developed a practical implementation and application methodology of MAP. The paper presents this implementation and application methodology, and its application in testing early concepts of software tool for supporting designers in deciding on smart energy savings. Based on our experiences obtained in the conducted focus group sessions, we can conclude that MAP is an effective method to present software product concepts to multiple stakeholders in an early phase of their development. However, we consider MAP as a milestone towards a fully interactive abstract prototyping (IAP). Our follow up research will focus on the exploration of possibilities of a highly interactive real-time abstract prototyping by using

IAP skeletons and web-hosted object and knowledge repositories.

KEYWORDS Early development, multiple stakeholders, modular abstract prototyping, software tool concepts, focus group sessions

1. INTRODUCTION There is a growing need in the industry for new means to support testing of software tools in the early phase of their development, where they exist just as functional or procedural concepts. As for now, the available means are rather limited and more focused on the technical development of software tools, than on the demonstration of the operations and the impacts on the use environment [1]. Having new supportive means in the early phase of software development is important because the most influential decisions concerning the functionality, the manifestation, and the costs are made in this phase. Several papers have discussed that most of the detected faults in the existing software can be traced back to problems of requirements specification, preimplementation testing, and user conformance evaluations [2]. An important issue is that the activities in the different phases of software development, in particular in conceptualization and structural design, do not scale to precisely match the underlying needs of the users [3]. On the other hand, there is a large opportunity in these phases to develop and investigate multiple concept variants, as well as to modify concepts quickly and without large incurring costs.

1

Early prototyping of software (tool) concepts is a challenging task not only due to the incompleteness and vagueness of the information that is available in this stage, but also due to the lack of proper modeling, simulation and demonstration means. The term ‘abstract prototyping’ has already been used in the literature to describe the application of a set of means and methods for functional specification and enhancement of user interfaces. However, the term is used in a broader meaning and in a different context in our research. This more comprehensive interpretation is the result of our forerunning research, which explored that abstract prototyping offers much more opportunities, than just supporting interface design. It is in particular useful in the case of an all-embracing presentation concepts and demonstration of the proxy functionality and implementation of software tools to stakeholders. Typically, there are multiple stakeholders involved in a software development process, who usually have different demands and represent different opinions. This raises the need for an adaptable means by which it becomes possible to present software concepts concurrently to multiple stakeholders. A digital means could facilitate making demonstrations for dislocated stakeholders in a kind of virtual environment. This is an important aspect because bringing together all stakeholders for an on-site demonstration is often a complex and costly task. In addition, abstract prototyping can contribute to the success of customer-centered innovation and design. Moreover, it is also instrumental from the perspective of rationalizing and structuring the information for concept presentation [4]. Moreover, through abstract prototyping, software developers can rationalize the amount of efforts that they put into communication with the stakeholders. Another important issue is that the stakeholder’s feedback should be recorded in an effective manner and should be processed on a short notice. As one of the possible approaches, we have developed a methodology which is called modular abstract prototyping (MAP). This offers instruments for the demonstration of concepts of software tools to multiple stakeholders. This paper: (i) presents the assumptions, which underpin the methodology of MAP, (ii) explains the operationalization of the theory, (iii) discusses the implementation of the resources of MAP, and (iv) provides an example of the use of this methodology in a concrete application case. In the next Section, we present a literature overview on the state of the art of existing early

2

prototyping approaches and their evolution. Section 3 introduces the most important assumptions concerning MAP. Section 4 presents the theory of MAP, while Section 5 focuses on the implementation and use issues. We demonstrate the potentials and the applicability of the methodology through a concrete application example in Section 6. The testing and assessment of the whole MAP methodology are discussed in Section 7. Finally in Section 8, some propositions are offered and the future research opportunities are circumscribed.

2. REVIEW OF THE STATE OF THE ART OF EARLY PROTOTYPING Over the years, the need for early prototyping in the idea generation activities, and even in the fuzzy front end of software development has gradually emerged. In line with this, the objective and focus of early prototyping gradually shifted from externalization of product visions (i) to the embedment of products in real life situations, (ii) to providing impressions about manifestations, and (iii) to the investigation of user experiences related to future artifacts, systems, operations, processes, services and methods [5]. A large number of synonyms have been used in the literature to describe various approaches of early prototyping. For instance, it has alternatively been referred to as pre-implementation prototyping, rapid prototyping [6], abstract prototyping [7], soft prototyping [8, 9], low-fidelity prototyping, low-cost prototyping [1], throw-away prototyping [10], media prototyping [11], pre-implementation testing [12], etc. Since all approaches are different, i.e., they reflect different stances, express different viewpoints and objectives, and have been proposed for different purposes, there is no one general (or generic) definition of early prototyping [13]. For the reason of space limitations, we are not able to analyze all of them here. We should restrict our survey to the most representative approaches in the rest of this section. As discussed in [14], pre-implementation testing can effectively help developers (i) to quickly elicit and formulate requirements, and (ii) to thoroughly test abstract software implementations by systematically involving various stakeholders as subjects. Lowfidelity prototyping has been interpreted as the methodology of visualization of design ideas at very early stages of the design process [15]. As argued by the authors of [6], an abstract prototype enables designers to describe the contents and overall organization of a user interface without specifying its Els Du Bois, Imre Horvàth

detailed appearance or behavior. It is implied by these definitions that these interpretations are dedicated to optimization of concepts by designers, rather than to demonstration of concepts to stakeholders. The term rapid prototyping has widely been used to describe a family of virtual and rapid prototype development activities. According to a commonly accepted definition, rapid prototyping is a technology used to assess design ideas of interactive systems in the early stages of their development process [16]. Rapid prototyping attempts to foster the collaboration between all stakeholders who are involved in the development project, and to facilitate iterative cycles of reviewing and testing. As explained in [16], when rapid prototyping is used in the design of a user interface, design ideas are presented through a prototype that is relatively quick and inexpensive to construct, and provides a tangible basis for testing with the involvement of potential users. In the next sub-sections, we address three essential aspects of early software prototyping, namely, (i) prototyping of the functionality of software tools, (ii) prototyping of the user interfaces of software tools, and (iii) using dynamic or emergent early prototyping in the development process of software tools. While in the case of the first two aspects, an assessment of the previously proposed methods, tools, and approaches will be in the focus, in the case of the third aspect, we will investigate how much the various early prototyping approaches are able to cope with the dynamism of conceptual design and product innovation processes, and how well they are able to handle emerging innovation and design concepts. Again, due to space limitation, it is not possible to provide an exhaustive survey and analysis of all recent developments. Interested readers should consult other detailed surveys, such as [17] and [18], which discuss the issues of early prototyping from various perspectives.

2.1. Approaches of early prototyping of the functionality of software As we found in the literature, early prototyping of the functionality typically involves two dimensions of thinking. They are visualized in Figure 1, which will be used as a reasoning model for our assessment. The first dimension is the information content included in the early prototypes. The second dimension is the representation fidelity of the early

Figure 1 Reasoning model of early prototyping representing the relationship between the information content and the fidelity of representation

prototypes. In terms of the information content that describes the functionality of the software, we can identify explicit and implicit functional prototypes. Explicit prototypes typically implement the functionality of the software to a testable level, for instance, by coding and programming. However, implicit prototypes do not allow testing the functionality directly. They work with the expectations for and conditions of operation. They typically capture the requested functionality through a list or a structure of requirements or wishes. In terms of the representation fidelity, both low fidelity and high fidelity prototypes are considered. Low fidelity prototypes apply strong simplifications in terms of modeling existing or imagined reality, while high fidelity prototypes seek to achieve the most thorough and comprehensive representation of reality [18]. It has to be noted that the dimensions formed by the information content and the representation fidelity of prototypes are not independent of each other. Low fidelity prototypes either apply a higher level of abstraction or use implicit contents to describe software concepts. On the other hand, high fidelity prototypes are implemented as a set of executable algorithms, which produces all important operations of the software, and can be tested for various criteria, such as reliability of instruction execution, data sensitivity, and computational performance [19]. Several new techniques and approaches have been introduced in the field of low-fidelity functional prototyping. There is a noticeable shift both in research and in development from analog prototypes

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

3

(e.g. sketches, sticky notes, mock-ups, story boards), often called paper prototypes [20,21] to digital prototypes (e.g. PowerPoint, on-screen animations, live video streaming, motion simulations), which are often called software prototypes [22]. Several researchers investigated whether the different forms of media representation has an effect (and what kind of effect) on the outcomes of the functionality evaluations [19]. It seems as if researchers could not find difference in terms of the results of the two approaches. That is the reason why researchers proposed that the economic principle should be followed in prototyping [17]. This principle suggests that the best early prototype is the one which makes the possibilities and the limitations of a software concept visible and measureable in the simplest and most efficient way. High fidelity functional software prototyping apparently received less research attention so far. While low fidelity prototypes are usually throwaway prototypes by nature, and are produced by some quick-and-dirty prototyping techniques, high fidelity prototypes are more robust testable implementations (evolutionary prototypes), which are produced using production-quality coding, and are designed for easy growth and frequent improvements [23]. Highfidelity functional prototyping is often referred to as agile software development, or human-centered extreme programming [24]. In requirement engineering, a difference is made between horizontal and vertical prototypes, which are used to test the functionality of software [25]. A horizontal prototype (or behavioral prototype) is like a movie set: it displays the user screens, the interaction between the user and the system, the functional and navigational options, but does not implement the real functionality. A vertical prototype (or structural prototype) serves as a proof of the concept, through implementing a set of the functionality of the software. It is typically used to test the soundness of a proposed architectural scheme, to optimize algorithms, to evaluate a proposed database scheme, or test critical timing requirements [10].

2.2. Approaches of early prototyping of user interface of software Abstract user interface prototypes offer designers a form of representation for specification and exploration of visual and interaction design ideas that are intermediate between abstract task models

4

and realistic or representational prototypes. Like in the case of functional prototyping, the use of low or high fidelity prototypes is an issue in itself, as well as designing and checking the user interaction with the functional elements of the tested software [26]. From user interactivity point of view, application of analog prototyping and digital prototyping have also been compared [15]. To support low fidelity user interface prototyping, canonical abstract prototyping has been introduced. This method provides a formal vocabulary for expressing visual and interaction designs without considering the details of appearance and behavior. Using standardized abstract design components facilitate the comparison of designs, eases recognition of potential difficulties in interaction, simplifies the description of common design patterns, and lays the foundations for a better software product [27]. Different software tools have been developed, which allow the developers to intuitively build interfaces for software prototypes on low and high fidelity level. DENIM [28] and SILK [29] are good examples of interaction design prototyping tools that make the designers capable to quickly create sketch-based prototypes, and to interact with them on a computer screen. These software tools also support the substitution of the drawn components with actual programmed components. Other systems, such as SketchWizard [30] and SUEDE [31] are able to support new interaction modes and modalities. For instance, SketchWizard makes it possible for the software developer to use pen-based digital input to describe the user-interface, while SUEDE offers a speech interface for this purpose. The Ex-A-Sketch tool [32] supports interface designers by quickly animating sketches drawn on a whiteboard. It is an issue how end-users are involved in the assessment of the user interface during early prototyping. In general, they can play either a passive role or an active role in the assessment process. As stated in the literature, active participation not only means completing the reasoning and information processing that is needed to operate a computer program, but also creative contribution to the interface development and optimization based on direct interaction in various testing contexts. When concepts of software tools and interfaces are demonstrated to designers in interactive sessions, stakeholders not only may make comments and ask questions, but also may propose changes in terms of the operation of the programs Els Du Bois, Imre Horvàth

and interfacing with them. In case of passive participation, the opportunity of creatively intervening or changing is not offered to the participants. In these reflexive demonstrations, the interface prototypes are presented to the stakeholders without interruption. The discussion of the experiences and the impressions typically happens in post-demonstration sessions or using remote interrogation techniques [29]. As some recent studies show, active early prototyping is usually used in testing complex cognitive interfaces, while passive early prototyping is typical used in functional assessment of software concepts. In active sessions, often Wizard of Oz techniques are also used to automatically to track the user actions [26]. There is a clearly observable shift in terms of the way of conducting early interface prototyping. The experimental sessions are moving from investigations in laboratory environments to testing in real-life use environments and contexts. This is inspired by the opportunity of and demand for mobile prototyping [33] and real-time prototyping in ubiquitous applications [22]. These operation and interface prototyping approaches should allow the users to freely interact with the appliances, to experience with them, and improve them as they were used in real life settings. A new trend is to do longitudinal exploratory research using early prototypes [34].

2.3. Dynamic/emergent early prototyping of software As discussed above, software concepts may evolve in the phase of conceptualization, but may also change dynamically during an interactive demonstration session. In addition, demonstration to various stakeholders usually requires different contents to be demonstrated in the form of abstract prototype. Since the latter two issues together pose additional challenges for abstract prototyping, we have studied the literature to see what scientific and practical research questions have been addressed, and what approaches and solutions have been proposed to support emergent and dynamic early prototyping of software. However, we restricted our attention to the development of early prototypes with varying contents and to rapid adaptation of prototypes to varying demonstration contexts, and ignored the technical issues of how changes can be incorporated in an early prototype.

Development of software prototypes with varying contents belongs to the domain of extreme programming or evolutionary prototyping [24]. As we found, the results in this domain are very scarce and limited, and studying the phenomenon of emergent prototyping is still in its infancy, contrary to the potentials that research in this domain may have. In the current practice, typically the same prototypes is presented to all stakeholders, they are not changed in the course of the demonstration and testing sessions, and the requested changes are discussed and introduced off-line. This implies that changes must be communicated back to all concerned stakeholders afterwards [10]. Nevertheless, the need for dynamic reconfigurability in prototyping has already been recognized. Gray, P.D. et al. argued that it is a crucial factor for rapid prototyping to indeed be able to rapidly reconfigure prototypes (optimally, with a time delay of at most a few seconds) [35]. A second factor is that, ideally, the dialogue support system should allow the user to break off execution, make changes to the specification, and resume execution from the original position in the dialogue, which they also call suspended time editing. As a rule, reconfigurability must be easy and fast to achieve maximum benefits. Dynamic reconfigurability also ensures that changes can be made whenever the need is perceived, without any loss of the problem context. The reconfiguration cannot be the responsibility only of the (interface) designer or the design team. Since they prefer to be in control, solutions are needed that are able to make it possible for end users to adapt software programs. From the aspect of emergent prototyping, we have to differentiate the situations when any part, including the application code, of the software can be reconfigured, and the situations when only the interface specifications are modifiable. It seems that both are challenging and this gives the reason why only a very few researchers has touched upon the problem of dynamic and evolving prototyping of software concepts.

3. ASSUMPTIONS FOR MAP As mentioned in the Introduction, the general objective of this research is to develop an instrument for the demonstration of software tool concepts to multiple stakeholders in an early phase of the development process. First of all, it has to be remembered that we are using the term abstract prototyping (AP) in a broader context in our research

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

5

and in this paper, than its original interpretation in the literature. We re-conceptualized it as a comprehensive methodology of early and low fidelity, but rich-in-information, prototyping [36]. As a methodology, AP should be based on an underpinning theory and should be supported by an application independent procedural framework, covering both prototype development and demonstration. Furthermore, the already published generic AP methodology also identifies a set of methods to enable efficient work in its broader application context. The underpinning theory of generic abstract prototyping (GAP) has been developed based on the assumptions presented in [36]. By definition, GAP concentrates on a comprehensive capturing and demonstration of foreseen real-life processes in their embedding environments, including the involved humans and their actions, for all kinds of stakeholders. GAP produces abstract prototypes of monolithic architecture. Just to summarize, the main assumptions for general abstract prototyping were: (i) the AP is demonstrating a real life process, established by the functionality of the software concept, the human actions, and the application environment, (ii) the content of the process is captured in a scenario or a scenario bundle, (iii) the communication with stakeholders happens through perceptive and cognitive channels of human intellect, and (iv) the process of AP consists of four main parts. In procedural order, these are: (1) aggregation of technical information about the proposed software concept, (2) compilation of the demonstration content of the AP, (3) (field) demonstration and testing of the software concept by processing the contents of AP, and (4) assessment of the data and deriving conclusions on possible improvements. Since the previously proposed theory does not explain the methodology of constructing and applying MAPs, we had to develop a modified theory considering additional assumptions. Our main assumptions for the manifestation of MAP are as follows: 1. The MAP is presented to multiple stakeholders, who are interested in the assessment and improvement of software concepts and implementations from multiple different perspectives. The MAP is intended to be an instrument of exploring and aggregating information about the opinion of multiple

6

stakeholders, to enable the fulfillment of their requirements.

highest

level

2. From an information technological point of view, a MAP is a hierarchical organized information structure, which involves multiple modules. Thus, a MAP features a modular architecture, which in turn allows an independent development and flexible adaptation of the modules in association with multiple stakeholders and demonstration sessions. 3. The information structures represented by the modules of an abstract prototype can semantically be decomposed into complementing information sub-structures. These information sub-structures can be encapsulated in modules of MAP according to the interest and viewpoint of the stakeholders. 4. A demonstration session can be decomposed to a series of sub-sessions, in which the dedicated MAP contents are presented to the different stakeholders. In the practice, separate sessions are organized for the different stakeholders This way, the information overload of the stakeholders can be reduced in comparison with that of generic APs, and the development of the demonstration material can be more efficient and flexible. 5. Based on the methodology of modular abstract prototyping, it is expected that the number of necessary iterations is reduced and iteration cycles are made shorter, taking into consideration the stakeholders’ opinion. 6. The optimal number of modules (i.e. the resolution of the AP) is related to the number and interests of different stakeholders, who are involved in the software concept assessment process, but can also be defined based on different principles. A specific combination of the modules should ensure that the optimal amount and pieces of information are provided to each of the stakeholders, in a cognitively controlled way. As shown in the next Section, the additional assumptions for MAP have also influences on the theory and the component information structures.

4. CONCEPTUAL MODELLING THE INFORMATION STRUCTURE OF MAP In conceptualization of MAPs, the formal theory of GAP, published in [36], has been used as a platform of departure. The information structure of MAP has Els Du Bois, Imre Horvàth

Figure 2

Visual representation of the information model of MAP

been derived taking into consideration the abovementioned assumptions. We have adapted all formal definitions from [36] that are appropriate for MAP. The adapted notional concepts and information constructs of GAP are listed below:

concept information is not directly encapsulated in the APM. This however should also be aggregated in order to understand the technical concepts in a broader view and deeper. We refer to this as auxiliary technical concept information, and denote it by ATC. From the aspect of APM development, RTC should be processed explicit (built in) information, and ATC can be exploited as implicit information, guiding the proper definition of the technical contents of APMs. This additional information should in fact be considered by knowledge engineers at making decisions on the information contents and demonstration of MAPs. Symbolically, we can write: TC = RTC + ATC. Using the definitions provided in [36], TC can be formally defined as a four-tuple: TC = {Π, Ξ, H, Σ}, and

-

the to-be demonstrated process (Π)

-

the software scenario (Ξ)

RTC = {{S, T, L, D}, {K, O, IA}, {P, PA, MA}, {E, Γ, ∆, Χ}}

-

the involved human actors (H)

ATC = {{Ω}, {A}, {K, R}}

-

the surrounding environment (Σ)

-

the content demonstration media means (M)

-

the concerned stakeholders (SH).

The technical content information that is eventually embedded in a MAP is a sub-set of the RTC. This is actually the demonstration content of the APMs. Let’s denote it by DN. Using the above introduced symbols:

As a consequence of the specific assumptions discussed in Section 3, we may consider the following: In general, any kind of AP is constructed from four major pools of information: (i) the technical concept information that describes the technical (functional, structural, and implementation) concepts related to a new software, (ii) context information which help transform the technical concept information into the possible technical content of the MAP, (iii) the demonstration content of MAP, which is derived from the technical concepts by considering the presentation context, and which is actually built into the modules of a MAP, and (iv) the presentation context, which informs about the preferable way of structuring and presenting the modules. As represented in Figure 2, these bodies of information can symbolically be defined as follows. Let the technical concept information be denoted by TC. This includes a sub-set of information, representative technical concepts information (RTC), which is processed in the different abstract prototype modules (APM). The other sub-set of the technical

DN = RTC’, where RTC’ ⊆ RTC. Considering the above specifications, we can write: {S, T, L, D}’⊆ {S, T, L, D} {K, O, IA}’⊆ {K, O, IA} {P, PA, MA}’⊆ {P, PA, MA}, and {E, Γ, ∆, Χ}’ ⊆ {E, Γ, ∆, Χ}, This means: DN = {{S, T, L ,D}’, {K, O, IA}’, {P, PA, MA}’, {E, Γ, ∆, Χ}’}. With these, the total demonstration information embedded in a MAP is: DN =

content

′

where, n represents the number of modules.

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

7

This embedded demonstration content information is semantically appended with two other bodies of information, namely: 1. the auxiliary demonstration context information, DX, which is composed of context information from two sources: (i) the auxiliary technical concept information (ATC), and (ii) the stakeholders (SH) related demonstration context information, SHX, (defining the technical content of APMs), and 2. the presentation context information, PX, (which guides and influences the way of development and delivery of the media-based presentation). The stakeholder related demonstration information, SHX, can be defined as: SHX = {{Λ, Ρ}, α} where, {Λ, Ρ} are the stakeholders perspectives and demands, and α is interpreted as a module selector operator, which is playing role in expressing the context of interest of the stakeholders. Considering these, DX can be symbolically defined as: DX = {ATC, {Λ,Ρ}, α} or DX = {Ω, A, {K,R},{Λ,Ρ}, α} As mentioned earlier, PX is a complement of DX. This set of information is used to select the most appropriate media (M) according to the stakeholders (SH) and the demonstration content (DN). The demonstration content of an abstract prototyping module (APMi) consists of a subset of DN and is represented by means of some content demonstration media, Mi. With this: APMi = {DNi, Mi}. In Figure 3, we visualized the relationships between the above introduced information sub-structures and the different stakeholders. The bottom part of the figure shows the stakeholders. The middle part indicates the MAPs, which are presented to ndifferent stakeholders. The upper part indicates the configuration of m-number of APM, which are included in a particular MAP. As shown, a particular MAP may consist of different numbers of modules, and the total information content of a specific MAP in a given demonstration context, DX = {ATC,{Λ,Ρ}, α}, can formally be defined as: MAP = ⊗APMi = ⊗{DNi, Mi}

8

Figure 3

Assembling the APMs into specific MAPs for different stakeholders

In the next Section, we will elaborate on the procedural aspects of the MAP methodology. In addition to describing the prototyping procedure, we also touch upon some of the methods that can be applied to generate and process the information structures implied by our theoretical considerations.

5. PROCEDURAL ASPECTS OF APPLICATION OF THE MAP METHODOLOGY From a procedural point of view we assume that the conceptualization of the software to be developed has been completed by the responsible designers and engineers to a sufficient detailing level, and the results are available for abstract prototyping. The process of MAP decomposes to four phases. The first phase of the MAP process concentrates on the aggregation of technical information about the software concept. The process starts with an investigation of information available for the software concept selected for demonstration. There are two major goals here, namely (i) making the specifications as complete as possible, and (ii) clarifying the context of prototyping. The second phase involves the compilation and testing of the technical contents for the individual modules of the abstract prototype. The third phase deals with the demonstration of the abstract prototypes, assembled from multiple different modules, to the stakeholders. The specific objective of this phase is to gather the stakeholders’ opinion about the functionality, interfacing, and the performance of the demonstrated software concepts. In the last phase, the information obtained from the stakeholders, is assessed and possible refinements of the software concept are defined. Els Du Bois, Imre Horvàth

In the rest of this Section, the mentioned phases are further detailed and all actions needed to operationalize the MAP methodology are explained.

5.1. Phase 1: Conceptualization In order to aggregate the necessary information for building the abstract prototype, the following activities should be completed in this phase:

Identification of the players This action involves identification of the various stakeholders, exploration of their probable interests and demands, and simultaneously with these, creating a profile description for each group of stakeholders. Decision is made of who to invite for demonstration sessions and what they would be interested in. In the profile descriptions, qualitative descriptions are included about the stakeholders’ perspectives, and their demands concerning: (i) the to-be demonstrated processes, (ii) the necessary technical contents for the modules of abstract prototypes, and (iii) the most favorable forms of implementation of MAPs and delivery of presentations.

Defining the technical concept The prototyping starts with the definition, specification and investigation of a software concept. The objective is to aggregate the largest possible technical information about it, and to structure and prioritize the pieces of the describing information according to their significance (criticality). The goal of demonstration and concept review is to provide feedback to the software engineers from multiple perspectives and, this way, facilitate the improvement of the software tool. To this end, a careful decision is made on the technical content that will be processed in MAPs, and it is also considered what is only implicitly, or not at all, included in various modules of the MAP.

Defining the demonstration context As the term implies, the role of context information is to inform the software designers and programmers, as well as the MAP implementers about the context of development of the abstract prototype. The demonstration context provides information about the stakeholders (their perspectives and demands), the conditions of operations, actions and interactions set by the embedding environment, the objectives of the reallife process, the functional possibilities of the

software (set of affordances offered to user), and the roles and competences of the human actors. Context information is not built into the modules of the abstract prototypes. In this regard it is implicit, but plays an important role in guiding the content development.

Defining the demonstration content The demonstration content is the total of the chunks of information that are explicitly built into the modules by using various media resources. The demonstration content of an abstract prototype includes the explicit definition of the demonstrated process, the functions of the developed software, the actions of the involved human actors and their interactions with the software, and the surrounding environment (including the constituting entities, their characteristics and relationships). Defining the demonstration content includes three interwoven sub-processes, namely: (i) conceptualization and specification of the end-users as persona, (ii) modeling and specification of the software concept as a functional and structural system, and (iii) modeling and specification of the environment in which the operation of the software and the end-user interaction happens. These chunks of information must be used to set up a complete scenario of system operation, human actions, human-system interactions, and environment effects.

5.2. Phase 2: Design Modularization The first steps in this phase are (i) decomposition of the AP into different demonstration modules, and (ii) allocation of the parts of the demonstration contents to specific modules. The decision on the number and the contents of the modules is guided by the context information related to the stakeholders and their interests. Above, Figure 3 presented an example for possible relationships between stakeholders and modules, and for one way of assembling of various abstract prototype modules into a MAP accordingly.

Implementation The demonstration contents of abstract prototype modules are embedded in the narration and in the enactment, which are two interrelated constituents of abstract prototypes. Narration is a simplified synthetic description of the outline and the highlights of the foreseen real-life process. Narrations are operationalized in the abstract prototype by

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

9

appropriate media (e.g. animated text, human voice, synthetic sound, etc.). Enactment is the actual staging, performing, and media-enabled visualization of all significant arrangements, happenings and contributors of the process. The narration part of an abstract prototype module is typically developed and edited in textual form. The text of the narration makes it possible for the developers of the prototype to identify logical units in each and every module, which are called episodes. Furthermore, within each episode they can identify the most important terms and phrases as keywords. The keywords represent points where the elements of the enactment can be linked. In other words, the keywords play the role of anchors, with which the elements of the two constituents are brought together to have optimal effects in the cognitive, as well as in the perceptive channel of human understanding. In the content development process, decisions have to be made at every keyword about a specific unit of the enactment, called segment (i.e. about what it is and what media is used to implement it). Actually, the enactment as a whole is a keywords implied sequence of segments, with smooth transitions between them. An appropriate medium or a composition of media must be selected for the segments of the enactment, which a view to the related episode of narration.

Outlining the discussion questions In order to increase the informing potential of the AP modules, and to maintain the perceptive and cognitive synergism between the narration and the enactment, theirs elements (i.e. the episodes and the segments) should be developed concurrently. The MAP developers should consider the potential questions by which they want to gather the stakeholders’ opinions, and should provide enough information through the narration and the enactment to make the stakeholders able to formulate their opinion based on what they have understood and experienced.

Inviting participants and plan sessions In addition to the development of contents for the modules of the abstract prototype, the prototype makers should also develop a plan for the demonstration sessions. An efficient approach is to organize focus group sessions with on-site or videoconferencing-based participation of the stakeholders. As a first step a decision must be made on the testing method and procedure. More information about these is included in Section 5.3.

10

Next, the participants should be sorted into different focus groups, testing sessions should be arranged, and the participating stakeholders should be invited. Besides the availability of the stakeholders, the heterogeneity of their professional background and interest is the factor that makes a focus group session challenging. In preparation of focus groups sessions, AP developers should also consider that fact homogeneity of the participants’ background improves their shared understanding and awareness, in addition to enhancing the effectiveness of the discussion.

Pre-assessment This activity concentrates on the testing of the contents and the implementation of the modules of the abstract prototype by some sort of pilot experimentation, before they are used in full-scale real-life demonstration sessions. The appropriateness of the various modules needs to be carefully tested by sufficient number of proper test persons. Other test persons should be invited for the scaled-down, but real-life pilot experiments, than for the full scale experimentation, giving proper attention to the issue of statistical significance in sampling. The harmony of the contents and the means of presentation are of particular importance, due to the well-known confounding situation: The convincing nature of a carefully constructed technical information content can easily be destroyed by a poor structuring and implementation (presentation quality) of the AP modules, and vice versa. An exaggerating presentation may over- or under-emphasize the real technical issues and the functional quality of the presented software tool. This makes the first step of the preparation of the pre-assessment, namely the criteria definition, critical. The criteria should concern the foreseeable functional and utility qualities of the demonstrated software concept, rather than the attractiveness or appeal of media used. Therefore, criteria such as exactness, transparency, understandability, completeness, and fidelity should be used as measures of goodness of the abstract prototype.

5.3. Phase 3: Execution The objective of the execution phase is the actual full-scale assessment of the software concept by the different invited stakeholders through the abstract prototype. Different approaches can be used in individual assessment and in focus group assessment: (i) passive (observant) participation of Els Du Bois, Imre Horvàth

the stakeholders in the demonstration session, but with the opportunity to reflect on and to pose questions in a follow up discussion session, (ii) active (interactive) participation in the demonstration session and having the opportunity for immediate reflections, interrupting questions and follow up discussion, and (iii) executing the assessment in an inventive form, providing opportunity for the stakeholders to propose changes in the software concept and to see the effects of the proposed changes right after their acceptance. This latter needs a software tool which allows the reengineering of the concerned modules (episodes and segments) of the abstract prototypes according to the proposed changes in the software concept. It has to be noted that interrogation of individuals and focus group sessions are just the two most popular techniques for prototype assessments. In addition, many other techniques, such as in depth-interviews, field observations, questionnaire surveys, and logging actual use, can be applied [37,38].

5.4. Phase 4: Data evaluation Data processing Phase 4 concentrates on the processing and evaluation of the experimental data. Towards this end, the discussions with the different stakeholders or groups are recorded. As suggested in literature, it can happen in two ways simultaneously: (i) by video-recording (with the permission of group participants), and (ii) note-taking by a fellow researcher (who does not take part in the actual discussion). These recordings should be transcribed, integrated and checked, in order to obtain as complete and thorough information as possible at all for quantitative and qualitative analyses [39].

Drawing conclusions towards concept enhancement The results of the quantitative and qualitative analyses have to be converted into knowledge on how to change, further improve, or optimize the software concept. Usually, data reduction techniques are needed to rank the data, and semantic interpretation to take out their meaning. The conclusions on the necessary and probable changes of the software concept should be evaluated for feasibility.

Validation of the results

The results of the testing experiments should be validated. This can be done, on the one hand, by using a control group, and, on the other hand, by comparing the responses of different stakeholders (e.g., by statistical analysis of the tendencies). The theory of theoretical saturation can be used to define the number of focus groups needed to collect the knowledge [40]. Data saturation is reached when no significant new information emerges in a focus group session.

6. TESTING THE PROPOSED MAP METHODOLOGY Empirical testing in concrete application cases is known to be the most effective way of testing of methodologies, though it is a reasoning-withconsequences strategy. We applied this strategy, because no other theoretical or non-experimental strategies could be considered for a confirmative testing. In this Section we will provide information about how the methodology has been used in a concrete application case, which involved conceptualization and development of a software tool to support designers in smart energy saving. Sub-section 6.1 offers more information on the application case. Sub-sections from 6.2 until 6.5 discuss the taken procedural steps, and give an overview of the applied methods. Finally, the findings and the conclusions concerning the applicability and the benefits of MAP are presented in Sub-Section 6.6.

6.1. Doing the experimentation The above described assumptions, theory and implementation approach have been applied and tested in a Ph.D. research project. The objective of this research is to develop a concept of a knowledgeintensive software tool for trade-off forecasting in case of ubiquitous augmentation of energy intensive products. Using this knowledge-intensive software tool, designers of electronic household appliances can make more reliable decisions easier, by considering the relationship between the costs of augmentation and the gains achievable with smart control functions. The objective of using MAP was to explore and aggregate the opinions of various stakeholders in order to be able to improve (optimize) the concept before implementation. We focused on the demonstration of the real-life process that is implied by the software tool in various application contexts, rather than only on the functionality, or on the user interface of the tool. Due

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

11

to its relative complexity, the proposed software tool concept is an adequate testing case. The MAP methodology could be applied without any constraints or limitations. The concrete process is discussed are discussed in the rest of this Section.

6.2. Conceptualization Identification of the stakeholders We identified three different groups of stakeholders: (i) electronic appliance designers or product designers, who are seen as future end-users of the software tool, (ii) software developers, who are involved in the programming and constructing of the software tool, and (iii) knowledge engineers, who are involved in knowledge processing (e.g. about past products) for the software tool. In the pre-testing phase, not only the special characteristics of the particular groups of stakeholders were identified, but tentatively also a body of information that they need about the functionality and application of the software tool in order to be able to judge the merits and pitfalls of the proposed concept. For example, product designers must be practicing designers, must have sufficient experience with electronic application design, and should have experience with applications of design software tools. Further characteristics of their competence profile have also been taken into consideration at sorting the designers into groups according to their experience with ecodesign, their attitude to use interactive and knowledge-intensive tools, their initial knowledge on smart and ubiquitous technologies, and their experiences with designing smart controls. An overview of the identified stakeholders and their profiles are shown in Figure 4.

Figure 4 Identification of the stakeholders

6.3. Development of the MAP The prototype building As media representation for the contents of the whole prototype, we decided to use animated movie, in which different forms of visual representation could be included, depending on the contents of the modules. Acting in the roles of software end-users, program designers, and knowledge engineers, the stakeholders have been specified as personas. For all of them the working principle of the tool was demonstrated, but they also received specific information about the plan of programming and computations, and the knowledge processing mechanism, respectively. The narration was developed on paper, and presented and recorded orally. In the enactment, line drawings and hand sketches are combined with product images, screen

Defining the demonstration context and content Having identified the characteristics of the stakeholders and their possible demands and requirements for the to-be-demonstrated software concept, we collected and structured the technical information concerning the concept of the software tool. Based on this, the technical information content to-be-embedded in the MAP and the technical information contexts were defined. Furthermore, information about the demonstration context was also collected. Based on these, the contents of the various modules have been determined, and the composition of modules into stake-holder oriented MAPs has been defined (Figure 5). Figure 5 Overview of the modules developed for different stakeholders

12

Els Du Bois, Imre Horvàth

shots, and movie clips. These have been animated and recorded in one single digital demonstration media Adobe Flash Professional CS5 and Adobe premiere CS5 were used for animation and recording. Figure 6 shows examples of the episodes of the narration and the segments of the enactment linked to them, at the keywords. The screenshots show various moments (scenes of enactment) and contents of the digitally-recorded demonstration material, as they are connected to their semantic anchors in the narration.

Outlining the discussion Based on the work of Krueger and Casey [40], we defined four groups of questions for each group of stakeholders: (i) understanding questions about the whole of the software tool (to check if they understood the general principles, and to have the chance to further clarify some aspects), (ii) general questions on each module, (iii) specific questions on specific aspects in each module, and (iv) concluding questions (to summarize the whole, identify the most important aspects, and to give the ability to provided additional information, which was not mentioned before).

6.4. Working with the MAP Execution technique

Figure 6 Examples of the elements of the narration and the enactment parts of the AP

We decided to complete the assessment experiments in the form of focus group sessions [41]. Focus groups are discussions within a relatively small group of people (usually involving 6-12 participants), addressing specific topics, which are either matched to the characteristics of the participants, or varied according to the specific interest of the researcher [40]. The reason why the method of focus group sessions was chosen is that focus group sessions are generally relatively easy to

assemble, and the experimentation is inexpensive. Furthermore, focus group sessions provide rich data through the constant interaction [39].

Number of sessions Taking into consideration the different profiles of stakeholders, we organized four sessions with product designers, two sessions with software developers, two sessions with knowledge engineers, and one session with a heterogeneous group of the above mentioned people, as a control group. The

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

13

number of focus group sessions for the most important group of stakeholders (product designers = end-users) was decided based on the rule of thumb of Krueger and Casey [40]. They proposed to plan three or four focus group sessions in a queue. They advise that once you have conducted these, determine if you have reached saturation, which is the point where no new information can be expected to emerge from sessions with additional groups.

Inviting participants To select the participants, stratified homogeneous sampling was applied, as suggested by Patton [42]. The reason is that focus groups are typically organized by bringing people of similar backgrounds and experiences together, and that their participation in a group interview about major issues may differently affect them. The participants were selected based on the scale of their fitting the above mentioned profiles. We also decided to have minimum sample size so as to have in average: n = 7 people per session. Anticipating no-show ups we over-recruited each group by inviting 10 persons. The sessions were held in Antwerp, Belgium.

Conduct of the sessions Each session was organized as follows: First, the participants were given a brief introduction, explaining the goal of the session, and how it would be structured. They were also informed that, in case of their unanimous confirmation, everything would be recorded for the data processing. After this introduction, the modular abstract prototype was presented in approximately 30 minutes for the participants. The digital demonstration material was composed of two general modules (General introduction and Design tool functions) and different number of specific modules dedicated to particular stakeholders. After the demonstration, a reflexive discussion was held based on a list of predefined questions. During this discussion, the questions were projected by using PowerPoint slides, together with some explanatory images taken from the digitally recorded demonstration material. The latter served as reminders to critical argumentations and explanations embedded in the modules of the abstract prototype. Because of the large number of aspects and questions to be discussed, exactly five minutes have been allocated to each question. It should be noted that the sessions were facilitated by two moderators. One of them, the owner of the research project, guided the session and safeguarded the proper tracks of discussions. The other moderator

14

helped with session administration, time-keeping, and making notes on the discussions.

6.5. How MAP was used to get to the results The ultimate objective of our confirmative research was to collect the opinions of stakeholders in order to be able to enhance and optimize the concept of the software tool. By using a list of prepared questions during the focus group discussions, the findings could be structured according to the keywords, they were referring to.

Results of the pre-testing All experts agreed on that the abstract prototype facilitated the presentation of the functions and the implementation details and added a lot of value to demonstrate the concept of the software tool. At the same time, they also indicated that the total length of the prototype had to be reduced to a maximum of 20 minutes. This meant that there was a need to rearrange and reorganize the full-scale research sessions. One group of stakeholders, the participating product designers argued that the “Design tool functions” module was not really useful for them to answer the questions. They also proposed a restructuring and bundling of the chunks of information concerning the up-date of the knowledge embedded in the system. Originally, these were scattered over multiple modules, but they have been compiled into one module in the final version of the MAP.

Results of the full-scale research The full-scale research provided three major groups of results. These are: (i) data on the technical functions and implementation of the software, (ii) data on the utility of the software, and (iii) data on the used demonstration method. In general, the data related to (i) and (ii) included directly usable enhancement proposals. These could be used to develop a refined version of the software tool. On the other hand, some of the propositions required further investigations, for instance, discussions with other stakeholders, or expert interviews, or literature review.

6.6. Findings In general, we were pleased with the amount of data generated during the focus group sessions. This was inseparable from using MAP in the sessions as a Els Du Bois, Imre Horvàth

stakeholder-tailored, information-rich demonstration means. Nevertheless, certain difficulties or complications originating in the use of MAP were also observed and experienced, respectively, during the focus group sessions.

Homogeneity of the focus groups A high level of homogeneity was an important aspect at composing and working with the focus groups. To achieve this, not only the participants were chosen based on certain criteria, but we also tried to balance their knowledge about the objectives and conduct of the sessions. Together with the invitation letter, also a questionnaire was sent to each participant, in order to be able to identify their profiles. However, the intended homogeneity could not be achieved in all cases, because we had to make compromised due to the availability of the participants for sessions. Despite of this, the achieved level of homogeneity was reasonably high, which was evidenced by the fact that there were almost no problems with misinterpretations.

Language Another issue emerged was the language used in the MAP and during the sessions. Our assumption was that the language of the modular abstract prototypes should be English, as well as the language of the discussion sessions. In all modules we used English. However, the focus group sessions took place in Antwerp, and most of the stakeholders spoke and preferred Dutch. Though, significant understanding problems were not observed in the case of the MAPs, the introduction was delivered and the discussions were conducted in Dutch. It was much easier for the participants to discuss in their native language, though the questions guiding the discussions were presented in English. Thanks to the permitted recording, all raw data provided in Dutch could be transcribed into English text with an excellent fidelity.

Relevant information We confronted a difficulty in making decisions on which information was relevant to which of the stakeholders. We have the impression that we could not present them an absolutely complete picture, because they had different mindsets and relationships to the tool, and were interested in different issues. That was the reason why we consulted some stakeholders in advance. In these informal and open discussions, we managed to get hints and clues on what to embed in the various

modules, and what answers could be expected when asking questions in context.

Duration of MAP demonstration Another reason why we must define the relevant It is scientifically proven that people can listen attentively not more that maximally 20 minutes [43]. Therefore, we had to restrict the duration of the digitally recorded demonstration material to this length of time. Obviously, the density of information conveyed to the human intellect through the perceptive and cognitive communication channels has also a word to say in this context. Our experience was that the above duration was appropriate for the overwhelming majority of the participants, but the intensity of information transfer posed a challenge for some of them.

Number of modules The information relevant for the particular groups of stakeholders was embedded in different modules of the abstract prototypes. The larger the number of modules, the larger flexibility can be expected at composition of MAPs. On the other hand, an extreme large number of modules would lead to a combinatorial complexity. It indicates the need to find an optimal resolution of modules, for which it is rather difficult to provide generic rules. In this context, adaptability and reusability of the modules should also be taken into consideration.

Representation of information Adaptation of the enactment to the view of different stakeholders was another issue in this research. We had to look at how the stakeholders visualized their information. Product designers like using visuals and images, while software programmers think in flow charts and algorithms. Thus, the selection of the presentation methods is of importance. To fulfill different needs, different representation resources have to be applied in the various modules. We also have to mention that the influence of the media representation was rather large in our experimental work.

Structured discussion By structuring the discussions with pre-formulated questions, we noticed that the participants were activated every time we showed a new question. This observed effect is considered to be very positive since it maintains the attention and keeps the focus of the participants.

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

15

Participants’ opinion on the used method As the last question we asked the participants what they think about the demonstration methodology and means (MAP) that was used in the focus group sessions. In addition to addressing the points of the question, the participants offered some other remarks, which were not directly related to the MAP methodology. In general, all stakeholders were positive about the use of the methodology in the early phase of appliance and software. As main advantages they mentioned that using MAP: (i) gives a structured support for the discussions, (ii) guides the thinking of the people in the same direction, and (iii) does not requires the participants to generate an all-embracing complete picture, which is often a problem. The participants also commented on that extra research is still needed to optimize both the content and the framework of the software tool.

7. DISCUSSION As discussed in [36], abstract prototyping enables rapid ideation, modeling, and demonstration of concepts in early phase of development with the objective to receive extra information about the functioning, quality, features, properties of the demonstrated concept to modify or improve the initial concept. In general, the major benefits of abstract prototyping are that it (i) influences the most creative phases the development process, and (ii) opens the way towards intelligence that cannot be obtained otherwise. One recognized limitation of using general abstract prototypes is that they are structurally monolithic and offers no real time opportunities for content changes. Therefore, they are not the most suitable to help find answers to ‘what-if’ or ‘why-not’ type of questions. Contrary to these observed limitations, generic AP can be useful in many application fields as a very useful demonstration and thinking stimulation means. Since the limitations of generic AP can be traced back either to issues associated with its constrained flexibility and the lack of sensitivity to multiple stakeholders, or to the amount of effort needed to handle the complexity inherent in this form of abstract prototyping and the amount of work needed to implement the narration and enactment parts in an integral, fluent and attractive way. In order to increase flexibility and eliminate some of the typical bottlenecks we have worked out the concept of modular abstract prototyping, and developed a methodology that can supports its application in

16

various academic research and industrial development projects. The major objective was to offer the possibility of quickly develop contents in the context of multiple stakeholders by allowing a flexible combination of different modules into one specific abstract prototype. Modularization also lends itself to a higher level of reusability, that is, different combinations of abstract prototype modules can be combined according to the views and demands of stakeholders. This can also reduce the complexity of the content development efforts, as well as the incurring costs. Evidently, modular abstract prototyping is a significant step towards a flexible and efficient early prototyping methodology, but it still can be further developed. MAP does not allow abstract prototypers to introduce changes in the technical information content and to adapt the demonstration contents accordingly. This would need a fully interactive, real-time emergent approach, which has been called interactive abstract prototyping (IAP). The methodology of MAP has been developed without considering this particular objective. It has to be also mentioned that IAP needs a specific computer tool that supports not only the presentation, but also collecting content and context information. Our research is going in this direction and a functional framework and an implementation plan are being developed for this tool, which has been conceptualized as a web-hosted information hub, equipped with means for real-time editing of abstract prototype contents. The benefit of this would be a much shorter feedback loop between the prototype developers and the stakeholders, and a dynamic feedback to the concept developers based on a more comprehensive investigation of the stakeholders.

8. CONCLUSIONS Based on the findings and their critical evaluation in the discussion part, we can offer the following propositions: One of the important conclusions is that the method of modular abstract prototyping is an effective and goal-oriented methodology to elicit the opinion of a group of stakeholders. It harmonizes with the procedural aspects of focus group sessions. In addition, we have concluded that MAP is useful for software developers because it can show how a future tool would work in a real-life environment and how the tool can be experienced by future tool users. Els Du Bois, Imre Horvàth

Our next proposition is that using a modular prototype structure increases the flexibility that is very much needed when different contents should be presented to multiple various stakeholders. In the conducted experimental sessions, different compositions of modules were used with different stakeholders to facilitate an intense information elicitation process. We could also conclude that a near-optimal resolution was found when we applied nine modules. They allowed a sufficiently articulation of the contents according to the needs of the three kinds of the involved stakeholder groups. This number is an important finding for the reason that too many modules would lead to a high complexity, and too few modules would not give enough flexibility. We believe that the method of modular abstract prototyping is especially useful for software development, but we believe that is can also be used in other contexts such as appliance development, or service specification, and product-service combinations, where the real-time processed should be optimized for multiple criteria. Obviously, further research efforts are needed in these directions, to optimize the use of modular abstract prototyping in several practical applications. Since modular abstract prototypes are working both in the perceptive and the cognitive channels of human communication, they contribute to a rapid formation of a shared awareness and understanding among the software designers and the stakeholders. This may lead to a deeper and more rigorous assessment of the proposed concepts by stakeholders, and to a more consolidated feedback and enhancement proposals for the designers.

REFERENCES [1]

[2]

[3]

[4]

Hakim, J., and Spitzer, T., (2000), "Effective prototyping for usability", Proceedings of the IEEE professional communication society conference, IEEE Educational Activities, Cambridge, Massachusetts, pp. 47-54. Dow, S.P., Heddleston, K., and Klemmer, S.R., (2009), "the efficacy of prototyping under time constraints", Proceedings of the C&C'09, ACM, Berkely, California, USA. Kyng, M., (1995), "Making representations work", Communications of the ACM, Vol. 38 (9), pp. 46-55. Buxton, W., (2007), Sketching User Experiences: Getting the Design Right and the Right Design, Morgan Kaufmann.

[5]

[6] [7]

[8]

[9]

[10] [11]

[12]

[13]

[14]

[15]

[16]

[17]

Horváth, I., (2011), "Theoretical framework for comprehensive abstract prototyping methodology", Proceedings of the International conference on engineering design, ICED11, Kopenhagen, Denmark. Constantine, L., (1998), "Rapid Abstract Prototyping", software development, Vol. 6 (10). Opiyo, E.Z., Horvath, I., and Vergeest, J.S.M., (2001), "Knowledge representation and processing in abstract proottyping of design support tools", Proceedings of the ICED 01, Glasgow. Cooprider, J.G., and Henderson, J.C., (1990), "Technology-process fit: perspectives on achieving prototyping effectiveness", J. Manage. Inf. Syst., Vol. 7 (3), pp. 67-87. Shao, G., and Hanna, W., (1990), "Soft prototyping in the design of military electronics", Proceedings of the Aerospace and Electronics Conference, 1990. NAECON 1990., Proceedings of the IEEE 1990 National, pp. 729-735 vol.722. Wiegers, K.E., (1999), Software requirements, Microsoft Press. Tideman, M., van der Voort, M.C., and van Houten, F.J.A.M., (2008), "A new product design method based on virtual reality, gaming and scenarios", International Journal on Interactive Design and Manufacturing, Vol. 2 (4), pp. 195205. Krishnan, V., and Ulrich, K.T., (2001), "Product development decisions: A review of the literature", Management Science, Vol. 47 (1), pp. 1-21. Du Bois, E., and Horváth, I., (2011), "Abstract prototyping in software engineering: a review of approaches", Proceedings of the ICED11, Technical University of Denmark, Copenhagen. Opiyo, E.Z., Horvath, I., and Vergeest, J.S.M., (2001), "Developing software tools for preimplementation testing of design support tools". Sefelin, R., Tscheligi, M., and Giller, V., (2003), "Paper prototyping - what is it good for?: a comparison of paper- and computer-based lowfidelity prototyping", Proceedings of the CHI '03 extended abstracts on Human factors in computing systems, ACM, Ft. Lauderdale, Florida, USA, pp. 778-779. Fay, D., Hurwitz, J., and Teare, S., (1990), "The use of low-fidelity prototypes in user interface design", Proceedings of the Int Symp on Human Factors in Telecommunications, Turin, pp. 2331. Lim, Y.-K., Stolterman, E., and Tenenberg, J., (2008), "The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas", ACM Trans. Comput.-Hum. Interact., Vol. 15 (2), pp. 1-27.

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

17

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25] [26]

[27]

[28]

[29]

18

Yang, M.C., (2005), "A study of prototypes, design activity, and design outcome", Design Studies, Vol. 26 (6), pp. 649-669. Walker, M., Takayama, L., and Landay, J.A., (2002), "High-Fidelity or Low-Fidelity, Paper or Computer Choosing Attributes When Testing Web Prototypes", Human Factors and Ergonomics Society Annual Meeting Proceedings, Vol. 46 (5), pp. 661-665. Sauer, J., Franke, H., and Ruettinger, B., (2008), "Designing interactive consumer products: Utility of paper prototypes and effectiveness of enhanced control labelling", Applied Ergonomics, Vol. 39 (1), pp. 71-85. Snyder, C., (2003), Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (Interactive Technologies), The Morgan Kaufmann Publishers. Liu, L., and Khooshabeh, P., (2003), "Paper or interactive?: a study of prototyping techniques for ubiquitous computing environments", Proceedings of the CHI '03 extended abstracts on Human factors in computing systems, ACM, Ft. Lauderdale, Florida, USA, pp. 1030-1031. Wood, D.P., and Kang, K.C., (1992), "A Classification and Bibliography of Software Prototyping", Requirements Engineering Project, Carnegie Mellon University, Pittsburgh, 1992. Memmel, T., Gundelsweiler, F., and Reiterer, H., (2007), "Agile Human-Centered Software Engineering", Proceedings of the People and Computers XXI – HCI, Linden J. Ball, M.A.S., Corina Sas, Thomas C. Ormerod, Alan Dix, Peter Bagnall, and Tom McEwan (Ed.). Borysowich, C., (2007), "Prototyping: Types of Prototypes", toolbox.com, Vol. 2011, 2007. Derboven, J., Roeck, D.D., Verstraete, M., Geerts, D., Schneider-Barnes, J., and Luyten, K., (2010), "Comparing user interaction with low and high fidelity prototypes of tabletop surfaces", Proceedings of the Proceedings of the 6th Nordic Conference on Human-Computer Interaction: Extending Boundaries, ACM, Reykjavik, Iceland, pp. 148-157. Constantine, L., (2003), "Canonical Abstract Prototypes for Abstract Visual and Interaction Design", Proceedings of the DSV-IS, Madeira, Portugal. Lin, J., Newman, M.W., Hong, J.I., and Landay, J.A., (2000), "DENIM: finding a tighter fit between tools and practice for Web site design", Proceedings of the Proceedings of the SIGCHI conference on Human factors in computing systems, ACM, The Hague, The Netherlands, pp. 510-517. Landay, J.A., (1996), "Interactive sketching for the early stages of user interface design", School

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

of Computer Science, Computer Science Division, Carnegie Mellon University. Davis, R.C., Saponas, T.S., Shilman, M., and Landay, J.A., (2007), "SketchWizard: Wizard of Oz prototyping of pen-based user interfaces", Proceedings of the Proceedings of the 20th annual ACM symposium on User interface software and technology, ACM, Newport, Rhode Island, USA, pp. 119-128. Klemmer, S.R., Sinha, A.K., Chen, J., Landay, J.A., Aboobaker, N., and Wang, A., (2000), "Suede: a Wizard of Oz prototyping tool for speech user interfaces", Proceedings of the Proceedings of the 13th annual ACM symposium on User interface software and technology, ACM, San Diego, California, United States, pp. 1-10. Hartmann, B., Doorley, S., Kim, S., and Vora, P., (2006), "Wizard of Oz sketch animation for experience prototyping", Proceedings of the UbiComp 2006, Dourish, P., Friday, A. (Eds.), Vol. vol. 4206, Springer, Heidelberg de Sá, M., and Carriço, L., (2009), "A mobile tool for in-situ prototyping", Proceedings of the Proceedings of the 11th International Conference on Human-Computer Interaction with Mobile Devices and Services, ACM, Bonn, Germany, pp. 1-4. Heyer, C., and Brereton, M., (2010), "Design from the everyday: continuously evolving, embedded exploratory prototypes", Proceedings of the Proceedings of the 8th ACM Conference on Designing Interactive Systems, ACM, Aarhus, Denmark, pp. 282-291. Gray, P.D., Kilgour, A.C., and Wood, C.A., (1988), "Dynamic reconfigurability for fast prototyping of user interfaces", Software Engineering Journal, Vol. 3 (6), pp. 257-262. Horváth, I., Rusák, Z., Vegte, W.v.d., Opiyo, E.Z., and Koojman, A., (2011), "Demonstration and assessment of innovation: abstract prototyping of artifact and service combinations", Journal of Computing And Information Science In Engineering. Brandt, E., and Messeter, J., (2004), "Facilitating collaboration through design games", Proceedings of the Conference on Participatory design: Artful integration, ACM, Toronto, Ontario, Canada, pp. 121-131. Maguire, M., (2001), "Methods to support human-centred design", International Journal of Human-Computer Studies, Vol. 55 (4), pp. 587634. Bertrand, J.T., Brown, J.E., and Ward, V.M., (1992), "Techniques for Analyzing Focus Group Data", Evaluation Review, Vol. 16 (2), pp. 198209.

Els Du Bois, Imre Horvàth

[40]

[41]

[42]

[43]

Krueger, R.A., and Casey, M.A., (2000), Focus Groups: A Practical Guide for Applied Research, Third Edition Sage Publications. Liamputtong, P., (2011), "Focus Group Methodology: Introduction and History", in: Focus Group Methodology: Principle and Practice SAGE Publications Ltd p. 224. Patton, M.Q., (2001), Qualitative Research & Evaluation Methods, third edition, Sage publications, Inc. Van Petegem, P., (2009), praktijkboek: activerend hoger onderwijs, Lannoo campus.

MODULAR ABSTRACT PROTOTYPING FOR MULTIPLE STAKEHOLDERS

19