3.5 Drivers for Framework Design
3.5.9 Other Goals
We established several additional goals that influenced the design. These mainly relate to pragmatics:
• should not be encumbered by a particular license (e.g. inclusion of GNU Public License (GPL)code would require the license for Cruiser to beGPL)15;
• structured so thatLesser GNU Public License (LGPL) libraries may be used without affecting the license (i.e. they must bedynamically linked, which can be cumbersome in Windows – see §A.2);
• legacy support to run arbitrary programs within an interactive photograph, so that we could easily augment the experimental interface with existing, familiar tools if that was useful for an experimental trial;
• fast prototyping to allow new ideas to be tested quickly;
• debugging facilities that work well within the complexities of multithreading and immersive graphical environments;
• support for written annotations, with a pen or stylus.
3.6
Chapter Summary
The design focus presented here has guided the implementation of the Cruiser framework: its API, implementation methodologies, interaction techniques and user interface elements. The development has also been influenced top-down, by the requirements of the PhoTable application. However, by grounding the design in generic interaction techniques backed by
14or, more correctly, a lattice due to multiple inheritance
15Inclusion of code licensed under aBerkley Software Distribution (BSD)-style license does not have this
flexible and reusable framework components, we aim to create a general purpose framework allowing a number of versatile tabletop applications to be built.
The key design elements (§3.3) influence what users of the tabletop interface will see and interact with. The realisation of the interface design is described from the user view in Chapter 4, to follow. Evaluation of the effectiveness of the interface is presented in Chapter 7.
The framework design drivers (§3.5) primarily influence what application and plugin developers will use to create new tabletop functionality. The Cruiser framework has been designed to address all of these drivers, and is discussed in Chapter 5. Evaluation of the effectiveness of the Cruiser framework in terms of these goals is presented in Chapter6.
Chapter
4
User View
The development of Cruiser was motivated by the desire to share digital photographs on a multi-user interactive tabletop interface, thereby realising the PhoTable application (see §1.1.1 Naming). To achieve this effectively, development of software aspects of the interface have been geared towards facilitating a highly learnable, natural and intuitive interaction, tightly bound in physical analogies. The starting point is the display of the digital photographs on the tabletop that mimics the way physical, printed photographs would behave.
A photograph is displayed as a rectangular object, appearing on the interactive tabletop, with the image content of the photograph visible. Many photos can be visible on the tabletop at once, and they may be arranged. Photos can be moved, simply by dragging them with a finger, stylus, mouse cursor, or some other input device, depending on the hardware configuration (Cruiser is designed to avoid dependence on any specific hardware device). Photos can also be rotated, resized, flipped and manipulated in other ways. These interface actions are described in Section4.2.
However, a photograph is just one type of on-screen object: an image. Visible objects are generalised as resources, and other examples include handwriting, audio, video and interactive images. Image is also specialised to create objects with behaviour similar to photographs, but with added functionality. For example, special image objects can act as temporary storage bins, a cropping tool, content browsers, or a “black hole” (for deletion)1. The behaviours of special resources are described in Section 4.3.
The display of the visible resources is achieved by maintaining the positions of the objects, their scale and orientation, in computer memory. Each time the screen is redrawn, OpenGL is used to draw each on-screen object. For photographs this involves rendering a mipmapped texture, with decorations to assist selection, laid out appropriately on the interface. When interaction occurs, we determine which object is touched, and where on that object contact is made, which determines the type of manipulation that should occur. The mechanics of selection are managed by the Cruiser framework and will be described in Section5.2.1.
This chapter will focus on the user view of the interface. That is, the appearance and behaviour of the interface and interface components from the perspective of an end user. The design of the framework is at a lower level, and so the interface from a plugin developer’s perspective is covered in the next chapter. In this chapter, concepts are described in terms of on-screen objects and interaction behaviour, where Chapter5 will deal with concepts in terms of classes and functions.
1Figure5.2shows the relationships of most of the special objects available, with a complete depiction in
4.1. Interface Design Approach CHAPTER 4. USER VIEW
4.1
Interface Design Approach
Here, design refers to the general structure of on-screen objects and the interactions that are available to the user, rather than notions of graphic design, which could be deferred to later stages of development2. This section discusses the design approach, towards creating the PhoTable application and showcasing the functionality provided by the Cruiser framework. But interactive tabletops are a new environment for computer-human interaction, so how do we design the interactions on such an interface?
Design drivers were presented in Chapter3. In essence, there are several fundamental differences between tabletop interfaces and conventional desktop computer interfaces. The tabletop provides both opportunities and challenges of innovation in creating new ways to interact. If we are to exploit the opportunities offered by the special properties of tabletops, whilst taking account of the limitations that they impose on design, we need support for the exploration of the rich design space.
One key requirement for this is a set of techniques to assist in evaluating a range of possible ways to design new elements for tabletop interaction. With the current state of the evolution of tabletop interaction, there are many interface elements that deserve exploration. Existing tabletop systems have many different ways to do even such primitive actions as moving, rotating and resizing objects visible on the table.
Many of the interaction primitives that are a core part of traditional interfaces are yet to be explored. For example, there is only early work on mechanisms for accessing files that are stored in a file system attached to the table [Collins et al., 2007]. Another common task that has received little attention is copying, and my own work has formally explored the basic action of copying elements on the table [Apted and Kay, 2006a] (see also §4.3.8). Similarly, clutter is a serious problem for tabletop interaction (§3.1), yet there is still much to be done in exploring techniques for this to be addressed; some are explored in this thesis.
The approach to interface design was primarily influenced by our guidelines in Chapter3. But we still need a way to evaluate the design. Part of this involves user studies, which are presented in Chapter 6.1. Heuristics were used early in the design process to assist development.