THE HUMAN-COMPUTER INTERACTION PROBLEM
When learning a subject by the help of a tutor program, the student must interact with the system, and this interaction probably differs a lot from his earlier experiences of a human tutor.
The learner must connect the new pieces of information to his earlier knowledge. These new pieces are stored in the tutoring program. Therefore the learner must now take the role of an user of the tutoring program (Mandl & Lesgold, 1988, p 167) He has to build up an inner model about how the program is working and what it´s components are. This model of the user may differ from the model of the programs designer.
An important point when the learner builds up his model
is the interface of the program. A well designed interface makes the user understand the goals and concepts that are important to him as well in understanding the subject being studied. When thinking of what is a good interface, we have to again consider who is the user; his past experiences and capabilities. It is also important that the interface should match the domain. There are different styles of interfaces. First-person interfaces allow the user to work directly with the domain, he can for example manipulate graphic objects by selecting icons that represent data structures and procedures. In second-person interfaces, the user can give orders to the system processor, for example by using command language. Menu systems fall between these two types of interfaces; they present information that the user can select (second-person) and specify in a direct way (first-person) (Polson & Richardson, 1988, p. 154).
There are problems to solve when building an interface. A conceptual model of the program guides the user to imagine possible ways to handle problems and errors. A good conceptual model should offer clarity and have a high degree of coverage; it should explain as many aspects of the interface and domain as possible. It should also offer a sound level of abstraction of the system; to allow the user to make strong and correct inferences about the interface and domain. It should still be so general that the user is able to look for (when necessary) and accept differences between literal intepretation of the model and the applicated domain ( Polson & Richardson, 1988, p.145). It may be difficult to build a conceptual model that has all these capabilities. A simple model may be clear but may not be so high in abstraction when presenting the domain. An other problem is about task-mapping; the distance between the users goal with the program and the actions that the program makes available for the user in order to reach this goal.
There exist several interface technologies between which it may be hard to choose. They can for example use text, graphics, voice or typing.
The style of the interface depends of the domain in question. One technique is better than the other in one case and worse in another. We also have to investigate and find out more about human´s cognitive capabilities, which set limits to the users understanding ,in order to create better programs (Polson & Richardson, 1988).These capabilities cover for example a humans memory capacity which is very limited.
We also have to take into account that a human perceives his surroundings through senses. Therefore to attract the users attention, we should perhaps investigate more about how senses adapt to the surrounding. Would it for example be better to use strong or mild colors in the monitor and how should movement in the screen be applied. One important fact is also that a computer never gets bored, but people do. Therefore a program designer should keep in mind that the program should be interesting enough to hold our concentration. The atmosphere and outlook of the program are almost as important as the informational concept of it.
Tillbaka till sammanfattningen - Till litteraturlistan