Clemens Zeidler

Christof Lutteroth

Wolfgang Stuerzlinger
email: wolfgang@cse.yorku.ca

Gerald Weber
email: g.weber@cs.auckland.ac.nz

Evaluating Direct Manipulation Operations for Constraint-Based Layout

Keywords: GUI builder, layout editing, layout manager, constraint-based layout, layout preview, evaluation

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Graphical user interfaces (GUI) are widespread, even on web and mobile platforms. WYSIWYG GUI builders facilitate the creation of such GUIs by developers and designers. In GUI builders, the user can drag & drop widgets from a palette onto a GUI canvas and adjust their properties.

Today's applications are used across a wide range of screen sizes, and users often use multiple applications concurrently on the same screen. Thus users expect that GUIs can be resized and that widgets use the space allocated to an application judiciously. Early drag & drop GUI builders enabled only the creation of static layouts that are unable to adapt to window resizing or other changes to the distribution of screen space. In order to create resizable GUIs with dynamic layouts, a layout manager has to be used, which implements a layout model. The latter defines how objects in a layout, the widgets, can be arranged and how their resize behavior can be specified.

Constraint-based layout models are naturally powerful: with the notable exception of flow layouts, many other layout models including gridbag layout [START_REF] Weber | A reduction of grid-bag layout to auckland layout[END_REF] can be reduced to constraint-based layouts, see also Figure 1. Many other layout models rely on a hierarchy of nested layouts to define more complex layouts. Within nested layouts, widgets typically cannot be aligned across different levels of the hierarchy. In contrast, constraint-based layouts can align widgets that are situated in completely different parts of a layout [START_REF] Lutteroth | Domain Specific High-Level Constraints for User Interface Layout[END_REF], which greatly reduces the need for nested layouts. Fig. 1. Example of a constraint-based layout. When resizing, the middle row moves independently of the top and bottom rows. This layout is impossible to achieve with a single gridbag layout, e.g. as the radio button is not constrained to a column.

While constraint-based layouts are more powerful, their creation may be more complex and poses challenges. General constraints are difficult to visualize and even harder to manipulate directly. Specifying individual constraints can be tedious and error-prone, as they are situated at a low level of abstraction. Moreover, specifications may become over-constrained, i.e. have no solution, or permit widgets to overlap each other. Presumably it is for such reasons that support for constraint-based layouts in GUI builders is less developed than for other layout models. This makes it harder for GUI designers to leverage the advantages of constraint-based layouts.

In this paper we evaluate the use of simple drag & drop operations for the manipulation of constraint-based layouts. These operations are sufficient to create a wide variety of constraint-based layouts, including layouts where widgets are aligned to other widgets and no additional constraints exist between them. Our operations are designed to prevent situations where widgets can overlap. To test these operations with regard to their usability, we created a novel GUI builder -the Auckland Layout Editor (ALE) -that implements these operations. In ALE there is no need for the designer to know about the underlying constraint-based layout model.

In two controlled experiments we compared ALE with two state-of-the-art GUI builders. The experiments target the question if ALEs operations are effective for editing of constraint-based layouts. The first experiment compares ALE against a GUI builder that uses the gridbag layout model, which is currently one of the most frequently used layout models. The second experiment compares ALE against a GUI builder that supports constraint-based layouts. The evaluations show the promise of our new approach, with significantly shorter completion times for typical layout creation and editing tasks, and a strong preference from most of the participants for ALE.

Section 2 reviews related work. Section 3 presents ALE and Section 4 the edit operations used in ALE. The evaluation that compares ALE to a gridbag-based and a constraint-based GUI builder is described in Section 5. Section 6 finishes with conclusions.

Related Work

There are various non-constraint-based graphical GUI builders. Myers [START_REF] Myers | User-Interface Tools: Introduction and Survey[END_REF] summarized various techniques to create GUIs, including graphical tools to place interface objects on screens. IBuild [START_REF] Vlissides | A unidraw-based user interface builder[END_REF] enabled the creation of complex GUIs in a WYSIWYG manner. It already supported nested layouts and spring-like "glue" layout elements. Moreover, IBuild enabled interactive testing of the resize behavior. Druid [START_REF] Singh | Druid: a system for demonstrational rapid user interface development[END_REF] predicted the intended alignment and spacing of a widget during editing, facilitating widget placement. FormsVBT [START_REF] Avrahami | A two-view approach to constructing user interfaces[END_REF] supported simultaneous editing of a textual and a graphical representation of a layout. Some graphical GUI builders permit manual constraint editing. Lapidary [START_REF] Zanden | The Lapidary graphical interface design tool[END_REF] supported editing of constraint-based layouts with rich editing functions for constraints. In the constraint-based Gilt system [START_REF] Hashimoto | Graphical styles for building interfaces by demonstration[END_REF], widgets could be aligned relative to userspecified tabstops or other widgets. In contrast to ALE, users had to manage tabstops themselves. In the Intui GUI builder [START_REF] Scoditti | A new layout method for graphical user interfaces[END_REF] layout constraints can be edited directly by toggling between struts (fixed-size constraints) and springs (variable-size constraints) defined between and inside of widgets. However, only one constraint per widget side is supported. Finally, Rockit [START_REF] Karsenty | Inferring graphical constraints with Rockit[END_REF] automatically infers constraints from static drawings, using hard-coded rules and heuristics. These approaches require the user to edit or handle individual constraints. In contrast, ALE makes it possible to create constraintbased layouts without knowledge of the (somewhat complex) underlying constraint system.

Today, there are many open-source GUI builders, such as WindowBuilder Pro1 , Matisse/Swing2 , and Qt Designer3 . There are also many commercial GUI builders, such as MS Expression Blend4 , Visual Studio5 , and the Apple Xcode Interface Builder 6 . Most of them support aligning widgets via snapping. With the exception of the Xcode Interface Builder, where Apple added support for constraints in 2012, none of them support the interactive construction or maintenance of constraint-based layouts.

In Xcode widgets can be placed "freely" onto the editing canvas, and constraints can be added between the widgets. However, common GUI design guidelines such as [START_REF] Galitz | The essential guide to user interface design: an introduction to GUI design principles and techniques[END_REF], which guide designers towards appropriate layouts, generally emphasize that it is not desirable to place widgets completely "freely", i.e. at an arbitrary position in a layout. Aligned layouts are more compact and easier to understand [START_REF] Heim | The resonant interface: HCI foundations for interaction design, chap. 6.6[END_REF]. ALE automatically keeps widgets aligned, which can lead to a faster layout creation and editing process.

Supple is an automated system that can adapt layouts to changes in display size, in particular to different devices. The system supports discrete changes of widgets, i.e. it changes the controls that are used within an input form depending on the available space [START_REF] Gajos | Supple: automatically generating user interfaces[END_REF]. However, the designer has less influence on the actual layout.

A previous usability comparison between constraint-based and grid-based layout models [START_REF] Zeidler | Comparing the usability of grid-bag and constraint-based layouts[END_REF] used printed screenshots and sketching. This comparison found that the constraint-based layout model is a competitive alternative to the grid-bag layout model and performs better for editing existing layouts. The current paper compares constraint-based and grid-bag layout model editing directly in interactive GUI builders.

3

The Auckland Layout Editor (ALE)

