Pruebas de tolerancia a mineral

The Cognitive Dimensions of Notations were introduced by Green in 1989 as criteria for assessing the usability of both interactive user interfaces and non-interactive notations [163]. Consisting of a small set of concepts that are relevant to any “information artifact”, they have previously been applied in detail to the specific domain of visual programming languages [161]. The Cognitive Dimensions8 _{serve as discussion tools, not as absolute qualities of a desirable system, such}

that different systems will require different positions on the axis of each dimension, with some dimensions trading off against others.

The Cognitive Dimensions are used in this section to structure the justification of the various decisions taken in the design of Jeeves, and the trade-offs in other dimensions that these decisions have introduced. The dimensions of interest, and their relationships to other dimensions, are summarised in Table 5.7.

5.3.1.1 Closeness of mapping: What ‘programming games’ need to be learned?

The closeness-of-mapping dimension defines how closely problem entities in a domain are mapped onto task-specific program entities. In the problem domain of ESM, programmatic representations are inherently event-driven; for example, “when something happens (an appropriate time, or a button press), do something else (send a survey, send a prompt)” is an example of an event-driven programming statement.

5.3. VISUAL SYNTAX AND SEMANTICS 103

Table 5.7:Strong dimensions of Jeeves, and their positive and negative influence on other dimensions

Strong Dimension Positively affects Negatively affects

Closeness of mapping Role-expressiveness Diffuseness Abstraction Error-proneness Hidden dependencies

Viscosity N/A

Premature commitment Viscosity

Error-proneness N/A Secondary notation Role-expressiveness Consistency Error-proneness N/A

Viscosity Premature commitment N/A

Visibility Viscosity

Progressive evaluation

Hidden dependencies Abstraction

Consistency Error-proneness Hidden dependencies

Hard mental operations

Blocks-based programming languages support a one-to-one mapping between problem concepts and task-specific program entities (in this case, graphical blocks) provided that these concepts are carefully chosen. Further, studies of Scratch and App Inventor show that students can quickly create complex apps with an event-driven structure, suggesting that blocks are appropriate for mapping problems that can be expressed as such.

In Jeeves, the event-based problem concepts have been derived from previous ESM studies, including relevant triggers, actions and conditions. Mapping these concepts to blocks, and grouping these blocks by the type of function they perform, appears to simultaneously increase therole-expressivenessof the notation, defined as how well a visual representation of elements communicates their purpose.

Trade-offs?

The problem concepts defined in Jeeves do not enable additional abstraction beyond that introduced in the design. Blocks can be combined to provide the functionality of an app, but combinations cannot be encapsulated into larger abstract blocks. Allowing flexibility in abstraction is not necessarily a positive feature, as time must be taken by end-user developers to learn and create these additional abstractions.

104 CHAPTER 5. DESIGN OF JEEVES

Figure 5.9:Diffuse representation of a ‘Do not Disturb’ button

Figure 5.10:More terse representation, but with a program entity not mapped to a

derived problem concept

A further trade-off to mapping only concepts considered relevant to a problem is that of

diffuseness, or how many entities are required to express a meaning. Consider Figure 5.9, which shows the design of a ‘Do Not Disturb’ button for restricting survey prompts, and Figure 5.10, a considerably moreterseexample of the same function. The ‘snooze’ action was not initially felt to map closely to the problem domain of experience sampling. However, as a result of a usability study described in Chapter 6, the snooze action is now an adopted block. Further studies may trade off closeness-of-mapping for less diffuse representations in a similar way.

5.3.1.2 Error-proneness: Does the design of the notation induce ‘careless mistakes’?

Visual languages are well-suited to reducing error-proneness in novice users. Particularly in Jeeves and similar blocks-based languages, the puzzle-shaped program entities afford syntactically correct combinations, which appear to visually fit together. When one attempts to insert a block where it does not make syntactic sense, the block does not appear to ‘snap’ into place, and instead sits detached on the canvas. The reduction of syntactic errors by definition improves app quality and reliability - of particular importance in EUD where the developed artifact is to be used by a separate group of users (public-outward EUD [142]). Minimising the opportunity for errors has a generally positive effect on developer experience [138], but particularly in relation to the Cognitive Dimensions of hidden dependencies and viscosity.

