The last week was rife with technological progress on our side. We have been putting better architectural rails around our initial prototype and we are seeing the core functions of the Interactive Tutor taking shape.

I’m proud to announce the first iteration of the Interactive Tutor! We have a demonstration movie for you that shows the user interface (we’ll discuss more about the internals right after) :

How does that all fit together? Well, there are three big concepts that support this version : the Finite State Machine, the Actions and the Event Filters. The Finite State Machines (FSM from here on) describe a chain of logical states that the student must go through in order to learn the new features. In each of these states, there are actions that the tutor must take to interact with the student, and there are transitions to other states associated with events.

The actions represent the yellow text bubbles that you see popping up when the FSM changes state. An action might also be graying out controls or awarding the student a trophy : in short, it’s anything that interacts modifies Sugar!

The events themselves are caught by the Event Filter. When the FSM enters a state, it registers all of the Event Filters corresponding to the state’s outgoing transitions. These filters register themselves as listeners for their respective events, either an internal command (like a timeout) or a GTK event (like a button click). When that event is triggered, the Event Filter warns the FSM that it needs to go to the next state it points to.

Wrapping up : we have a data model to describe tutorials now, based on states with actions and transitions by events. The following question arose a couple of time : “How can you tell that by following events like those at the GTK level, you will be able to properly interpret them and know the right state of the activity?” In the worst case, if we don’t interpret an event correctly or if we don’t have enough information to do so, there might be differences between the real state of the activity and the state perceived by Tutor, leading to wrong indications to the student. That’s one of our big concerns, and we are making the following two assumptions in order to say that it will work.

1. Tutorials will be generated by teachers running the activity inside a ‘recorder’, that will listen for all the events triggered during the use of the activity. This recorder will then create a list of possible events and let the teacher interpret them properly. This means that people understanding the activity’s model will be creating the links, preventing us from having to do it automatically.
2. We will be able to limit the interactions between the student and the activity, so as not to fall in an unknown state. That implies disabling buttons and blurring unused regions of the UI. We might even go as far as hijacking the Sugar Journal functions to save the state of an activity and reloading it before starting a tutorial, thus having it in a known good state.

Of course, those concerns are bit further down the development road! We’re just looking ahead a bit. For now, you can either take a look at our gitweb or directly access our repository to review our first iteration. Your feedback is invaluable and we look forward to hearing from you! Is the event handling system extensible enough? Are the FSMs well structured and expressive enough? Give it a whirl and tell us what you think.

Tagged: architecture, Event Filters, feedback, finite state machine, Interactive Tutor, try it out!