Similar to other GUI builders, ALE's user interface consists of a component palette and an editing canvas (Figure 2). New widgets can be dragged from the palette into the editing canvas, where the designer can change the layout using a rich set of edit operations, as described in the next section. Here we first define the terms used to describe ALE.

In the underlying constraint-based layout model, each widget has a minimum, a preferred and a maximum size, also called intrinsic sizes. A widget should assume its preferred size if there are no other constraints for it, similar to the behavior of a sponge. By default, widgets are surrounded by a small margin, as visible in Figure 1.

There are two common types of linear constraints: hard constraints, which have to be satisfied, and soft constraints, which may be violated if necessary. When inserting a widget into a layout, some constraints are automatically derived from the intrinsic sizes of a widget: a hard inequality is created for the minimum size, and soft equalities for the preferred and the maximum size. These constraints are added in both the horizontal and vertical direction. As ALE inserts these constraints automatically, users do not need to manage the constraints for intrinsic sizes manually. The preferred size of each widget can be fine-tuned, which is comparable to changing the "weight" of a row or column in a grid-bag layout. Variables in a constraint are called tabstops and represent horizontal or vertical grid lines. Other frequently used names for the same concept are aligners, guides, snap lines or anchor lines. The edges of each widget are always connected to two horizontal (top and bottom) and two vertical (left and right) tabstops, which form a rectangular area. Connecting widgets to the same tabstop aligns them. Figure 3 shows a simple layout and its tabstops. Each GUI container, such as a panel or a window, defines tabstops for its four borders. If all widgets are connected to at least one horizontal and one vertical tabstop, the whole layout can be computed directly. The reason for this is that the intrinsic sizes determine the size and the tabstops the x and y position of each widget. The chosen constraint solver controls how soft constraints are handled, which determines the final visual appearance of the layout. In our GUI builder and in the final applications, the quadratic active set method is used for solving [START_REF] Fletcher | Practical methods of optimization[END_REF]. In contrast to a linear approach, this leads to unique and aesthetically more pleasant layouts [START_REF] Zeidler | Constraint solving for beautiful user interfaces: how solving strategies support layout aesthetics[END_REF]. An overview of different solving techniques can be found in other works [START_REF] Badros | The Cassowary Linear Arithmetic Constraint Solving Algorithm: Interface and Implementation[END_REF][START_REF] Jamil | Extending linear relaxation for user interface layout[END_REF].

The minimum size of widgets is guaranteed by a sufficiently large minimum size of the outermost container, e.g. the window. With this, a layout always stays solvable as only a soft inequality constraint is used for the maximum size. If a maximum size constraint is violated, then more space is allocated than a given widget is able to use. In this case, the widget is by default aligned in the center of its allocated space. The right side of Figure 1 illustrates this. The two buttons at the top share the full window width, and the maximum width constraints of the buttons are violated here. Thus, the buttons are centered in their allocated space, as visualized by the light gray areas.

ALE Layout Edit Operations

Ideally, a GUI builder should make the creation of a layout easy to learn, simple to achieve, and quick to perform. ALE's edit operations for constraint-based layouts automatically keep widgets aligned to each other as far as possible, by connecting them to existing tabstops. This makes it easier to rearrange widgets while keeping the layout consistent. Furthermore, the edit operations leave a widget connected to at least one horizontal and one vertical tabstop. This ensures that the position of a widget is always well-defined. The edit operations provided are moving, swapping, resizing, inserting, and removing of widgets. These operations enable the user to create complex layouts without manual constraint authoring.

As in most GUI builders, a GUI can be created and edited by drag & drop operations. Edit operations are started by dragging an already placed widget or the border of a widget. Then, ALE checks at each mouse position if an operation can be applied and gives corresponding visual feedback (Figure 4). For this, the operation is applied tentatively in the background. If an operation is appropriate, the user can commit the operation by "dropping" the dragged item and the result becomes visible. In general, edit operations can affect multiple widgets and a layout may differ in several places after an operation. To help the user understand such changes, a short animation visualizes how the affected widgets are changed.

Moving a Widget While dragging a widget, its shape is visualized as a dotted rectangle. We limit the size of the dragged outline to a reasonable size to avoid problems with very large widgets. Two cases need to be considered when moving a widget from one position to another.

First, a widget can be inserted into an empty area (Figure 4). To identify the correct empty area, we attempt to snap the dragged rectangle to existing tabstops. If the widget can only be snapped on one side in a certain direction, horizontally or vertically, a new tabstop is inserted at the opposite side. If a widget cannot be snapped to any tabstop in a certain direction, then two other suitable tabstops have to be found. These are the respective tabstops of the largest empty rectangular area at the pointer position.

The combination of snapping widgets to existing tabstops and placing them into the largest empty area at the pointer makes the move operation quite versatile. For example, it is possible to place a small item accurately into the corner of an empty area by snapping it on two borders. Dropping a widget roughly in the middle of an empty area will fill the area with the widget. Furthermore, a widget can, e.g., be placed in the left half of an empty area by moving the item's left border close to the area's left border midway between top and bottom. ALE visualizes the location where a widget will be placed when "dropped" with a green rectangle (Figure 4). Second, a widget can be placed between an existing tabstop and a widget adjacent to that tabstop. This happens when a widget is dropped close to an existing tabstop and on the adjacent existing widget (Figure 5). In the following, only the insertion at a vertical tabstop is described; the horizontal case works analogously. When dropping the dragged widget, it is inserted so that its top and/or bottom are connected to those of the existing widget, using the same rules as in the first case: if the top or bottom of the dragged rectangle is close to the top or bottom of the existing widget, then they are snapped together. If only one side is snapped, either top or bottom, a new tabstop is created at the opposite side. If the dragged rectangle is not close enough to the top or bottom of the existing widget, then the dragged widget is connected to both the top and bottom of the existing widget. In Figure 5, the string view is snapped to the bottom of the right button. The left and right tabstops of the moved widget are then set so that the widget is placed between the vertical tabstop and the existing widget. There are two cases to consider for resizing. First, a widget can be resized to an existing tabstop, by dragging and snapping it to said tabstop (Figure 6). Second, an item can be resized to match its preferred size when a dragged border is released without snapping it to a tabstop. In this case, a new tabstop is inserted for the dragged border and its position is calculated so that the widget gets its preferred size. Finally, the resize behavior of widgets can be controlled manually via the preferred size settings in a properties window (see right side of Figure 2).

Inserting and Removing Widgets

Inserting a new widget is practically identical to the move operation. A widget can be removed from the layout by dragging it outside of the layout and dropping it.

Filling Gaps

A move, resize or remove operation can disconnect adjacent widgets that were only connected through the one widget that was edited. In this case, a gap may appear in the layout (Figure 7) and the position of some widgets may become undefined in the constraint system; the widgets are "floating". ALE avoids such situations by checking for disconnected widgets after move, resize and remove operations. If the layout contains widgets or groups of widgets that are disconnected, then these widgets are moved one after another into the direction of the removed or resized widget. If a group was connected to the right side of the removed or resized item, the group is moved to the left, and similarly for other directions (Figure 7). All disconnected groups are moved until they are connected directly or indirectly to at least one horizontal and one vertical layout border.

Non-Overlapping Layouts

