The Perspectives Interactions Paradigm (PIP) focuses on the interactions between three key actors: student(s), teacher and designer (of software).

The PIP thus focusses on interactions between:
* teacher and student(s)
* teacher and designer
* student and designer

Students and teacher are viewed as generalised students (learners) and generalised teachers (people who support learners). The designer encapsulates all the functions that go into developing some software.

Using the PIP involves thinking about the interactions between each of three pairs of actors, as described above. A breif summary of the key elements of the interactions for each pair of actors is provided below.

The Teacher and Student Perspectives Interaction
The focus here is on interactions between teachers and students (learners) and between student (learner) and student (learner).

In thinking about these interactions you need to address both those interactions that take place at the computer as well as those related interactions that take place elsewhere but are generated by the computer.

Squires & McDougal indentify a range of questions that one might usefully ask about the potential interactions that a particular application supports:-

• What kinds of classroom activities and interactions might the software encourage?
  
• How might the use of the software be organised? (eg. groupings, on and off computer work, etc)
  
• How much control can the students take for their own learning?
  
• How much and what kind of teacher interventions are appropriate?
  
• What teacher (student) roles and styles of classroom management would be suitable?
  
• How well do all of the answers to the above fit with the particular classroom context?

The Designer and the Student Perspectives Interaction
The Designer within the PIP is embodied within the software. Thus, Squires and McDougal identify that the view of learning that is held by the designer underpins the possible interactions between the designer and the students. This is because this view of learning will have informed and shaped the design of the software.

Squires and McDougal suggest that there are two main 'educational approaches' underpinning most educational software: behaviourist, as exemplified in drill and practice software for example, and constructivist (in the Piagetian sense), as exemplified in 'microworlds' for example.

The degree to which the software succeeds in embodying the designer's view of learning will vary, as will the degree to which this underlying educational design is made explicit to users of the software. Thus an important task in thinking about the potential interactions between the designer and students is to identify the underlying theory of learning within the software.

Squires and McDougal point out that some software may not have an underpinning learning theory and suggest that this is indictative of software that is unlikely to support learning directly, although it may help manage the administrative side of learning. They go on to suggest that there are three key aspects of software design which can be used to help identify if a particular application is likely to support 'appropriate' designer/student interactions. These are:

• The extent of learner control
• The complexity of the material presented to the learners
• The challenge felt by the learners

Squires and McDougal (p91) provide a table that summarises the position you would expect for behaviourism and constructivism against learner control, complexity and challenge:

Behaviourism

• Learner control - little or no control. Learners as passive consumers.
  
• Complexity - Highly structured, simple formats, small incremental steps, positive feedback.
  
• Challenge - Artificially contrived rewards, extrinsic.

Constructivism

• Learner control - significant levels. Learners active/purposeful participants.
  
• Complexity - high.
  
• Challenge - intrinsic rewards (based on satisfaction in completing tasks/succeeding in understanding environment).

In thinking about the interactions between the designer and students Squires and McDougal say that you need to identify the underlying learning theory(s) embodied within the software and decide how well these match your percieved needs and how consistently they are implemented within the software.

The Designer and Teacher Perspectives Interaction
The key issue here is the degree of match between the designer's view of the curriculum, as embodied within the software, and that of the teacher who is going to use the software. Squires and McDougal use 'curriculum' here to include both the educational content and process.

As with the underlying theory of learning that underpins the software, the degree to which the curriculum is made explicit within the software will vary, or may be absent (eg in the case of software that was designed for use in a business rather than an educational context).

Squires and McDougal suggest that there are four key tasks that need to be addressed when thinking about the Designer-Teacher interactions:

• Identifying implicit curriculum aims.
• Matching explicit and implicit curriculum aims to percieved specific curriculum requirements.
  
• Realizing the possibilities of 'subverting' explicit and implicit curriculum aims to specific curriculum requirements.
• Realizing the educational possibilities of the use of software which initially has no explicit or implicit curriculum aims.

It is important to bear in mind that Squires and McDougal were writing about software evaluation and were trying to provide advice about how to select appropriate software. Non the less the PIP does highlight a number of important issues for thinking about the practice surrounding computer use.

The area where I think it is weakest is in terms of the lack of specificity of the dimensions.

It would be interesting to hear your views on and/or experiences of using the PIP - why not email me (PeterT@meD8.info)?

Home Frameworks Index PIP PIP details
Investment Literature Impact Reasons Solution Limitations The CPF Discussion

This page is maintained by Peter Twining (PeterT@meD8.info)
Last updated 7th January 2002