Tutorius integration proposal for Sugar 0.90

Here is a proposal to integrate a tutorial system into the next release of Sugar (0.90). This proposal builds on top of the work done on Tutorius during the last year and attempts to provide a draft version to be improved by community feedback. First, a high-level overview of the result expected is discussed and mock-ups based on screenshots are used to illustrate the idea. Second, the technical feasibility is discussed given what we learnt during the last year. Third, a roadmap is suggested to take into account the release calendar of Sugar.

Overview

The proposal consists in providing a default interactive tutorial for Sugar that will give an overview of the particularities of the Sugar interface and activities. This tutorial should be accessible from the first login screen, right after the color selection, and from the option menu:

login

options

The tutorial will provide an overview of the Desktop, the Group and the Neighborhood Views as well as the Frame, the Journal, the Write and the Browse activity. Here are screenshots of what it might look like for some of them.

desktop

neighborhood

journal

write

The information presented to the user will be essentially composed of bubble messages pointing at screen elements. Progress through the tutorial will be accomplished by the user clicking a next button at the bottom of the screen. Once the tutorial is over, the user will be brought back to the Desktop screen where she will be able to resume interacting with the system normally.

The tutorial should be stored in the user home directory, alongside any activity data, as an XML file representing the execution states of the tutorial.

Translation of the tutorial should be made using the gettext convention by storing translations of the tutorial strings along side the XML file using the gettext schema (.po, .pot, .mo files).

The tutorial should be independent of the screen resolution.

On top of that, the tutorial should be designed to be robust against unscripted actions made by the user. It means that if the user clicks on any button while the tutorial is showing the different elements of the interface, the tutorial should never become out-of-sync with the state of the interface in a way that cannot be resolved by the user. The examples given previously simply rely on the user pressing the next button when she is ready to move on, therefore issues about the exact state of the interface should be avoided.

For the 0.90 release, the tutorial won’t be user modifiable other than by modifying the XML format by hand, which won’t be recommended.

Feasibility