ALE guarantees that all created layouts are non-overlapping. In other words, widgets do not intersect each other, regardless of the window size. This ensures that all widgets are completely visible and accessible at all GUI sizes. Non-overlap for a layout also implies that no widget intersects the boundaries of the GUI. Note that we need to differentiate between concrete layouts, as they are rendered on a screen, and layout specifications, which can be rendered at many different sizes and hence lead to many concrete layouts. For example, the layout in Figure 8 is non-overlapping, but as the layout size is reduced, the check boxes overlap the buttons due to a missing constraint. ALE's operations are designed to avoid overlap. For this, the layout is tested after each operation for possible overlap. If necessary, additional constraints are added. For example, if the user resizes the layout in Figure 8 during the build process as shown, ALE would add a constraint that keeps a positive distance between the checkbox and the buttons.

Evaluation

We considered two hypotheses, addressed in the following Experiments 1 and 2:

H1 ALE makes it easier to create layouts from scratch compared to other available GUI builders. H2 ALE makes it easier to edit existing layouts compared to other available GUI builders.

Experiment 1 compared layout creation in ALE with a popular gridbag GUI builder (H1). Experiment 2 compared ALE with a modern constraint-based GUI builder, considering both creation of new layouts and editing of existing layouts (H1 and H2).

Experiment 1: Comparison with a Gridbag GUI Builder

In the first experiment, we targeted H1 by investigating how our approach performs in comparison to a state-of-the art GUI builder. For this comparison we chose the GUI builder in MS Visual Studio 2010 (VS) as a representative for the state of the art, since it was popular at the time of the study. A prior study compared the usability of the gridbag and the constraint-based layout model, finding that the gridbag layout model has advantages in the creation of new layouts [START_REF] Zeidler | Comparing the usability of grid-bag and constraint-based layouts[END_REF]. This supports our choice of a gridbag GUI builder such as VS for comparison with ALE when investigating H1.

16 participants, mostly software engineering students with experience in GUI development, were asked to perform four GUI creation tasks, each either with ALE or with VS. In each task, they were asked to rebuild a realistic GUI layout from a sample screenshot. Figures 9,10 and 11 show the four tasks. We measured task completion time as an indicator of efficiency, and used a post-questionnaire to determine participants' preferences.

With the VS GUI builder it is not easy to modify the row-and column-span in a gridbag layout, since this cannot be done visually. It can only be achieved by opening a properties dialog. Thus, participants were instructed to nest multiple gridbag layouts, permitting users to recreate the target layouts more easily.

For both ALE and VS, a training task was given before the respective main tasks to ensure a reasonable amount of training with both tools. To counteract potential learning effects, half the participants were allocated to a group which first performed the training and tasks I and II with ALE, and then the training and tasks III and IV with VS. The second half used the tools in the opposite order.

If there were errors in the layout after the participants had finished a task, e.g. a widget was placed erroneously, the experimenter indicated the errors to them. Afterwards, timing continued and the participants had to fix these errors. In this way, all participants were able to succeed in all tasks.

Results and Discussion

The measurements were not normally distributed. The medians of ALE and VS were 74 and 188 seconds, respectively. A Wilcoxon signedrank test identified a significant effect of the GUI builder (Z = -5.31, p < 0.0001), which supports H1. Pairwise Wilcoxon signed-rank tests show that ALE was significantly faster than VS for every task, with p < 0.01 or better. Figure 12 shows the individual times broken down by task. According to the post-questionnaire, 11 of the 16 participants preferred ALE over VS. A separate study is necessary to determine what exactly made ALE perform better than VS. It was not the aim of our current work, as we only aimed to evaluate how ALE competes with the gridbag-based VS builder at the task level.

One potential threat to validity is the fact that in VS participants did not use a single gridbag layout, but a nested gridbag layout with a column-and row-span of one. According to observations during the experiment, many participants had difficulties when nesting multiple layouts to create the desired outcome with VS, even though this was easier in the VS GUI builder compared to creating a single gridbag layout. A possible explanation is that a gridbag layout specification has to be understood more thoroughly upfront, and cannot easily be developed on the fly during the design process as with a constraint-based layout approach.

Note that for this experiment, a slightly older ALE version was used [START_REF] Zeidler | The Auckland layout editor: an improved gui layout specification process[END_REF] than for Experiment 2. Although this version was less polished and had some small usability problems, all operations discussed here were available. It is possible that the different versions of ALE would differ slightly in their performance.

Experiment 2: Comparison with a Constraint-Based GUI Builder

In a second experiment, we tested both H1 and H2. Apple's Xcode offers currently the only easily available GUI builder for constraint-based layouts. Xcode's layout model is similar to ALE's layout model, supporting simple linear hard and soft constraints. Also, Xcode permits free placement and resizing of widgets on the editing canvas. Consequently, we compared ALE with Xcode in this experiment.

The evaluation involved two main tasks (Task V and VI), preceded by a training task that was similar to the main tasks. Each participant performed all tasks once with ALE and once with Xcode. To eliminate order effects, half of the participants started with ALE, the other half with Xcode. Each task was divided into a layout creation subtask and three editing subtasks.

The first editing subtask (a) required swapping two widgets; the second editing subtask (b) required moving a widget to a position between two other widgets (see Figure 5). For these two subtasks, we expected ALE to perform better because users need only a single operation, while in Xcode multiple operations are necessary. With the free placement approach of Xcode, moving a widget between two other widgets requires the user to first move at least one of the other widgets aside to make room for said widget. Furthermore, it is necessary to manually fill the empty space that the moved widget has left behind. The last editing subtask (c) was more complex and required a combination of multiple edit operations. Figure 13 shows the layout for the creation subtask for Task V, and Figure 14 shows the editing subtask (c) for Task VI. In Xcode, participants were asked to align widgets as well as possible via the snapping functionality provided by the builder. As with the previous experiment, after each task, timing stopped, the experimenter pointed out layout errors to the participants, timing continued and participants had to fix the errors.

After finishing the tasks using Xcode and ALE, the participants were given a Likert-scale questionnaire to gather general information and to analyze their preferences. Furthermore, they were asked for comments in an open-ended question.

Results and Discussion

For this study, 14 participants were recruited, mostly graduate Computer Science students. All of them stated that they had understood the tasks. Most participants had experience with user interface design and were familiar with creating GUIs using a GUI builder. Four participants had used Xcode before, while only one participant had used ALE before (see Figure 15).

Overall, the measured task completion times were not normally distributed. The results for the creation tasks are shown in Figure 16.

The medians of all creation times for ALE and Xcode were 66 and 80 seconds, and for all editing times 9 and 38 seconds, respectively. Figure 17 depicts the results for the editing subtasks of Task V. The results for the editing subtasks of Task VI are shown in Figure 18. A Wilcoxon signed-rank test identifies a significant effect of the GUI builder for creation (Z = -2.05, p < 0.05), which supports H1. There is also a significant effect for editing tasks (Z = -9.19, p < 0.0001), which supports H2. For layout creation and layout editing, ALE was clearly faster for Task V and Task VI. Pairwise Wilcoxon signed-rank tests show that ALE was significantly faster than Xcode for every creation and editing subtask, with p < 0.01 or better. The swapping (a) and the moving (b) subtasks were much faster using ALE. The results from the post-experiment questionnaire show a consistently positive response (Figure 19). Most participants preferred ALE and found it easier for creating and editing layouts. Furthermore, participants enjoyed ALE more than the Xcode builder.

