empiriKit: empiriKit sensor units, 3D printed cases & more

empiriKit: empiriKit sensor units, 3D printed cases & more: Check out Ingemar's post on how we are building some of the hardware for empiriKit! - I am *very* excited that we are doing great stuff like this!  More to come :)

Localization is important

One of the larger obstacles in using material (books, software, etc.) from outside Latin America in Latin America is that it is usually only provided in English.  Unfortunately, many young students don't speak, read or write anything but Spanish, so it's important to think localization into solutions for this region from the very beginning.

With the technologies I have settled on for the Education Kit, this becomes an easy task for some parts and require a more creative solution for others.

The Client

Because the custom web client is written in pure Qt5 (C++ and QML), localization becomes quite easy here:

• Wrap all strings to be translated in qsTr("...") (some extra hacks needed to get QML to swap language on the fly)
• Modify the .pro file to inform which languages we want to translate to
• Run lupdate to create/update translation files for each selected language
• Give some nice red wine, chocolate and QtLinguist to the translators - and wait for the result
• Run lrelease to produce compact binary versions
• Enjoy! :)

The Server

As we would like the server to keep the settings and generally be able to dispatch any global configuration to remotely connected browsers fetching exercises, the server needs to support a few things:

• Getting the chosen setting information from the QML client
• Some way of storing the settings
• Provide the settings to connected web clients (both the custom client's WebView as well as remote clients, e.g. tablets, phones and more)

As a first shot, to get the information from the QML client to the node.js server, I chose to do a simple XHR from QML:

    function selectLanguage(value) {

        language.selectedLanguage = value;

        var req = new XMLHttpRequest();

        req.open("POST", "http://127.0.0.1:3000/settings/language/"+value, true);

        req.send();

    }

NOTE:  This will probably change to some cleaner direct socket call.

There is a corresponding handler on the server side:

    app.post('/settings/language/:value', edukitapps.setLanguage);

And now store and dispatch the information to all connected clients (using socket.io):

    exports.setLanguage = function(req, res) {

        var language = req.params.value;

        console.log("Setting language to: " + language);

        selectedLanguage = language;

        res.send("Setting language to: " + language);

        if (_io !== 0) {

            _io.sockets.emit("language", {language: selectedLanguage});

        }

    };

The Exercises (WebApps)

All visible texts in the exercises are surrounded by span tags with unique IDs, e.g.:

    <h1><span id="txt_color_mixer"></span></h1> 

When the application loads, it will include a settings.js javascript file that is auto-generated on the server side to include all kinds of user settings (for now - just the language):

    exports.getSettingsJS = function(req, res) {

        var str = "// This is the auto-generated settings from the server\n";

        str += "var _LANGUAGE = '" + selectedLanguage + "';\n";

        res.type("application/javascript");

        res.send(str);

    };

Inside the exercises, the language information can then be used to set the text strings, e.g.:

    function setStrings(language)

    {

        if (language === "es") {

            $("txt_color_mixer").innerHTML = "Mezclador de colores";

        } else {

            $("txt_color_mixer").innerHTML = "Color Mixer";

        }

    }

NOTE:  A more elegant solution is in the works - and it will most probably be based on pure socket.io .

Even if the WebApps are running in a WebView (WebKit2) in the custom built client, there is currently no easy way of for the QML to communicate directly with the content when changes happen as there was in the case of QtWebView (WebKit1) - or at least I haven't found any ;).

Therefore, the sequence of events happening from the user pushing a language selection button to the exercise visually changing the text strings is the following:

1. The user selects a language in the QML client
2. QML sends an XHR call to the server
3. The server notifies all connected WebApps of the change using socket.io 
4. All connected WebApps, including the one running inside the custom client, gets the notification and can act upon it

It may sound a bit complicated, but the result is instant and the code to handle it is simple on both server and client side.  Here is the required handler code in the WebApp:

    socket.on('language', function (data) {

        setStrings(data.language);

    });

What about the source code?

 This gets a bit more complicated to keep localized as the code should remain readable and functional.  However, it should also be OK to require for future software developers to learn a bit of the technical English they will encounter anyway if they choose to become proper developers.

The comments should be kept in a very clear and simple English - with the possibility for small extra translations in complex places.

NOTE:  This may change though - based on the feedback from future pilot tests in Latin America.

Working on the UI

Trying to keep the UI as simple and uncluttered as possible,  I have chosen to go with a design, where the running exercise (WebApp) is using the whole screen without any border, etc.

The only visible additions are the 2 (currently) tabs in the bottom of the screen.  One brings up the exercise overview and the other the settings panel.

Exercises are blueprints

The design chosen for the exercises themselves is done as if everything is an animated blueprint.  This was done to 

1. Make sure that the information in each exercise is always easy to find (e.g. no fancy colors distracting everywhere - unless the exercise is about distracting fancy colors ;)) - and
2. To keep the design simple for the students to be able to - fairly quickly - come up with their own applications to share, without the need to be experts in Gimp or Photoshop.

The application is made with Qt5/QML with some C++ mixed in, where needed.  This results in a smooth UI experience - even on RaspberryPi*

The panels

When clicking one of the tabs in the bottom, the respective panel appears to reveal a semi-transparent overlay with very simple functionality.

NOTE:  This is NOT the final design - I've left that for my graphics design buddies to help me with.

The exercise panel has three sections:

