Requirements for Pedagogical-PDEs

Professional-PDEs provide a host of features, ranging from simple editor functions to complex refactoring tools, while pedagogical-PDEs often provide a subset of these features, as well as features that have been specifically tailored to novice programmers. PDEs are developed with various aims in mind and can range from attempting to reduce the possibility of syntax errors from occurring to alternate

methods of specifying programs and increasing productivity. PDEs can be defined by the features that are provided to the programmer.

The question arises then: which features should a PDE for novice programmers have? In order to address this question, Section 3.2.1 considers the mechanics of programming that a novice programmer is expected to be fluent in by the end of an introductory programming course. The tasks that a novice programmer can likely engage in while performing practical learning activities are examined and elaborated. Following this, usability guidelines that have been proposed for novice programming systems, including the programming notation and PDE, are discussed in Section 3.2.2. Finally, based on the requirements for learning to program, the mechanics of programming and the guidelines for novice programming systems, a set of requirements for a pedagogical-PDE supporting the mechanics of programming is proposed in Section 3.2.3.

3.2.1 Mechanics of Programming

The novice programmer needs to interact with a number of different tools within the PDE in order to perform various programming tasks while programming. The tasks that novice programmers are required to perform while programming are:

• management of program files; • creating and editing program code;

• searching and navigating within program code;

• validating program code for syntactic and semantic correctness; and

• consulting documentation regarding error messages, language constructs and specifications of existing functionality of pre-defined program modules.

Programs are stored within one or more files on a computer and the PDE needs to provide file management tools. These tools allow the novice programmer to perform typical file management operations on the files constituting a program, such as creating a new file, opening files or saving files. Many programming languages and PDEs require multiple files be created and placed in the correct places for programs to be compiled and run. The file management tools should make the process of creating and managing these files as easy as possible.

Program creation and editing tools allow novice programmers to create new programs or sub-parts of a program and then to edit the code. Editing involves extending or modifying existing program code. The creation and modification of program code is an error-prone process, as novice programmers can easily introduce syntax and semantic errors (Gugerty & Olson, 1986).

Searching and navigation occupy a large portion of time during programming (Cockburn, 2001, Cockburn & Churcher, 1997, Cox et al., 2005). While writing program code, programmers need to examine type definitions or the parameters a function requires, amongst other information. When debugging programs, the programmer needs to locate specific code when testing hypotheses regarding program correctness. Searching and navigation tools provided by the PDE should be simple to use, yet powerful enough for the programmer to locate the required information quickly.

Once a program has been written, the code needs to be validated before it can be compiled and executed. Code validation tools provide feedback to the programmer regarding the syntactic correctness of program code. Feedback regarding semantic correctness of program code should also be provided by the tool. For example, the code in Figure 3.2 is syntactically correct (it obeys the grammar of the programming language), but is semantically incorrect (a float cannot be assigned to an integer). Code validation messages from the PDE to the programmer should be concise, understandable to the programmer and correct.

int x = 10; float y = 1.5; x = y;

Figure 3.2: Syntactically correct, but semantically incorrect code

Code validation tools are typically invoked at discrete periods by explicit programmer requests. Certain validation checks, however, can be conducted continuously with immediate feedback being provided to the programmer.

Once syntactically and semantically correct program code has been created, there is no guarantee that the program code is correct. Programmers spend much time debugging programs to remove logical errors. Tools that assist in tracing the execution of programs and the examination of program state during program

execution are particularly useful. Without these tools, programmers are forced to resort to other methods, such as hand tracing program execution or making use of program execution logs.

Programming is inherently a problem solving process and the programmer is required to search for information, both in the program code and in documentation. When messages are received from the compiler or the programmer wishes to locate information, then help systems are consulted. Help systems organise information into logical compartments and allow programmers to search for information meeting their requirements.

The PDE being used to create and debug programs has an impact on the mechanics of programming. The general usability of the system affects how easy it is for the novice programmer to complete tasks related to programming mechanics (Pane et al., 2002). The next section examines some of the issues related to PDEs and their usability. 3.2.2 Usability Issues

Pane and Myers (1996) have detailed a number of usability issues that are important when designing Novice Programming Systems. A Novice Programming System is defined as a combination of a programming notation and the PDE in which programs using the programming notation are created, edited and debugged. Pane and Myers detail usability issues relating to both programming notations and PDEs for novice programmers.

The usability issues are a subset of the heuristics defined in the Heuristic Evaluation usability engineering method (Nielson, 1994) and are meant to guide the decision making process. Amongst the usability issues, there are a number that relate specifically to development environments:

• system status visibility; • user control and freedom; • recognition, rather than recall; • aesthetic and minimalist design; and

• helping users recognise, diagnose and recover from errors. Each of these will briefly be discussed.

System Status Visibility

The status of the novice programming system, which includes the programming notation and the PDE, should be visible at all times. Information that is important to the programming process should be made visible to the novice programmer when appropriate.

Signalling can promote the visibility of important information within program code. An example of signalling is syntax highlighting, which uses typography to identify certain aspects of the programming language’s syntax. Another example of signalling is semantic highlighting, which can draw attention to semantic relationships, such as identifier usage and scope.

Comprehension test performances have indicated that the readability of program code is improved in systems using typographic signalling (Baecker & Marcus, 1990). Signalling can reduce the cognitive load placed on novice programmers by making distinctions in syntax that can be misleading. For example, the use of syntax highlighting that annotates strings and numbers differently would allow novice programmers to visually discern that “123” and 123 are not the same. Therefore, the use of signalling promotes code comprehension (G3).