Several participants commented in the open-ended question that they liked the swap operation and that layout editing was easier. Other comments pointed out that "one first had to get used to the different concepts of ALE, e.g. that [a widget] cannot be placed freely." Another stated: "I would imagine that ALE may perhaps be very efficient when acquainted with." This is consistent with our observations that participants needed more time to get used to ALE. However, after the training phase most participants were able to perform all tasks without problems. One noteworthy observation is that with the free placement approach of Xcode it was more difficult to align items precisely. Participants made many erroneous alignments or seemed to be unaware of misalignments in the layout. Another observation is that when using Xcode, participants often first aligned a newly inserted or modified widget precisely to some other widgets, and realized only later that they had to align said widget again to achieve the target layout. ALE avoids this problem by automatically keeping widgets aligned, which is one contributor to the much shorter completion times. A threat to validity is that in Xcode, resizing a text or list widget was sometimes difficult, as users had difficulties clicking the resize handles. However, users also experienced similar minor usability problems in ALE.

Another threat is that layouts in both experiments were relatively small. Since the evaluation took already about an hour we tried to keep the layouts small. However, we believe that the layouts have a reasonable size because for larger layouts one would naturally start to use nested layouts.

Conclusion

We presented ALE, a GUI builder that makes it possible to quickly create and edit constraint-based layouts with simple mouse operations. ALE defines a set of layout edit operations that hide much of the complexity of constraint-based layouts from the designer. These edit operations are moving, swapping, resizing, inserting and removing of widgets. All operations maintain alignment and establish appropriate constraints automatically. ALE automatically aligns widgets to each other when placing a widget. It also moves other widgets aside if necessary. Swapping of widgets does not require manual resizing or moving of the adjacent widgets. Additionally, ALE automatically keeps layouts non-overlapping.

In two comparative evaluations, we found that ALE permitted participants to construct several realistic layouts significantly faster than with current commercial solu-tions, both for a gridbag and a constraint-based layout. Furthermore, we found that editing existing constraint-based layouts is also significantly faster with ALE. Participants enjoyed using ALE, and once familiar with the new edit operations, found it easier to use.

This evaluation demonstrates that it is feasible to utilize the power of constraintbased layouts in graphical GUI builders. The encouraging results from the experiments illustrate also that operations that automatically keep widgets aligned can result in a substantial boost in productivity. Overall, we see this as an indication that there is ample potential for improvements in today's GUI builders.

Future work Ideally, a GUI builder should be able to guarantee that all created layouts are non-overlapping, regardless of window size. ALE addresses this by automatically adding constraints when potential overlap is detected. We will describe this functionality in more detail in future work. ALE's edit operations are already powerful enough to create many common layouts. However, a constraint-based system can be used to create far more complex layouts. For that, general constraint editing has to be integrated into ALE. We will investigate this in the future as well.

Fig. 2 .

 2 Fig. 2. Screenshot of the ALE GUI builder. New widgets can be inserted into the editing canvas (left) via drag & drop from the component palette (right).

Fig. 3 .

 3 Fig. 3. Widgets are aligned to tabstops. In the picture there are four outer tabstops (L, T, R and B) and two inner tabstops (x1 and y1).

Fig. 4 .

 4 Fig. 4. Move operation: Dragging the button to the bottom-right of the empty area. The area where the button will be inserted when dropped is highlighted in green.

Fig. 5 .

 5 Fig. 5. Move operation: Moving a string view between two buttons.

Fig. 6 .

 6 Fig. 6. Resizing the top of the list widget to the bottom tabstop of the string view.

Fig. 7 .

 7 Fig. 7. Filling gaps: Upon removal of the list widget (left), the two buttons are both "floating" vertically. Moving the group of the two buttons to the top fills the gap. The top of the buttons is now connected to the bottom tabstop of the combo box (right).

Fig. 8 .

 8 Fig. 8. The constraint-based layout on the left appears sound. Yet, when decreasing its size, as shown on the right, overlap between widgets occurs due to a missing constraint. The used constraint-based GUI builder, Apple Xcode, gave no indication of this issue.

Fig. 9 .

 9 Fig. 9. Experiment 1, Task I: VS on the left and ALE on the right side.

Fig. 10 .

 10 Fig. 10. Experiment 1: Task II for VS on the left and Task III for ALE on the right side.

Fig. 11 .

 11 Fig. 11. Experiment 1, Task IV: VS on the left and ALE on the right side.

Fig. 12 .

 12 Fig. 12. Boxplot of the task completion times for all four tasks of Experiment 1.

Fig. 13 .

 13 Fig. 13. Experiment 2, Task V: Xcode on the left and ALE on the right side.

Fig. 14 .

 14 Fig. 14. Experiment 2, Task VI (c): The complex editing subtask.

Fig. 15 .

 15 Fig. 15. Results for the general Likert-scale questions of Experiment 2.

Fig. 16 .

 16 Fig. 16. Task completion times for layout creation in Experiment 2, Task V and VI.

Fig. 17 .

 17 Fig. 17. Task completion times for layout editing in Experiment 2, Task V.

Fig. 18 .

 18 Fig. 18. Task completion times for layout editing in Experiment 2, Task VI.

Fig. 19 .

 19 Fig. 19. Results for the Likert-scale usability questions of Experiment 2.

eclipse.org/windowbuilder

netbeans.org/features/java/swing.html

qt.nokia.com

microsoft.com/expression/products/Blend_Overview.aspx

microsoft.com/visualstudio/en-us

developer.apple.com/technologies/tools

Acknowledgements

We would like to thank Rishika Mukerjee and Keerthana Puppala for helping to design and perform the first experiment.


Parisa Eslambolchilar
email: p.eslambolchilar@swansea.ac.uk

Julie Webster
email: j.webster@swansea.ac.uk

Gerrit Niezen
email: g.niezen@swansea.ac.uk

The Evolution of Number Entry: a case study of the telephone

Keywords: Number Entry, Interaction Design, Usability, Telephone Interfaces

This paper details a user study to investigate serial digit entry on analogue and digital input platforms and the errors associated with them. We look specifically at the case of entering eleven-digit telephone numbers without a decimal point. The telephone is used as a platform for comparison, due to its clear evolution from a rotary dial to a pushbutton keypad and more recently, touch-based input. Thirty participants took part in a user study, which concluded that the touch interface was four times less accurate than the pushbutton and rotary dial interfaces. The latter two interfaces performed with similar accuracy; however, users were more than three times faster on the pushbutton keypad and recognized almost twice as many errors on the rotary dial. We have extended previous error taxonomies to include some errors relevant to sequences of numbers and built upon task-based guidelines found in the literature to suggest context-based design considerations.

Introduction

The design of interactive systems has evolved over time in hopes of making them easier to use. Errors are typically blamed on a human factor, forgetting that the system should have been built to take them into account and attempt to minimise these types of problems [START_REF] Thimbleby | Press On: Principles of Interaction Programming[END_REF]. The goal of interaction design is to aid the user in completing a task with a minimal number of errors or no error at all. An interaction that fails to accomplish this has likely failed at various levels.