1. An exercise class filter (symbols representing chemistry, history, mathematics, etc.) to be used for fast filtering.  E.g. when a chemistry teacher wants to select among the exercises that link to chemistry, a simple click on the filter will remove all other apps from the list.
2. The actual list of exercises.  This is done as a scrollable (QML ListView) list of exercise applications, where each one has a title, an icon and up to 4 category markers (the same as the filters above)
3. Deeper information about the app that is selected or hovered with the mouse.

The settings panel currently has a few buttons - but will be extended with more juicy stuff.

One of the more relevant things already working though, is the ability to change language on the fly inside the client:

Selecting "English"

Selecting "Español"

What's missing?

I'd love to hear your input! - but please be nice... IANAGD!**

Some things I know I want to include:

• A way for students to do a simple login before performing an exercise (for feedback to the teacher)
• A way for students to see their results
• An exercise cloning tool and a simple exercise creator, allowing students to make their own exercises and share them with others, when the device is online.

* NOTE:  Sometimes, WebKit brings the RaspberryPi to it's knees, which is not the fault of QML.  I am working on ironing out the performance issues in the QtWebKit source and the exercises (WebApps) themselves so the final product will run like a charm (hopefully).

** I am not a graphics designer ;)

Introducing the Education Kit

UPDATE:  If you want to give a small donation to the project - I have made a bitcoin address for the purpose:  1HbqRbycQ9p4ntdNkR7MzYnpVaeyfXW1Ny

Since I first visited my wife's home town in San Luis Potosi, Mexico, I have been contemplating on how I could apply some of the knowledge gained through years of work as a software engineer to do good in a region that is very rich on natural resources - but starting to lose the battle against a declining economy, crime and most of all - brain drain.

In 2010, I started working with a technical high-school there on solutions that would boost the offering of educational content - and at the same time, introduce students to software development, empowering the teachers and students to do more, while not creating unnecessary overhead. 

After a great deal of iterations on different ideas and designs, we settled on a model that would give the best benefit to the students at a very low cost, utilizing technology already present:  Nokia S40 and other devices running J2ME apps.

Some years have passed and today we have a range of very affordable hardware available that can do much more than run simple J2ME apps.

The Education Kit

For the last half year, I have been working on creating a brand new experience, building on the same basic concept done in collaboration with the technical school in Mexico.

Some of the schools outside the larger cities in the areas I have been in in Mexico, don't have much more than an outside basketball court and a few connected rooms with chairs and a TV inside.  NOTE:  Of course this is worst case - but it's nice to know that the worst case is covered by the design.

The whole thing will be based around HTML5/WebApps and the primary target platform delivered, consists of a Raspberry Pi running a software stack with node.js on the server side and a customized Qt5/QML2 WebKit2 WebApps centric browser on the client side.  The Raspberry Pi may not be the most powerful board available, but it's quite affordable and connects to old and new TVs out of the box.

Why not use <insert your favorite technology here>?

The decision to use WebApps as technology for the exercises and not e.g. python or .net is the following:

• It is becoming the industry standard for apps (phones, tablets, desktops, ...).  Even Microsoft is going in that direction.
• It's fairly easy to get started with HTML and JavaScript
• Many local technical schools typically offer courses in... Delphi, Visual FoxPro, Visual Basic, no C/C++ but HTML and JavaScript! - mainly for web design, but still:  The base knowledge is present.

So - what's the scope?

Everything is designed to live up to the following requirements:

• It must be VERY easy to use for both teachers and students.
• All WebApps exercises must strive to be directly supplementing the existing curricula
• Every exercise must be possible to complete within a standard session (~ 45 mins)
• Every exercise must have some stretch goal that involves injecting code (JavaScript) directly into the WebApp (to introduce software development)

One example is a color mixing app that is part of the standard official apps, where the normal exercise tasks involve matching colors using subtractive and additive color systems - and the stretch goal is:  "make the application write how many percent of each primary color is in the mix on screen".

Working outside the box

As one of the goals of the project is to function as a catalyst for the young bright minds to come up with new software/hardware solutions with local businesses, an addition to the minimal setup will also include an Arduino based board and libraries for the WebApps to easily be able to interact with connected motors and sensors.  This will provide a foundation for industrial prototypes that will otherwise be hard to access in these regions.  Where it makes sense, exercises will be able to interact with connected hardware, e.g. a color sensor would make a lot of sense to use in connection with a color mixer exercise.

Additionally, because of the split of the server and client, it will be possible for schools with LAN connectivity to hook up the device and offer several students to work on exercises from the same box at the same time.  Another possibility could be to have a WiFi dongle attached to the RaspberryPi, providing access to exercises to students with WiFi enabled devices in the classroom.

Where to go from here?

Well - the next milestone is a talk at OpenSourceDays 2013 in Denmark.  

In parallel, I am working hard on getting the system ready, as well as looking for additional help, potential sponsors, publishers for content and schools for pilots.

If you want to support this in any way, leave a comment and I will get back to you!

YAML(TM)...

or...Yet Another Moon Lander

Here is an example that I made for a university class while teaching QtWebRuntime.

It's a very simple web application used as a base for the students to add things like "make the rocket use up it's rocket fuel while using thrusters" or "pick up a key on the way to the primary platform" - all things most of the students managed to do in less than 30 mins during the exercise part of the session.

The gray square on the left is a "virtual touchpad" that can be used as a joystick to control the rocket.

There is a touch version and a mouse/desktop version available (was too lazy to merge at the time).

Enjoy!

NOTE:  The rocket was borrowed from purzen at openclipart.org.