Basic level exploration in a discovery learning environment allows the user to explore a domain with minimal system intervention. However, when procedural skills are to be taught, it may be necessary to apply some type of task structure over the domain material. This task structure can be passive and act as a guide or reference structure for the topic within the
domain to be covered. Alternatively is may be active and force the user to meet appropriate goals in the domain or to complete tutor-defined tasks.
Figure 5.4 : Example task structure for a car maintenance domain.
As the teaching area focused on in the current work is based on using a discovery learning environment, only limited support for task feedback has been developed. A hierarchical task structure is overlaid over the domain and defines the relations between the different goals in a domain and their sub-goals. An example task structure can be seen in Figure 5.4. This structure is used as the main component of the student task model (STM). Three feedback operators are provided to work with the STM. These are task, try and hint.
The task command is used to display the current state of the STM. The user may select this for two reasons. Firstly, to see their progress through the tasks set for the current domain or secondly, to aid in the selection of the next task to attempt.
Initial and subsequent tasks are selected automatically by the system once the previous task has been successfully completed. However, if the user wishes to complete an alternative task first, to change the focus of the session, this can be made using the try command. This command notifies the system that the user is now attempting a new task. Although this mechanism is laborious in a text version interface, it can be used effectively with a flexible graphical interface.
The h i n t command is used to allow the user to rece1ve task-oriented feedback on the task that they are currently attempting. The h i n t command uses either the local task information provided by situated control rules or dynamically creates a projection network from the current situation to determine what the next most appropriate actions would be. In the current implementation, hint feedback is limited to the 'best' candidate operator from the current situation. The best candidate operator is selected by finding the shortest path to the current goal node in a projection graph. Therefore, a complete path of operators from the current situation to the final goal state is not provided to the user, only enough feedback is provided to enable them to move closer to the final goal.
When task-oriented feedback is to be applied, both situated control rules and projection networks can be used to augment the feedback that can be generated. As the user is navigating through a domain space, pre-defined SCRs act as beacons or signposts for encouraged actions. Especially when a particular task is to be completed, SCRs are usually defined for critical choice points in the domain space where it is important that either the user makes some choice or is made aware that certain actions may be more appropriate. As the SCRs are constructed before domain navigation begins, they are a useful source of quick reference feedback.
A similar feedback technique can be used with projection networks but with the drawback that projection networks must be generated dynamically at run-time. Although this generation is not as efficient as the use of SCRs, projection networks can be generated from any domain situation and are thus more flexible and do not have to be explicitly defined by a tutor before the tutoring session is started.
The effectiveness of using the projection networks to find valid paths between current situations and goal situations is dependent on the level of detail that has been defined in the task/ sub-task model. If a detailed STM is provided, then smaller projection networks can be generated, while a limited STM may force the need for more extensive projection networks to be constructed.
[ j ac k ( ava i l able ) , whee l_brace ( avai labl e ) )
Command? task
Current goal = ' wheel removed ' .
[ j ac k ( avai lable ) , wheel_brace ( ava i l able ) ) Command? remove wheel
That canno t be done a t the moment .
[ j ack ( avai l able ) , whee l_brace ( ava i l able ) )
Command? try car on jack
Ok .
[ j ack ( ava i l able ) , wheel_brace ( ava i l abl e ) )
Command? hin t
A s t ep t owards the goal c a r ( on , j ac k ) i s ' p l ace j ack under car ' .
Figure 5.5 : Example dialogue of task feedback in a car maintenance
domain.
As seen in Chapter 5, the size of generated projection networks is an important issue due to the computational overheads of their generation. The size of projection networks can be reduced if appropriate sub-goals can be found early in the projection process. This breakdown of goals to sub-goals is not essential but does increase the speed of feedback generation and improves the continuity of the tutorial session.
An example of the use of the three task oriented feedback operators can be seen in Figure 5.5. User commands are in italics, completed tasks are greyed out on the task model and the current task has a double border around it. The task, try and hint commands are task oriented feedback operators and are made available to help generate feedback in respect to the local context of the domain environment and a student task model. To guide the overall performance of the user and to focus the user to a p articular learning method, teaching strategies are used to help enforce teaching methods.