Number entry is a task that is performed daily with little conscious thought. These number entry tasks seem trivial, but we still experience problems when performing them. Consider how many times we dial a phone number. It is rare to dial a wrong number, but it does happen occasionally and the results are potentially embarrassing. Similar problems occur with alarm systems where the wrong code results in a blaring sound or with personal identification numbers (PIN) for bank accounts that lock us out if entered incorrectly too many times in a row. All of these systems use a simple input method, such as a knob or keypad, laid out with either buttons or a touchscreen. In these cases, inputting a single wrong digit does not get us close to what we intended -it is instead entirely wrong. A wrong digit in a telephone number will result in Fig. 1. The evolution of the telephone [START_REF] Webster | Proceedings of the 2012 ACM Conference on Ubiquitous Computing[END_REF].

speaking to a different person all together. This specific category of numbers, which includes telephone numbers, PIN numbers, and credit card numbers do not have a decimal point. The telephone gives us a good vehicle for exploration because it demonstrates a clear evolution from one input device to another, as shown in Figure 1.

Related Literature

This section details literature that has influenced this case study of the telephone by looking at errors and their taxonomies as well as number entry interfaces.

2.1

What is Error?

James Reason [START_REF] Reason | Human error[END_REF] defines two major categories of error: slips (or lapses) and mistakes. Slips result from the incorrect execution or incorrect planning of a correct sequence of actions, so an error is made even though a person has the knowledge needed to perform the number entry task. In contrast, mistakes occur when a person has incorrect or absent knowledge of the task they are aiming to complete. In other words, mistakes result from the correct execution of an incorrect sequence of actions. For example, consider the misinterpretation of feedback: Reading "121" as the expected value "12.1" could be a slip, whereas thinking a symbol signifies "On" when it signifies "Start" is probably a mistake.

Taxonomies of error

Zhang et al. [START_REF] Zhang | A Cognitive Taxonomy of Medical Errors[END_REF] proposed a cognitive taxonomy to categorise medical errors at the level of individuals, based upon Reason's taxonomy. Wiseman et al. [START_REF] Wiseman | A Taxonomy of Number Entry Error[END_REF] built on Zhang et al.'s taxonomy by focusing on number entry errors -errors that occur when a series of digits is being entered. In the medical domain, an example could be specifying values for an infusion pump, such as rate of infusion or the total volume to be infused. The study in [START_REF] Wiseman | A Taxonomy of Number Entry Error[END_REF] consisted of 20 participants each entering 30 numbers, where the length of numbers ranged from two to five digits. Half of the numbers entered were integers and the other half contained decimal points. A total of 350 errors were gathered and categorised into 21 classes of error, based on Zhang et al.'s taxonomy.

Number Entry Interfaces

Oladimeji [START_REF] Oladimeji | Towards Safer Number Entry in Interactive Medical Devices[END_REF] identified three categories of number entry interfaces: o Serial digit entrynumber is entered sequentially from left to right, e.g. telephones, ATMs or calculators, o Independent digit entryuser controls the digits that make up the number separately, e.g. using up/down buttons to change the digit (0-9) and left/right buttons to change the position of the digit being entered, and o Incremental number entryuser increases or decreases a number analogous to scrolling through values on a number-line, e.g. using up/down buttons, sliders or knobs. There are certain trade-offs to consider when selecting a number entry interface, including speed of entry, severity of errors and space required for the interface. Oladimeji et al. [START_REF] Oladimeji | Number Entry Interfaces and their Effects on Error Detection[END_REF] compared keypad interfaces to up/down button interfaces (press and hold to increase or decrease values) and showed a factor of two fewer unnoticed errors with up/down buttons. Fixation experiments showed that users are less likely to notice errors on the display when using keypads, as they fixate twice as much on the keypad itself (compared to the up/down buttons).

We focus our research on serial digit entry and the errors associated with these types of interfaces, when not using a decimal point. We focus on three types of serial digit number entry interfaces: the rotary dial, the pushbutton keypad and the touch display. The telephone was chosen as a platform for comparison due to its clear evolution from analogue interfaces to digital interfaces.

Experimental Setup

Existing studies on number entry research focus on a specific domain, for example entries on infusion pumps in the medical domain [START_REF] Oladimeji | Towards Safer Number Entry in Interactive Medical Devices[END_REF][START_REF] Wiseman | A Taxonomy of Number Entry Error[END_REF]. The focus of this study was on more everyday interaction -serial digit number entry without a decimal point. This is the type of number entry we perform almost on a daily basis, for example entering PIN numbers or telephone numbers, where one wrong digit invalidates the whole number being entered.

A user study was performed to compare a rotary dial interface, touch interface and a keypad interface (Figure 2). A total of thirty participants completed the user study task. All were recruited through emails sent to the students and staff at the university and were affiliated with the university in some way. Most were postgraduate students and staff, 14 were male and 16 were female. Three participants were between 17 and 20 years old, 19 participants where in the 21-30 age group, four participants were between 31 and 40 years old, and four participants were between 41 and 50 years old. Participants were fluent in English for questionnaire purposes and were compensated for their time with a £5 shopping voucher. Before the sessions, the order of interfaces was randomly assigned and 50 11-digit numbers were randomly generated to allow all 30 users to enter the same 50 numbers on all three interfaces. Participants were allowed five practice runs to familiarise themselves with the interface before the 50 11-digit numbers that were then recorded. The time it took to enter each number was recorded, along with the number entered compared to the number given to the participant. Participants were not provided with a display to see what digits they had entered, so they had to rely on the inherent tactile and visual feedback provided by the input devices. This was done to maintain consistency betw-Fig. 2. The three telephone-style interfaces used by participants: the rotary dial (left), pushbutton keypad (middle) and touchscreen keypad (right).

-teen the three interfaces, as a visual display would not have been used on older interfaces.

Participants were not allowed to correct their entries. If they perceived that they made an error, they were asked to notify the researcher and continue entering the rest of the number. This made it possible to determine how many errors would have been recognised, for a given number being entered. To alleviate fatigue, participants received a five-minute break before using the next interface. After thirty user sessions, data was collected from a total of 4,293 numbers, amounting to 46,807 digits in total, including digit additions and omissions due to errors. These results were analyzed in a variety of ways, detailed in Section 4.

Hardware Setup

A rotary dial interface from an early 1960s telephone was used as the analogue input device. When the dial spins, a cog inside moves the same number of clicks as the number selected, opening and closing a switch. For example, moving the number "6" around and letting go will cause the cog to engage a switch six times. An Arduino Uno microcontroller was used to count the number of pulses and each digit was outputted to the computer along with a timestamp.

A button interface for a FEZ Spider Kit1 was used as the digital input device. The interface consisted of membrane buttons laid out as a traditional 3x4 keypad and was connected to the kit. An SD card module was used to store the numbers entered on the device, along with a timestamp for each digit.

The touchscreen interface was created on a resistive touchscreen with the FEZ Spider Kit. A 3x4 keypad was created on the touchscreen to look like the physical keypad. The LCD, touch-capable screen was attached to the mainboard and USBpowered modules of the kit. An SD card reader was utilized in the same way as on the pushbutton interface. A small button labelled "Next" was placed next to all three interfaces, which the user pressed to indicate that he/she was ready to enter the next number. The interfaces were mounted on platforms (Figure 2) to allow users to interact with the devices in the manner that they were the most comfortable.