5.3. VISUAL SYNTAX AND SEMANTICS 105

The puzzle-piece block shapes, which suggest how they should fit together, makes hidden dependencies between programmatic constructs visually explicit. Further, a notation that does not allow for erroneous changes increases the ease with which correct changes can be made, thereby reducing the viscosity of the notation.

Trade-offs?

There do not appear to be any direct trade-offs to reducing error-proneness in Jeeves, or indeed any language. Although there areindirecttrade-offs such as the visual verbosity of the blocks paradigm, it is never desirable for a language to be far along the error-proneness dimension.

5.3.1.3 Premature commitment: Do programmers have to make decisions before they have the information they need?

Green and Petre have identified different types of commitment that languages may enforce [161]. For example, some languages have alayout commitment, where developers must commit to placing visual components in certain places on-screen. This is avoided in Jeeves by the ability to freely move blocks around at any point. Further, separate triggers do not need to be joined together, removing the potential for ‘spaghetti diagrams’ that can cause problems in flow-based visual languages. Jeeves also avoids aconnection commitment- if an action is found to be in the wrong trigger, for example, then it can be moved to the correct trigger in one drag-and-drop motion, ensuringviscosityis reduced. One potential issue identified in Jeeves is thecommitment to construct - if multiple actions are found to be in the wrong trigger, then there is no way to transfer them as a group; each must be moved individually. The magnitude of this issue is reduced through ensuring that Jeeves enforces nocommitment to order of creation. Developers can identify appropriate actions before knowing which trigger to use, or define an attribute before knowing which expression it will belong in.

Commitment to order of creation is prevalent in EUD-ESM tools based on Web forms. Although forms are a familiar input mechanism for the majority of computer users, and a common paradigm for EUD-ESM, the guided, linear approach could be problematic. In usability studies conducted in Chapter 6, participants would often define actions before deciding how to trigger them. Others would create triggers, then fill them with actions. A researcher’s mental model may be inhibited by forcing premature commitment to either [161]. Instead, blocks can support researchers in translating their study protocols in abricolagefashion [164], thereby reducingerror-proneness.

Trade-offs?

As with error-proneness, while the conditions affording low premature commitment may have their own disadvantages, there can be no direct trade-off to ensuring developers have the

106 CHAPTER 5. DESIGN OF JEEVES

knowledge necessary to avoid programming incorrect functionality.

5.3.1.4 Secondary notation: Can programmers use layout, colour, other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language?

In virtually all domains and languages, visual or otherwise, the use of secondary notation is beneficial. Although Jeeves in its current state does not allow comments or annotations, other sources of secondary notation have been used to facilitate construction. For example, the shape and colour of blocks are suggestive of where they should be integrated into the specification, reducing the potentialerror-pronenesscaused by dragging incompatible blocks together. Further, the canvas of Jeeves allows users to arrange triggers as they see fit, potentially grouping them by functionality or ordering time-based triggers chronologically, to employ their own secondary notation.

In Bertin’s Semiology of Graphics, eight visual variables are defined that can be used to distinguish information graphically [165]. These are: horizontal position, vertical position, shape, colour, size, brightness, texture, and orientation. Jeeves makes direct use of the two positional variables, as well as shape, colour and size. While not making full use of potential information, this secondary notation is adequate to ensure therole-expressivenessof each block. When the role of each block type is established through this secondary notation, it simultaneously enhances theconsistencyof Jeeves as developers learn to apply the same block patterns.

Trade-offs?

Again, there are no direct trade-offs to employing secondary notation. As expressed in Green and Blackwell’s tutorial on the Cognitive Dimensions:“It is hard for me to imagine any situation that would not be improved by making a notation easier to read”[166, p. 29].

5.3.1.5 Viscosity: How much effort is required to perform a single change?

