Levels of programming complexity

End-user programming has been referred to as “tailoring” - broadly defined as an activity to modify a computer application within its context of use [114]. Through tailoring activities, end-users can become masters of their own software tools, modifying these tools to suit their own requirements without the need to rely on a professional programmer.

Mørch defines the complexity of tailoring approaches into three categories: customisation,

integration, andextension[115]. These categories overlap to some extent with EUD activities described by Lieberman et al., and indeed it is not always possible to place activities into one of the three categories. Instead, they appear to represent three points on a spectrum of complexity.

4.1.1.1 Customisation

Mørch’s definition of customisation is similar to the definition employed by Lieberman et al. of “parameterization and customization”[16]. Such activities involve the adjustment of parameters that allow an end-user to change the content of an application, but not its behaviour. “End-user authoring” tools, such as those described for conducting participatory sensing campaigns in Section 3.1.1, fall into this category through supporting content modification while leaving the programmatic structure intact. For example, they allow users to change the design of a questionnaire form, but not the conditions under which it is presented. Another customisation activity discussed by Lieberman et al. is that of “annotation” - supplementing programs, data and results with comments, as a form of secondary notation to impart additional meaning. This thesis argues that, although customisation is clearly a tailoring activity, it is not end-user development; adjusting parameters of an existing application’s behaviour is not the same as adjusting the application behaviour itself. As a simple example, adjusting the time on an alarm clock application would not be considered as development. However, development could be integrating a function that snoozes the alarm for a number of minutes, and it is thisintegration process that forms the basis of many EUD tools.

4.1.1.2 Integration

Integration is closely related to the definition of “program creation and modification” by Lieberman et al., who also consider integration activities to be relevant examples of EUD, as opposed to customisation [16]. Conceptually, end-users compose existing program functionality to define their chosen behaviour. While no modification of source code is required, integration activities can enable a wide range of program behaviour through linking and swapping of high-level components.

60 CHAPTER 4. END-USER DEVELOPMENT

Program modification can also involve“extended parameterisation”, whereby end-users select and integrate functionality created by other end-users, stored in a shared repository [16]. However, such activities still only allow for combinations of existing functions. Creating new functions requires modification beyond the scope of integration, which can instead be accomplished throughextensionactivities.

4.1.1.3 Extension

Extension is the most complex manifestation of EUD, whereby functionality exists to allow end-users to define their own components, as opposed to simply integrating pre-existing ones. This level of complexity generally requires the end-user to perform some modification of source code to realise these components, and thus bridges the gap between end-user programming and realprogramming.

Mørch’s view of the end-user in such development activities is in line with that of Segal, who distinguishes “professional end-user developers” as those for whom software development is already part of their working practices to some degree [113]. Indeed, Spahn et al. consider such users to be professional programmers [116], transcending their role as domain expert developers.

4.1.1.4 Roles of end-user developers

In contrast to the often steep learning curves of professional programming languages and development environments, EUD tools should offer a low threshold to entry. In addition, dependent on the desired flexibility of development enabled, tools could support a user from simple customisations to formal scripting of applications, through the three levels of tailoring previously described. As such, EUD tools have the potential to provide a smooth transition into real programming, or simply to provide sophisticated modification abilities without the need to ever learn such real programming.

In their recommendations for EUD design principles, Spahn et al. advocate a“gentle slope of complexity”, allowing end-users to move seamlessly from simple customisation activities to more complex extensions [116]. Additionally, they also define three types of end-user by borrowing Nardi’s definitions ofnon-programmer,local developerandprogrammer[117]. In this definition, local developerrefers to any end-user engaged in EUD practices, but not proficient in high-level textual programming. Their thesis is that appropriate design principles could allow end-users to start as non-programmers and become programmers, but within a single embedded EUD environment, as illustrated in Figure 4.1. This figure also illustrates their suggestions of testing, community, and appropriation support for scaffolding end-users through their increasingly complex development activities.

4.1. EUD AND VISUAL PROGRAMMING 61

Figure 4.1:Gentle slope of complexity from Spahn et al. [116]

An alternative perspective is that of the Software Shaping Workshops (SSWs) methodology [118]. This concept places design stakeholders in three separate roles: end-users, domain experts, and meta-designers. Each role has a corresponding SSW, conceptualised as an “artisan workshop” in which each user group finds the tools, andonlythe tools that they need to perform their relevant activities. As such, rather than considering the end-user as having a dynamic, evolving role, each end-user has their own workshop solely for performing customisation, integration or extension as appropriate to this role. The concept is illustrated in Figure 4.2, and will be explained in further detail in Section 4.1.4 on organisational factors of EUD.