Results

A digit-by-digit analysis was conducted of each number entered to determine what types of errors were made. Table 1 summarizes the total number of digits that were incorrect in each interface.

We used a subset of the error taxonomy of Wiseman et al.

[10] to classify the errors made in our user study. Wiseman's taxonomy included numbers with decimal points, so some categories did not apply to our study. The following definitions were used:  Digit(s) wrong -a different digit was entered from what was intended (e.g. '1' instead of '4')  Digit missing -a single digit was omitted (e.g. '14' instead of '124')  Digit added -a single digit was added (e.g. '124' instead of '14')  Anagram -digits were reversed (e.g. '14' instead of '41')

Based on observations during in our study, we have added the following error classes to more fully understand user errors when entering whole numbers:  Repeat digit missinga single digit the same as the previous one was omitted (e.g. '14' instead of '144')  Repeat digit addeda single digit the same as the previous one was added (e.g. '144' instead of '14')  Repeat n digit patterna pattern n digits long was repeated (e.g. '1414' instead of '14')

Table 2 shows the total number of each type of error on each interface, as well as the frequency of errors on the interfaces. In the tables, n represents the number of errors made and r is the frequency, calculated to be 100n/N percent to represent the frequency that particular error occurred on that interface.

The most common error on the rotary dial interface was entering an incorrect digit. Missing digits were the next most common error, but they were almost eight times less likely than entering the wrong digit. A total of 180 digits were entered incorrectly on the button interface, slightly less than the rotary dial and more than five times less than the touch interface. The most common error on the button interface was adding one repeat digit. This may have occurred because users held down a button for too long hoping to make sure that it registered, but instead resulted in multiple instancesof the same digit. A missing digit was the next most common error. The most comm- -on error on the touchscreen was a missing digit, likely a result of the user not tapping the screen hard enough to register their selection. A wrong digit and missing a repeat digit were the next most common errors but were roughly four and five times less common, respectively, than the omission of a single digit.

We conducted a mixed model analysis for each interface to determine if learning or fatigue affected the user as they completed the number entry task (Table 1). The analysis was performed by comparing the order that the interface was given to that participant and the error rate. Performance when the participant used the touchscreen first had a significance of 0.046 compared to a value of 0.022 when used second. No significant difference was observed for performance on two other interfaces.

Figure 4 shows a binary representation of all of the errors made on each interface, where each row represents a participant and each column represents a number being entered. Effects of learning would suggest that errors were concentrated at the beginning, while effects of fatigue would suggest errors concentrated at the end. Based on visual analysis of the figure, it appears that the rotary interface may have caused fatigue because there was a slightly higher concentration of errors at the end. In contrast, the touchscreen interface looks like it may have benefitted from learning as the user progressed through the task because the errors occurred slightly more often at the beginning. The button interface does not appear to have been affected by either because the errors look evenly spread across the use of the device.

Discussion

There are trade-offs to consider when selecting a number entry input device, as demonstrated by the data collected in our experiment. Our results showed that the button interface is only 0.07% more accurate than the rotary dial. Because the error rate is very close between these two interfaces, other factors such as the recognized error rate or the speed of entry may become important factors in selecting the most appropriate input device. Based on our results, the button interface is slightly more accurate may not always make it the right choice, because the recognized error rate was 13.80% higher on the rotary dial.

The most common errors on each interface vary and show that the errors must be dependent on the interface and therefore, independent of the user. This kind of analysis is important because we can note that some errors only occur on certain interfaces, or some occur on all interfaces at the same rate, such as 'Anagram', the reversal of two digits. This means that although it may not be possible to select an input device to reduce 'Anagram' errors, selecting the rotary dial will likely reduce 'Repeat digit missing' errors since they did not occur on the interface when tested in our study. By knowing what kinds of errors are common on each interface, it is possible to design devices that should work best for the objectives of that task.

One important observation from our study came from users' interaction with the resistive touchscreen. Most touchscreen mobile phones and tablets on the market today use capacitive screens, which only require a tap of the fingertip to register the selection. Our resistive screen is more similar to the types of touchscreens used on other types of devices, such as ATMs, PIN pads and GPSs. The error rate in our study may have been so high on the touchscreen because users simply tapped the screen expecting the digit to register and did not watch for the visual feedback provided by the button on the screen to confirm the correct number. This would explain why the most common error was 'Digit missing', because users did not tap the screen hard enough, even if they thought they had entered the number correctly.

Conclusions and Future Work

In this paper we focused on analysing the number of errors that occurred during interaction with three number entry interfaces on a telephone platform. Telephone inputs are not outdated; on the contrary we use numeric keypads everyday at cashpoints.

Although physical rotary dialers are nearly gone, they are available as smartphone apps.

From our study, it is evident that multiple trade-offs need to be considered when selecting an input device, with the type of task not being the only design criterion. There are a number of contexts where the most appropriate design for the user may be different than what is best for the task, so a compromise must be made. Instead of compromising to sacrifice usability for one group, considering the context could instead create a successful design. Many users have memorized a certain position of their fingers on a PIN pad to quickly enter their code, so if the layout was changed from the usual '1' at the top to having the '1' at the bottom, many users would enter their PIN numbers incorrectly in the context of paying at the till in a busy shop filled with distractions.

By considering learning and fatigue as factors in a device's use, an informed decision can be made about the most appropriate input device for the task. Since one device may have shown learning, one fatigue and one neither, we assume that the interfaces themselves caused the errors. This suggests that the interface choice is critical to the usability and performance of a device.

As future work we would like to repeat this study using other platforms of number entry, such as capacitive touchscreens, to find out if the touchscreen error rates are still so much higher than the other two interfaces. We would also like to compare these results with the errors caused by continuous input method of entering numbers such as knobs. This would lead to providing generalised recommendations for number entry interfaces. Devices could also be fine-tuned to offer more intuitive interaction for users. For example, incorporating real-world physics into an input device's response could assist users, such as a rotating wheel on a touchscreen that mimics the effects of friction when slowing down.

Fig. 4 .

 4 Fig. 4. A binary representation of all errors made on each interface: rotary (top), button (middle) and touch (bottom). The rows represent the thirty participants and columns are 50 numbers.

Table 1 .

 1 Total incorrect digits and correlation of error rate and order of interfaces

	Interface	Total Incorrect Digits	Correlation
	Rotary	190 (1.19%)	0.344
	Button	180 (1.12%)	0.615
	Touch	896 (5.81%)	0.046

Table 2 .

 2 Rotary Errors (R), Button Errors (B), Touch Errors (T)

	Error Type	nR rR (N=15928)	nB rB (N=15906) nT rT (N=15389)
	Wrong digit	120 0.75	33	0.21	150 0.97
	Digit missing	28	0.16	34	0.21	509 3.31
	Added 1 repeat digit	19	0.12	94	0.59	30	0.19
	Added 1 digit	13	0.08	8	0.05	87	0.57
	Added 2 repeat digits	4	0.03	-	-	-	-
	Anagram	3	0.02	3	0.02	19	0.12
	Repeat digit missing	-	-	6	0.04	96	0.62
	2 digit pattern missing	2	0.01	-	-	4	0.03
	Repeated 2 digit pattern	-	-	1	0.01	-	-
	Repeated 3 digit pattern	1	0.01	1	0.01	1	0.01