The major part of the system has already been developed as part of the Tutorius project, that has been running from January to December 2009. The subsystems that have been developed include:

  • An engine to run tutorials through many activities
  • An XML format to save tutorials to disk
  • A translation scheme for user-visible strings based on gettext
  • A rendering mecanism to display custom defined drawings on top of an activity or on an overlayed window
  • A communication mecanism between the engine, Activities and the Shell to send information to be displayed (Bubble Messages) and receive events generated inside the activity based on dbus

    • However, a number of issues prevent the current system from being able to run the aforementioned scenario:

  • Current Bubble Message positions are pixel defined. Therefore, they are not resolution independent
  • A transparent window cannot be reliably overlayed on top of each Shell view, preventing Bubble Messages from being displayed on those
  • Assessement of the security of the communication mecanism between the engine and the different Activities must be done to make sure that we do not break the security scheme already in place

    • Those are the major issues that will need to be worked out to make the system works and the integration smooth.

    Roadmap

    A tentative high-level roadmap is proposed, taking into account the roadmap to Sugar 0.90. The major difficulty anticipated is having the code reviewed, understood and integrated in the Sugar mainline by core developers. To ease the transition, the current system will be rebased on top of the latest release of Sugar (0.88), so that a patch for sugar and sugar-toolkit will be easily derivable. Also, a custom build of SoaS with the Tutorius system will be made available for testing. This roadmap is subject to changes if a better order is found to facilitate a progressive testing by the NZ team.

    March

    Discuss with the Sugar community about the proposal
    Specify the content for the introduction tutorial
    Rebase the current Tutorius code base to Sugar 0.88

    April

    Produce a new SoaS image with Tutorius based on Sugar 0.88
    Fix the window stacking to correctly overlay bubble messages on top of Views and the Frame

    May

    Migrate the Bubble Message position rendering from absolute to relative
    Fix remaining minor bugs

    June

    Make sure localization of Tutorials correctly works
    Add the logging screen option for the introduction tutorial
    Add the option item to replay the introduction tutorial

    July

    Produce a first complete Tutorial
    Produce documentation for the localization team to translate the Tutorial

    August

    Bug fix
    Revision of the Tutorial
    Help with the release effort

    September

    General help

    Please contribute any relevant comment below!

    Published:
    March 7, 2010 – 3:16 pm
    Author:
    By Erick
    Categories:
    Comments:
    None

    More progress with a second iteration

    We’ve been working hard this last month to further advance the Tutorius core and to assemble a somewhat rudimentary but simple-to-use editor. Again, we know that words are not enough, unless they come from a YouTube video broadcast so here’s one for your viewing pleasure.

    This means that we now have an easy and friendly way to create tutorials. Even if the editor is rather limited, as it only allows to edit linear scenarios without the ability to modify what has been done, it still is a large step forward for tutorius as we start bringing usability to the project. We plan to further refine the included tools to add more/better input validation, along with more actions and the ability to replay events.

    And what’s new on the architecture side? Well, first we did a lot of cleanup on the tutorial file format. By defining an XML format instead of the previous pickle format, we hope to facilitate the sharing of tutorials while avoiding some vulnerabilities of python pickle. We also refactored actions to have better introspection for editable properties, so we can now edit them live in the editor.

    Published:
    May 2, 2009 – 12:27 pm
    Author:
    By Simon
    Categories:
    Comments:
    2 Comments

    First Public Presentation!

    On April 1st, I gave a presentation of the Tutorius project at my current internship job.  At first, I was a little unsure about my English public speaking skills but it turned out to be good enough to be shared ;-)   The whole presentation last 30 minutes, 15 minutes for the presentation itself and the demo and 15 minutes of quite interesting questions!

    Here is a quick break down:

    1:03 Roots
    3:41 Need
    5:00 Opportunity
    5:26 Inspiration
    7:36 Tutorius
    8:41 Design Goals
    10:43 Demo
    15:08 Questions

    I’ll be looking for your questions, comments and suggestions in the comment section!

    Enjoy!

    Published:
    April 11, 2009 – 11:47 pm
    Author:
    By Erick
    Categories:
    Comments:
    None

    Tutorius is now more social

    There are many ways to stay in touch with us, give us feedback and get involved. Because we are looking to build something way stronger than a piece of software and because we like to stay accessible and visible, we are trying to use the most popular medias out there to communicate. If you like what we do, here is how we can keep in touch:

    feed2RSS feed

    That’s an easy one of course, make sure you are subscribed to our feed so you get all the latest and official news: Tutorius RSS Feed.

    youtubeYouTube Channel

    We’ve already published a screencast and we are planning to publish more as the project grows. For this reason, we have created a YouTube Channel you can join so you don’t miss any video update.

    IRC

    If you want to chat with us and ask questions about the project, it’s one of the best way. Join us in the #tutorius channel on Freenode.

    twitterTwitter

    If you are on twitter, we have a twitter account so you can follow us and get some news about tutorius, Sugar and OLPC. Our twitter is not dedicated to Tutorius only, it’s a sharing point for everything related to Sugar/OLPC/Tutorius.

    facebookFacebook

    Of course, we have a Facebook group. If you are a Facebook addict, join the group here: Tutorius Facebook Group.

    linkedinLinkedIn

    We proudly show our professional network that we are part of this great project. You can join the LinkedIn group and stay in touch with us if you’d like to do the same.

    Tagged: , ,

    Published:
    April 3, 2009 – 1:41 pm
    Author:
    By Ben
    Categories:
    Comments:
    1 Comment

    Getting your hands dirty

    So you’ve seen the first iteration, you’ve checked out the code and you want to get coding? Sure thing! Since we would appreciate any help, we are even willing to give you a bunch of spoilers! Here is a quick rundown of what you absolutely need to know:

    Where is our code?

    In our git repository, you will find a lot of things. But a lot of that is the original sugar code and a bunch of libraries that are bundled with it. So, which folders are interesting?

    • source/activities : Different activities developed or modified by us for testing/demo purposes
    • source/external : Working jhbuild environment for building and testing. In there, install/share/sugar/activities/ is your friend for adding activities to the test environment.
    • source/external/source/sugar-toolkit/src/sugar/ : Sugar Toolkit sources. So far we have played a bit in the sugar toolkit, but most of our work is in the tutorius folder in there.
      • tutorius/core.py: Finite State Machine, Tutorial and States. Those are the big gears that make everything turn
      • tutorius/filters.py: EventFilters that allow defining State transitions
      • tutorius/actions.py: Actions that can be executed when entering a new State
      • tutorius/gtkutils.py: Utility functions for playing with Gtk object hierarchies
      • tutorius/services.py: Currently contains only the ObjectStore “service”
      • tutorius/tests: Our tests
      • activity/activity.py: A few changes have been made to the ActivityToolbar to allow launching Tutorials
    • docs/: We keep documents there. Some are reports written for our classes, but the main areas of interest should be the arch and Design subfolders. There is a small amount of stuff there, including some ArgoUML class diagrams and use cases.
    • Branches : We are a small team of people working on this, and we should try to push everything into the master branch. So far, though, there might be a few new features in some of our branches. So far, mike, simpoir and tutorial_toolkit have the most stuff.

    So now you know where most of our interesting stuff is. You should be able to explore on your own if you feel adventurous. If you do, you can use the small amount of docs we have to help you, and tell us where it is lacking the most.

    What does the code do?

    Now, if you want to understand how current tutorials work, here is where you should be looking:

    1. Tutorials are defined in the Activity code itself for now. They are listed from the activity’s get_tutorials function.
    2. The sugar.activity.activity.ActivityToolbar uses get_tutorials to create a combo box to choose tutorials from. A callback triggers attaching the tutorial to the activity via Tutorial.attach()
    3. The tutorial’s FSM is set to the initial state, and everything begins. Actions are performed, EventFilters are installed. The tutorial runs.

    Apart from that, you should note how widgets are resolved for EventFilters. A treeish string in the form “0.1.0.0.1.2.1.0.0″ is what we currently use as identifiers for widgets. This represents the path to take down the GtkWidget hiearchy, starting with the Activity itself. Each step has an index in the current widget’s children list. It is possible to obtain those numbers via the gtkutils functions by registering event filters on the whole widget hierarchy, and logging the events by sending them to a default handler that logs the widget name and event name. The Tutorial editor will make this easier, and and in the meantime there is a WidgetIdentifier that allows viewing some events in an activity.

    That is really the base, there are plenty more things to know.

    What can you do?

    If you are searching for something to do, check the project page on launchpad. It has our bugs and tasks so far. We should be adding a lot more tasks and bugs once we go through our current list, and through the code looking for FIXME’s. Also, if you have great ideas feel free to email us or file a bug on launchpad. You can also try to find me (vvinet) on freenode irc in #sugar or alone in #tutorius.

    Published:
    March 20, 2009 – 9:05 am
    Author:
    By Vince
    Categories:
    Comments:
    2 Comments

    The First Iteration of the Tutor

    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: , , , , ,

    Published:
    March 11, 2009 – 10:33 pm
    Author:
    By Mike
    Categories:
    Comments:
    2 Comments

    The Three Main Components

    We’ve spent quite a bit of time lately to prepare a presentation for our teachers on Tutorius. Not all of them were having a technical background, so we did a couple of diagrams to make sure everybody understood our Technical Holy Trinity : the Interactive Tutor, the Tutorial Edition Activity and the Community Web Site. The web site itself is having a lot of data on this already, so we’ll just go ahead and give you the eye-candy!

    Step 1 : The Interactive Tutor

    Step 1 : The Interactive Tutor

    The first step in promoting the usage of Tutorius will be to have teachers, developers and enthusiasts generate ideas and content for the platform. In order to enable these people to insert their tutoring ideas in Tutorius, we will be creating a Tutorial Editor. This will be a Sugar Activity that will enable one of these creators to generate a tutorial. You will be able to connect blocks to create a list of steps that the student must go through in order to learn what you want to show them, and you will be able to specify actions to take at each of these steps (display a texte bubble, change the color of an interface element, etc…). The goal of the Tutorial Editor is to make it extremely easy to create new tutorials.

    Step 2 : Sharing on the Web Site

    Step 2 : Sharing on the Web Site

    The second step is to browse the Community Web Site to fetch the latest and greatest tutorials that were made around the world. The web site will be featuring a list of the most popular tutorials, as well as a classification of the tutorials according to the various topics. Students will be able to select this content on the web and to install it on their own version of Sugar. We do not plan to make the Community Web Site mandatory to share tutorials; we wish to make it so that teachers creating their tutorials can share them via mesh network with their student. The brightest side of the Community Web Site is that the best content will be widely available.

    Step 3 : Interactive Tutor

    Step 3 : Interactive Tutor

    The third and final step is to have the Interactive Tutor guide the user in a variety of topics. The tutor pops up explanation text bubbles, highlights important sections of the interface and generally makes the life of the student easier with his programmed brain from a teacher. We’d like the tutor to be able to suggest new tutorials to the student, based on his actions and knowledge. Is the student hitting the backspace key a lot? Perhaps he would like to know about the Typing Activity! Or perhaps the student just finished a tutorial on turning text bold? Perhaps he’d like to know more about doing italic! The possibilities are endless.

    Our current development goals are to create a basic version of the Interactive Tutor, then begin right away the construction of the Tutorial Editor. These two components will be the main focus of our next two months, and we wish to release on a monthly basis. So I encourage you to get access to the source code of the tutorius_toolkit branch and give a look at the first version we made in the /tutorius/source/activities/Writus.Activity folder! We’ll be releasing further architecture details soon.

    Stay tuned!

    Published:
    March 9, 2009 – 1:19 pm
    Author:
    By Mike
    Categories:
    Comments:
    None

    On the importance of mentoring interfaces

    Just watched Program for the Future after having read Bill Kerr’s blog post. It strikes me how the comment from Alan Kay between 00:56:13 and 0:58:20 seems to apply to our project! (Bold from me)

    “[...] I believe for most education problems, having to do with things with we have deemed important for a long time [...] have to be handled by a user interface that can mentor its users. This is another one I would aimed at Google because, Google has every reason to actually be able to make a user interface that can teach its users new things because, that allows them to expand what user interfaces can do, not just what the actual applications can do.  So, this is another one of these very very deep, very important problems that has been part of the province of AI for litteraly 15 years  now and has not even been really funded with any strength that I know of over the last, at least, 15 years.

    [...]

    There has to be some set of processes that can help people learn, [...] that could make a large community that is actually at a higher level of skill than just at the entry level for decades and decades.  I believe we have to do that and just as a person who doesn’t hate user interface design enough not to do it at all, I believe this is where all the user interface focus should actually go over the next 5 years. If they can think about something that, as an interesting possibility like the OLPC initiative going in the third world, where we are putting a machine in the third world,  without shipping it with a teacher, that is better than no teacher, that is better than a bad teacher, it is not gonna have the impact that it needs. ”

    I am totally convinced that to be successful, the OLPC project must not only provide a platform that facilitate learning through educational activities, but also carries on with itself everything needed to improve the platform itself, not just the source code and the knowledge to modify it but also a way to present that knowledge so that users will acquire efficiently a proficiency to adapt the platform. This is were our tutor comes in.

    I must say that I have been following, for 3 years now, a lot of what Alan Kay brought to the table in terms of the fundamental possibilities the computer opens up, so it comes as no surprise that this project is tainted by his vision.  But still, it has been elaborated before I heard about this talk and I now have a(nother) confirmation we are working on something really important.

    Now let’s make it happen!

    Published:
    March 8, 2009 – 10:30 pm
    Author:
    By Erick
    Categories:
    Comments:
    None

    The birth of the Core

    The Tutorius Core was designed with simplicity in mind. In order to have any chance of being used by anyone but us, we needed to have a core that required little to no modification of activities to work. Another goal was to make tutorials as easy to edit as possible. Those two goals serve the common purpose of making it easy to create and edit tutorials, even for someone with little technical background.

    Before letting our brain do any work we started by hacking into an activity to generate a simple tutorial. The first tutorial was quite simple: how to turn text to bold in the Write activity. The first problem we faced was how to catch the different events in the interface and associate them with a concrete action. Catching the events was a simple matter of spidering down the GTK widget hierarchy and attaching an additionnal event handler to anything capable of generating events. Even though we then had all events, at that point it was pretty hard to tell if the bold button was the gtkButton instance at 0xb77a050c, or was it at 0xb77a093b? The widget hierarchy chain leading up to the button might have been a little better, but still it was tricky identifying the correct widget. The first solution to this problem was to name widgets using set_name. This allowed us to clearly know which button was pressed, focused or typed into. We added a little bit of control in the form of a rudimentary finite state machine – a dict in which keys are states, and values are a dict containing a message, and a set of possible events to catch that will lead to another state. This allowed us to create our first working prototype.

    Tagged: , ,

    Published:
    February 23, 2009 – 8:16 am
    Author:
    By Vince
    Categories:
    Comments:
    1 Comment

    So, you want to see the code?

    A new opensource project, cool! but where’s the source? As we make some change to the core of Sugar, we’ve setup our own repository which is a fork from the Sugar repository. We try to maintain it sync-ed with the sugarlabs git but it may lag a bit. A public git repository can be accessed at http://bobthebuilder.mine.nu/git/tutorius.git so you can fetch it from our build machine with:

    $ git init; git pull http://bobthebuilder.mine.nu:80/git/tutorius.git

    For the curious, you can also browse the repository from gitweb at http://build.tutorius.org/ . This may be more convenient as it allows to get a snapshot of a specific revision.

    As time of this post there isn’t much more than the forked code, so it may not be really interesting to look at but we plan to add stuff to it very soon. Rest assured that whenever we get something that compiles and do something we’ll post a built packaged version so that anyone can conveniently try it and tell us what they think.

    Tagged:

    Published:
    February 22, 2009 – 2:11 pm
    Author:
    By Simon
    Categories:
    Comments:
    1 Comment