Time to start writing about the Groove Tour. This may be interesting to people who want to build with the Groove EIS; also more generally to provoke thoughts about distributed, coordinated applications. I'll start here; if there's more you want to know about what or why or how, then please ask.

[Aside: this is unstructured train-of-thought doc. I already have some internal-use developer doc, and this is different. If there's a good way to convert train-of-thought into structured documentation without breaking its readability whilst in progress, I'd be interested to find it. Documentation has two time-and-space domains: "in progress" (linear time, nonlinear content) and "wrapped" (linear content, nonlinear time). Meanwhile I'll just dive in and say things as they occur to me.]

The aim of the tour framework is to make a little, generic, "conversation engine" inside Groove. The first application of this is a self-paced guided tour of Groove. You begin with some slideware, introducing Groove Workspace. Then an instant message arrives from a co-worker (a bot). You reply to the message, and wind up inviting this "person" into your shared space. Then you add some tools, and hold (primitive) conversations using those tools (and chat).

To implement this, there's a very loosely-coupled pair of state machines: one at the client, and one at the bot. Each state machine runs a script, through which interesting events are processed. Most of the events are transparent across the network connection, so that the bot sees what's happening to the client (at some level), and the client sees events which originated at the bot, too. There's some optimisation to keep the chatter down: "timer" events aren't disseminated, nor are windowing events at the client, nor are instant-message events (although that's mostly to protect privacy, rather than to reduce chatter). There's a hard-wired restriction right now that the tour involves just two participants: one user, and one bot; there's not good reason for that, and it's not a big deal to remove later.

The other aim of the tour framework is that the state-machine's scripts be editable by a non-developer. That's a hard aim to meet, since I don't really know what a non-developer is. In this application it means: you don't need to know much about programming. You still need to grok the hard bit, though: coordinating actions at two locations, using separate (and loosely-coupled) scripts, to achieve some didactic purpose. To see how that works, here's an example of the script code. (This is XML and JavaScript. Maybe a better format would have been better. I don't know.)

In the client script:

<t:Stage Name="*">

    <t:Action Trigger="Chat" Param1="/^stop/i" Param2="user">

        tour.Trigger("GoEnd");

    </t:Action>

    <t:Action Trigger="GoEnd">

        if( ui.MessageBoxYesNo( "Do you really want to finish the tour now?" )=="YES" )

            tour.GoTo( "TourComplete" );

    </t:Action>

</t:Stage>

In the bot script:

<t:Stage Name="TourComplete">

	<t:Action Trigger="Initialize">

		tour.StartTimer();

	</t:Action>

	<t:Action Trigger="Timer" Param1="3">

		var sMsg = "Your Groove Tour is complete now...\nCongratulations.";

		tour.SendIM2( tour.GetUserURL(), sMsg, "c:\\thankyou.wav" );

		tour.DeleteSpace();

		tour.StopTimer();

	</t:Action>

</t:Stage>