A glass Box Approach to Adaptive Hypermedia
Initial Interviews With Users of SDP
Download 0.88 Mb.
|
- Navigate this page:
- Method
- Using SDP
- Available Help Sources
- Summary
Initial Interviews With Users of SDPThe first study in PUSH corresponded to the early phases in CTA where the aim is to get a grip of the whole problem situation. As proposed in CTA we used free interviews in this work, and we interviewed both experienced and less experienced users. The initial interviews described here were done during autumn 1993 by Catriona McDermid and Anna-Lena Ereback, (McDermid and Ereback, 1994). At that time SDP had recently been introduced and the method was quite unstable and was frequently released in new versions. So this should be seen as a snapshot of users’ feelings about a method still in its infancy. What we report here are first and foremost the problems users of SDP experienced, not the advantages. We have summarised the results from the study due to the secrecy restrictions imposed by the former Ellemtel. MethodThe initial interviews were informal. Users were asked to give their opinions on SDP and its usage. Fifteen subjects were interviewed. Most were software designers. Their knowledge of SDP ranged from those who had only recently had initial training in SDP to those who had had practical experience of an entire design project using the process and those who had several years’ experience of design projects using the methods used prior to SDP at Ellemtel (AXE-10). The interviews lasted between thirty minutes and two hours. They were tape-recorded. Most interviews were conducted with individual users, but two were conducted in small groups. The analysis of the interviews is centred around two themes: using SDP and evaluation of available help sources.
Among the important underlying principles of SDP, we can note the life-cycle perspective and the object-oriented analysis and design, all of which pose difficulties to our users. Users had difficulties with applying the life-cycle perspective taken in SDP. They wanted to find information on how to sequence the processes. This was particularly difficult to users who were experienced in the water-fall method AXE-10, used previously at Ellemtel. Connected to this problem was knowing when a certain process should be considered to be finished, and the next process to be started. In fact, the designers of SDP emphasised that the correct approach was that any process could be started at any point in time. The important question to ask is when to ”close the door behind you”, i.e. when a process is finished. Still, there were not many clues given to users on how to evaluate their work and determine when a certain process should be finished. Since SDP is a method that should be applicable to many different kinds of projects, all parts of the method are not equally important for every project. A problem for users was to decide when certain stages of the method could/should be omitted. The other important principle underlying SDP is the object-oriented analysis and design. Users seemed to have problems in how to apply the object-oriented style of problem solving. They expressed a gap between the SDP theory and practice, and felt that little support was given in how to go from the abstract theory to actual realisation of the object-oriented thinking. In particular, those who had worked with the previous more procedurally oriented method AXE-10, had difficulties in grasping the ideas around object-oriented thinking. In fact, our later studies showed that several of the very fundamental concepts in SDP and in object-oriented methods in general, are fuzzy. What has to be communicated is a way of thinking, a way of solving problems. Since object-oriented thinking is a paradigm shift from procedural problem solving, it should be treated accordingly in courses, documentation, etc. Available Help SourcesSince we were interested in how we could design a good help system on SDP, we needed to see how well the available information sources worked. As mentioned above, there existed an on-line manual on SDP, implemented in FrameMaker. At the point in time when the interviews were done, there was also a paper back version of the manual. Users of SDP also went through a four day course on SDP. Finally, they had access to the developers of SDP through the SSN network – a network where users could query the developers of SDP about various issues utilising News, local experts, e-mail, etc. In these interviews (and also in our other studies) we found that many users did not use the manuals at all. They relied entirely on receiving instructions from their supervisor and local experts. Among those who used the manuals, the gap between the theory and practice was emphasised again. Users lacked concrete examples in the manuals. They also felt that there was too much information. Information was repeated and standardised information cluttered the texts. Since there was no index to the manual it was also difficult to get to the right topic. Users asked for tailor-made information rather than many, quite general, documents. The on-line manual was found more useful, than the paper back version. Users often fetched template information (which helps them to create an instantiation of an object type – which IEs to create, which format they should have, etc.) and apply it to their project tasks from the on-line manual. SummaryIn the interviews, many users complained about the lack of information, but at the same time they were overwhelmed with information. Partly, it is true that information about SDP was not complete at that stage: for example, the manual lacked examples of how to apply the method. But even so, it seemed as though even when the information was there to be found, they would either not find it or not understand it once they found it. So one part was a navigation problem: users lacked powerful tools that would aid them to search for information, examples, guidelines etc. The other part was in making the information useful and understandable to users. Another problem that came through in these studies was the need for user motivation when introducing SDP. If people are not motivated to use SDP, or feel too time-pressed to learn it, they will tend to misunderstand and misuse the method no matter how well it is explained. An underlying problem might have been the switch from traditional software development in a water-fall model, to the object-oriented life-cycle software development in SDP. The whole approach to specification, implementation and testing changed completely. Directory: ~kia -> papers ~kia -> Usability and fun An overview of relevant research in the hci community papers -> Comparing Two Approaches to Context: Realism and Constructivism ~kia -> B. Cahour (1), P. Salembier (1), Ch. Brassac (2), J. L. Bouraoui (1), B. Pachoud (3), P. Vermersch Download 0.88 Mb. Share with your friends:
|