The Karma Project: Code Less, Teach More

September 15, 2009

Karma version 0.1 Released

Filed under: News — Tags: , , , , — bryanwb @ 7:35 am

We are proud to release Karma version 0.1 today. Please download the code and try it out for yourself. You can also test out the demo here. You need Firefox 3.5 to run the demo and you will need to tweak Firefox 3.5 on the XO or you can download this Karma XO bundle Karma-1.xo


  • Chaining of operations
  • Wrappers for drawing functions
  • API documentation
  • simple mechanism for pre-loading images and audio

Known Bugs:

  • You cannot access the Adding_Up lesson from google chrome or chromium. It does work if you have the lesson stored on your local machine. This is because chromium does not yet support loading media over HTTP.
  • Knavbar with adding up.
  • The links on ‘kstart’ page to Teacher’s Note and Lesson Note don’t go anywhere
  • The css on stages 2 and 3 of Chakra are all screwed up

Features that didn’t make it into Release 0.1:

  • Internationalization mechanism
  • SVG manipulation
  • Addition of knavbar to adding_up_to_10
  • A refactored version of the Quadrilaterals lesson


  • Bryan Berry
  • Felipe Lopez Toledo
  • Christoph Derndorfer
  • Om Prakash Yadav
  • Rabi Karmacharya
  • Roshan Karki
  • Saurav Dev Bhatta
  • Devendra Khadka
  • Pavel Mocan

Please test out Chakra and our first lesson “Adding up.” We would most appreciate it if you report any bugs you find to our bugtracker on launchpad


September 8, 2009

i18n Options for Karma — and also HTML in the Large

Filed under: News — bryanwb @ 8:27 am

I am procrastinating learning object-oriented javascript by thinking about different i18n options for karma

Here are just a few of the key requirements for i18n in karma
1. Support inline text in the html

<div>This text should be translated</div>

2. Support in code translation
document.write(_(“This text should be translate”));

This is pretty standard use of gnu gettext and is well-supported

3. Grab inline text with inline markup

<div>This text should be captured, even the <strong>inline markup</strong> </div>

4. Whatever solution we use, it shouldn’t invalidate the html against an html5 validator, as the suggested solution for XML in GNOME would

So I only see two possible solutions at this point

1) Using a client-side micro-template, similar to a server-side template

<% this should be translated % >

advantages: could be very powerful and very flexible

drawbacks: this could be slow and could invalidate the markup. It could also make the markup hard to read. It could also cause problems accessing karma lessons from web servers that mistake the as a server-side include.

2) using the data-* collection of author-defined attributes in html5

conceivably, we could add the attribute data-k-translate=”true” to every element we want translated

advantages: doesn’t invalidate the html, makes use of html5

drawbacks: verbose,
might not be very flexible,
we would have to add the attribute to a lot of elements

We could possibly use the attribute data-k-translate-children=”true” to specify that all child elements w/ text should be translated.

Conceivably, we could also use data-k-translate-children=”false” to turn off translations for all children. I could also use

to turn off translations for the entire document.

I haven’t yet discussed i18n for the .css. In fact, I haven’t really thought hard about it. Ideas from smart folks would be much appreciated.

September 7, 2009

Karma Pages

Filed under: News — christophderndorfer @ 4:55 pm

Most current E-Paath activities, especially the ones we refer to as tutorials in Karma (basically introductions to a specific subject matter), are very much page-driven. Activities consist of multiple pages through which the user proceeds by clicking on an arrow-button in the lower-right corner of the screen. A page is basically one screen from a story-board with a consistent background and theme.


Additionally a similar step-by-step navigation is used within pages whereby one also proceeds by clicking on an arrow-icon within the page. This interaction advances a story-line within a page by revealing more text, possibilities for user input, etc. What’s also important is that most of the E-Paath activities save the state between pages which enables users to go back to previous screens to revisit the learning material.


We obviously want to provide very similar facilities within Karma but have yet to figure out how to exactly implement it. Especially the state saving is something that we have yet to take a closer look at.

In terms of the pages itself we’re somewhat torn between using tabs on an individual page and having individual pages. In some ways using tabs would be a bit cleaner and also going back and forth between pages with saved content would be quite a bit easier. On the other hand we would end up with a single huge html file with tons of <div>-elements which lends itself to confusion and is quite error-prone.

