Discussions

In Stage 1: Needs Collecting, the coordinators must be very clear in which situation they needed to intervene and to what extent. In the needs collection stage, especially at the beginning, the students were always impatient to start exploring solutions to satisfy the proposed needs, rather than focusing on collecting needs, so the coordinators had to stop them in time. In Stage 2: Task Sequencing, personas and scenarios were used to capture the requirements of the system. One of the best practices is to identify primary personas, ‘the individual who is the main focus of the design’ [38]. To be primary, a persona is ‘someone who must be satisfied but who cannot be satisfied with an interface designed for any other persona. An interface always exists for a primary persona.’ [37] With regard to scenarios, storyboards or customer journeys were used to test the validity of design and assumptions. The students had to be encouraged to design an appropriate level of detail. In Stage 3: Prototype Designing, some solutions might be found to be flawed to some extent, either by the students or the coordinators. In such a case, the risk was that students might be unwilling to fix flaws or they might need extra time. The coordinators had to encourage them to get the solution as well as control

68

the time, because even if the work was incomplete, the highlighted issues could still inspire the designers.

In Phase II: Application Synthesis, the designers arranged the requirements proposed by the students, the descriptions of content-based requirements. It is always possible for the designers to misunderstand the original meaning intended by the students. Hence it is necessary to show the reorganised requirements to the students, and ask them to check whether the requirement list is consistent with their original ideas. Finally, the students were asked to confirm the resulting requirement list, to ensure its closeness to their original desires.

Overall, the students willingly contributed to generating the requirements for the system design according to their intended learning outcomes, previous knowledge and e-learning experience. They were satisfied with both the experiment and the knowledge they acquired during the experiment. Some of them mentioned that they really enjoyed this type of design process and learnt what was a Participatory Design. From the system designer’s perspective, the requirement list obtained represents a generic level of detail into the requirements definition, which was collected as natural language statements describing what services the system was expected to provide. Besides, these requirements created a common vision between the students and the system designers, to make sure the system that would be developed was what the students really needed.

Facebook is the biggest social networking website in the world. It has 802 million daily active users and 609 million mobile daily active users on average in March 2014 [203]. However, most people use Facebook for entertainment [179] rather than learning, which is why the questionnaire result shows that only 16.7% of the students chose that they have ever collected learning resource from Facebook.

Another interesting result is that half of the students chose ‘Compulsory to Use’ as a reason to use an e-learning system. This might be because the systems are hard to use, or the students are not confident to use such systems. Therefore it is necessary to evaluate and analyse existing e-learning systems, in order to find out how to improve them, or how to design a better new system. The opinions of the systems’ end-users, the students, are very important, and many aspects (e.g., system usability, accuracy of recommendation, intended learning outcomes, learning context) of the systems need to be taken into consideration. Therefore the evaluation should be conducted by using a multi-dimensional approach [127].

The main difference of this experimental study from the original We!Design framework was that all the students who participated in the design sessions were asked to answer a questionnaire, more information could be collected about the system design requirements. Although the coordinators were trying to avoid transferring their own opinions in the design session, it remains possible that they could still have influenced the students. In contrast to the design sessions, the questionnaires have uniform questions, but no middleman bias, and the research instrument does not interrupt the students. Besides, the structured questionnaires

70

enable the responses to be standardised, hence easier to analyse. The questionnaires were delivered after the application synthesis phase, because on the one hand, as the designers had already analysed the requirement proposed by the students, they would be able to ask pointed questions to further understand students’ opinions, and on the other hand, since the students had already gone through the design session, they might like to have more chance of proposing extra expectations as well as helping the system designers to understand the priorities of the previously extracted requirements.

One issue to raise here is that although the software engineering knowledge of the computer science undergraduate students could help shorten the design duration, as the author of the We!Design framework stated [180], this might also have limited their ability to create a domain-independent e-learning system. For instance, they mentioned the importance of tools for practice courses such as those of programming languages, but they did not consider multimedia delivery as highly important, when for instance, for art and social science subjects, the quality of multimedia transmission and presentation might be very important.

3.9

Conclusions

This chapter has described the experimental study performed to gather issues and initial preferences for the overall research. The We!Design framework has been applied in this work, in order to investigate needs of the learners, the end-users, of a social personalised adaptive e-learning system. The main outcome of this chapter

is that a list of initial system implementation requirements has been extracted, based on which the initial social personalised adaptive e-learning system has been developed, detailed in Chapter 4.

Additionally, this chapter has also explored how to better apply Participatory Design (PD) methodology in the early stage of system development. The We!Design framework has been further developed with some advice for better conducting such experiments. The main difference from the original We!Design framework is the combination of the additional questionnaire survey, which provides more information about the system requirements from an end-user point of view, and avoids middleman bias produced by experiment coordinators.

In conclusion, the study presented in this chapter has addressed the research objective O2: “exploring and understanding the needs of the learners for a social personalised adaptive e-learning system, aiming at gathering the requirements for the implementation of the research environment”. The process of addressing this research objective, and the results – section 3.7 Suggestions on System Requirements – have contributed to answering the research question R1: “how can we synthesise social interaction and adaptation techniques and technologies, in order to ensure e-learning systems provide a high level of effectiveness, efficiency, satisfaction, and engagement amongst learners?” These suggested system requirements are further implemented in the initial social personalised adaptive e- learning system (Chapter 4), in order to answer the research question R1.

Initial Social Personalised Adaptive