Similar to signalling, secondary notation can clarify or obscure information in a program by the use of white space and comments within program code. As stated in Chapter 2, secondary notation in a program can invite the novice programmer to draw incorrect conclusions regarding code structure if incorrect indentation has been applied. Such misleading appearances should be avoided. This can be done by either the structure being inferred from the indentation as a programmer would or imposing formatting on program code to avoid the incorrect application of indentation. While signalling draws attention to information within program code text and secondary notation promotes acquiring higher level mental representations of a program, there are still dependencies within a program that may not be visible.

Locality and hidden dependencies should be made visible to the novice programmer, as these can reduce the understanding of code (Green & Blackwell, 1998). Locality refers to the physical proximity of related items, such as the declaration and use of variables being either near or far apart. Hidden dependencies refer to dependencies

between different constructs not being immediately visible, such as variables being passed to sub-programs that have parameters being passed in by reference (Pane & Myers, 1996). The limitations of novice programmer working memory are reduced depending on the extent of information that is visible onscreen. The use of secondary notation and powerful search and navigation features of PDEs can reduce the effect of hidden dependencies.

Immediate feedback aids in problem solving (Lewis & Olson, 1987). Constantly informing the programmer of the status of the program, both during code editing and debugging, provides the novice programmer with additional sources of information with which to build mental representations. Providing immediate feedback during debugging can promote the acquisition and the manipulation of the state model of a program (Section 2.4.1). Stepping through a program can also help in the comprehension of the program (Goldenson & Wang, 1991).

System status visibility is important, but novice programmers should also have the freedom to perform actions in the order that is natural for them. Systems that are restrictive can be counter-productive as the novice programmer may feel that they are fighting the PDE when creating programs.

User Control and Freedom

Novice programmers should not be overly constrained by the programming notation or the PDE. Programming notations and PDEs that are viscous or require premature commitment constrain the novice programmer.

The PDE as a whole should not be viscous. Viscosity refers to how easy it is to alter program code once it has been created. The more viscous a system is, the more difficult it is to alter code. The tasks of creating program code and editing it should be equally easy for the novice programmer to perform, yet in some systems this is not so. Viscosity increases the level of frustration in the novice programmer and can lead to a decrease in motivation over a period of time.

Novice programmers should not be required to create programs in a rigid, inflexible fashion which would require an excessive amount of thinking ahead. PDEs that enforce this kind of behaviour force novice programmers to commit prematurely to design decisions, which places more cognitive load on short-term memory. In

addition to this, premature commitment forces novice programmers to proceed in a manner that does not match their natural progression of thought and make decisions before they are ready to do so. A sign of premature commitment is if the correct generation of program code requires subsequent pieces of code to be known (Pane & Myers, 1996).

Recognition, rather than recall

Expert programmers are able to utilise external memory to relieve their cognitive load and store chunks of conceptually related information as single information units in working memory (Curtis, 1982). Novice programmers are not able to perform chunking and instead rely extensively on working memory when programming (Davies, 1996). Poor performance by novice programmers is attributed largely to working memory limitations (Anderson & Jeffries, 1985). As novice programmers gain experience, they are able to start recognising frequently occurring patterns and build increasingly larger chunks (Curtis, 1982).

Therefore PDEs should minimise memory load requirements placed on novice programmers, not requiring them to memorise unimportant information, or information easily made available by the PDE (Pane & Myers, 1996). The reduction in cognitive load will allow more working memory to be available for novice programmers to build larger chunks.

Aesthetic and minimalist design

Nielson (1994) states that “dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.” Interfaces used by novice programmers should only contain pertinent information; information that is irrelevant should be removed. This implies that interface components present should be used often by novice programmers. While Nielson refers to the interface of a system, Pane and Myers (1996) relate this principle to the programming notation as well.

Help users recognise, diagnose and recover from errors

Non-trivial programs are seldom initially free of errors, requiring testing and debugging tasks to be performed. Novice programmers experience difficulty performing these tasks and the PDE should provide error messages that are expressed in plain language, precisely indicate the problem and constructively suggest a solution (Nielson, 1994).

Additionally, PDEs should provide tools to assist the novice programmer in debugging and feedback should be in terms of the programming language itself (du Boulay, 1989). The skill of debugging is not automatically learnt in the programming process and PDEs that proactively suggest debugging strategies would be useful (Pane & Myers, 1996).

To summarise, PDEs used by novice programmers:

• should ensure that the system status is always visible;

• should use signalling and secondary notation to promote code comprehension; • should make locality and hidden dependencies visible;

• should provide immediate feedback, both during editing and debugging; • should not be viscous;

• should not require premature commitment; • should promote recognition, rather than recall;

• should not place undue cognitive load on the novice programmer; • should not contain unnecessary interface components; and

• should help novice programmers recognise, diagnose and recover from errors. The following section discusses the requirements that pedagogical-PDEs supporting the mechanics of programming should meet.

3.2.3 Requirements

Based on the issues related to usability in PDEs (Section 3.2.2) and the guidelines that ought to be followed in order to further the process of learning to program (Section 2.5), it is possible to derive a set of requirements that PDEs developed for novice programmers learning to program should meet. Table 3.1 lists the requirements that pedagogical-PDEs should implement in order to assist the novice programmer with the mechanics of programming in the process of learning to program. The requirements are categorised by the guideline that they are derived from.

G1 Reduce cognitive load placed on novice programmer R1 Recognition, rather than recall

R2 Aesthetic and minimalist design

R3 Eliminate finer implementation details of programming process R4 Appropriate language usage

G2 Optimise time-to-success of program execution R5 System status visibility

R6 User control and freedom

R7 Support novice programmer tasks

R8 Help recognise, diagnose and recover from errors G3 Promote program code comprehension

R9 Use of signalling

R10 Promote correct use of secondary notation

Table 3.1: Pedagogical-PDE Requirements