SCHOOL OF INFORMATION TECHNOLOGIES
CORE OPERATING SYSTEM ELEMENTS FOR EMBEDDED INTERFACES
TECHNICAL REPORT 664
ANDREW JOHN CLAYPHAN AND JUDY KAY
Core Operating System Elements for
Embedded Interfaces
Andrew John Clayphan and Judy Kay
School of Information Technologies University of Sydney Sydney, Australia, 2006 ajc,[email protected]
Abstract. The growing availability of relatively low cost hardware for Single Display Groupware (SDG), in the form of tabletops and large wall displays, is one of many emerging elements in a person’s digital infras-tructure. This creates many opportunities and creates new user interface challenges. An important one of these, that has had little attention, is the nature of the user interface for core operating system functions. This should support user tasks such as authentication, finding, and organizing files, coordinating the tabletop and the rest of each individual’s digital ecosystem, supporting collaboration, starting applications, and customiz-ing the appearance of the tabletop.
This paper presents an analysis of the nature of tabletop interaction, identifying its distinctive characteristics and uses. Shown is how this affects the core operating system functions needed by tabletop users, both in terms of the ways this differs from desktops and in terms of how this defines the character of the interface to the functions. The key contribution is to provide a foundation for the principled design of user interfaces to support core operating system functions at tabletops.
1
Introduction
We are seeing the emergence of a range of new interaction devices that offer the promise of a rich digital ecology of devices for user interaction. Among classes of widely available devices are the smartphone, a personal but powerful device, the laptop and desktop computers, also increasingly powerful personal devices. We are just beginning to see a new class of device added to a person’s digital ecosystem. These are the tabletops, also called single display groupware devices. These create new possibilities for people to work together at a single device [62]. This makes them fundamentally different from devices such as a desktop.
Reflecting the distinctive nature of tabletops, we have already seen consider-able research on many aspects for supporting tconsider-abletop interaction, including, for example, exploration of natural gestures for touch interaction [17,69,71], territo-riality that affects management of the space on the table [45,58,65], interaction in
the space above the table [23,32], new approaches to creating menus [29,30] and ways to integrate use of physical objects [11,12,21]. However, there has been very little work to explore the nature of the fundamental facilities, the core concepts underlying the interface to the operating system that need to be available to support the effective use of tabletops. With the fast emergence of new tabletop hardware, supporting natural interaction, particularly touch-based interaction, it is timely to explore this issue. This paper tackles the task by a careful analysis of the nature of tabletop interaction, the aspects that distinguish it from inter-action with other devices such as desktops, and then reasoning about the core concepts that should be supported within the interface to the operating system when using tabletops.
Fig. 1. The role of core concepts for the user interface to the operating system
Figure1illustrates the notion of the core user interface to an operating sys-tem. The figure shows the actual operating system at the bottom. (Of course, below this is the actual hardware). At the top is the layer that the user actu-ally sees; in the case of desktops, this is generactu-ally the interface provided by the windowing system. The middle layer, the core concern of this paper, is the con-ceptual elements of this user interface which represent applicable things and actions, which we call Thacts. So, for example, a user coming to any new desktop system would expect a file system which makes it possible to work with files, where these might be images, documents, spreadsheets, web pages and many others. The user would also expect to be able to do tasks, such as starting an application, copying, renaming and deleting files. Current windowing systems are very alike in terms of both the upper two layers of the figure on all widely used desktops [40]. While this means that users of tabletops are likely to be fa-miliar with a desktop user interface paradigm, the significant differences between desktops and tabletops mean that we cannot assume that this will work well for tabletops. Notably, we cannot expect the Thacts of the desktop user interface to support the special and different aspects of the tabletop.
Table1identifies three key classes of use of tabletops. The first row represents the use that has dominated research in tabletops, where the tabletop is assumed to be available for any user. The final row of Table 1 indicates the opposite extreme where the tabletop is for personal use in a restricted space. This has had little attention in research, although there has been one reported example of long term personal use [67] based on the Windows desktop interface and this pointed to major limitations of that way to use a tabletop.
Class Example
Public Space Kiosk
Restricted Group Use Group planning, Classroom, Board Room, Home Restricted Private Space As a Desktop
Table 1. Distinctive classes of use of tabletops
The middle row describes an important emerging role for a tabletop, where it is embedded within a restricted space, for use by the people in that area. So, for example, an important role of the tabletop in a home would be to support the needs of the people who live there. We are already seeing many schools with interactive whiteboards that could be easily used as a tabletop. In this case, if the tabletop is in a room that is primarily used by a single class of students, it should be able to support collaborative tasks by small groups within that class. This class of use for tabletops is likely to be particularly important as it exploits the particular affordances of tabletops to support small group work, at an interface that is conveniently located in the environment used by the group. To date, reflecting the rather new nature of tabletops and the many associated interface challenges, there has been relatively little work on this role and even less exploration of the core interface elements of the operating system interface they should offer, with some notable exceptions [18,33,46,47].
This paper aims to create a foundation for the design of effective interfaces for tabletop interaction by identifying the core operating system elements that are needed for the range of roles for which tabletops offer most promise, no-tably the restricted group use in the middle row of Table1. We drive our work with an analysis of; the nature of tabletops and their place in the user’s digital device ecosystem; the distinctive classes of use and Thacts. This is followed by discussions and a conclusion regarding the elements we identify as important.
2
Analysis of the Nature of Tabletops and their Place in
the User’s Digital Device Ecosystem
Our goal is to identify the Thacts for tabletops. We start by analyzing the partic-ular characteristics of tabletops, their relationship to other devices that people use, their important similarities to these as well as their differences. In particular, we clarify key differences between tabletops and the extremely well established and widely used desktops. This is important for informing analysis of the ways that the Thacts for tabletops might maintain consistency with the familiar desk-top and where this would jeopardize the effectiveness of the tabledesk-top, by denying the full potential of its particular affordances.
In Table2, the columns present a set of key classes of devices in what we call the user’s digital device ecosystem, which is the set of digital devices a person may use. The rows describe the dimensions we use to capture the different nature of these devices.
Dimension
Tabletop Wall Desktop Laptop Tablet Mobile
of nature Phone Group X X 7 7 7 7 Use Private 7 7 X X XX XXX Ownership Mobility 7 7 X X XX XXX Keyboard/ 7 X X X 7 7 Mouse Other, X 7 7 7 7 7 Physical Artefacts Large XX XXX X 7 7 7 Screen Size Reach X X 7 7 7 7 Issues Legend
X feature is present, more ticks refers to level of emphasis 7 feature is missing or minimal in nature
Table 2. Comparison of key characteristics of devices in a person’s digital ecosystem
The first column shows tabletops, our focus. Next we have large wall dis-plays because they share some of the characteristics of tabletops. The remaining columns (desktops, laptops, tablets and mobile phones) represent classes of de-vices that are already in wide use. These are important for several reasons. First, many people are likely to be familiar with some form of these. So, the design
of tabletop interaction should take account of the user’s existing knowledge and expectations, based on these devices, especially when the tabletop is to be used in conjunction with them. We now discuss each row, analyzing the ways that it helps to define the distinctive nature of tabletop interaction.
The first row, group use, is a fundamental dimension, characterizing table-tops. While there has been some study of a single user with a tabletop (for example, [67]), the potential to support small-group collaboration is one of its defining features. Indeed, the alternate name, single-display groupware, reflects this characteristic. As the table shows, it shares this characteristic with large wall displays and all the other classes of devices differ on this aspect, since all are primarily for use by a single user at a time.
The second row, private ownership, is closely related to the first but takes the notion of private use further, to private ownership. The table shows the mobile phone is a particularly personal, privately owned device. The desktop, laptop and tablet are also shown as privately owned, but we acknowledge that this is at a weaker level. Certainly, desktops and laptops typically support the notion of login, with multiple user accounts. In spite of this, many of these devices are almost exclusively used by a single person.
The third row, mobility, distinguishes the tabletop as an embedded device that is fixed in one location. This follows from its size. If the tabletop is to be large enough to be used collaboratively, it needs to be large enough for sev-eral people to sit comfortably around the screen. This makes it inherently less portable than any of the personal devices, particularly the phone. The laptop may be better seen as portable rather than mobile [70]. Importantly, the mobility of devices like laptops, tabletops and mobile phones suggests that the user may want to be able to use them in conjunction with a tabletop.
The fourth row, keyboard/mouse reflects the different nature of interaction, with touch being part of the vision for tabletop interaction. While many table-top systems have keyboards, both on the table interface (for example, [34,35]) or as physical keyboards (for example, [20,24]), tabletops generally favor direct interaction with the tabletop surface. This difference has been the focus of much research in exploring how to effectively manage it.
The fifth row indicates the role of other, physical artefacts, such as paper documents, objects such as cups or jars, passports and mobile phones. This is a somewhat subtle aspect; it is not entirely obvious that the tabletop should operate in conjunction with such artefacts when the other devices do not. But the literature certainly includes considerable work exploring this dimension (for example, [15,22,26,27]). Part of the reason follows from the ways that people currently use ordinary tables, putting things on them. Another part is due to the ease with which vision-based tabletop technology can readily “recognize”
some objects. But broadly, it is strongly influenced by the other dimensions of the nature of tabletops, especially that they are fixed, rather than mobile. This means that it is practical to add hardware and software to support recognition of objects, capture the content of paper documents and integration of other phys-ical devices such as knobs [12,22,43]. Yet another reason for integrating other physical artefacts follows from the challenge of designing effective interaction support within the limitations imposed by the lack of a mouse and keyboard. And, another reason for this follows from their nature as a device fixed in one place; people may bring devices such as mobile phones and other materials for their collaboration to that place.
The sixth row, screen size, reflects working area. Tabletops have large screens which makes it feasible for multiple users to work at device at the same time. Importantly, with existing hardware, the large screen is not necessarily matched with the capacity to achieve high resolution as well [51]. One important ap-proach to this issue is to create very high resolution on large tables [8,64]. For most hardware, size and resolution are competing goals, with the former often winning the trade-off.
The last row, reach issues, are formed from considering how a person interacts with a device. The large size of tabletops, combined with the goal of direct interaction, without a mouse, creates the need to consider a person’s reach. In this respect, the tabletop and large wall display have to deal with the fact that the user may not be able to reach parts of the display area that hold artefacts that they wish to use. The desktop and laptop avoid this because they make use of a mouse (and if the user did need to touch the screen, it is within reach). The tablet and mobile phone avoid this problem because the screen is small, reflecting their mobile nature.
3
Analysis of Distinctive Classes of Use
There are useful analyzes that combine those in Tables1 and2. Figure 2taken from Ackad [1] summarizes the relationship between embeddedness in public versus restricted spaces, against the degree of specialization versus general pur-pose use.
Revisiting Table1, a tabletop has a number of roles to offer, and the one that holds most promise is restricted group use. This points to the need to explore the effect of the distinctive aspects of tabletops for this use, as identified in Table2: collaborative use by a group of people, creating the need to consider different orientations and problems with clutter; the context of the fixed location; direct input without a keyboard or mouse and problems associated with reach.
Fig. 2. A map of the specialization and user space of everyday technology
Collaborative Interaction
A key goal of tabletops is to facilitate and support collocated collaborative in-teraction. This requires the support of multiple parties either working together or separately at an interface. Given current hardware limitations the design of tabletop software should aim to support small groups and exploit current as well as any likely hardware possibilities.
Context of Use
Restricted group use needs to be designed such that there is no overarching own-ership on the table. This is to facilitate group use rather than private ownown-ership.
Input Interaction
The tabletop must accommodate natural interaction for it to be used. As a key-board and mouse may not exist, elements designed need to be receptive to the input methods available. In this case, this is touch interaction, and thus appro-priately sized target zones should be set up to facilitate input.
Reach
As the table gets larger it is necessary to understand that not all areas of the table may directly be accessible by a user. In this case, considerations need to be made in the design of interfaces to counter this issue.
Orientation
As the point of restricted group use to is encourage and facilitate interaction, artefacts should have the ability to be situated and oriented appropriately, such that all users can take in information being displayed.
Clutter
Clutter arises when several elements cover the tabletop making it hard to com-plete tasks. This issue may arise from the need to view a lot of information and when there are multiple users are working at a tabletop. Mechanisms are required to reduce or remove this issue.
4
Embedded Devices
Embedded Devices are elements that are fixed (or have become fixed) in an environment. An environment defines the access for individuals and the tools present. An embedded device can be optimized to support functions required of an environment.
From Table 1, the vision for tabletops is focused on restricted group use. The tabletop provides an interface that acts as the link allowing individuals and groups to carry out tasks. With restricted groups, assumptions are made to the types of people that will use the tabletop. These assumptions can then be factored into the design of the interface in addition to assumptions about the environment to support the particular user interests. This is illustrated with a few examples:
– Research Lab: facilities are required to support meetings.
– School : elements to encourage and enhance activity between students are required for teaching lessons.
– Corporate Showroom: functions to display product information and the ability to capture orders are required.
The tabletop is part of a user’s digital ecology. This is one part of a series of devices and technologies of a pervasive computing environment. It follows from the nature of embedded, that particular actions can be realized through the design of the environment around the tabletop. As a tabletop will not move, it makes sense to allow for specialized hardware such as cameras to be set up to augment the pre-existing tabletop interface.
5
Analysis of Thacts for Embedded Tabletops
The focus of the tabletop is of the role of restricted group use which is the middle row of Table 1. The characteristics of tabletops, as captured in Table2
are considered and then the Thacts that should be supported in the default environment of tabletops are identified. Things are identified first and then the Actions on them.
5.1 Things and their organization
Table3 summarizes both the basic Things and the structuring mechanisms for collections of them. It begins with users; this follows from the collaborative na-ture of tabletops. They need to support multiple users. As we focus on embedded tabletop, there should be some people who are regular users, who are “known” to the tabletop, because they normally occupy the place the tabletop is located, where this may be a workplace area, a classroom or a home.
Things Brief Description Literature
Users People within the space the table resides in. [24]
Digital Artefact (DA)
Digital information element, e.g. email item, image, video.
[5,21]
DA
Representative
Representation of a DA, e.g. icon. –
Shared Space Places where Thacts are available to other users. [59] Private Space Places where they are not available to other
users.
[59]
Digital Ecosystem
Arbitrary other devices, DA stores people use, e.g. phone, cloud and web.
[15,31,55]
Physical Artefacts (PA)
Physical objects for use with the tabletop. [12,26,27]
Controller Interface element for performing actions. [12,53,69]
Long term store of DAs
DA persistance between sessions of use. [24]
Hierarchical Structure on DAs
Abstract organization of DAs. [13]
Tagged
Structure on DAs
Abstract organization of DAs. [21]
Context Collections of DAs and Controllers in a state, at a time.
[24]
Settings Configurable aspects of the above elements. [1]
Table 3. Summary of Things and their organization. Bold indicates elements which have important differences from conventional desktops. The final column gives examples of work concerning this aspect.
Next in Table3is the notion of a digital artefact and its representative on the tabletop. This tightly coupled pair of concepts is not different from other devices, such as desktops. However, it combines the generalized notion of a “file” as well as any interactive element, such as an application. It is noted that a “file” is re-ally concerned with low level implementation rather than a concept in a mental model [41,25]. “A mental model is an explanation of someone’s thought process about how something works in the real world.”1. So taking email as an example,
in some systems each mail item is kept in a separate file while other systems use one file to hold all the mail items in a folder; from the user’s point of view, this
1
is not important and is not normally visible. In both cases, the user is supported in thinking about each mail item as a separate digital artefact. As indicated in the table, this may be any digital information element that makes sense to the user and it may include active artefacts such as movies. A file system is one core constituent of an operating system [50] and underlying file systems impose limits on the nature of digital artefacts. The notion of “DA representative” describes what the user can see at the interface; in terms of the user’s mental model, this is a representative of the more abstract digital artefact. So, for example, in the case of a movie that is not playing, the DA representative may be a simple static icon.
The next pair of rows in the table relate to shared and private spaces. These notions are particular to tabletops and follow from their use for collaboration. Users will, at least at some time, have the need for private spaces (such as ma-nipulating their own content) and that should be supported [59].
The digital ecosystem for embedded devices is particularly important and represents a shift from desktops. Since people come to a tabletop to work to-gether, that shared device will only be effective if people can, as needed draw upon their private information stores and ensure that the results of their work are available for private use later. There has already been some work exploring the use of carried mobile devices [15,55] for this role and for providing a control-ling interface that protects private information [42] as well as the use of physical artefacts to link to cloud resources [31,34].
The role of physical artefacts is a novel aspect of tabletops. As already noted they can serve as controllers and as a connection to users’ digital ecosystems. Indeed, existing guidelines for tabletop design explicitly calls for integration of physical artefacts [57]. Notably, users may expect to be able to gracefully inte-grate physical documents with digital ones at the tabletop [21].
A controller provides an interface for digital artefacts to be acted upon re-flecting user expectations. It can take several forms:
1. Gestures, have been a focus of research on tabletops (for example, [17,38,71]). Gestures are typically based on actions of one or more fingers, but can involve the hand [69], a stylus or any other physical artefact, such as a phone [53].
2. Menus, are conceptually like those on the desktop windowing model, so make use of the same mental model [3,4].
3. Special digital objects, which appear on the tabletop as an icon and this, too, has been used on desktops, for example where a printer icon is used for printing by dragging documents onto it.
4. Special physical objects, which are conceptually similar to their digital counterparts, but have a special role in tabletops, as reflected in the body of work that involves tabletops and tangibles [12,26,27].
The next row in the table refers to the long term store of DAs. It follows that digital artefacts may persist after a session, having the ability to be used again at a later point in time.
The next two rows look at the structure of digital artefacts at a tabletop [13,21,24]. All are common to desktops (although tagged approaches are less widespread) and so we conclude that a user will expect them to be available at a tabletop.
The next row, context, is particular to tabletop interaction. It refers to the complete state of the environment, including all visible and stored digital arte-facts at a point in time, where this includes their organization at that time. This seems particularly important for enabling a group of people to restart a collab-orative task, with the table in the same state as when they last met to work on it [24]. It will also be important for reverting to an earlier state, for example when one of the people at the table performs an action that alters the state in ways that others at the table were still working on.
The last row, settings defines any of the variable aspects of the above ele-ments and is pivotal to application management [1].
Overall, this analysis points to several Things that are important for the effective use of embedded tabletop interfaces. Most of these have had little at-tention and certainly, the current state of research does not provide a coherent basis for creating software that will enable users to think and work in terms of these aspects.
5.2 Actions involving digital artefacts
The analysis of the Things, focusing on the digital aspects identified in Table3is now refined. This section does not discuss controllers as they are the mechanism for achieving the Actions. While the analysis is limited to digital artefacts, it should be noted that physical artefacts are partly covered under the digital ecosystem.
Actions associated with users
Table 4 lists three actions to support multiple users at a tabletop. Ideally a tabletop will identify each person present as a basis for tailoring the experience, for example, ensuring the availability of the digital artefacts they use. However, common tabletop hardware [34,48,61] has poor support for automatically as-sociating touch with a person. A notable exception is DiamondTouch [35]. A lesser, but useful approach is to at least provide software support for users to manually identify themselves, for example Hunter [24] provides a set of images representing known users.
Actions Brief Description Literature Identification Determining the people present and linking
individ-uals to actions at the interface. Identification is af-fected by hardware support.
[24,35]
Authentication Verification of the identity of a person. [28,54,55] Group
Coordination Support
Support for controls such as sharing and ownership. [9,24]
Table 4. Summary of Actions associated with users
Identification
Identification is the act of recognizing and naming an entity. Identification in this section refers to users rather than digital artefacts. Being able to identify users allows actions to be personalized. While most systems have failed in the hardware to support proper automatic identification, it is still an incredibly im-portant aspect to tabletop research.
Authentication
Authentication is the “verification of the identity of a person”2. Given the large
screen of a tabletop, the physical security of the place can partly restrict who gains access to the tabletop. One has to assume that people within the space can make use of the tabletop. There are particular situations which demand au-thentication, for example connecting to a remote service. This poses a problem. It is not straightforward to enter a password at a tabletop as it is a public space. Some work to address this includes: Schoning’s [54,55] use of biometrics, RFID tags and mobile phones and Kim’s [28] exploration of inputting passwords on the tabletop itself, each with limitations in terms of time and effort. After examining the literature, mobile phones [53] have seen to be a viable option for entering sensitive information as the device is both private and personal to each user.
Group Coordination Support
There are a full range of activities that may help people collaborate more effec-tively at the tabletop [24]. In many cases, it is valuable to create mechanisms that support team work [52] such as visualizations of group activity, as in [9,66]. Another dimension of support for group work is making use of ideas from ex-isting tools for collaboration, such as Trac3, particularly its support for issue
tracking and version control.
2
http://foldoc.org/authentication
3
Actions on digital artefacts, and groups of DAs, and their represen-tatives
A summary of actions on individual and multiple digital artefacts is presented in Table 5. The table is split into seven parts each grouping similar actions. Each part is separated by double horizonal lines. The first part is concerned with the manipulation of DAs through move, rotate and resize. The second part is con-cerned with the concept of copying on a tabletop. The third part is concon-cerned with the removal of artefacts through hide and delete. These three parts collec-tively manipulate digital artefacts on the tabletop. These actions are present in many systems (such as [6,8,34]). The fourth part deals with the transformation of digital artefact representatives to digital artefacts themselves, such as enlarg-ing an icon (the representative) to reveal the digital artefact. The fifth part deals with organizational structure. The sixth part deals with browsing artefacts and the last deals with the concept of searching on the tabletop.
Manipulation of Digital Artefacts
People create, use, access and modify digital artefacts on the tabletop. The famil-iarity of desktop window managers such as Windows, Linux and the Macintosh motivate expectations for these primitives on tabletop systems. A desktop win-dow manager currently provides mechanisms to move, copy, hide (minimize) and delete files. This is indicated by the “Builds on the Desktop Mental Model” col-umn in Table 5. The ticks indicate Desktop experience meaning they are likely to be familiar with these concepts. The crosses indicate actions specific to the Tabletop. Many of these additional primitives are due to the collaborative na-ture of tabletops, this is shown on the rightmost column of Table5.
An explanation of the manipulable actions:
– Move: to change location. Move is essential because people need access to artefacts independent of where they are relative to the tabletop. Even with move, people still may not be able to reach DAs at distant parts of the table.
– Rotate: to turn around a point. Rotate is important for tabletops because people may be situated differently a tabletop. This creates many cases where it is useful to re-orient a DA (or its representative). Re-orienting an artefact allows it to be viewable at the right orientation. A tabletop is unlike a desktop in this respect. Users of a tabletop may move around. Tabletop interfaces should support this. In this case, also, reach may be an issue.
– Resize: to change dimension. When a group of people at a tabletop focus on particular DAs, it may be helpful to make these quite large. Conversely it may also be useful to make DAs small to minimise clutter and shift focus to other DAs.
Actions Brief Description D.M.M.4 Lit.5 Collab.6 Move DA Alter the location of DA(s), or their
representatives.
X [19] [49] Rotate DA Alter the orientation of DA(s), or their
representatives.
7 [7,19] [49] Resize DA Alter size of DA(s), or their
representatives.
X [7] [49] Copy DA Create multiple copies of DA(s) for
individual use.
X [7] [36] Copy linked DA Create multiple copies of DA(s) for
collaborative use.
X [6,7] – Hide DA Hide DA(s), or their
representatives.
X [6] [7] Delete DA Remove DA(s), or their
representatives.
X [34] [36] Transform DA
representative to DA
Convert a model into an artefact, such as starting an application.
X [1] –
Group DAs Any form of grouping of DA representatives.
X [44,56] – Alter hierarchical
structure
Creating new nodes, moving DAs within the structure.
X [6] – Alter tags Add, delete or modify tags on DAs. 7 – [21] Hierarchical
Browsing
Matches existing mental model for desktops. E.g. Windows Explorer, Mac OS X Finder.
X [13] –
Tagged-based Browsing
Matches existing mental model for many applications. E.g. Google Desktop
7 – [21]
Search on table Matches existing mental model for desktop search.
X [14] [37,39]
Table 5. Summary of Actions associated with DAs and their representatives
– Copy: to reproduce. The table distinguishes between two types of copy. The first type is “copy DA”. Making a copy of a DA duplicates the orig-inal underlying system object. The copy of the underlying object brings about a new digital artefact to the table. Each copy is independent of one another. A way of thinking about this is to think of the operation like that of a physical photocopier, where the original and copy are different products. The second type is “copy linked DA”. Making a copy of a linked DA makes a copy of the DA but any action performed on the original or copy is reflected on all other copied instances. An example is a Google
4 Actions that build on the a Desktop Mental Model 5
Literature
6
Maps linked copy. When the original or copied content is interacted with, for example zoomed in, other linked instances follow suit in the operation. The implementation of copy in literature has seen various forms. For ex-ample Apted [7] uses a special photocopier object to create copies whilst Morris [36] has used a collaborative pull-apart team gesture for copying. – Hide: to conceal from sight. The ability to hide a digital artefact needs
to be considered carefully at a tabletop. A tabletop can have a number of digital artefacts and the ability to hide any artefact allows for the management of clutter and user focus for the remaining artefacts present. – Delete: to erase or remove. Delete needs careful design for tabletops, espe-cially if it is irreversible. Several approaches explored include: the necessity for people to agree on delete [36], the placement of a red cross (or similar icon) at the top of an artefact [34] and the use of a special object to denote deletion such as a black hole [7].
Transformation of a digital artefact representative to a digital artefact
On a tabletop a digital artefact may be represented directly exposing the under-lying artefact or it drawn through a representative. A representative is an item that acts as a placeholder for the actual artefact. On a tabletop this is commonly seen with icons being a compact representation of the real artefact. Upon ma-nipulation of the icon, such as enlarging the representative is transformed into the artefact itself. Another example is that of opening an application. Often a label will take the place of the artefact and upon selection transforms into the program.
Organization of digital artefacts
Organization covers the last three parts of structure, browsing and searching.
Digital artefacts in a system will often need to be co-ordinated into a unit or structure. This means that artefacts may be placed together in some way. A few methods that have been investigated include piling and grouping. Piling is explored by Agarawala [2] where artefacts are overlaid on top of each other similar to a stack of magazines in a Doctors office. Grouping is explored by Scott [56] and Trent [6] who look at storage bins for artefact aggregation. Similar work is explored by Pinelle [44] who utilizes flat trays to place artefacts together.
In a tabletop system the structure of artefacts is not normally revealed to users. From the users perspective they see digital artefacts (or their represen-tatives) on an interface and interact with them. An interface can expose its underlying structure (such as through visualization) but is under no obligation to do so. This means primitives for creating new nodes and manipulating arte-facts are not tied down to any one particular structure.
A tabletop gives rise to an expectation to browse information. This requires an ability to view available data sets and navigate through context. Browsing can take many forms on a tabletop. Most common on the desktop is
hierarchi-cal browsing, where artefacts are linked together in a tree like structure. This model has been explored on the tabletop by Collins [13]. Another mechanism is tag based browsing. This is where artefacts are given meta data describing characteristics that feed into actions to retrieve relevant content from stores. An example is Hartmann’s [21] work on meta data group tagging. Similarly Collin’s [14] work explores artefact retrieval through associative access. This type of ac-cess locates similar content from both the tabletop and devices attached to the system such as mobile phones.
With the collaborative nature of a tabletop, new ways to locate content are required. In the literature, work by Morris [37] and Paepcke [39] have looked at collaborative search, comprised of boolean operators from different individuals to form search queries.
Actions associated with personal and shared spaces
Actions associated with spaces are explored in Table6. It is important to under-stand the difference between types of spaces. Some actions are personal, meaning that the action is available to only that user whilst other actions are group based, being available to many or even needing many people to complete the action. Table6is split into three parts. The first focuses on individuality, the second on collocated group space and last on remote collaboration.
Actions Brief Description Literature Individual What actions are specific to a user. [24] Private action on
personal mobile device
Make use of private device to perform private actions at table.
[55,60]
Group What actions are applicable to a set of users together.
[58] Coordination
Support
What is required to help people out. [10,59,57,58] Remote
Collaboration
What is required for supported where participants are not collocated.
[10,65]
Table 6. Summary of Actions associated with spaces
Individuality
A user working on a tabletop may have operations that are specific to just that user. For example viewing a users private data set, or acting upon their digi-tal artefacts or stores. While a tabletop promotes collaboration, this should not exclude operations that are private to individuals. Besides individual actions specific to a user, a user may bring to the system his or her own device (be it physical or wireless). This allows private actions to be performed on the device which can then be relayed to the tabletop. An example taking emergence is the
use of mobile phones to enter (or view) sensitive data [60] which is otherwise cumbersome at a public tabletop interface.
Collocated Group Space
There are often actions on a tabletop that are applicable to a set of users. These refer to how the space (or surface) of the tabletop is shared between participants. This requires an understanding of how a tabletop can enable many different types of actions to be performed concurrently. This has resulted in literature exploring how artefacts can be shared in tabletop environments. Seminal work is by Scott [58] who examines issues of territoriality on the tabletop.
Remote Collaboration
Remote Collaboration allows a tabletop is extend past a collocated space. This is where individuals are able to work on their own tabletop but mechanisms exist that promote collaboration where neither participant is physically next to each other. By using cameras and other technology, this research has been the focus of many groups. For example, the work by Tuddenham [64] examines high resolution tabletop prototyping for mixed-presence tabletop applications. This is achieved by superimposing shadows of remote participants onto local tables. Similarly work on remote collaboration is explored by Brave [10], Tang [63] and Wilson [68].
Actions to move DAs and groups of DAs within the digital ecosystem
The ability for artefacts on a tabletop to move between devices in a digital ecol-ogy increases the usefulness of tabletop systems. Table 7looks at these actions in three parts: export, import and synchronization.
Actions Brief Description Literature Export DA Transfer DA(s) to other parts of digital ecosystem – Import DA Transfer DA(s) from other parts of digital
ecosystem
[13,34] Synchronise DA Ensure DA(s) kept consistent across other parts of
digital ecosystem
–
Table 7. Summary of Actions related to digital ecosystem
Export of Digital Artefacts
A tabletop can be used as the medium upon which artefacts are discussed. Upon discussion it may be important to the user (or users) to take the content they interacted with, with them. Physically moving a tabletop is not practical due to size. Allowing artefacts to be transferred to other devices such as laptops, tablets and phones or emailed to a location allows the experience that was had at the tabletop to travel with the user. So far, there has been minimal research
in the area of exporting digital artefacts, although some groups have started to look into the use of mobile phones in conjunction with a tabletop.
Import of Digital Artefacts
Bringing content to the tabletop removes the restriction of being limited to what is locally packaged with the tabletop. Importing has been visited in the work of Microsoft Surface [34], where external devices can be accessed through Blue-tooth technology to retrieve the digital stores of the device for display on the table. The work of importing content has also been visited by Collins [14], who examined the release of files from a mobile phone onto the tabletop. Collin’s work allowed the user to specify permissions, controlling which files were and were not allowed to be displayed on the tabletop.
Synchronization
Synchronization allows digital artefacts to be kept consistent across all other parts of a digital ecosystem. Synchronization is useful as changes reflected at one site are propagated to another. This action has yet to be the topic of much research. However, with products like Dropbox [16], which synchronizes files at different sites gaining popularity it may not be long until this area is explored.
Actions on contexts
“A context is the surroundings, circumstances, environment, background, or settings which determine, specify, or clarify the meaning of an event.”7. Table8
represents actions on contexts through the concept of navigation, saving and loading.
Actions Brief Description Literature Navigate contexts Switch between work spaces. [24] Save context Ability to save a state for later use. It needs to be
saved in such a way that the system can understand and search over.
[24,34]
Load context Ability to load a context from the past. There needs to be flexibility to find a context based on param-eters. For example at the most basic: time, then if supported: users involved, meeting meta-data, etc.
[24]
Table 8. Summary of Actions on contexts
7
Navigate Contexts
Navigation means to move between contexts. This refers to switching between different environments that are set up with tasks. In literature this is best de-scribed with the use of work spaces. A work space is an area where actions take place. Being able to navigate a work space, means to change where an action is invoked. For example, there may be a workspace for formal discussion and one for adhoc brainstorming. Each represents a different area. Hunter’s work [24] has shown that it is feasible to have work spaces on a tabletop and he provides a simple mechanism for navigation.
Save Context
Saving preserves something in time. Saving a context captures the intent and purpose of the actions at that point. This is useful, for example when a number of people meet at a tabletop to have a discussion. The results of the discussion can be recorded for later analysis. In the literature, Hunter’s work [24] allows for the state of the tabletop to be saved at any point in time, creating a his-torical log of operations. Other work includes the Microsoft Surface [34] which provides a mechanism entitled session management. This is an API designers and programmers can use to specify what an application can do in order to save a context in an application.
Load Context
Loading activates past events. This is useful when you want to restart from a given point in the past. Similarly to save, Hunter’s work [24] allows for the load-ing of a context, by givload-ing the user the ability to select any point in history to resume from. This is important because it allows you to begin your work with-out needing to go through a series of actions to get to the point where you left off.
While many tabletop systems have not featured the actions of save and load, these actions are staples in the desktop world. With time, these actions are set to emerge, enabling a greater use of tabletops.
Actions on Settings
The last part deals with settings. Settings define the parameters that can be modified in a system. The flexibility of settings allows different users in a system, fileset choice and how artefacts can react to one another. The general area of tabletop settings has seen minimal work. There is a recent paper by Ackad [1] who looks at exploring this aspect of the tabletop. He focuses on application level configuration management.
6
Discussions and Conclusion
There has been fast growth in tabletop research, with new hardware emerging, costs dropping and many researchers exploring various aspects of software and interface design that exploit the affordances of tabletops and address their limita-tions. This makes it timely to improve our understanding of the whole enterprise of designing for this important new class of pervasive computing device.
The motivation of the analysis reported in this paper was completed because it was felt that there were core concerns that needed to be addressed if tabletops are to serve in the role that have been described as restricted group use where the tabletop operates as an embedded device that should operate gracefully within people’s overall personal digital ecosystems, as well as other embedded devices such as wall displays. As hardware prices drop, this will be one of the new and important roles for tabletops.
If tabletops are to be effective in their role as an embedded device, which are primarily for use by people who normally use that space, we need to provide the core user interface functionality that is available on desktops, primarily in the form of window managers. This led to an exploration of the differences between desktops and tabletops in terms of the mental model that should be supported for the core interface functionality that is available for the tasks that operating systems enable people to do, to make their computers general purpose. We real-ized that there is no term for this mental model. The term Thacts was defined to capture this notion of the mental model, in terms of the Things that should be supported and the Actions that the user should expect to be able do with those Things. This is the first contribution: the identification of the need to explore Thacts and the creation of a term to describe this notion.
Building from the notion of Thacts, Things were analysed, selecting the most important for the distinctive character of tabletops and then the Actions were analysed on them. Drawn upon literature covered a number of conferences, in-cluding Tabletop (under its various names, now ITS), CHI, CSCW, Ubicomp and Pervasive to assess which Thacts had been explored. All have had some attention. However, it is clear that there has not been an attempt to create a coherent research agenda for creating software support for Thacts that will re-ally support the key affordances of tabletops, notably group work. The critical aspects identified for providing software that implements Thacts are:
1. support identification and, at times, authentication;
2. support group coordination over the long term over collaborative long term projects that are partly supported by tabletop interaction;
3. make effective use of digital artefacts at the table, with good support to resize, rotate, copy with both linked and independent copies of dynamic artefacts;
4. provide effective mechanisms for grouping of digital artefacts, both at the table and in long term stores that are connected to the table;
5. support for privacy when it is needed (or wanted); 6. consistent support for managing settings;
7. integrate the tabletop, as just one embedded device, within the full digital eco-system of each of the users at the table;
8. and finally to support groups’ contexts within sessions and across sessions.
All of these aspects need more research, even though, as has been reported in the analysis, some work has been found that is relevant to each of these aspects.
Tabletop computing, as a form of embedded interaction, has great potential to support new ways for people to work collaboratively. But effective support for this role will rely upon interfaces that support the Thacts identified. The primary goal, and the key contribution for this paper, is a foundation for the exploration of effective ways to create the software that supports the Thacts identified and to drive active discussion of those proposed. This paper identifies important aspects that are significantly different from desktops; so, while it is acknowledged that the mental models people bring from their desktops are important, tabletops, especially as embedded collaboration devices, are so different from desktops, that the design of software support for Thacts at tabletops must be different from that on desktops. Hopefully the identification of other Thacts is encouraged, ones that we have missed, and ones that were outside our scope (notably physical artefacts and wall displays). The need for this, is the principled foundation for building the software systems that will make tabletops an effective component of personal digital eco-systems.
References
1. Ackad, C.J., Collins, A., Kay, J.: Switch: Exploring the design of application and configuration switching at tabletops. In: Proceedings of ITS ’10: the ACM Interna-tional Conference on Interactive Tabletops and Surfaces. pp. 95–104. ACM Press, New York, NY, USA (2010), http://www.dfki.de/its2010/papers/pdf/fp165. pdf
2. Agarawala, A., Balakrishnan, R.: Keepin’ It Real: Pushing the Desktop Metaphor with Physics, Piles and the Pen. In: Proc. CHI 2006. pp. 1283–1292. ACM 3. Ahlstr¨om, D., Alexandrowicz, R., Hitz, M.: Improving menu interaction: a
compar-ison of standard, force enhanced and jumping menus. In: CHI ’06: Proceedings of the SIGCHI conference on Human Factors in computing systems. pp. 1067–1076. ACM, New York, NY, USA (2006)
4. Ahlstr¨om, D., Cockburn, A., Gutwin, C., Irani, P.: Why it’s quick to be square: modelling new and existing hierarchical menu designs. In: CHI ’10: Proceedings of the 28th international conference on Human factors in computing systems. pp. 1371–1380. ACM, New York, NY, USA (2010)
5. Aliakseyeu, D., Subramanian, S., Lucero, A., Gutwin, C.: Interacting with Piles of Artifacts on Digital Tables. In: Proc. AVI 2006. pp. 159–162. ACM
6. Apted, T.: Cruiser and PhoTable: Exploring Tabletop User Interface Software for Digital Photograph Sharing and Story Capture. Ph.D. thesis, The University of Sydney, School of Information Technologies (2008), http://ses.library.usyd. edu.au/bitstream/2123/4207/1/th-apted-2009-phdthesis-photable.pdf, Verified: 2010-08-04
7. Apted, T., Kay, J., Quigley, A.: Tabletop sharing of digital photographs for the elderly. In: CHI 2006. pp. 781–790. ACM Press
8. Ashdown, M., Robinson, P.: Escritoire: A Personal Projected Display. vol. 12, pp. 34–42. IEEE (2005)
9. Bachour, K., Kaplan, F., Dillenbourg, P.: An Interactive Table for Supporting Participation Balance in Face-to-Face Collaborative Learning. IEEE (2010) 10. Brave, S., Ishii, H., Dahley, A.: Tangible Interfaces for Remote Collaboration and
Communication. In: Proc. CSCW 1998. pp. 169–178. ACM
11. Cao, X., Forlines, C., Balakrishnan, R.: Multi-User Interaction using Handheld Projectors. In: Proc. UIST 2007. pp. 43–52. ACM
12. Cheng, K.Y., Liang, R.H., Chen, B.Y., Laing, R.H., Kuo, S.Y.: iCon: Utilizing Everyday Objects as Additional, Auxiliary and Instant Tabletop Controllers. In: Proc. CHI 2010. pp. 1155–1164. ACM
13. Collins, A., Apted, T., Kay, J.: Tabletop File System Access: Associative and Hi-erarchical Approaches. In: Proc. TABLETOP 2007. pp. 113–120. IEEE
14. Collins, A., Kay, J.: Escaping Hierarchies and Desktops: Associative, Pervasive File Access with User Control. Tech. Rep. 649, Sydney University (2010), http: //sydney.edu.au/engineering/it/research/tr/tr649.pdf, Verified: 2010-08-04 15. D¨oring, T., Shirazi, A.S., Schmidt, A.: Exploring gesture-based interaction tech-niques in multi-display environments with mobile phones and a multi-touch table. In: Proc. AVI 2010. p. 419. ACM
16. Dropbox:http://www.dropbox.com, Verified: 2010-08-04
17. Freeman, D., Benko, H., Morris, M.R., Wigdor, D.: ShadowGuides: Visualizations for In-situ Learning of Multi-Touch and Whole-Hand Gestures. In: Proc. ITS 2009. pp. 165–172. ACM
18. Haller, M., Leithinger, D., Leitner, J., Seifried, T., Brandl, P., Zauner, J., Billinghurst, M.: The Shared Design Space. In: SIGGRAPH 2006. p. 29. ACM 19. Hancock, M.S., Carpendale, S., Vernier, F.D., Wigdor, D., Shen, C.: Rotation and
Translation Mechanisms for Tabletop Interaction. In: Proc. TABLETOP 2006. pp. 79–88. IEEE
20. Hartmann, B., Morris, M.R., Benko, H., Wilson, A.D.: Augmenting Interactive Tables with Mice & Keyboards. In: Proc. UIST 2009. pp. 149–152. ACM
21. Hartmann, B., Morris, M.R., Benko, H., Wilson, A.D.: Pictionaire: Supporting Collaborative Design Work by Integrating Physical and Digital Artifacts. In: Proc. CSCW 2010. pp. 421–424. ACM
22. Hilliges, O., Baur, D., Butz, A.: Photohelix: Browsing, Sorting and Sharing Digital Photo Collections. In: Proc. TABLETOP 2007. pp. 87–94. IEEE
23. Hilliges, O., Izadi, S., Wilson, A.D., Hodges, S., Garcia-Mendoza, A., Butz, A.: Interactions in the Air: Adding Further Depth to Interactive Tabletops. In: Proc. UIST 2009. pp. 139–148. ACM
24. Hunter, S.: MemTable - Contextual Memory in Group Workspaces. Master’s the-sis, Massachusetts Institute of Technology (2009),http://fluid.media.mit.edu/ people/seth/publications/MemTable_SethHunter_Final_Compressed.pdf, Ver-ified: 2010-08-04
25. Jakob Nielsen: Mental Modelshttp://www.useit.com/alertbox/mental-models. html, Verified: 2010-10-19
26. Jord`a, S., Geiger, G., Alonso, M., Kaltenbrunner, M.: The reacTable: Exploring the Synergy between Live Music Performance and Tabletop Tangible Interfaces. In: Proc. TEI 2007. pp. 139–146. ACM
27. Kaltenbrunner, M.: reacTIVision and TUIO: A Tangible Tabletop Toolkit. In: Proc. ITS 2009. pp. 9–16. ACM
28. Kim, D., Dunphy, P., Briggs, P., Hook, J., Nicholson, J., Olivier, P.: Multi-Touch Authentication on Tabletops. In: Proc. CHI 2010. pp. 1093–1102. ACM
29. Leithinger, D., Haller, M.: Improving Menu Interaction for Cluttered Tabletop Setups with User-Drawn Path Menus. In: Proc. TABLETOP 2007. pp. 121–128. IEEE
30. Lepinski, G.J., Grossman, T., Fitzmaurice, G.: The Design and Evaluation of Mul-titouch Marking Menus. In: Proc. CHI 2010. pp. 2233–2242. ACM
31. Lonely Planet: http://www.lonelyplanet.com/press-centre/press-release. cfm?press_release_id=473, Verified: 2010-08-04
32. Lucero, A., Aliakseyeu, D., Martens, J.B.: Augmenting Mood Boards: Flexible and Intuitive Interaction in the Context of the Design Studio. In: Proc. TABLETOP 2007. pp. 147–154. IEEE
33. Mazalek, A., Reynolds, M., Davenport, G.: The TViews Table in the Home. In: Proc. TABLETOP 2007. pp. 52–59. IEEE
34. Microsoft Surface: http://www.microsoft.com/surface, Verified: 2010-08-04 35. Mitsubishi Electric Research Laboratories: DiamondTouchhttp://www.merl.com/
projects/DiamondTouch, Verified: 2010-08-04
36. Morris, M.R., Cassanego, A., Paepcke, A., Winograd, T., Piper, A.M., Huang, A.: Mediating Group Dynamics through Tabletop Interface Design. vol. 26, pp. 65–73 (2006)
37. Morris, M.R., Fisher, D., Wigdor, D.: Search on surfaces: Exploring the potential of interactive tabletops for collaborative search tasks. vol. 46, pp. 703–717. Pergamon Press, Inc. (2010)
38. Morris, M.R., Huang, A., Paepcke, A., Winograd, T.: Cooperative Gestures: Multi-User Gestural Interactions for Co-located Groupware. In: CHI 2006. pp. 1201–1210. ACM (2006)
39. Morris, M.R., Paepcke, A., Winograd, T.: TeamSearch: Comparing Techniques for Co-Present Collaborative Search of Digital Media. In: Proc. TABLETOP 2006. pp. 97–104. IEEE
40. Myers, B., Hudson, S., Pausch, R.: Past, Present, and Future of User Interface Software Tools. vol. 7, pp. 3–28. ACM (2000)
41. Norman, D.: Some Observations on Mental Models. Mental models p. 7 (1983) 42. Olsen, D.R., Clement, J., Pace, A.: Spilling: Expanding Hand held Interaction to
Touch Table Displays. In: TABLETOP 2007. pp. 163–170. IEEE
43. Patten, J., Ishii, H., Hines, J., Pangaro, G.: Sensetable: A Wireless Object Tracking Platform for Tangible User Interfaces. In: Proc. CHI 2001. pp. 253–260. ACM 44. Pinelle, D., Stach, T., Gutwin, C.: TableTrays: Temporary, Reconfigurable Work
Surfaces for Tabletop Groupware. In: In Proc. TABLETOP 2008. pp. 41–48. IEEE 45. Pinelle, D., Barjawi, M., Nacenta, M., Mandryk, R.: An Evaluation of Coordination Techniques for Protecting Objects and Territories in Tabletop Groupware. In: Proc. CHI 2009. pp. 2129–2138. ACM, New York, NY, USA
46. Piper, A.M., Hollan, J.D.: Tabletop Displays for Small Group Study: Affordances of Paper and Digital Materials. In: Proc. CHI 2009. pp. 1227–1236. ACM 47. Piper, A.M., O’Brien, E., Morris, M.R., Winograd, T.: SIDES: A Cooperative
Tabletop Computer Game for Social Skills Development. In: Proc. CSCW 2006. pp. 1–10. ACM
48. PQ Labs: G3 Plushttp://multi-touch-screen.com, Verified: 2010-08-04 49. Ringel, M., Ryall, K., Shen, C., Forlines, C., Vernier, F.: Release, Relocate,
Re-orient, Resize: Fluid Techniques for Document Sharing on Multi-User Interactive Tables. In: Proc. CHI 2004. pp. 1441–1444. ACM
50. Ritchie, D.M., Thompson, K.: The UNIX Time-Sharing System. vol. 17, pp. 365– 375. ACM (1974)
51. Ryall, K., Morris, M.R., Everitt, K., Forlines, C., Shen, C.: Experiences With and Observations of Direct-Touch Tabletop’s. In: Proc. TABLETOP 2006. pp. 89–96. IEEE
52. Salas, E., Sims, D., Burke, C.: Is there a Big Five in Teamwork? vol. 36, p. 555. Sage Publications (2005)
53. Schmidt, D., Chehimi, F., Rukzio, E., Gellersen, H.: Phonetouch: a technique for direct phone interaction on surfaces. In: Proc. UIST 2010. pp. 13–16. ACM 54. Sch¨oning, J., Rohs, M., Kr¨uger, A.: Spatial Authentication on Large Interactive
Multi-Touch Surfaces. In: Proc. TABLETOP 2008. IEEE
55. Sch¨oning, J., Rohs, M., Kr¨uger, A.: Using Mobile Phones to Spontaneously Au-thenticate and Interact with Multi-Touch Surfaces. In: PPD 2008 as a part of AVI 2008 (2008)
56. Scott, S.D., Carpendale, M.S.T., Habelski, S.: Storage bins: mobile storage for collaborative tabletop displays. vol. 25, pp. 58–65 (2005)
57. Scott, S.D., Grant, K.D., Mandryk, R.L.: System Guidelines for Co-located, Col-laborative Work on a Tabletop Display. In: Proc. ECSCW 2003. pp. 159–178. Kluwer Academic Publishers
58. Scott, S.D., Sheelagh, M., Carpendale, T., Inkpen, K.M.: Territoriality in Collab-orative Tabletop Workspaces. In: Proc. CSCW 2004. pp. 294–303. ACM
59. Shen, C., Everitt, K., Ryall, K.: UbiTable: Impromptu Face-to-Face Collaboration on Horizontal Interactive Surfaces. In: Proc. UbiComp 2003. pp. 281–288
60. Shirazi, A.S., D¨oring, T., Parvahan, P., Ahrens, B., Schmidt, A.: Poker surface: Combining a multi-touch table and mobile phones in interactive card games. In: Proc. MobileHCI 2009. pp. 1–2. ACM
61. Smart Technologies: Smart tablehttp://www.smarttech.com, Verified: 2010-08-04 62. Stewart, J., Bederson, B.B., Druin, A.: Single display groupware: A model for
co-present collaboration. In: Proc. CHI 1999. pp. 286–293. ACS
63. Tang, A., Boyle, M., Greenberg, S.: Display and presence disparity in mixed pres-ence groupware. In: Proc. AUIC 2004. pp. 73–82. ACS
64. Tuddenham, P., Robinson, P.: T3: Rapid Prototyping of High-Resolution and Mixed-Presence Tabletop Applications. In: Proc. TABLETOP 2007. pp. 11–18. IEEE
65. Tuddenham, P., Robinson, P.: Territorial Coordination and Workspace Awareness in Remote Tabletop Collaboration. In: Proc. CHI 2009. pp. 2139–2148. ACM, New York, NY, USA
66. Upton, K., Kay, J.: Narcissus: Interactive activity mirror for small groups. In: Proc. UMAP 2009. pp. 54–65
67. Wigdor, D., Penn, G., Ryall, K., Esenther, A., Shen, C.: Living with a Tabletop: Analysis and Observations of Long Term Office Use of a Multi-Touch Table. In: Proc. TABLETOP 2007. pp. 60–67. IEEE
68. Wilson, A.D., Robbins, D.C.: Playtogether: Playing games across multiple inter-active tabletops. In: Proc. IUI 2007 Workshop. ACM
69. Wobbrock, J.O., Morris, M.R., Wilson, A.D.: User-defined Gestures for Surface Computing. In: Proc. CHI 2009. pp. 1083–1092. ACM
70. Woodruff, A., Anderson, K., Mainwaring, S., Aipperspach, R.: Portable, But Not Mobile: A Study of Wireless Laptops in the Home. In: Proc. Pervasive 2007, vol. 4480, pp. 216–233
71. Wu, M., Shen, C., Ryall, K., Forlines, C., Balakrishnan, R.: Gesture registration, relaxation, and reuse for multi-point direct-touch surfaces. In: Proc. TABLETOP 2006. pp. 185–192. IEEE
ISBN 978-1-74210-210-8
School of Information Technologies Faculty of Engineering & Information Technologies
Level 2, SIT Building, J12 The University of Sydney NSW 2006 Australia T +61 2 9351 3423 F +61 2 9351 3838 E [email protected] sydney.edu.au/it ABN 15 211 513 464 CRICOS 00026A
