ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
Switch: Exploring the Design of Application and Configuration Switching at Tabletops Christopher James Ackad, Anthony Collins, Judy Kay School of Information Technologies University of Sydney, Australia
[email protected],{anthony.collins,judy.kay}@sydney.edu.au
ABSTRACT
In all but the purest appliance interfaces, users need some of the fundamental core facilities for general computing interface elements: to change applications; change the files the application uses; and control which interface elements are present on the table. While these facilities have been refined for desktops, the particular affordances and limitations of tabletops call for a rethink of the interfaces for these actions. We describe the design process for Switch, which supports the core functions of application and configuration switching at an interactive tabletop. We began with several low-fidelity prototypes, evaluating these to a refined set of four. We then evaluated each of these using Heuristic Evaluation with 4 experts and Cognitive Walkthrough by 5 experts. From this, we created the final Switch design which we evaluated for usability with a think-aloud study by 8 users. We conclude that Switch is easy to learn and use for the core facilities for general computing. We reflect on lessons learnt and directions for the future. Our key contributions are the exploration of user interface support for a set of the most fundamental core facilities for general computing at tabletops, our use of these to design the Switch tool and our usability evaluation of Switch, providing a foundation for the design of the core user interface elements that will enable people to make flexible use of tabletops.
Figure 1: A map of the specialisation and user space of everyday technology.
provide at least some of the most fundamental of the core facilities for general computing. At the most basic, users need to have interface elements for starting a new application, changing the files used in the current application, and altering application settings. We are beginning to see mechanisms for changing applications. However, there has been little research exploring the relevant interface elements and support for core facilities for general computing at tabletops. This is why we have identified a set of the core facilities for general computing as a starting point for exploring approaches to providing interfaces supporting them at tabletops.
H5.2 [Information interfaces and presentation]: User Interfaces ACM Classification: General terms:
Key drivers for designing interfaces for core facilities for general computing at tabletops come from the nature of their use, as we illustrate in Figure 1. The horizontal dimension indicates the level of specialisation, with desktop computers being at the general purpose end of the spectrum and, at the other end are the very specialised public kiosks which typically provide one well defined function, such as giving directions in a large shopping centre or information at a cultural heritage site. Older mobile phones are also shown near the right (specialised) end with smartphones to their left, as they have more general functions. At present, tabletop research and deployed systems are to the right, some operating as rather limited kiosks.
Design, Human Factors
Keywords: Tabletop interface, surface computing, application menu, application switching INTRODUCTION
As tabletops and other surface computing appliances become increasingly available, there will be a large number of available applications for use on them, reflecting the many user activities that can be particularly well supported by such embedded devices. This will create the need for tabletops to
The vertical dimension in the figure has devices for individual, or personal use at the bottom, with mobile phones as exemplars. We show desktops a little higher as they are really designed for use by a single user at a time and are heavily used as personal devices. On this dimension, tabletops are at the top because they are particularly well suited to use by small groups of people and this means that they are inher-
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ITS’10, November 7-10, 2010, Saarbr¨ucken, Germany. Copyright 2010 ACM 978-1-4503-0399-6/10/11...$10.00.
95
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
available for the Microsoft Surface, where touching spots at the corners of the screen changes modes, to present icons in a slide reel, that the user can slide across to browse the applications available. The reel shows each application as a large icon or preview, and it shows a preview of any paused (minimised) applications. The Surface extended this in Service Pack 1 [10] which enables a user to start an application, with a particular set of files, by placing a tagged physical object on the table. The relatively recent emergence of these core facilities for general computing and the similarity that some show with new smartphone touch interfaces points to the timeliness and importance of research into effective tabletop interfaces for core facilities for general computing. The Windows 7 operating system, with its support for multi-touch interaction, is another indicator of the importance of work on both user interfaces and deeper operating systems support for core facilities for general computing on tabletop, and other touch, interfaces. Notably, its task bar design takes account of the fat finger syndrome and it supports gesture recognition to improve the usability of core facilities for general computing, such as window management, manipulating icons and accessing properties.
ently suited for use by multiple users. In addition, the particular groups of people will typically differ over time, meaning that there may be quite large numbers of people who have access to the tabletop and a moving population of users. Importantly, this means that we can expect that an important class of usage of tabletops will involve first-time, intermittent and infrequent users. This means that learnability of interfaces is likely to be very important for that broad class of uses of tabletops. Taking account of these important differences in the nature of tabletop interaction, we can still draw upon the long term work that underpins current desktop support for these core functions. For example, the current dominant desktop metaphor has its foundations in the Xerox Star [6]. That interface design was profoundly affected by the assumption of a single user, with mouse and keyboard, and consistent screen orientation. We cannot assume the same interface is well suited to tabletops. This is partly because tabletops have different, perhaps more limited forms of user input. But, equally important is that tabletops have different affordances, as well as different uses as indicated in Figure 1. It is not even clear just which of the many desktop core facilities for general computing are needed for tabletops. Furthermore, it is unclear how to support these actions in effective interfaces for multi-user, collaborative tabletops.
Paradigms for Managing Applications on Desktops
The core facilities that enable a user to interact with the underlying operating system of a general purpose computer have been identified as: program management; computer communications; file system manipulation; I/O operations; and system status [20]. These facilities are available on a range of devices from mobile phones to gaming consoles. In due course, we need to consider whether and how to support all of them on tabletops.
This paper describes our exploration of interfaces for core facilities for general computing at tabletops, with the resulting Switch interface. It provides the functionality commonly associated with a Start and File Menu found on a conventional desktop operating system. It was implemented with the Cruiser tabletop framework [2], but the design process and final design are relevant to a broad range of tabletop interface software.
On the desktop, there have been several quite distinct classes of interfaces for core facilities for general computing. The UNIX [19] command-line interface had a “tools metaphor” rather than the “desktop metaphor” of the Xerox Star interface [6]. In the tools metaphor, a user invokes an application and specifies options and files. It offers filters and pipes that can combine such application invocations (or tools). Another distinctive interface is offered by Acme [17], a graphical shell and text editor for the Plan 9 operating system. It offers a windowed command line interface. Its design optimised the use of the mouse, and provided an alternative to conventional menus. It makes any onscreen text a potential executable command, providing a powerful, flexible, dynamic and customisable environment for the expert user who can write commands and execute them with a mouse click.
The next section overviews related work. Then, we describe our design process and present the user view of Switch. We describe our study evaluating its usability and conclude with lessons learnt and future directions. RELATED WORK
We have made use of three important foundations. In this section, we describe two of these: the existing tabletop approaches and the long term design of interfaces that enable users to achieve core facilities for general computing. The third comes from design principles for tabletop interaction, which we discuss in the next section. Tabletop Application Management
A quite different path that dominates current desktops owes much to the Xerox Star [6], which implemented a graphical user interface that metaphorically represented an office desktop. It introduces icons for file management and direct manipulation so that users interact with the applications and files directly [22]. It provided core file system commands such as copy, paste and delete and made them available within applications. Its user interface provided a high level of consistency across applications. A desktop metaphor influenced some of the earliest tabletop work [11].
Some commercial tabletop systems are beginning to provide interfaces for limited core facilities for general computing. For example, the SMART Table [21], NUITEQ Snowflake [16] and Microsoft Surface [9] support rudimentary application management. All use a moded approach, meaning the user is either in an application or leaves it to the management environment. There have been two main interface styles for that management environment. One is rather similar to the interface on smartphones like the iPhone. This is the case for Snowflake and the SMART Table, where the user is presented a set of icons, one per application, and these can be arranged in various configurations. A different interface is
These approaches have quite different interface paradigms, ranging from being based on typed commands to relying on 96
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
direct interaction, and explorable menus. We explored the key ideas and views of the nature of an interface to the underlying computer’s facilities to identify the functionality that we should aim to support. We also reflected on the relative strengths and weaknesses of each for a tabletop interface. At the same time, we recognise that the widespread availability of the desktop metaphor means that people are very familiar with it. So it has been particularly influential for our design.
the right type in the user’s file space. We decided that, at this stage, such generality cannot be assumed to be necessary for tabletops. Accordingly, we have restricted our exploration to a more kiosk-like operation where there is a restricted number of file-sets that are intended for each application and that the application designer defines these. So our second core function is switch between restricted file-sets for an application. We have not seen tabletop interfaces that provide this.
DESIGN PROCESS
The third key facility should support selection of start-up settings for an application. This allows an application designer to expose any desired settings to the user. For example, in a photo sharing application, one setting could be to cluster photos into events on a timeline; another setting could present them scattered around the table, grouped by tags. So, the third function we aim to support enables the user to alter the default start-up settings for an application.
Our design approach had five main stages. First, we identified the set of core facilities for general computing we should support. In Stage Two, we identified a set of design heuristics. These have a dual role: to inform the design process; and later for evaluation of each design and to compare them. Stage Three was the identification of a set of approaches and creation of low fidelity prototypes for each. The fourth stage was to conduct discount usability evaluations of each design. For this, we used the Heuristic Evaluation and Cognitive Walkthrough methods [12]. Heuristic Evaluation makes use of the design heuristics of Stage 2, clarifying the tradeoffs associated with different design approaches. The Cognitive Walkthrough was also critical, providing an evaluation of the learnability of each design approach. The fifth stage was to select the most promising approach and then to refine it, making use of the information from the Stage Four usability evaluations. We now describe each of these briefly.
The fourth and final class of facilities should enable the user to control whether optional interface elements are present on the table. We believed it was important for users to be able to control these, especially because clutter is acknowledged as an important problem for tabletops [5, 7, 18, 8]. This suggests that it is important to enable the user to decide which interface elements they wish to have on the table and which should be hidden. Based on our experience of building and evaluating various tabletop applications, we had also become aware that there are many interface objects which are useful when needed but can get in the way at other times. For example, a storage bin can be useful for collecting a set of interface objects but, equally, if that functionality is not needed for the current task, it can be irritating if objects are accidentally dropped in it. Similar issues apply to interface elements for deletion and copying as well as other active objects that can be accidentally invoked by an unintended touch. This issue interacts with that of clutter. We expect that users should be able to easily change the interface elements visible on the table at various times during their use of an application. This approach also seems important for first-time users of an application. The system can be configured so that the bare minimum of interface elements appears as the default. Then, as the user wants to explore the additional facilities and interface elements, they can find these and decide to activate them one at a time, and try each out. So, the fourth function we wanted to support is activation of new interface elements within an application, or their deactivation.
Identifying a core set of functionality
As indicated in the last section, desktop computers provide a rich set of interface elements for core facilities for general computing. At this stage, where it is not clear just which of these is really needed for tabletops, we selected a core set of functions. To identify the relevant functions to support, we aimed to move tabletop interaction towards the left in Figure 1, but not to the extreme left. There are two main reasons why this is an appropriate approach. Firstly, at this rather early stage of exploring the appropriate core facilities for general computing for tabletops, it would clearly be useful to have at least some rudimentary facilities. If they are well chosen, they will give users valuable functions that will make tabletops support a broader range of facilities. The second reason for beginning by providing a small set of facilities is pragmatic; as we explore interface approaches, it is feasible to carefully evaluate these for a smaller set of facilities. So, we now need to identify a valuable set of basic functions. We had already built several applications and it became clear to us that users should be able to switch between these at the tabletop. As just described, commercial systems reflect this view. So, our first core function was change application.
We do not claim that this set of four functions will suffice for the long term roles that tabletops may play. However, they represent a core of critical functions that we believe to be valuable for the roles that tabletops play, as defined by their affordances for collaborative interaction.
We also had applications that could operate on various data sets and we wanted users to be able to switch between these. This, too, seems to be a quite fundamental and important facility. Notably, past work on file system interaction for tabletops [4] indicates that the nature of file system interaction at tabletops is fundamentally different from that at desktops. This follows from the private nature of desktops and the collaborative, multi-user nature of tabletops, as indicated in the vertical dimension of Figure 1. In the case of desktops, applications are generally designed to operate with any file, of
Design Heuristics
In Stage Two of our design process, we identified 21 design heuristics. We took the widely used Nielsen Ten heuristics [14] because they deal with the general usability, and are applicable to most user interfaces. Briefly, these are: Visibility of system status; Match between system and the real world; User control and freedom; Consistency and standards; Error prevention; Recognition rather than recall; Flexibility and efficiency of use; Aesthetic and minimalist design; Help users 97
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
recognise, diagnose, and recover from errors; Help and documentation. We also used the Large Screen Information Exhibit heuristics [23] as they are the most relevant set of validated design heuristics we found in the literature. Although tabletops are often small table displays, these heuristics have the potential to be valuable for this rather similar class of interfaces. They are: Appropriate colour schemes can be used for supporting information understanding; Layout should reflect the information according to its intended use; Judicious use of animation is necessary for effective design; Show the presence of information, but not the details. We augmented the set of heuristics with the Tabletop Software heuristics [1]. While these have not been validated, they are the only set directly relevant to tabletops. They are: Design independently of table size; Support reorientation; Minimise human reach; Use large selection points; Manage interface clutter; Use table space efficiently; Support private and group interaction.
Figure 2: Switch’s early prototype designs. Top Left: Scatter, Top Right: Drawable Menu, Bottom Left: Zipper, Bottom Right: Panel.
Exploration of approaches based on low-fidelity prototyping
file-sets while already in an application, the user dwells on the wormhole to see the available file-sets (coloured purple), and then dwells on one to activate it. To change applications, the user dwells on the active application icon to go back to the application selection screen, where a different application can be launched.
Stage Three involved the creation of prototypes for different approaches, resulting in four designs for the layout and form of the interface elements. Each was the result of an iterative design process, starting with paper prototypes and other low-fidelity prototypes. We explored two distinctive types of interface: three prototypes based on a moded approach; and one that made use of a special object. All the moded prototypes use a lightbox approach where the main tabletop display is dimmed and only the switching elements are bright. The variable factor across these three was the mechanism for activating the mode change and the layout of the switching elements, as we describe below. The moded approach makes it clear to all people using the table that the switching elements are being used. The fourth prototype, based on a special object, could be used in parallel with other tabletop activity. The effect of changing applications or file-sets as well as deactivating interface elements within an application constitute a major change in the state of the table. This may make the moded approach preferable as it ensures all users are aware of this. On the other hand, the activation of new interface elements is less disruptive and the unmoded, special object may be preferable for that. Figure 2 provides a screenshot for each. For each prototype, we created the screens for three core functions: start an application, change file-sets and switch applications.
At the upper right of the figure, we show the drawable menu design, inspired by [7]. A similar style of interface has also appeared on some touch-based desktops. The screen starts blank and the user draws an arc to bring up the applications in the scrollable arc. Dwelling on an application icon moves it below the arc, and then the available files and options are shown above the arc, each with its name below its icon. To change file-sets while the application is running, the user dwells on the wormhole object, which dims the screen, allowing the user to activate the menu by drawing an arc. From here the user can select another file-set by dwelling on it or switch to another application by dwelling on the application icon like in the scatter prototype. It has the merit that the user defines the orientation of the displayed icons by the way they sweep out the curve shown at the bottom of the figure. In the zipper design, shown at the lower left of the figure, the menu content is revealed as the user drags from a fixed object towards themselves. They first select an application by dwelling on the application icon, then dwell on the fileset to launch an application. To switch applications, one dwells on the wormhole object to switch modes, causing the screen to dim and the wormhole to move to the centre. A user drags the zipper towards them, revealing the available file-sets; dwelling on one switches the file-set in the running application, or dwelling on the application icon returns to the application menu. This too has the advantage of the user defining the orientation.
The upper left, is a scatter design. It was inspired by interfaces we have seen in several tabletop systems, for example [4] — icons for each application are scattered, or spread across the screen, so that each user around the table has some near them and some are oriented towards them. A wormhole icon is always present; dwelling on it switches to an application menu mode (which is active when the table starts-up) where the main display is dimmed and the available applications appear as icons (boxes in the figure). Dwelling on an icon removes all the other application icons and shows the available file-sets for that application in the same manner. Dwelling on one of these starts the application. To change
The fourth design, the panel, starts as a single icon on screen. Once enlarged, it reveals a configuration panel, shown as the large green box at the lower right of Figure 2. On this, the 98
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
Figure 4: (Left) Switch minimised, (Right) Switch expanded. Figure 3: People using Switch to change applications and settings at an interactive tabletop.
primitive objects, the browser widget for accessing files, the copier, and the black hole for deletion. Users can move all primitive and special objects by touching the main area and dragging. All objects can be ro-sized (a combination rotation and resize) by touching one of the corners and dragging, with outward moving enlarging, angular movement rotating. A dwell on a primitive object does an associative search [3], retrieving all similar objects. We implemented Switch to be consistent with other special objects; it can be moved, rosized, but cannot be copied or deleted.
user selects files and options with large buttons to configure and launch the application. Discount usability evaluations
In Stage Four, discount usability evaluations were completed by four experts, all experienced interface designers, all members of our research group, one being the second author. All had prior experience in designing tabletop applications. The Heuristic Evaluation involved assessing each prototype from Stage Three according to the heuristics on a set of three tasks representative of two of the four key functions: changing application and switching between a restricted file-set for an application. These three tasks involved first approaching the table and selecting an application to launch with a specified file-set, switching to another application and changing the current application’s file-set. The Cognitive Walkthrough used the same tasks and at each step, the experts reflected on the questions: Will user understand this sub-task is needed? Will correct action be obvious? User understand instructions? Will user know if progress has been made?
We present the user view of Switch as a series of ‘tableshots.’ At start-up, the user sees the minimised Switch icon, shown at the left of Figure 4. This is always present on the tabletop. It was designed to be small enough to avoid clutter but distinctive enough to be easily found when needed. For large tables a user can call this element to them by dwelling on an empty part of table. When the user enlarges the icon, it displays the icons for available applications as in the right of Figure 4, for a case with four applications: a Blackjack game, PhoTable, Museum Guide and Travel Guide. The user can enlarge this by either dragging on the corner or by dwelling on the icon (we refer to this as resize on dwell). Dwell is used in this case to differentiate from the primitive move gesture.
Selecting and refining a prototype
The evaluations pointed to a range of weaknesses for each prototype. Here we report those that experts gave high severity ratings, and that are inherent in the approach (omitting those that could have been amended as a refinement of the design). For the scatter prototype, key problems were clutter, reachability, memory load and learnability problems in recognising the role of the control elements. The main flaws for the zipper and drawable menu design related to learnability. The panel design was the best, with best learnability of all, but with some reachability problems. This meant that at Stage 5, selecting an approach to explore further, we chose the panel design. Importantly, the evaluation process informed refinement of that design.
To start one of the applications, the user drags the relevant icon out and enlarges it to see the launch options for that application. If the user does this for the Travel Guide, it appears in its default mode as shown in Figure 5. The top left displays the same icon as in the previous widget (labeled A in the figure), with the image promoting recognition of the application. The title (B) is at the upper right and a short text area below (C) so that helpful information can be provided about the application. The typical use, with defaults for files and options, requires the user to dwell on the Start button (D). This is the only interface element requiring a dwell to activate. This design aims to avoid errors from inadvertent taps on the Start button, which would have a significant impact on the state of the table if it were done accidentally.
SWITCH OVERVIEW
At the lower left is the available file-sets (E) with Florence selected (F) indicated with blue highlighting, and other options having a gray background. Application designers specify icons and names for each file-set to support visual recognition as well as reading the name. In this particular application, the user can only select one file-set. In general, Switch
The implemented system, in use, is shown in Figure 3. It was created within the Cruiser framework [2] which provides several interface elements and functionality. Its primitive objects include images, documents, movies and audio. Its special objects, which can be used in conjunction with all the primitive objects, include storage bins for holding groups of 99
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
Figure 5: The Switch Launcher panel for the Travel Guide application.
Figure 7: Switch’s application panel once an application has been launched.
lects them and the tool is loaded immediately. Dwelling on Update changes the file-set while the application is running (the update button is only shown once a different file-set has been selected). EVALUATION
For the evaluation of Switch, we designed a small scale user study, to evaluate the hypotheses: H1: Learnability, Switch is easy to learn. H2: Ease of Use, Switch is easy to use. H3: Error Recovery, it is easy to recover from any errors in using Switch. Learnability was a key design goal. We intended that the first time user of Switch could explore the interface to discover its functionality without tuition. This is particularly important if tabletops in shared places are to be useful for novice, intermittent and infrequent users. Ease of use and error recovery were also key design goals. People should be able to complete tasks in the minimal number of interface steps and, if they happen to make a mistake, such as selecting an unintended file-set, they should be able to work out how to recover from that.
Figure 6: The Travel Guide application, with the minimised Switch widget.
can support multiple selections. To select a different file-set, the user taps it. At the lower right of Figure 5, we see the options selected (G). To select a specific option the user taps it. A tap is used instead of dwell (required for the Start button), as the effect of the tap is easily reversible in this case. A little later, the table appears as in Figure 6, running the Travel Guide with the Florence file-set. The Switch widget is minimised to reduce clutter on the tabletop. The application designer can specify that the Switch widget should be hidden. In that case, the user makes it appear by dwelling on a blank area of the table. Hiding the Switch widget means that the user needs to know how to activate it but in applications such as games, the application designer may decide they want that. Once an application has launched, Switch appears as in Figure 7. This provides the usual application icon (A), title (B) and information (C). It now provides Update and Exit buttons (D). The lower left still has the available file-sets (E) but now the right side shows the available tools (F), in this case a photocopier, crop tool and storage bin. Tapping these se-
Experimental Design
We used a Think Aloud [13] user study evaluation as this provides insight into the user’s reasons for actions performed. In this method, participants externalise their thoughts as they use the interface. With this method, timing data is unreliable so we did not record it. The study had 4 parts: 1. Background questionnaire, asking about: occupation; age; gender; level of computer use; previous use of tabletops in general and the specific tabletop applications that were used in the study. 2. Tutorial and practice for the basic tabletop interface without Switch. 3. The user was asked to complete a set of tasks, each assessing a function of Switch, but with no tutorial or introduction to it. 100
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
4. Post-experiment questionnaire, asking about the user’s perceptions of learnability, ease of use and general comments about Switch.
Table 1: Observations of task execution for Scenario 1
The tasks were designed to be completed within 45 minutes. They involved two scenarios, the first involving use of a travel guide, the second exploring a museum exhibit. Each scenario had 5 tasks, each requiring different functions of Switch: starting an application; setting a file-set; setting a configuration; changing the file-set; adding a tool; and exiting the application. The design required participants to perform 5 of the key functions at least 3 times, but to set the configuration just once. The repeated use was so that we could observe whether people became more fluent especially, if they had problems the first time they tried to make use of a new function. The actual text of the first scenario was: 1. You have decided to use Travel Guide to organise your trip to Melbourne, and you also need a container to store these files. Now start the Travel Guide. 2. Now that Travel Guide has loaded with the Melbourne collection browse this collection to locate four files on Melbourne’s attractions and place them into your container. You have now acquired a collection of items for Melbourne, and now are ready to plan the next part of your trip. You now need to get a collection of places to go from the London files. Now you need to plan the London part of your trip. 3. Now that the Travel Guide has reloaded, again browse this collection to locate four files on London’s attractions and place them into your container. You should notice that the container is getting crowded, so you decide to get another Storage Bin to place your files from London. 4. Now you are ready to plan the final part of your trip in Florence, Italy. You now need to get 6 files of places to go in Florence. You may require an additional Storage Bin for Florence. 5. You have finished. Now get ready for the next task, which will use a different application.
Participants 4 5 6
Tasks
1
2
3
1. Loading the Travel Guide Open Application Container Open Application Panel Configure Application Start Application
l 3 3 7
3 3 3 3
3 3 3 l
l 3 3 l
l 3 3 l
2. Planning London Trip Open Application Panel Select Options Update Application
3 3 3
3 3 3
3 3 l
3 3 3
3. Using the Tools (Folder) Open Application Panel Add a Folder
3 l
3 l
3 l
4. Planning Florence Trip Open Application Panel Select Options Update Application Add a Folder
3 3 3 3
3 3 l 3
5. Finishing up Open Application Panel Exit Application
3 3
3 3
7
8
l 3 3 7
3 3 l l
3 3 3 l
3 3 7
3 3 3
3 3 l
3 3 3
3 l
3 3
3 l
3 3
3 l
3 3 3 l
3 3 3 3
3 l 3 3
3 3 3 l
3 3 3 3
3 3 3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 = Task successfully completed on first attempt l = Task completed after experimentation 7 = Task failed
each task, the tables show the Switch functionality that participants needed to learn in the first use, and remember for subsequent uses. In both tables, a subtask has a tick if the participant completed it fluently. This means the observer judged that the participant took each step required without the need to explore to find the correct action for the subtask. If they needed to explore, but succeeded in the subtask, we show a solid circle. If they needed help, there is a cross. There are some clear trends. On the first attempt (Table 1), many participants needed to explore for some subtasks as one would expect. In just three cases, a user failed. Table 2, representing second and third attempts at tasks, has no failures and less exploration.
For the most part, Scenario 2 gave more opportunities to do similar tasks. Notably, Task 7 also asked participants to recover from having started the application in the wrong mode, requiring them to recover from this. To do this, they had to exit and restart, with altered initial settings.
We now explain the tables in detail for selecting and launching an application (Tasks 1, 6 and 7). Table 1 shows that 5 participants (P3, P4, P5, P7, P8) discovered how to do this task after exploration, and, somewhat surprisingly, P2 completed it fluently, even on this first attempt. The other 2 participants (P1, P6) needed help on starting the application, by dwelling on the Start button. Table 2 shows the picture for subsequent attempts to load an application (Tasks 6–7). All but 1 participant did this fluently, and all succeeded. This indicates most users could discover how to do this task by exploration, but all could do it alone afterwards, most doing it fluently.
Participants
Eight participants were recruited, enough to be likely to disclose significant usability problems [15]. The participants were a maths tutor, junior animator, and university students from Information Technology, Electrical Engineering and Science. All participants used computers at least 21 hours a week, most more than 31 hours. This population is highly computer literate, somewhat limiting the generality of the results. Three had used tabletops before, two of them had used the same tabletop and one an interactive museum tabletop. None had seen Switch before the study.
Tasks 2, 4 and 8, involving changing file-sets, show a similar picture. We note that in Task 8, the one failure was due to a problem with the underlying museum guide application.
Results
Table 1 summarises the results for the first scenario (Tasks 1–5) and Table 2 for the second scenario (Tasks 6–10). For
Tasks 3, 4 and 9 involved adding tools and there, too, we see 101
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany Table 3: Quantitative results from the questionnaire
Table 2: Observations of task execution for Scenario 2 Participants 4 5 6
Tasks
1
2
3
6. Loading Museum Guide Open Application Container Open Application Panel Configure Application Start Application
3 3 3 3
3 3 3 3
3 3 3 3
3 3 3 3
3 3 l 3
7. Reloading the Widget Open Application Panel Exit Application Open Application Container Open Application Panel Configure Application Start Application
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
8. Switching to Greek History Open Application Panel Select Options Update Application
3 3 3
3 3 3
3 3 l
9. Using Tools (Crop Tool) Open Application Panel Add Crop Tool
3 3
3 l
10. Finishing up Open Application Panel Exit Application
3 3
3 3
7
8
3 3 3 3
3 3 3 3
3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 l 3
3 3 3
3 3 3
3 3 3
3 3 3
3 3 3
3 3
3 3
3 3
3 l
3 3
3 l
3 l
3 3
3 3
3 3
3 3
3 3
3 = Task successfully completed on first attempt l = Task completed after experimentation 7 = Task failed * This task intervention was related to a problem with the Museum Guide application, not Switch and therefore not covered
the same trend. We note that in the third attempt in Task 9, P2 and P8 first attempted to drag the crop tool from the panel; both then realised that it only needed to be tapped. P6 still dwelt when adding a crop tool to the table. This suggests some confusion between dragging, dwelling and tapping that apply in different parts of the interface, reducing learnability and ease of use. For the task of exiting the application (Tasks 5 and 10) participants found the task easy in both first and second use, perhaps due to increasing familiarity with the interface.
Statement
1
2
3
4
1 2 3 4 5 6 7 8 9
6 7 6 7 7 6 7 7 7
3* 7 7 3 3 7 6 6 7
6 7 7 5 6 6 6 7 5
5 6 6 5 4 7 2 7 5
Participants 5 6 7 7 7 7 7 7 7 7 4 7
3 7 5 5 6 2 6 7 7
6 6 5 5 4 2 6 6 6
8
Median
6 6 6 6 4 4 6 7 4
6 7 6 5 5 6 6 7 6.5
* This result was related to a problem with the Museum Guide application, not Switch
The low score from P2 was due to a bug in the underlying application. P6 had difficulty with dwell when it was required. Statement 2 was Find the application that I was looking for. Statement 3 was The Launcher is easy to understand; it had strong agreement for all but P6 and P7. For Statement 4, Switch provides adequate feedback to actions, participants’ comments point to the problems encountered: P2 explained that they expected to be able to move and resize the application icon after initiating the dwell to resize function without releasing the object. P7 stated “Inconsistent audio feedback. . . had somewhat frustrating experience trying to not accidentally trigger behaviours. That said, all buttons provided feedback and worked consistently.” Statement 5 was The resize on dwell function is easy to use and intuitive. P2 was confused about this as for Statement 4. Others commented they felt it was intuitive. For example, P6 stated “I think I used it without realising I was dwelling and resizing.” For the 6th statement, Understood need to dwell on the buttons P6 stated: “Initial problems with [launching the] Travel Guide application, because I did not dwell on the start button.” This was again a problem with the dwell. Statement 7, Understood need to tap to select File Sets and Options has strong agreement by all but P4 who commented “I was dwelling on them.” Interestingly, P6 said “After assistance, I assumed that dwelling was necessary for all buttons.” P5’s disagreement on Statement 8, I had no trouble changing the file-sets using the Launcher was because they dwelled on the exit button without realising that this quits the application, instead of minimising the launcher. They said “I did have trouble with it at first with two options being ‘update’ and ‘exit’. I first thought that ‘exit’ would change the files, but I restarted the application instead.” Finally, Statement 9 was I understood how to select the tools I wanted. P8 said “Sometimes forgot and attempted to drag them off the launcher, but always remembered when this had unexpected results.”
We now consider each participant in the second scenario (Table 2). These were completed successfully, with the following exceptions. P5 accidentally launched the wrong application. P8 forgot to specify the required file-set when starting the application. These were slips; participants quickly realised and recovered. More serious is that P3 kept tapping, rather than dwelling on the Update button when trying to change the file-sets. We have already mentioned the use of drag rather than tap by P2 and P8, and P6’s use of dwell rather than tap. P3 repeatedly tapped on the exit button instead of dwelling. Table 3 summarises results of post-experiment questionnaires, on a 7 point Likert scale (7 for strong agreement, 1 strong disagreement). All statements had most participants agreeing. We now briefly discuss the statements and the outliers and the additional comments participants made to explain their scores. Statement 1 was Perform tasks with no problems. 102
DISCUSSION
Our evaluation hypotheses related to three aspects of usability which we now discuss as a basis for our conclusions about the lessons learnt.
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
H1 Learnability
CONCLUSION
As we have noted, the nature of tabletops makes learnability critical. This was why we designed the evaluation so that users had no training at all. We wanted to assess whether they could use Switch effectively by simply exploring and making use of their existing mental model of using computers. The prime indicator of learnability is discoverability, meaning that the participants could discover how to complete each subtask needed. A secondary indicator was their ability to recall it later. For people who needed help on their first attempt, we can assess aspects of learnability in terms of their ability to recall it and use it successfully later.
The driver for the work on Switch came from the recognition that tabletops are currently used as rather specialised devices, at the right of Figure 1. Yet the very nature of tabletops and the broad range of tasks for which they have the potential to be useful indicates that they should become more general purpose devices. One of the essential prerequisites for this is that they provide at least a core set of the functions that are available at desktop computers, enabling users to start arbitrary applications, use them with arbitrary files and to configure them and the desktop as they wish. We began the design process by identifying a suitable set of functionality as a first set of general purpose operating system functions. We identified four: to change application, switch between the set of files available for an application, alter the default start-up settings for an application, activation of new interface elements within an application, or their deactivation. We have explained why these constitute a valuable set of basic operating system functions for making tabletops more useful for a broader range of activities.
Table 1 shows that about half of the participants (5 of 8) could discover all functional elements on their first attempt. Each of the other three failed in just one of 15 subtasks. All had the same problem: they did not dwell long enough on Start to launch an application (P1 and P6) or they forgot to do this for the Update on a later use (P5). Table 2 shows that all participants succeeded on the second set of tasks. Importantly, they recalled how to do the task rather than needing to explore. So, in Table 1, 21 subtasks required exploration while in Table 2, this drops to 7 subtasks.
The second key aspect of our work was the exploration of potential interfaces. We explored three forms of an interface, which is moded, as are the SMART Table [21], NUITEQ Snowflake [16] and Microsoft Surface [9] basic application management interfaces. The fourth prototype makes use of a special object. We evaluated these with low fidelity prototypes using Heuristic Evaluation by 4 experts and Cognitive Walkthrough by 5 experts. This informed our choice of the special object approach which was refined to the Switch interface. We still consider that it could be valuable to explore the effectiveness of a moded approach, especially in terms of user preference for being aware of an impending change in the application or file-sets. It would also be useful to assess how this fits with the task of activating new interface elements, or deactivating them. Our special object approach, being less disruptive than a mode change, may be better.
These counts, our observations and participant comments indicate that that dwell poses a problem. While this aspect of the design was intended to avoid accidental start or update, we need to revisit it, or provide feedback that indicates the need to dwell to activate this function. H2 Ease of Use
This aspect is clearly linked to learnability since a user must learn to do a task before ease of use can be assessed. The dwell problem also affects ease of use. In addition, our observations indicate that some participants had difficulty remembering which gesture to use in different parts of the interface, with one trying to drag new interface tools, instead of tapping.
Our third contribution is in the design, implementation and usability evaluation of the special object approach. Overall, this indicates that Switch is highly learnable, easy to use and users will be able to recover from errors. The evaluations clearly indicate that there was a problem with the dwell for Start and Update, but not for the Exit as well as some confusion for two participants on when to tap, drag or dwell. Before we can draw broad conclusions about this, we need to be aware that this aspect of our work is deeply affected by the underlying Cruiser framework [2] and the particular applications we used in the evaluations, based on Focus [3] which uses a dwell for the file search. This posed no problems for the participants in the study. We consider that a somewhat shorter dwell for Start and Update may address the problems. However, we also can return to the decision for the use of dwell in the design, to reduce the chance of accidentally doing these actions. The current interface does not enable users to return to the state of the table as it was before these actions. So, one important possibility to explore is to support an undo operation, perhaps via a history of key states of the table, as is already available in Focus [3].
The questionnaire comments also highlight the problem with the dwell for enlarging the icon, and activating Start and Update. It is unclear why participants had more difficulty with this in some parts of these, notably Start and Update, but not for the Exit. H3 Error Recovery
The 8 participants experienced 32 errors (excluding one due to a failure in the underlying software), 29 during exploration and 3 due to accidental actions in later use. They recovered from 30 of these without assistance. The other 3 have already been discussed and relate to the problems in learning about the need to dwell long enough on Start and Update. In addition, Task 7 was designed to test another form of error recovery. It told participants to start an application with an incorrect configuration, simulating a user unintentionally doing this. All participants understood how to recover and did so with just one participant needing to explore. Overall, this indicates that error recovery was good except in the first use of the interface elements involving the dwell.
Important aspects of the design of Switch differ radically 103
ITS 2010: Applications
November 7-10, 2010, Saarbrucken, ¨ Germany
8. A. Lucero, D. Aliakseyeu, and J.-B. Martens. Augmenting mood boards: Flexible and intuitive interaction in the context of the design studio. In TABLETOP, pages 147–154, 2007.
from interfaces on current desktops. The Switch interface reflects the somewhat specialised nature of tabletops in that its design favours a small number of file-sets, set-up options and optional objects. This simplifies the interface, avoiding the need for a scrolling mechanism or an approach that presents only partial information at one time; this avoids potential demands on user recall and ensures all relevant information is visible at one time. It would not work well for the arbitrarily large number of files, options and objects typically available at desktops.
9. Microsoft. Experience Microsoft Surface. URL: http://www.microsoft.com/surface/, June 2009. Last Visited June 24, 2009. 10. Microsoft. TechNet: What is new in Microsoft Surface 1.0 SP1? URL: http://technet.microsoft.com/enus/library/ee692113(Surface.10).aspx, 2009. Last Visited June 19, 2010.
As tabletops become more general devices, they need to provide a suitable set of core facilities for general computing. This is the first report of exploration of the design space to bring the core facilities for general computing that are present on desktops and some other computing devices to the tabletop environment. The current Switch interface is usable and provides useful facilities. Our key contributions are: identification of the need for exploration of the design of interfaces supporting core facilities for general computing at tabletops; identification of a functionality that is critical for the long term and constitutes an important starting point for research at this stage; exploration of a set of quite different interface approaches, each being evaluated with discount usability techniques; implementation of the most promising of these as the Switch interface; and a qualitative think-aloud evaluation of its learnability, ease of use and error recovery — all critical aspects of usability for tabletops.
11. W. Newman and P. Wellner. A desk supporting computer-based interaction with paper documents. In Proc. CHI ’92, pages 587–592, New York, NY, USA, 1992. ACM. 12. J. Nielsen. Finding usability problems through heuristic evaluation. In Proc. CHI ’92, pages 373–380, New York, NY, USA, 1992. ACM. 13. J. Nielsen. Usability engineering. Academic press, 1993. 14. J. Nielsen. Usability inspection methods. In Adj. Proc. CHI ’94, pages 413–414, New York, NY, USA, 1994. ACM. 15. J. Nielsen. Why you only need to test with 5 users. URL: http://www.useit.com/alertbox/20000319.html, March 2000. Last Visited October 28, 2009.
ACKNOWLEDGMENTS
We gratefully thank our experiment participants for their time, and our reviewers for their helpful feedback. This work is partly funded by the Smart Services CRC.
16. NUITEQ. Snowflake Suite TouchCore. URL: http://nuiteq.com/products/snowflakesuite.php, June 2010.
REFERENCES
1. T. Apted, A. Collins, and J. Kay. Heuristics to support design of new software for interaction at tabletops. In CHI Workshop on Multitouch and Surface Computing, 2009.
17. R. Pike. Acme: a user interface for programmers. In Proc. WTEC’94, pages 18–18. USENIX, 1994. 18. D. Pinelle, T. Stach, and C. Gutwin. TableTrays: Temporary, reconfigurable work surfaces for tabletop groupware. In TABLETOP, pages 41–48, 2008.
2. T. Apted, J. Kay, and A. Quigley. Tabletop sharing of digital photographs for the elderly. In Proc. CHI 2006, pages 781–790. ACM, 2006.
19. D. M. Ritchie and K. Thompson. The UNIX timesharing system. Commun. ACM, 17(7):365–375, 1974.
3. A. Collins, T. Apted, and J. Kay. Tabletop file system access: Associative and hierarchical approaches. In TABLETOP, pages 113–120, 2007.
20. A. Silberschatz, P. B. Galvin, and G. Gagne. Operating System Concepts. John Wiley & Sons, Inc, 7th edition, December 2004.
4. A. Collins, A. Bezerianos, G. McEwan, M. Rittenbruch, R. Wasinger, and J. Kay. Understanding file access mechanisms for embedded ubicomp collaboration interfaces. In UbiComp, pages 135–144, 2009.
21. SMART. SMART Technologies. http://smarttech.com/, June 2010.
5. B. Hartmann, M. R. Morris, and A. Cassanego. Reducing clutter on tabletop groupware systems with tangible drawers. In Adj. Proc. UbiComp 2006, 2006.
URL:
22. D. C. Smith, C. Irby, R. Kimball, W. L. Verplank, and E. Harslem. Designing the Star user interface. In Readings in Human-Computer Interaction: A Multidisciplinary Approach, pages 653–661, San Francisco, CA, USA, 1987. Morgan Kaufmann.
6. J. Johnson, T. Roberts, W. Verplank, D. Smith, C. Irby, M. Beard, and K. Mackey. The Xerox Star: a retrospective. Computer, 22(9):11–26, 28–29, Sep 1989.
23. J. Somervell, S. Wahid, and D. McCrickard. Usability heuristics for large screen information exhibits. In Proc. IFIP TC13 International Conference on Human Computer Interaction, pages 904–907, 2003.
7. D. Leithinger and M. Haller. Improving menu interaction for cluttered tabletop setups with user-drawn path menus. In TABLETOP, pages 121–128, 2007. 104
