Chapter 6 INSPECTOR: Interactive User Interface Specification Tool
6.1 Adequate Method- and Tool-Support
Most UI development tools are inappropriate for supporting actors from different disciplines in designing interactive systems. They all possess their own particular inputs of UI artefacts expressed in their own formats, and these formats are gener-ally heterogeneous and incompatible. It is therefore genergener-ally recognized by SE, IxD and BPM specialists that structured approaches are required to model, specify, and build interactive systems with high usability (Metzker 2002). Nevertheless, in many non-IT organizations (see Chapter 2), UI design is still an incidental or opportunistic by-product and appropriate methods are not sufficiently embedded in the overall corporate software-development process. Even if they are integrated, their contribu-tion remains marginal, thus reducing the expected positive impact on software qual-ity.
As explained in (Memmel & Reiterer 2008; Memmel et al. 2008f), this reality can be explained by the fact that most integrated development environments (IDEs) are inappropriate for supporting actors from different disciplines in designing inter-active systems. Formal UI tools prevent many actors from taking part in collabora-tive design if they do not have adequate knowledge of specific terminologies. On the other hand, being too informal leads to misunderstandings and conflicts in commu-nication with programmers. Moreover, on further examination, many tools turn out to be more focused on requirements management than on providing support in ex-tracting requirements from user needs and translating them into good UI design. Af-ter all, despite - or perhaps precisely because of - the vast functionality of many tools, the outcome is often unsatisfactory in terms of UI design, usability and aes-thetics. This is described as the high threshold - low ceiling phenomenon of UI tools
Interdisciplinary UI Specification
(Campos & Nunes 2004a). Due to the lack of appropriate tools, many actors tend in-stead to use tools they are familiar with and that can be categorized as being low threshold (for application) - low ceiling (of results), a phenomenon observed in (Campos & Nunes 2007). In order to easily produce some results with reasonable ef-forts, an IDE should have a low threshold: the threshold with which one can obtain a reasonably good UI should be as low as possible. On the other hand, an IDE should have a high ceiling: the maximum overall performance of the IDE should be as high as possible. To these two dimensions, a third one - wide walls – is usually added (see Figure 90). An IDE should have walls that are as wide as possible, meaning that the range of possible UIs that can be obtained via the IDE should cover as many dif-ferent UIs as possible. This cultural change must be supported by an integrating UI specification tool that enables the translation of needs into requirements and subse-quently into good UI design.
Capabilities
Resources
(time, experience,…) 100%50%
Ceiling
Threshold
First generation Second generation Thirdgeneration IntegratedDevelopmentEnvironments
UI types
Walls Capabilities
Resources
(time, experience,…) 100%50%
Ceiling
Threshold
First generation Second generation Thirdgeneration IntegratedDevelopmentEnvironments
UI types
Walls
Figure 90: Threshold vs. ceiling vs. walls for expressing the capabilities of IDEs (Memmel & Re-iterer 2008)
In accordance with (Campos & Nunes 2006), (Geyer 2008) summarized the most important guidelines that UI specification tools should follow:
Explorability. UI tools should effectively support the explorative nature of de-sign processes. As UI dede-sign processes lead to a variety of artefacts, it is neces-sary to provide means to creatively explore large design spaces.
Expressiveness. As modelling and design relies heavily on visual presentation, the means of expression should not be limited. In expressing their ideas, design-ers need to be supported with a variety of informal and formal tools.
Guidance. A design tool should guide the overall design process just enough to Design principles for UI tools
tractive to become adopted in practice. The models and design artefacts em-ployed need to invite stakeholders to apply them.
Explorability and expressiveness imply that UI specification tools should support abstract thinking and detailed modelling. Accordingly, stakeholders should be guided in travelling along a UI specification process that incorporates tasks involv-ing thinkinvolv-ing and buildinvolv-ing. In contrast to most UI tools, the real work style of stake-holders who take part in corporate UI specification is to be taken into account. With tool support that is appropriate for both the user and the problem, creative processes can be simplified. Creativity has been rightly recognized as a key to economic growth and social transformation. Following (Florida 2002; Florida 2005), the future is shaped by technology, talent and tolerance. Accordingly, support for creativity has to attract the most innovative minds and empower them to accelerate the pace of discovery and innovation (Shneiderman et al. 2006b).
According to the mega-creativity framework by (Shneiderman 2000; Shneider-man 2003), the inspirational, the structural and the situational models support the creative thinking necessary in UI development processes. The inspirational model promotes techniques such as brainstorming, free association and imaginative think-ing. Creativity can emerge if stakeholders and designers can break away from their existing mindset and are enabled to perceive the problem from a new perspective.
This can be supported by visual techniques that present loose relationships between artefacts, such as mind maps (Geyer 2008). The structural model supports creative processes by analyzing previous work. Visualizing how things work currently and modelling the status quo, for example in flow charts, is the key to understanding a problem. (Shneiderman 2000) recommends iterative structural modelling with in-cremental methods that support going back and making changes. The situational model considers the social context as a key part of creativity. Accordingly, the influ-ence of social challenges, mentors and peers creates a strong desire to innovate in pursuit of recognition. According to (Shneiderman 2000), the context is incorporated by consultation with people and discussion with actors in the field.
Based on this creativity framework, (Shneiderman et al. 2006b) summarize con-crete design principles for the development of tools that support creative processes.
What distinguishes these principles from other UI principles is that they emphasize easy exploration, rapid experimentation, and fortuitous combinations that lead to de-sign innovations. While some of these guidelines explicitly address UI tools, they also aim at improving general creative processes that require a combination of novel artefacts in the domains of computer programs, scientific writing, engineering dia-grams or artwork. The most important of the guidelines that are relevant to UI speci-fication are summarized in the following, using just very slightly adapted versions of the original wording by (Shneiderman et al. 2006b):
Support Exploration. An important requirement for creativity is to be able to try out many different alternatives. Users must be encouraged to explore the UI specification space and need support for sketching and trying out dozens of ideas. A UI specification tool must also be simple and easy to use, so that pro-ject stakeholders can model different artefacts quickly. Finally, tools must be pleasurable and fun to use. When people are stressed or have to concentrate too much simply to use the tools, they will have fewer cognitive resources available for finding creative solutions to their tasks (Shneiderman et al.
2006b).
Low threshold, high ceiling, and wide walls (see Figure 90). Effective UI tools should make it easy for novices to get started (low threshold), but also al-low experts to work on increasingly sophisticated projects and develop power-ful results (high ceiling). The concept of wide walls means that tools should support and suggest a wide range of explorations. One strategy for achieving all three dimensions is to include elements and features that can be used in many different ways. The design challenge is to be specific enough so that us-ers can quickly undus-erstand how to use the features (low threshold), but general enough so that users can continue to find new ways to use them (wide walls).
Creativity-driven UI specification
A framework for creativity
Design principles for UI specifica-tion tools
The tool should help users to learn how to use the features so that they can un-derstand the variety of possible uses (Shneiderman et al. 2006b).
Support Many Paths and Many Styles. Research distinguishes between „left brain‟ thinkers (logical, analytical; people who can do maths) and „right brain‟
thinkers (holistic, intuitive; people who can draw). In many organizations, the
„left brain‟ approach is extolled and viewed as superior to the „soft‟ approach.
With regards to bridging the gaps between the disciplines and interdisciplinary UI specification, a UI tool should pay special attention to making sure that tech-nologies and activities are accessible and appealing to the „right brainers‟ as well (Shneiderman et al. 2006b).
Support Collaboration. An important implication of the diversity of stake-holders is the need to provide support for collaboration. In corporate UI specifi-cation, most creative work is done in interdisciplinary teams. It is important that the creativity-support tools allow each person to contribute by using their own talent. A UI specification tool should also allow team members to work on their own parts of the UI in parallel (Shneiderman et al. 2006b).
Support Open Interchange. The creative process is often supported by a single tool but will more often require that the user orchestrate a variety of tools, each of which supports part of the task. This was well demonstrated by the analysis of related work in Chapter 5. The common solution is therefore that creativity-support tools interoperate with other tools. This includes the ability to easily import and export data in widespread formats such as XML in general, or usiXML (Vanderdonckt et al. 2004; Vanderdonckt 2008) in particular. Another approach is to integrate all necessary artefacts and models in one specification space. This can be achieved with a professional „plug-in‟ architecture (Shnei-derman et al. 2006b).
Make It As Simple As Possible - and Maybe Even Simpler. Reducing the number of features can actually improve the user experience in working with UI tools. What initially seems like a constraint or limitation for many experts or programmers can, in fact, foster new forms of creativity – for example, through the various opportunities created by interdisciplinary collaboration. The goal is to develop tools that offer the simplest ways to do the most complex things (Shneiderman et al. 2006b).
Iterate, Iterate - Then Iterate Again. Iterative design using UI prototypes is also important for support and UI specification tools. With creativity-support tools, users should be encouraged to play around with the materials and try out several alternatives, to change direction in the middle of the process, and to take things apart and create new versions (Shneiderman et al. 2006b).
Design for Designers. In designing new creativity-support tools, it is important to design for designers (i.e. stakeholders) – that is, to design tools that enable others to design, create, and invent things. With regards to corporate UI specifi-cation, this also means that non-IT experts should be able to design UIs without specific knowledge of SE or IxD. As outlined in Chapters 4 and 5, paper and pencil is a tool commonly used by creative practitioners such as architectural designers. Hand-drawn sketches and diagrams have been found essential for ar-chitects‟ creative contemplation. The process of drawing helps designers who are engaged in „reflection-in-action‟ (Shneiderman et al. 2006b).
UI specification and creativity-support tool research can contribute to bridging Bridging the gaps with creativity
development (von Hippel 2005). Developing an understanding of how work in one discipline is useful to another helps to foster creativity and UI quality.
With the common denominator, semi-formal and rather approximate and prag-matic means of modelling and UI design were established as a shared vehicle in cor-porate UI specification. Because agile notations are integrated in the common de-nominator, corporate UI specification processes - which are based on prototyping-driven interactive UI specifications as proposed in this thesis - could well be catego-rized as being agile. Taking into account the design room and whiteboard metaphor, this affinity is strengthened by agile practices such as „Display Models Publicly‟.
This practice also underlines the importance of shared design rooms in UI develop-ment (Gundelsweiler et al. 2004).
With INSPECTOR, this design room is moved into the virtual world, making it an electronic „wall of wonders‟ (Gottesdiener 2002). As explained by (Ambler 2006b), computer-aided support for sharing artefacts does not contradict the nature of agility.
“You should display your models publicly, often on something called a „modeling wall‟ or a „wall of wonders.‟ This supports open and honest communication in your team because all of the current models are quickly accessible to them, as well as with your project stakeholders because you aren't hiding anything from them. Your modeling wall is where you post your models for everyone to see;[…]. Your model-ing wall may be physical […]. Modelmodel-ing walls can (also) be virtual, such as an in-ternal web page that is updated with scanned images.” (Ambler 2006b)
Naturally, INSPECTOR can do more than just safekeep scanned images of UI-related artefacts. Moreover, considering the UI specification method and the concep-tual model underlying the proposed solution for tool support, INSPECTOR also needs to match the most important agile principles and practices (Ambler & Jeffries 2002; Ambler 2004b) outlined in Table 67 and Table 68. As discussed in (Memmel et al. 2007a), agile principles and practice help to bridge the gaps between the disci-plines. Accordingly, designing INSPECTOR with regards to agile values strength-ens its suitability for interdisciplinary, model-based UI specification processes.
Table 67: The compatibility of model-based semi-formal UI specification with some important ag-ile principles
Agile principle Compatibility with model-based semi-formal UI specification Model with a
Purpose Switching between different models allows the design rationale of a requirement to be under-stood and its origin to be traced; modelling therefore adds significant value to the UI specifica-tion process
Maximize
stake-holder ROI By allowing all stakeholders to participate in the UI specification process, they can contribute to the final solution without media discontinuities, loss of precision or overwhelming UI tools; in-teractive UI specifications are intended to prevent costly late-cycle changes and rework Multiple models No single model is sufficient for all UI specification needs. By providing different modelling
languages for different stages of the process, several ways of expressing problems are available;
the relationship or associations between the models is to be clear
Rapid feedback Because the model-based UI specification process is driven by prototypes, interactive UI speci-fications can usually provide ‘living simulations’ of the UI at any time
Embrace change Models should allow easy enhancement or change. Agile models only need to be approximate and tend to be rather pragmatic. They therefore allow changes without requiring the user to be excessively precise
Software is your
primary goal The goal of interactive UI specifications is to produce a specification-level UI design and reus-able code for suppliers, rather than extraneous documentation. With regards to this goal, a model-based approach just focuses on the models to be developed and on understanding the de-sign solution
In order to describe the work style of stakeholders in UI specification processes, the dimensions defined by (Campos & Nunes 2005a; Campos & Nunes 2006) help
Agile semi-formal UI specification
Wall of wonders
Addressing agile principles and practice
Dimensions of work style
to structure the most important activities of UI design and specification processes.
The dimensions can be grouped under three main categories: (1) notation style-related dimensions (perspective, formality and detail), (2) tool usage style-style-related dimensions (traceability, functionality and stability) and (3) collaboration style-related dimensions (asynchrony and distribution). Each dimension is highly relevant to UI specification tool support and accordingly is taken into account in the sum-mary of tool requirements outlined in Table 69.
Table 68: The compatibility of model-based semi-formal UI specification with some important ag-ile practices
Agile Practice Compatibility with model-driven development Active stakeholder
participation The common denominator invites all stakeholders to take part in modelling and designing in-teractive systems. Sketches and UI prototypes are a language everybody understands. Easy-to-use tool support that matches one’s usual work style fosters involvement
Apply the right
ar-tefacts Some modelling languages are inappropriate for describing specific parts of the system. The common denominator provides a sound set of artefacts for all stages of UI specification Iterate to another
artefact When a specific artefact is unable to express certain parts of the system, a linked and associ-ated network of artefacts supports switching to a different means of modelling
Model in small
in-crements Interactive UI specifications can be developed iteratively and incrementally; models and UI design can be charged with different levels of detail and become mature during later stages Model with others Stakeholders can model according to their expertise. Different models are combined to
simula-tions and the interactive UI specification
With regards to the requirements for developing tools able to support creativity and interdisciplinary UI specification, several detailed needs can be deduced. Table 69 summarizes all the important key requirements for a new and innovative UI specification tool that is adequate for the kind of corporate UI specification proc-esses outlined in Chapter 3. Accordingly, the following overview of tool require-ments takes the different capabilities of stakeholders into account. The requirerequire-ments in Table 69 also address the models and prototyping artefacts that make up the common denominator. They need to be properly integrated and visualized, and team members and stakeholders of all kinds need to be able to use them easily (low threshold). Nevertheless, the way the specification artefacts are integrated must al-low high quality, expressive and detailed UI specifications (high ceiling) for a vari-ety of corporate interactive software systems (wide walls).
Table 69: Requirements for interactive UI specification tools on the basis of (Campos & Nunes 2006; Shneiderman et al. 2006a; Campos & Nunes 2007; Memmel et al. 2007a; Geyer 2008);
nota-tion for tracing requirement to possible technical solunota-tion adapted from (Memmel et al. 2008b) Identified Need Principle(s) Tool requirement
All kinds of actors must be able to proactively take part in the UI speci-fication
Support for design assistance and creative thinking for everybody. Guide through the process by offering navigation aids.
Respect discipline-specific tool usage and knowl-edge.
Employ interaction concepts familiar to all actors and compatible with current work practice.
Employ metaphors to map tool support to corporate Overview of requirements for a new
UI specification tool
Identified Need Principle Tool requirement Stakeholders must prevent costly
late-cycle changes and specify the UI in detail to ensure UI quality
Explorability Support exploration Maximize stake-holder ROI
Provide adequate means of UI prototyping to allow up-front usability evaluation of look and feel; help to detect and document usability issues.
Implement means to easily provide feedback on the UI and the underlying models.
Stakeholders must be able to provide traceability of the design rationale and maintain transparency during the translation of models into UI de-sign and vice versa.
Stakeholders need to work at differ-ent levels of detail and must be able to implement smooth transitions
Enable keeping track of all artefacts during the de-sign process and allow structured organization.
Provide functions to interconnect artefacts to allow switching back and forth between different (levels of) models and UI designs.
Keep design decisions for later reference to extend traceability. Effectively communicate final designs and their rationale.
Keep design decisions for later reference to extend traceability. Effectively communicate final designs and their rationale.