Some programming environments like Oh et al.’s (2013) Digital Dream Lab dictate the relative positions in which objects have to be placed to constitute a proper program instruction. Other environments do not prescribe the relative positions of objects and instead leave that to the user’s discretion. An example is Media Cubes. Although this system requires that the programming objects
make physical contact with each other to be considered an instruction, the object order is not relevant. A benefit of Media Cubes’ design over that of Digital Dream Lab’s is therefore that it affords the user with an opportunity to arrange the objects according to her personal preference.
For example, if one cube represents a desk lamp and a second cube represents the time to turn on the lamp, then the sequence in which the user arranges the cubes is irrelevant. This approach dictates that the relative positions of objects need not be prescriptive and can instead be left to the user’s discretion. The consequence it that the user no longer needs to remember the sequence in which objects have to be placed and can instead position the objects according to personal preference.
Whereas Media Cubes only considers instructions comprising two objects, the Story Room (Alborzi et al. 2000) designs explore instruction compositions comprising multiple objects. To this end, its designers considered the meaning conveyed both by three overlapping squares (Figure 4-15) and closely spaced physical objects (Figure 4-18). I concluded that the Story Room designs implicitly depend on the Gestalt principle of grouping by proximity. However, Story Room does not fully explore object arrangements and I argued that a group of objects can maintain its meaning when the parts are rearranged. I supported my argument using eight arrangements comprised of Story Room sensor and actuator objects.
In addition to considering physical arrangements, Story Room follows an approach that I call grouping-by-temporal-common-region. I put it that when items are selected in a period demarcated by two previously well-defined events this action can be considered as grouping by common region, albeit temporal common region and not spatial common region. To elaborate, grouping by common region assumes a physical region demarcated using, for example, a coloured area or physical barrier.
In contrast, I propose that two successive button presses can define a temporal common region group. I label in Figure 4-24 (a) the time interval between the presses as temporal-common-region.
The first press in this example demarcates one temporal boundary while the second button press defines the end of the temporal area. The result is that all actions between these two events are grouped together. Likewise, my argument for temporal grouping can be extended to grouping by proximity and the result will then be a new grouping category that I call grouping-by-temporal-proximity (Figure 4-24b). Using the same scenario as for grouping-by-temporal-common-region, I base my argument on the time that transpires between events. That is, if the events are temporally close together then they are considered members of the same group. A challenge in using this grouping is in specifying the maximum time interval between two successive events to be viewed as belonging to a common group. A second problem is to determine the minimum interval between
events to consider them as belonging to two distinct groups. I do not explore temporal grouping further in this thesis.
While Media Cubes and Story Room program instructions are not spatially confined, SiteView defines dedicated and spatially separate locations where the user must place objects. I propose that instead of dictating that the objects have to be kept separate, the system can be designed in a way that allows the user to place them in close proximity to each other. This will result in a system based on grouping by proximity. In Figure 4-9, I offered an example of what I propose a program can look like when arranged this way. In this example, the lamp will turn on if it rains on a Monday morning. I further posit that it is possible to include multiple condition interactors of the same type in a single program. For example, a logical OR condition is indicated when a Tuesday indicator is added. As directed by the new configuration, the light will be activated on both Monday and a Tuesday mornings but only when it rains on these days. Likewise, more action interactors may be added and they will be actuated when the conditional expression holds true. To illustrate by means of another an example, if a coffee maker is included in addition to the light actuator, the system will turn on both the coffee maker and the light on rainy Monday and Tuesday mornings.
(a)
(b)
Button press Event 1 Event 2 Event 3 Button press
t0 t1 t2 t3 t4 Time
Event 5 Event 6 Event 7
Time
Δt1
Event 4 Event 8
Δt2 Δt3 Δt4
Temporal Group B Temporal Group C
Temporal Group A Temporal common region Grouping-by-temporal-common-region
Grouping-by-temporal-proximity
Figure 4-24 Grouping-by-temporal-common-region and grouping-by-temporal-proximity
4.4.4 Personally meaningful objects
There exist programming environments purposefully designed to encourage object personalisation.
Story Room and Quilt Snaps are examples of such environments. Using these systems, users can create personally meaningful objects by, for example, embellishing the objects using cardboard and cloth.
In contrast to environments in which the user can incorporate personally meaningful objects in their programs, a group of system designers prescribe the visual appearance of their objects. Examples include Electronic Blocks and TORTIS. Whether the designer’s decision to fix the appearance without the individual’s input is intentional or not, I argue that all physical programming environments can be modified to include personally meaningful objects. For example, even though the colour of the blocks and icons imprinted on the sides in Electronic Blocks serve to remind the user of their function, the designer does not give the user an opportunity to choose her own colours or other signs. It is therefore the user’s burden to memorise their meanings. Based on this argument, I put it that Electronic Blocks can be personalised using pictures and by writing on the plastic parts.
TORTIS is another system that does not give the user an opportunity to create personally meaningful program objects, yet can be adapted for this purpose. Since the program objects are made of cardboard I posit that it is possible to add personally meaningful signs by drawing on the cards or by gluing pictures onto the cards. A final example is Patten, Griffith, and Ishii’s Physical Strings system that can be customised to better represent the purpose of each string. To illustrate, the user can attach to each string a written description or another sign to remind her of its purpose. This illustrates that physical strings can be adapted to include personally meaningful objects customised to the user.
4.5 Conclusion
This chapter focussed on programming environments in which a program is defined when the user manipulates physical objects not usually associated with programming. I made a distinction between physical and tangible programming with the former involving computationally ubiquitous environments and the latter defined by the grasp-ability of the objects.
Central to the discussion was the user’s involvement in the creation of objects; that is, instead of using premade objects the user chooses personally meaningful objects with which to program. Of the literature studied, only three tangible programming systems explicitly include the user in the design and creation of the programming objects. These systems are StoryRoom, Quilt Snaps, and Diorama Table. Although some design methodologies do include end-user representation (Druin 1999), the design outcome is usually a compromise and often does not afford the user the opportunity to design and create a personally meaningful interface. Of the systems identified in this study that do explicitly include the user in the design and creation of the objects, none explicitly incorporates Gestalt principles in their design approach. In Chapter 6 I apply the design science research methodology to develop a tangible programming environment in which the user is both the
designer and creator of programming objects and in which certain Gestalt principles are explicitly incorporated in the use of the environment.
CHAPTER 5
RESEARCH METHODOLOGY
Chapter 1 Introduction
Chapter 2 Theoretical background
Chapter 5 Research methodology
Chapter 6
Design, implementation, and evaluation
Chapter 7 Primary research contribution
Chapter 8 Conclusion
Chapter 4
Literature review: Tangible programs Chapter 3
Literature review: Tangible objects
Figure 5-1 Document structure
5.1 Introduction
A paradigm implies the assumptions and philosophical views on ontology, epistemology, and human nature that the researcher makes and these influence his chosen methodology and methods (Burrell
& Morgan 2005; DeVilliers 2012; Schwandt 2007). I state my views on ontology, epistemology, and human nature in Section 5.2.
Research is guided by the chosen methodology (DeVilliers 2012) while research methods describe the tools for collecting research data. One or more research methods may be applied simultaneously to a project (Dawson 2009). In order to answer the research questions tabled in Chapter 1 (and repeated in Section 5.3.4.4), I applied Vaishnavi and Kuechler’s (2008) general Design Science Research methodology and used the methods of laboratory work and direct observation. The methodology and methods are described in Section 5.3.