A low viscosity is a major factor in the design of Jeeves, in order to ensure that changes can be made easily, particularly by novice users. The blocks paradigm supports this; adding, removing, or swapping an action in Jeeves is a simple case of dragging and dropping. Actions and expressions can be swapped about in their triggers, moved to different triggers, or removed entirely without the need to reconnect wires or rearrange boxes, as in flow-based visual notations. A low viscosity also has a mutually positive effect onpremature commitment. By ensuring a study is simple to modify, developers are not committed to a specific design, as any changes can be easily reversed.

5.3. VISUAL SYNTAX AND SEMANTICS 107

Trade-offs?

Green and Blackwell explain that high viscosity can sometimes be beneficial when dealing with safety-critical systems that could have disastrous consequences through small modifications [166]. While the magnitude of consequences are dependent on its context of use, appropriate role access is a more suitable safety mechanism than introducing unnecessary resistance to change.

5.3.1.6 Visibility: Is every part of the code simultaneously visible, or is it at least possible to juxtapose any two parts side-by-side at will?

The visibility of study specifications in Jeeves is high in comparison to many alternative EUD- ESM tools. Those that are composed of Web forms require navigation across separate pages, making it difficult to see an app’s function in its entirety. In contrast, the canvas of Jeeves, which supports panning and zooming operations, ensures that even complex applications can be viewed in one screen. Surveys and user data can also be viewed concurrently with the blocks if required, through adjustable panels.

Visibility in Jeeves supportsprogressive evaluation- with the entire study specification visible, it should be simpler to evaluate how an app’s functionality changes with respect to small changes in the blocks. This likewise has a positive affect onviscosity- if an app malfunctions due to an incorrect specification, the error can be located on-screen, without the need to navigate through a hierarchy of menus.

Trade-offs?

High visibility does, however, introduce trade-offs. In ensuring that all blocks are visible on the canvas, Jeeves does not allow developers to group triggers and actions together into their own

abstractions, a feature that was suggested by usability study participants in Chapter 6. Further, the visibility of Jeeves ironically introduces hidden dependencies. For example, explicitly showing dependencies between survey questions that set attribute values, and these attribute blocks on the canvas, would introduce extra visual clutter that would sacrifice overall visibility of the study specification.

5.3.1.7 Consistency: When some of the language has been learnt, how much of the rest can be inferred?

The visual language of Jeeves is designed for consistency; secondary notation ensures that triggers, actions and expressions are clearly identified, and all blocks within a given category have the same behaviour. This consistency of Jeeves minimiseserror-proneness. Once the general concepts of dragging actions into conditions/triggers, building surveys, and assigning

108 CHAPTER 5. DESIGN OF JEEVES

Figure 5.11:Participants had to work around the lack of a ‘survey expression’

Figure 5.12: The ‘survey expression’ makes implementation simpler, but

sacrifices consistency

attributes through surveys are understood, there are no new rules or combinations of actions that could induce further errors.

Trade-offs?

While the design of Jeeves was not expected to involvehard mental operations, user studies identified occasions where this was the case. For example, Figure 5.11 shows how a case study user implemented a function to prompt a user repeatedly if they had not completed a survey. The user had to find a somewhat complicated workaround by setting the value of atestcomplete attribute in an additional survey question, which was used in the blocks specification to determine whether the survey had been completed. Figure 5.12 shows how this can be resolved through a “Survey Expression” that returns whether or not a participant has completed a particular survey that day. However, a general syntactic rule in Jeeves is that all expressions contain at least one attribute. Thus, this expression introduces an inconsistency; there is a clear trade-off here. The goal of consistency has introduced further hidden dependencies. Attribute values are consistently set through survey questions, whether they are participant preferences or attribute

5.3. VISUAL SYNTAX AND SEMANTICS 109

values that trigger interventions. If the developer does not ensure that these preferences are established through surveys at the beginning of the study, this could cause errors. Consider the triggers in Figures 5.11 and 5.12. If the date attributes TestdatebegandTestdateend are not initially set, then the trigger will never fire. An inconsistent approach could have a separate means of establishing participant preferences that would minimise the chance of the developer forgetting to do so.