Learning activities

The five learning activities described below were designed with an emphasis on ‗learning by doing‘ (Race, 1994) to actively engage and stimulate learners to participate in their learning in a collaborative context (Dillenbourgh, 1999). With this in mind, the learning activities were designed to specifically stimulate learners to actively practice collaborative working and make sense of the course material administered during the course. To encourage learners to adopt a deep approach to learning (Biggs 2003) the learning activities were designed so that learners would gain an in-depth knowledge of the subject matter. The activities required learners to solve problems where each problem built upon the previous one. There was a mix of activities that comprised one individual and three group-based learning activities, designed to promote ownership and participation within groups and between groups. Individual tasks comprised the group commitment (activity 1 in section 3.4.2.1) and the individual reflective Blog (activity 5 in section 3.4.2.5).

Each activity is described with the rationale for the design in the following section. Tasks were designed to relate to one another and for learners to share within and between groups. In this way it was intended to help build a group dynamic (Lewin, 1951), promote mutual engagement (Wenger, 1998)

and a sense of belonging to a collaborative/community learning environment (Wenger, 1998; McConnell, 2004). In this way, the learning activities were designed to initiate learner curiosity and set the learners on the path to discovery.

To create effective learning together, the problem was designed to be plausible (Canole, 2002), each group member had a structured job to do, the tasks were divisible by the number of group members, and the tasks were interdependent (Doolan et al, 2006). In so doing, the intention was to motivate individuals within groups to support their group in the achievement of tasks.

The assessment design was intended to initially create the seeds for the Wiki learning environment and as a foundation for it to grow. Hence the tutor approach adopted for the up-front planning and design of the assessment was to nurture a collaborative/community learning experience (Doolan, 2006, 2007a). This organic view of the learning environment is provided in 0.

Learners were provided with a case study (see 7.9Appendix A) and expected to carry out the following:

3.4.2.1 Activity 1 (Individual) – Group commitment

The group commitment activity was set by the tutor as an individual task and was expected to be submitted by each individual group member to the ‗private‘ group space in the Wiki. Activity 1 was designed to obtain personal ‗buy in‘ to the group work to complete the set tasks. It was also intended to

support the development of a group dynamic between individual group members. With this in mind, activity 1 is a group commitment task. It was also intended through this task that, in keeping account of their contribution to the collaborative experience, they would ‗buy in‘ to the group activities and ‗commit‘ to ‗equal‘ participation in the collaborative experience.

The task requested them to submit their individual name and the names of other group members, e.g. I am Fred Bloggs and I am working with John Smith, Mary O‘ Reilly and Peter O‘ Connor. I am Peter O‘ Connor and I am working with Fred Bloggs, Mary O‘ Reilly and John Smith etc. This group statement was necessary to confirm that learners had a list of group contact details (names, telephone numbers, email addresses). The ‗ground rules‘ used by the group in order to be able to operate successfully were also set in the group commitment statement, in terms of the role and responsibilities agreed within the groups. In addition organised group meetings were expected to be documented and included in the final assessed report in the following format: dates and times of planned meetings, apologies for absence, minutes of last meeting, motions (list of matters discussed), actions identified at meetings including individual group member name(s) showing the person(s) responsible for carrying out these actions. Each individual student was responsible for signing and agreeing to these at every meeting. The signed copies were expected to be included in the group assessed report. Each individual student was responsible for demonstrating in their individual reflective log (see Activity 5) how they had met their agreed group

commitment. This was validated by the tutor against the signed copies of meetings.

3.4.2.2 Activity 2 (Group) - Identify needs and establish requirements

In the second task the core activity was designed so that other group tasks were built upon this. The core activity was recorded on audio (podcast) and video (Jumpcut) and linked to Wiki contributions by the tutor as discussed in section 3.5.1 The methods were delivered in a lecture and reinforced by practice in a tutorial. The learners were required to agree a method and to inform the tutor by means of the discussion forum on the University MLE. This communication was; firstly, to ensure learners had the resources; secondly, to find out if the learners needed support; thirdly, to find out if the technology chosen was compatible with the Wiki; fourthly, to ensure group agreement. The instructions were as follows:

1. Choose a method: interviewing, direct observation, brainstorming or another method of your choice. Agree this on the Discussion forum on the MLE by a set date. (Students were expected to state the technology they intended to use to carry out the task and whether or not they had the resources to undertake the task)

2. Record using one or more of the following: video, webcam, audio, podcast, document in Wiki or capture ideas using the discussion forum, or another method of your choice.

3. Add the results/product in Wiki, show, and share work and gain feedback from ―a set of potential users‖. (Learners were required to

submit their product in the communal area in Wiki and gain feedback from another group).

4. Use feedback obtained from the group to complete the ‗Requirements Document Template‘ provided to document the requirements.

Steps 2 and 3 provided a simulation of the real world and were thus designed based on the concept of authentic learning (Gupta, 2004). This was intended to help learners to prepare for the work place. Therefore step 2 involved data gathering activity intended to capture the requirements for a computer system. Step 3 was designed to seek out another group, ‗a set of potential users‘, to listen to the recording/read the script of the requirements captured during step 2 and to evaluate the findings. In this way, it was intended learners would be practiced in evaluation methods and in requirements capture both valuable to complete the assessment and in industry. The outcomes of steps 2 and 3 culminated in step 4 - the requirements document. This was expected to be included in the final assessed report.