Currently I’m leaning towards a tab-based approach but I guess the best thing to do is try out both approaches and see how they work out. As always I’ll keep you posted on our findings… 🙂

September 3, 2009

How Would You Store a Student’s Entire School History?

Filed under: News — bryanwb @ 2:35 pm

With laptops in the classroom and the prospect of digital interactive content, students will amass a lot of artifacts. Students will want to keep a number of these artifacts for themselves, such as essays, poems, and assorted projects. A lot of information will be useful to teachers and learning specialists. This history of quizzes, tests, and essays could illuminate if a child has never mastered certain basic concepts that inhibit them from normal progression and help specialists more quickly diagnose learning disabilities.

But storing, accessing, and tracking this information across different grades, subjects, and even school systems presents a major challenge. One key aspect of these different artifacts is that we can’t predict what form or schema they will conform to. We can set a file size limit on individual files but we can’t any more constraints. Content creators will come up w/ myriad of ever-evolving data formats.

With complex problems like this it can be tempting to come up with an equally complex solution. I think a workable solution would have a very simple core and push the system’s complexity out to its logical edges. In this case, the logical “edge” is the artifact itself. On first glance, this problem seems to scream for XML. Well, the problem does seem to lend itself to using XML but I am not a huge fan of using XML to describe data. XML is powerful, descriptive, very verbose, and often just too complex for developers to use. If the average developer cannot get his head around the “ideal” technology, well then it is no longer ideal or even realistic. I sometimes fall into the trap of thinking that a particular new technology is the answer to every problem. For better or worse, I think JSON is the easiest data format to use and perhaps JSON-Schema could be used to describe that data. Every digital artifact such as homework assignments, quizzes, and projects could contain a single url referencing the json-schema that describes that data.

It isn’t just the data format that matters but the architecture of the data storage. What I have in mind is essentially a big key:value database. I don’t see a relational database meeting this need. Bear in mind I am no data storage expert. But a repository storing all this stuff would be huge. The dataset would have to be easily partiitioned and distributed. I thinking that a relational database wouldn’t be very useful because the data wouldn’t be very structured. Besides a couple of unique identifiers such as the students ID number, there wouldn’t be any inherent structure to the data. We could assume that every homework assignment, project, document will be different.

Could couchdb or mongodb meet this need? Or a non-relational data store like like Google’s BigTable.

What this data store shouldn’t do is try to impose a lot of mandatory fields and connections to keep order of this data. I have already been involved in one repository project that became so complicated that it became completely unusable. The simplistic way of how assignments could be correlate is with “tagging.” But tagging really boils down using semantic technologies like RDF (oh no XML!) to build connections between elements. RDF is hard but not so hard if rdf connections are added incrementally. I have reading O’Reilly’s “Programming the Semantic Web” so I know enough about RDF triples to be dangerous.

I am not quite sure how these student repositiories will take shape but I do believe that this presents a great business opportunity for companies like google that excel at aggregating, storing data and providing access to it w/ consistent API’s. Putting this data together and managing it will be a job for the cloud. It will be too big a job for individual school districts.

September 1, 2009

Karma lesson navigation

Filed under: News — christophderndorfer @ 10:29 am

Apart from some work on improving the Chakra design I talked about last week I spent most of my time these past few days working on the lesson navigation. First I took a close look at the current E-Paath user-interface to see which aspects of the navigation work well and which ones don’t work so well.

epaath_ui E-Paath activity

Next I started working on an early mockup, as to be expected this one doesn’t really look like much:


After experimenting with that mockup for a little while I let some of the other folks take a first look at it. We then had two group brainstorming sessions to toss around different variations of the mockup and some other design ideas. The resulting design proposal looked similar to what you can see on the photo below (minus the coffee mug stain that is):


Yesterday and today I started implementing that design proposal. You can see the current state-of-things in the screenshot below and as always Om’s icons are what really makes this thing look nice. In terms of the navigation structure and details there’s still quite a lot to be discussed and tweaked so we’ll definitely see plenty of iterations of this design in the coming weeks and months…


Blog at