CanonSketch, TaskSketch, WinSketch and MetaSketch

CanonSketch and TaskSketch (Campos & Nunes 2004a; Campos & Nunes 2004b; Campos 2005a; Campos 2005b; Campos & Nunes 2005b; Constantine &

Campos 2005; Campos & Nunes 2007) are based on the idea of a hybrid view of UI design using canonical abstract UI prototypes and a variety of UI models. In order to match the work styles of practitioners, both tools are based on a novel UML-based notation called „Wisdom‟ (Whitewater Interactive System Development with Object Models). Due to the widespread incompatibility of UML with corporate UI specifi-cation, the Wisdom method is especially focused on UI-related issues. It concen-trates on those models relevant to describing the UI (Nunes & Cunha 2000; Nunes &

Cunha 2001)

Figure 85: Workflows, activities, models and diagrams in Wisdom (Nunes 2001; Nunes & Cunha 2001)

Wisdom is object-oriented and uses the UML to specify, visualize and document the artefacts. It is specifically adapted for developing interactive systems because it uses, and for this purpose it extends, the UML to support IxD techniques. However, Wisdom is a lightweight SE method, because it concentrates on a small set of mod-els. Wisdom is related to iterative UI prototyping efforts, which ultimately lead to Canonical prototypes and modelling

Modelling with Wisdom

user models may have led to considerable inconvenience when using this approach.

Even with this extension, however, the Wisdom approach only models roles indi-rectly through use-case diagrams and does not provide an explicit model for user modelling. In summary, the diagrams employed are all known from the discussion of modelling techniques in search of the common denominator (see Chapter 4). As it is, Wisdom only uses a subset of UML (approx. 29% of the total concepts in UML 1.1).

In the Wisdom approach, use-cases play an important part in capturing functional requirements and driving the whole development process. The use-cases also serve as the major input for finding and specifying task flows. Later, activity diagrams represent in more detail the desirable and realistic task flows performed by the users.

Activity diagrams are then used throughout the entire development process to proto-type and design the UI. Wisdom can also support modelling with the essential use-case notation, which allows the structure of use and the structure of the UI to be connected. Despite its focus on the UI, Wisdom also takes technical issues into ac-count and allows notes on non-functional requirements to be attached to use-cases (Nunes & Cunha 2001). All told, Wisdom models allow the linking of abstract re-quirements to the UI design through a systematic process that travels from models to the surface. CanonSketch and TaskSketch also have a strong focus on supporting transitions between design artefacts.

CanonSketch was the first tool presented by (Campos & Nunes 2004a; Campos

& Nunes 2004b). It introduces three distinct levels for modelling and UI design, namely (1) UML class diagrams, (2) abstract canonical prototypes and (3) concrete HTML for presenting the UI design. The class diagrams can be arranged in an easy-to-use modelling environment. The view of the UI can be easily switched from the class diagram to the other two presentations by simply clicking on a tab-like naviga-tion aid at the top of CanonSketch‟s canvas (see Figure 86).

Figure 86: Class modelling with CanonSketch (Campos & Nunes 2004b)

Later on, abstract models can be transformed into canonical abstract representa-tions of the UI, which in turn can be exported to HTML (see Figure 87). The model-driven approach (see Chapter 3.2.2) of CanonSketch therefore allows the same model to be displayed at different levels of abstraction and supports the generation of code from the developed models. But as a conceptual model for the UI has to ex-ist before tasks can actually be designed, CanonSketch is inadequate because it lacks

The models of Wisdom

CanonSketch

support for early process phases. This sets the stage for the tool‟s brother in arms, called „TaskSketch‟.

Figure 87: Canonical abstract prototype and HTML version developed with CanonSketch In contrast to CanonSketch, TaskSketch (Campos & Nunes 2004b) is focused on linking and tracing use-cases for requirement analysis, before actually designing the UI with CanonSketch. Again, the previously discussed Wisdom approach is utilized to adapt use-cases and activity diagrams to UI design. With TaskSketch, the user can develop activity diagrams, use-case narratives and a participatory view of the left side of the split pane (see Figure 88).

Figure 88: The main user interface of TaskSketch (Campos & Nunes 2005b) Task Sketch

With WinSketch, the concepts of CanonSketch and TaskSketch were further en-hanced. WinSketch combines the functionality of its two predecessors. Users are guided through the usage-centred design process by following a horizontal hierar-chical navigation that is structured into the basic entities „requirements‟, „analysis‟

and „design‟. Each step is accompanied by one or more diagrams that represent model-based views of different degrees of abstraction within the process. Book-marks of models are then used to trace mutual relationships between requirements or models and corresponding interface components. Due to its close relationship to CanonSketch and TaskSketch, WinSketch provides effective support in tracing re-quirements. However, (Geyer 2008) found that relationships between artefacts are sometimes barely visible. As diagrams are nearly always displayed in small frames, it is hard to gain an overview and to switch between different representations. The design rationale of the UI specification can therefore be hard to understand.

Figure 89: The UI of WinSketch (Alfonseca et al. 2006)

WinSketch (see Figure 89) was not presented to the scientific community, but was probably the basis for MetaSketch (Nóbrega et al. 2007; Nóbrega 2008). The motive behind MetaSketch is also to bridge the gaps between the disciplines, espe-cially SE and IxD. The tool is designed to overcome the differences between the disciplines by moving interdisciplinary modelling to the meta-modelling level. Ac-cordingly, MetaSketch is a workbench that allows the definition of new modelling languages based on OMG (The Object Management Group) standards such as MOF 2.0, OCL 2.0 and XMI 2.1, and it is specially tailored for creating new members of the UML family of language. It also means that MetaSketch can be used to extend and adapt version 2.0 of the UML, creating new possibilities and opportunities in the context of model-driven UI development approaches. In (Nóbrega et al. 2007), Me-taSketch is used to extend UML 2.0 with canonical abstract prototypes (see Chapter 4) and CTT (see Chapter 4). Due to its meta-modelling approach, MetaSketch is more flexible and potentially allows the integration of many more models in order to provide shared means of UI modelling. But ultimately, the approach is still very close to SE practice and requires a good understanding of UML, because the models created must be formal and precise enough to be able to generate code.

WinSketch

MetaSketch