The FEZ Spider Kit is a .NET Gadgeteer electronic set produced by GHI Electronics, consisting of a mainboard and a number of attachable modules.


Aurora Constantin

Helen Pain

Annalu Waller
email: awaller@computing.dundee.uk

Informing the Design of an Authoring Tool for Developing Social Stories

Keywords: Paper-based Interfaces, Design, Autism, ASC, Educational Tool, Assistive Technology for Children with ASC, Authoring Tool

This paper describes the design of an authoring tool, ISISS (Improving Social Interaction through Social Stories), for supporting practitioners using social stories to enhance social interaction in children with Autism Spectrum Conditions (ASC). The goals of the research are: 1) to determine practitioners' current procedures when working with social stories; 2) to discover how technology can better support such practitioners in the development and use of social stories that focus on improving children's social communication skills. An exploratory study was conducted with experienced practitioners, resulting in a number of design principles. Two low-functioning prototypes were developed, and explored in a second study. Further work is discussed.

Introduction

Children with Autistic Spectrum Conditions (ASC) frequently have difficulties with social interaction [START_REF] Shattuck | Change in autism symptoms and maladaptive behaviours in adolescents and adults with an autism spectrum disorder[END_REF]. These can be addressed through the use of social stories. The concept of social story was devised by Carol Gray as "a short story-defined by specific characteristics-that describes a situation, concept, or social skill using a format that is meaningful for people with ASD" [START_REF] Gray | Social Stories[END_REF]. It is written from the student's point of view and is a guide to follow when they have difficulties with a social situation (see Fig. 1). They are used to help the child acquire appropriate behaviour, reduce inappropriate behaviour, teach routines, teach skills, or cope with transitions and novel situations. Meta-reviews of social story interventions [START_REF] Kokina | Social Story interventions for students with autism spectrum disorders: a meta-analysis[END_REF][START_REF] Reynhout | Social Stories TM for children with disabilities[END_REF] focus on their effectiveness and on the impact of variables such as goal addressed, length of intervention, or participant characteristics. They conclude that social stories are promising, though it is not clear what variables are crucial to their efficacy. The aims of this research are: 1) to determine practitioners' procedures when working with social stories, and 2) to discover how technology can better support such practitioners. The longer term goal is to evaluate if computer-based technology can support and enhance the writing, presenting and assessment of social stories.

Fig. 1. Example of social story

Section 2 of this paper presents a short review of social stories and their importance for children with ASC. Section 3 describes a study which aimed to uncover practitioners' procedures and practices in order to see what support they need. The implications for design are considered in section 4. Section 5 assesses current tools for social stories in relation to the design principles and requirements elicited from the study. The design of an authoring tool to support practitioners in developing social stories is proposed. Section 6 presents the formative evaluation of the initial prototypes. Section 7 includes conclusions and future work.

Background

Psychological research has identified three dominant cognitive theories of autism: theory of mind, weak central coherence, and executive dysfunction [START_REF] Rajendran | Cognitive theories of autism[END_REF]. Individuals with ASC frequently have impaired Theory of Mind: they have difficulty understanding what other people think, feel, or intend to do [START_REF] Baron-Cohen | Does the autistic-child have a theory of mind?[END_REF][START_REF] Frith | Autism: Explaining the enigma[END_REF][START_REF] Perner | Theory of mind and self-control: more than a common problem of inhibition[END_REF]. A social story can provide information about how other people think and behave in a specific social situation, using perspective sentences that refer to other people's thoughts, feelings, actions and motivation. In this way a social story might reduce or remove the confusion and ameliorate the deficit in Theory of Mind. The weak central coherence theory describes the inability to build higher level meaning. An individual with ASC may be too focused on detail and miss the 'whole picture' [START_REF] Happé | The weak coherence account: detail-focused cognitive style in autism spectrum disorders[END_REF][START_REF] Rajendran | Cognitive theories of autism[END_REF]. Social stories are helpful in guiding individuals with ASC to identify the relevant details for a specific event and to correct mistaken assumptions; providing logical connections can help the individual to grasp the bigger picture.

Executive Function is a generic term for functions such as: initiating, sustaining, shifting and inhibition actions [START_REF] Zelazo | Executive function in typical and atypical development[END_REF]. It is thought to be responsible for handling novel situations where the routine is insufficient for optimal performance [START_REF] Rajendran | Cognitive theories of autism[END_REF]. Social stories seem to be useful in reducing or removing the deficit in executive functions, by Taking my temperature Sometimes if I am sick I get very hot. The doctor needs to know how hot I am. He will take my temperature with a thermometer. He will put the thermometer in my ear. This will not hurt. I might hear a beep or click noise, and this will not hurt. The doctor can see if I am sick. Then he can help me get better. The doctor will be happy and mum will be happy.

providing an individual with ASC with planning and organizing strategies in specific social situations, with initiation and impulse control.

Gray [START_REF] Gray | Social Stories 10.0[END_REF] suggests that social stories (SS) should be customized to meet the distinct needs and skills of the child, such as reading and comprehension skills, learning style, interests and attention. She provides criteria and guidelines to support the development of SS, including use of the first person; sharing social information in a simple, literal way; answering "wh" questions (who is doing, what, where, when and why?) and how questions, and use of positive language, with reference to positive rather than negative behaviour. Illustrations should be used when appropriate. She defines different sentence types to be used, including descriptive sentences (factual statements); perspective (describing a person's internal state, thoughts, feelings, beliefs); cooperative (identifying what others will do to help); directive (identifying a suggested response or a choice to a situation); affirmative (enhancing the meaning of previous statements), and control sentences (identifying strategies for recalling or applying information in SS). Descriptive, directive, perspective and control sentences may be either complete or partial (e.g. "Mom and Dad will feel _____ if I finish all my dinner"). She recommends a ratio between sentences of 0-1 directive and control to 2 or more descriptive, perspective, affirmative and cooperative.

Exploring how practitioners develop social stories

The approach taken in this research is primarily a Participatory Design approach, with practitioners as the main stakeholders. A study was conducted to better understand the following: 1) the process of developing SS; 2) the challenges encountered by practitioners in doing so; 3) to collect examples of SS developed, and typical content; 4) the tools currently used to support social story development. This study involved 4 practitioners who worked in special schools and had considerable experience in developing social story interventions for children with ASC. The practitioners were invited to participate in the study, and informed of its purpose. They were asked to think about their procedures and practices in SS, in advance of participation. The 2 hour study session took place outside of the school setting. Each practitioner was asked to write a social story. Practitioners were invited to express their thoughts aloud ('think aloud' protocol) while building the social story. Following this, semi-structured interviews were used to better understand the practitioners' experience and challenges when using SS with children with ASC. Both activities were recorded and video transcripts analysed qualitatively, using open, axial and theoretical coding [START_REF] Saldana | The Coding Manual for Qualitative Researchers[END_REF] to build a conceptual framework of social story intervention. Further literature was reviewed and incorporated into the framework. The results suggested that practitioners would value support for developing SS using a specialised computer tool, as an alternative to pen-and-paper or word processing methods currently used. The outcomes led to design principles and initial requirements for a 'social stories authoring tool', described below.

