Formal vs. Informal User Interface Specification

“Taken strongly, formalism in mathematics and computing is about being able to represent things in such a way that the representation can be analysed and manipu-lated without regard to the meaning.” (Dix 2003), p. 1(431)

Format and content of UI specifica-tions

The scope of UI specification

A formal notation should be well focused upon the problem and should therefore support the description of UI design and dialogue structures. The notation should also take the background of stakeholders into account and make sure that compre-hensibility and formalism are balanced. Especially with regards to iterative UI de-sign, the notation should be easy to change. One of the most important aspects is the usefulness of the notation for the application domain and the appropriate level of de-tail or formality.

Table 6: Criteria that make formal methods function well; adapted from (Dix 2003) with a focus on UI specification

Criteria Description

Useful The notation is to address a real problem and should be focused on the UI dialogue structure Appropriate The notation provides just enough detail. The formalism must not deal with too much detail, as

this makes it hard to see the things you really need

Communication Pictorial representations and clear visualizations of flow are adequate means of communication with the client. Formal methods are often claimed to be a means to improve communication within a design team, because of their precision. However, when precision is achieved at the cost of comprehensibility there is no real communication

Complementary The notation should follow a paradigm different to that of implementation. The notation must al-low one to see the system from a different perspective, in this case one more suitable for produc-ing and assessproduc-ing the UI design

Fast payback Reduce the lead-time to see the first running system. Spending a lot of time up-front is laudable, but results must be visualized early in the process. Dialogue flow charts do not produce long-term savings, but support early-stage production of running systems

Responsive The notation must support a rapid turnaround of changes. Changes to the UI design of a system can occur frequently, as requirements become clear with every iteration cycle. In this process, a feeling of control and comprehension makes it easier to safely make changes

Reliability Clear boilerplate code is less error-prone. Although the transformation process from diagram to code is not automated, it is a fairly automatic hand process applying and modifying boilerplate code templates. The heavy reuse of standard fragments greatly increases the reliability. This view of reliability through reuse can be extended in terms of taking software and HCI patterns (Gamma et al. 1995; Borchers 2001) into account

Quality The clear labelling of diagrams makes it easy to track whether all paths through the UI dialogue have been tested. The visualization of requirements and dialogue flow therefore plays an impor-tant role with regards to the quality of a software and UI development process

Maintenance It should be easy to relate bug and enhancement reports to the UI specification. If the screens pre-sented to the user include information labels, it is easy to track bug reports or change requests Formal notations used in software and UI development usually all try to remain

abstract and be detached from the way the system is coded, but still be precise about some aspect of its behaviour. In contrast to an informal description, a formal de-scription can say precisely whether or not a real system satisfies a dede-scription (Dix 1995). In all, formal notations can be categorized into two main groups (Dix 2003):

 Finite process notations: capture the sequences and processes of computation in terms of a finite number of stages, phases, states or steps. This includes many diagrammatic representations such as state-transition diagrams, flow charts and textual notations such as formal grammars and production rules.

 Infinite state notations: are somewhat mathematical notations using either a set and function notation, or a more algebraic representation.

With regards to the differentiation of formal notations, the question is whether a graphical notation can be formal. Diagrammatic formalisms (i.e. finite process nota-tions) are often recognized as being less formal in terms of being less rigorous or more accessible. For many stakeholders, diagrams are more tangible and immedi-ately appealing. Nevertheless, they can be just as rigorous as more obviously

Important properties of notations

What is formal?

Semi-formal graphical notations

mathematical looking notations (Dix 2003). Hence, a diagram can be formal, infor-mal or somewhere in between. Diagrammatic dialogue notations are not less forinfor-mal because they are graphical. After all, if a dialogue notation has textual annotations that require informal interpretation (see Figure 14), it is defined as being semi-formal. However, the structure of the diagrams (i.e. shapes and connections) is still formal and capable of formal analysis.

Figure 14: A state-transition network incorporating elements of UI design; from (Dix 1995) The advantage that comes with the precision of formal notations is that they ex-ternalize design decisions that otherwise might not be noticed until the final system is being implemented and delivered. The disadvantage of formal methods is their decreased acceptance, which can be widely explained as being due to lack of under-standing among non-IT personnel. In large and mature IT organizations (e.g. IT suppliers, service providers), some stakeholders may be able to work with formal methods (Dix 2003). This is, however, not true for non-IT organizations as we ana-lyzed them in the context of this thesis, for example (see Chapter 2).

“Structured engineering approaches that are focused on systems building and fa-vour use of formal representations, since they support the analysis and transition to implementation that is needed for making effective, efficient and reliable software.

Approaches that rely on participation of people unskilled in formal methods, natu-rally favour informal representations, as they enhance the dialogue with end-user and support validation. Unless political arguments are used, it should be possible to combine formal and informal representation, to get the benefits of both. In the end, the system description will have to be executable, so a formal representation must eventually be derived from the informal ones. Another important argument for for-Advantages and disadvantages of

formality