3.4.2.3 Activity 3 (Group) - Develop storyboard and design

Learners were expected to ensure that the tasks were clearly visible in their Wiki in their private group area designed by the tutor and described later in the chapter. Activity 3 was intended to be shared between the different group

members in keeping with the collaborative/community aspect of the pedagogical design.

1. Produce a storyboard based on identified requirements and user needs.

2. Show it to a set of potential users [using the roles provided on the ―Roles‖ handout role-play within your student group in the Wiki and obtain some informal feedback.

3. Sketch out the application‘s main screen (home page). Consider the screen layout, use of colour, navigation, audio, animation, etc. While doing this, consider: Where am I? What‘s here? Where can I go? Write one or two sentences explaining each of your choices, how these choices will affect the users, in particular Diresh, who has no experience in using computers: in fact he is terrified of using computers, and consider whether the choice is a usability consideration or a user experience consideration.‖

This learning activity was designed to build upon activity 2 (the core task) and to provide learners with a means to demonstrate and show their understanding of the concepts delivered in a lecture, reinforced through practice in tutorial sessions. The role-play was intended as a simulation of the workplace and based on authentic roles within the workplace. Step 3 was an opportunity for learners to demonstrate their practical understanding of the human interaction concepts introduced and practiced in classes. Within the group, the students were required to come to a consensus and agree roles between them from the description of roles provided for the

development team and the client/end user group (see Appendix B.ii). When playing the role of developer, each member of the group was asked to agree to play one role from the following: Business Analyst, Systems Analyst, Project Manager and HCI Specialist. The descriptions were designed to help the students to have an understanding of the different roles of a typical software development team and the importance of each role to the development project. When acting as the client/end user, each member of the group was asked to agree one role from the following: Owner, Managing Director, Secretary and Accountant. The descriptions were designed to develop an understanding of the varying needs of different users when developing a computer system and the importance of capturing clear requirements. Therefore, learners gained experience in playing two roles as each learner within a group played one role as a ‗developer‘ and one role as the ‗client‘. In this way, it was intended learners would gain practical experience necessary for the workplace.

When playing the role of developer the students were required to carry out one interview, brainstorm, observation or textual script. As the development team, the students were required to develop common questions to ask the end user, group questions tailored to each individual user in the group in order to gain an insight into the way the business currently operates and possible future requirements. To help the students with this task, two lectures were delivered to students on requirement gathering techniques such as interviewing, observation, and brainstorming. The requirement gathering techniques were also practiced in tutorials whilst learners were in groups. It

was not felt necessary to train students in the use of audio and video equipment given learners‘ postings on their technological preferences on the discussion forum. No students requested institutional resources. It was apparent that learners had decided to use their own equipment to undertake the task as described in Chapter 6.

3.4.2.4 Activity 4 (Group) - Develop a data model

Learners were expected to ensure that this section was clearly visible in Wiki in their private group area. This task was shared within the group.

1. Draw a current physical data flow diagram using Britton and Doake notation (in the course text book) that clearly labels the input and output flows and shows the system boundary.

2. State any assumptions you have made, and document at least two questions that you have asked during your requirements capture (Activity 2 above).

3. Using your own words in one sentence state how the Data flow diagram relates to requirements.

Activity 4 is built on the core task activity 2 and provides an opportunity for learners to co-produce models to help understand the development of a computer system whilst working collaboratively on the model. This also requires learners to relate to earlier work reinforcing concepts and helping learners, together, build knowledge and demonstrate this progression in knowledge development through the development of the model using the

Wiki. In this way, the tutor can bring misunderstandings forward into the lecture and clarify any misconceptions thus providing formative feedback on the assessment.

3.4.2.5 Activity 5 (Individual) – A reflection

This task was an individual task and intended to help learners reflect upon the process of the collaborative experience. Using their Blog on the University Managed Learning Environment each individual group member was required to keep a week-by-week reflective log of the process undertaken to complete this assignment, to help them reflect upon their experiences of group working. This formed part of the final group report submission. They were permitted to use pictures, sound etc. to describe their experiences. The Blog was not to exceed 10 pages of A4, was not permitted to be made visible to the group before the submission date. The Blog was accessible online by the tutor and had to include evidence to support their reflections. They were permitted to use screen shots in Wiki and/or the other technologies provided/used. Learners were provided with suggested headings and asked to write a paragraph describing the usefulness or otherwise of keeping the weekly Blog and of posting reactions to the week's use of Wiki, the alternative technologies, reflections on group assignment and the group process or anything else that was personal to them.

The intention of activity 5 was to help learners to learn by regular reflections on experiences and for the tutor to gain insights into the learning process in a system of mass Higher Education in an attempt to gain insights in the three

main key areas of interest: collaborative learning, technology, and the tutor as set out in 0.

The overall learning objective is to apply the principles and techniques of system development in a team environment, thus fostering and developing collaborative working skills (University of Hertfordshire, 2005). This requires learners to move from problem identification through to implementation and evaluation. The ‗core task‘, the problem identification (requirements elicitation and documentation) phase was recorded by the tutor and linked to Wiki contributions. This activity was crucial in the software development process with all the other group tasks building on this. Each of the learner groups was required to complete a report as part of their assessment. In summary, the learning was designed based on active participation in learning. The recordings were listened to by the tutor and a selection was sent to the internal examiner in keeping with quality assurance procedures. Following internal moderation, a sample was made available to the external examiner on a DVD, for scrutiny.