The approach being taken in this research is a device-based approach in a discovery learning environment with the teaching of procedural skills. A domain model is used as the basis of the environment and is presented to the user. This is very similar to a real world device or the environment that is being modelled. The user can then perform actions within this environment and can witness the effects this has on the elements of the domain. Varied levels of feedback can be supplied, dependent on the domain being modelled and the demands of the user.
The actions that the user can perform in a domain can be roughly grouped into one of six action types: correct, p re m a t u re, des truct ive, red u n da n t, impossible and u n k n ow n .
Correct actions are valid in a domain and do not cause any detrimental effects on the modelled domain. These actions are reversible, so that any effects that the action has had on the current domain situation can be undone. Premature actions are ones which are valid in the domain but that have preconditions for enablement which are not currently satisfied. They are not necessarily premature in terms of the time sequence of a tutoring session, but are premature in regard to the action that is currently being attempted and its unsatisfied preconditions. Destructive actions cause effects on the domain that are not reversible. Redundant actions produce an effect that is already in place in the current situation of the domain. These can be repeated with no change to the current domain. Impossible actions are valid in a domain but due to some circumstance are no longer possible. These usually occur after a destructive action. If an action is tried that is not valid in the current domain then it is an unknown action. Only limited feedback can be supplied after an unknown action since the context of the action may be impossible to determine.
After an action is attempted, immediate feedback can be given to a user. Similar success feedback can be provided after correct, destructive and redundant actions. Success at completing an action and any other effects on the environment can be relayed to the user. After an impossible, unknown or premature action the environment is not changed but the user still needs to be notified that the action was not successful. Typical
user responses after these types of actions are why or how queries. Five general help commands are used to provide appropriate user requested feedback. These are help, commands, hint, why and how.
The commands command is the most basic general feedback command. It provides a list of all the valid actions in the current environment. A subset command to commands is the help command. It provides a list of only the currently valid actions in the environment. After this command, only the correct, destructive and redundant actions are listed. The hin t command is related to task completion in the environment and provides a suggested action for the next step towards a current goal. This will be discussed later in section 5.5.
The why command is used to provide a second level of feedback after an unsuccessful action or as justification after a successful action. Figure 5.1 shows typical feedback generated after a why command.
Feedback Type Feedback
Why - after a correct action. Action X_action added Y_conditions to the current situation.
Action X_action removed Z_conditions from the
current situation.
Why - after a destructive action. Action X_action added Y_conditions to the
current situation.
Action X_action permanently removed Z conditions.
Why - after a redundant action. Action X_action added nothing to the situation.
Action X_action removed nothing from the
situation.
Why - after a premature action. Action X_action is premature in the current domain situation.
Action X_action conditions Y _conditions are not
satisfied.
- after an unknown action. Action X action is not in this domain.
The how command is typically used after a why command. It has a more limited scope as it can only really be used after an error action. After a successful action, the how command has no meaning. The responses for the three error action types can be seen in Figure 5.2.
Feedback Type Feedback Response
How - after a premature Condition Y_conditions is not satisfied. action. To satisfy condition Y_condition try action
X_action.
How - after an unknown Action X -action cannot be done in this
action. domain.
How - after an impossible Action X_action can now no longer be
action. completed .
Figure 5.2 : Feedback from the how command.
The actual responses generated by the feedback operators described above are best seen in an example. Figure 5.3 shows part of a dialogue in a car maintenance domain. The task the user is currently trying to perform is to remove the tyre of a car. The dialogue has a pictorial view of the domain and has a text component that is in three parts. Firstly, the current situation in the environment is listed. Then a user command is described (in italics) and finally, the feedback response from the system that is appropriate for that action in the current circumstances is given.
The dialogue for steps ( 1 ) and (5) are the standard positive feedback messages that accompanies a correctly completed action. Step (2) shows a premature action where a valid but currently unenabled action is tried. Steps (3) and (4) are typical responses to a premature action. Firstly, the cause of the failed action is defined and then a possible solution to overcome the problem is provided.
Step (6) provides a reason after an action is correctly completed. It allows the user to see exactly what effect their last action had on the environment. Steps (7) and (8) are examples of the use of help and hint feedback.
[ j ac k ( ava i l abl e ) , wheel_brace ( ava i l able ) ]
Command? use jack
Ok .
[ j ac k ( up ) , wheel_brace ( avai lable ) ]
Command? remove nu t 1
That cannot be done at the moment .
[ j ac k ( up ) , wheel_brac e ( ava i l ab l e ) ]
Command ? why
The c o nd i t i o n : c a r ( on , j a c k ) i s n o t
( 3 ) s at i s f i ed .
[ j ack ( up ) , wheel_brace ( ava i l abl e ) ]
Command ? how
A s tep towards car ( on , j ac k ) i s ' us e j ack ' .
[ j ac k ( up ) , whee l_brac e ( ava i labl e ) ]
Command ? use jack
Ok .
[ j ack ( ava i l able ) , wheel_brace ( ava i l abl e ) ) Command ? why
After ' us e j ac k ' , j ack ( up ) was removed from
the s i tuat i on and was added .
[ j ack ( ava i labl e ) , wheel_brace ( ava i l abl e ) ) Command ? help
( 7 ) Va l i d commands at thi s point are :
' p lac e j ack under car '
' s tore j ack '
' s tore whee l brace '
' u se
[ j ac k ( ava i l able ) , wheel_brace ( ava i lable ) ]
Command? hin t
( 8 ) A de s i rabl e s t ep at the moment wou l d b e
under car ' .
Figure 5.3 : Example of feedback dialogue in a car maintenance domain. The help, commands, hint, why and how commands are the base level user requested feedback commands. They help the user at a local level in the exploration of an environment to gain some extra feedback from the system. More task oriented feedback is provided by task feedback.