precision and uncertainty/commitment as important characteristics of design repre-sentations. Formal models, in turn, focus more on being concise, complete and final representations. Moreover, there are few possibilities for expressing informal char-acteristics in formal diagrams. (Jones & Sapsford 1998) accordingly note that infor-mal representations have the advantage that they do not impose any conceptual con-straints on the drawings. However, to ensure that agreement is really based on common understanding, it is necessary that more formal representations be used dur-ing later stages, when it is important to be able to share the design with other stake-holders. For example, the AUTOMOTIVE RE process shown in Figure 15 presents the process of refinement, starting with informal and vague requirements but ending with a consistent specification that depends on a successful translation of (usually) text-based description into more expressive kinds of notations.

Figure 15: The AUTOMOTIVE requirements-engineering process (von der Beeck et al. 2002) This suggests that formal notations should be packaged so that non-IT experts are able to understand and apply them without having a steep learning curve (i.e. a high threshold). One way this can be achieved is through notations that have formal un-derpinnings, but that are applied in a more pragmatic and approximate way. Semi-formal dialogue notations (see Figure 14), which have a graphical form, therefore tend to be more interdisciplinary artefacts. Dialogue specification (see Table 7) is the least mathematical kind of formal notation and therefore the one most easily used by the non-formalist stakeholder.

Table 7: Uses of formal methods; based on (Dix 1995) Use of formal method Description

Specification of individual interactive systems

Concentrates on a specific system and the complete specification of all aspects of its behaviour. Its purpose is to clarify design decisions, to expose inconsistency and to act as a contract with the implementer. UIs can be extremely complex and being able to deal with them at a more abstract level is thus even more important than it is for gen-eral software.

Generic models of interac-tive systems

Their purpose is to give new insight into general problems as the properties of the problem-domain are analyzed. They can be used as part of a formal development proc-ess to constrain the design of specific systems. In other words, results from the analysis of generic models can be applied to the formal specifications of specific systems.

Dialogue specification and analysis

Dialogue notations are used to describe specific systems, but at a different level of de-tail than a full formal specification. They are concerned with the steps of the user inter-action but typically do not fully specify the meaning attached to the user inter-actions.

Pragmatic semi-formal dialogue no-tations

(Dix 2003) identifies a huge growth in the use of diagrammatic UI specifications, especially in the use of formal UML. Even in HCI, the employment of formal meth-ods has gradually grown and is now a topic of various established conferences (e.g.

DSV-IS, CADUI, EHCI, TAMODIA). Here, UI specification has become almost synonymous with formal methods. One of the main uses of formal methods in IxD is therefore (1) to specify the behaviour of specific systems, (2) to assess potential us-ability measures or problems, and (3) to describe the system in sufficient detail so that the implemented system matches the requirements. As a side effect, the UI specification process forces the designer to think about the system clearly and to consider issues that would otherwise be missed (Dix 2003). After all, writing down ideas and requirements in a structured fashion helps to visualize the big picture and to externalize missing information. The notation that is used here should not influ-ence the number or nature of the ideas that the interaction designer generates.

To achieve more consistency between different kinds of models and notations, there must be a close correspondence of structure between the formal and the infor-mal concepts. Because stakeholders cannot all understand the requirements properly the first time, (Dix 2003) proposes a prototyping-based UI development process. But prototyping alone is fundamentally flawed unless it is guided by an analytical and theoretical framework. Here, different kinds of notations can help to understand re-quirements and support the translation of rere-quirements into UI design. A road map for UI specification of interactive systems should therefore take into account both of the different kinds of notations, i.e. UI-related models, and UI prototypes.

Any form of specification involves some formal parts, about which it makes pre-cise statements, and some informal parts, mostly in the form of textual comments. In order to overcome the limitations of textual UI specifications, as discussed in Chap-ters 1 and 2, text must be supplemented by interactive UI prototypes. The prototypes then function as living descriptions of the look and feel of the UI and help to under-stand and validate requirements. The prototyping process therefore is propelled and guided by informal, semi-formal and/or formal methods and drives the overall UI specification process. The assembly of different kinds of artefacts, i.e. models and prototypes, into a more expressive kind of prototyping-driven UI specification (see Chapter 1) reflects the common practice in today‟s UI development processes. Mate-rial from all phases of development that impact on the development of the final sys-tem must be forwarded to the developers (see Chapter 3.4).

Many argue that formal methods are too difficult, cannot be scaled and require too much training (Dix 2003). Particularly during the early stages of interaction de-sign, „back-of-an-envelope‟ notations are more widely used to capture initial, sketchy ideas (Preece et al. 2002). The gap between informal and formal methods therefore especially exists in the minds of designers and clients. What is still miss-ing, however, is a framework that integrates both formal and (semi-)formal ap-proaches and determines the stage from which more formal notations should be used. Such a framework could provide adequate notations for different target groups in order to ensure understandability. For communicating with developers, more for-mal and technical notations are the much better choice. Otherwise, more inforfor-mal notations are preferable.

Choosing the medium for the message can affect how the message is received and hence the meaning that is communicated, so it‟s important to get the medium right.

(Preece et al. 2002), p. 222

If different kinds of notations are to be integrated into a UI specification, it is necessary to determine their power. This refers to the graphical representation as well as to the ability to deduce from models information that is usually hidden due Formal methods and HCI

Correspondence between different kinds of models

Prototyping-driven UI specification

A road map for UI specification

The right kinds of models