Supporting Practitioners in Developing Social Stories

The study revealed that a tool for supporting practitioners in developing SS might help them organise their work, and address the main challenges they face, including re-using resources developed based on individuals' profiles. Design should also consider Gray's guidelines and best practice. The steps that practitioners use are identified and elaborated, along with other core concepts, in Fig. 2: the exterior arrows suggest that challenges and content are determined by steps and goals, while the interior arrows suggest that the four concepts are part of social story intervention. These led to functional requirements including being able to create new stories; extend and edit existing ones; browse and search a library of stories and related images; annotate story sentences; present them in various forms; create and edit child profiles; manage social story development through the use of status display, reminders, etc. and to record progress through and manage assessment of SS. A number of challenges were identified, and these are incorporated in design principles to guide the design of tools to support social story development.

Ease the practitioners' workload. A major challenge that practitioners encounter is the time spent in preparing educational materials. Although SS seem to be less demanding than other educational strategies, the whole process of preparing, writing, presenting and assessing a social story is labour intensive. To address these problems, any support tool needs to be simple, intuitive and must help practitioners organise their work, and support the steps in the development process. The practitioners identified that the tool should allow them to reuse SS, symbols and photographs and to monitor the impact of SS on children. Data about the child's progress should be accessed and presented in various ways, enabling practitioners to get new insights into the child's behaviour and assess the success of the social story.

Design for Customizability.

A common desire is to quickly customize newly created or re-used SS. Users should be allowed to create resources for each child, to add their own SS, symbols, photographs, rewards, as well as interests and strengths (which should be accessible from the child's profile). The stories should also be customizable to the story topic content, be re-usable and sharable with other practitioners and children. Text to speech capabilities should be added to accommodate children with reading difficulties. Options to choose between various layouts should be provided.

Design for Engagement.

This could be met by customization to the child's interests and familiar context (e.g. images of familiar people). Practitioners could add rewards at the end of SS (e.g. animated characters, songs) adapted to each particular child. Social stories with partial sentences check comprehension, but may also make the system more interactive, potentially improving the child's engagement with the tool.

Current Tools for Social Stories

Applications for creating social stories: e.g. Story Builder [START_REF]Story Builder[END_REF], Story2Learn [START_REF]Story2Learn[END_REF], Sandbox Learning [START_REF]Sandbox Learning[END_REF], Pictello [14], Social Stories [START_REF]Social Stories[END_REF], and StoryMaker [START_REF] Storymaker | [END_REF], were considered in relation to the need to support the steps proposed for story development, and the design principles and requirements, as above. These applications focus primarily on building, editing and presenting SS, but do not generally support checking the comprehension, monitoring the story, or assessing SS. None of the applications provides an option to annotate the type of sentences, as Gray defines them. The applications are presented as allowing customisation, but this consists largely of changing font sizes and colours, background and the type of voice (when using text to speech technology, e.g. Pictello). None permits change of the story layout, nor provide the option to create resources for a particular child (e.g. favourite pictures, symbols or rewards) or for their reuse when creating new stories for that child. None permit the creation of a profile of the child, or storing information about the SS created, or their progress.

The limitations identified means these applications are not viable as the basis for a computer-based application to support practitioners in developing SS. Anecdotal evidence shows that practitioners sometimes use generic tools to create SS: Communicate: In Print [START_REF]Communicate[END_REF], Boardmaker [3], or Comic Life [START_REF]Comic Life[END_REF], though these do not satisfy the requirements. This research suggests that, to better support practitioners, research is needed to investigate whether a computer based tool could be developed that satisfies more of the requirements and principles identified through studies with practitioners.

Authoring tools: enable users to author material using an intuitive interface. In his analysis of the state of art of authoring intelligent tutoring systems (ITS), Murray [START_REF] Kokina | Social Story interventions for students with autism spectrum disorders: a meta-analysis[END_REF] argues that authoring tools: a) reduce the effort used in creating ITS; b) reduce the necessary skill threshold for developing ITS; c) support the author in articulating or organizing her work; d) scaffold good design principles; e) facilitate rapid prototyping. Many of these arguments agree with the principles and requirements defined above, and support the use of an authoring tool to help practitioners in their work, enabling rapid customization, flexibility and requiring no programming skills.

Formative Evaluation of Initial Prototypes

A second study was conducted with practitioners. The goals of this study were: 1) to explore design alternatives; 2) to discover usability problems and solutions to overcome them; 3) to generate new ideas to include into the systems' features and interaction, and 4) to refine the system specification. Two versions of low-functioning prototypes were created using Balsamiq Mockups [START_REF]Balsamiq Mockups[END_REF], according to the requirements and design principles (see screenshots examples in Fig 3: a & b). They were explored with ten practitioners having experience in using SS with children with ASC. In each twohour session constructive interaction was applied, a version of the thinking aloud protocol which requires two practitioners at a time [START_REF] Holzinger | Usability engineering for software developers[END_REF]. The practitioners were presented with four scenarios and invited to follow each scenario using each prototype, by pressing on buttons and menus, and simulating typing. A researcher playing the "computer" role changed the screens according to the users' actions. The main researcher, acting as a mediator, encouraged the practitioners to express their opinions and preferences for various features of the prototypes. Brainstorming was then used to find solutions for the problems encountered and to generate new ideas. Qualitative analysis of session recordings was used to determine practitioners' preferences, usability problems and solutions, and to extract new ideas for design. The problems found were categorized into five groups: 1) page layout; 2) navigation/workflow; 3) concepts and terminology; 4) content, and 5) functionality. Based on these, the system interfaces and specification were refined. Figure 3 shows the revised working prototype. The tab navigator containing pictures, symbols, layouts and resources (for a child) was preferred on the left side (Fig. 3:d).

The navigation buttons were placed in left and right bottom corners of the story panel. The option to annotate the sentences was considered of high importance for practitioners and included in the working prototype (Fig. 3:e).

Discussion and Future Work

This paper reports on research that informs the design of an authoring tool for writing, presenting and assessing SS for children with ASC. This research has been guided by the methods of Participatory Design. The first study uncovered practitioners' procedures when developing SS. The focus was on the core concepts and themes that could be translated into design principles and system requirements. Although practitioners were aware that tools for social story interventions exist, most of them preferred paper and pencil to write SS, existing tools being either too complex to use or not flexible enough. They sometimes use tools not specific for SS, in order to access the library of symbols (in [START_REF]Communicate[END_REF] and [3]) and because of the simplicity of the interface (in [START_REF]Comic Life[END_REF]).

Through the second study the requirements were clarified, different design strategies explored, and interfaces and specifications refined. In both studies the practitioners contributed in creating knowledge and showed interest and enthusiasm for the project. These are the first steps in a project aimed at better scaffolding for practitioners in developing SS. In turn this may increase the positive impact of SS on social communication skills of children with ASC. The results have been incorporated in an evolutionary prototype authoring tool, which will be further evaluated with practitioners.

Fig. 2 .

 2 Fig. 2. The conceptual framework of social story intervention

Fig. 3 .

 3 Fig. 3. The Prototypes: a) initial prototype 1; b) initial prototype 2; c) working prototype; d) tab navigator for customization; e) annotate sentences; f) navigation button.