Karma

From Sugar Labs
Revision as of 00:37, 20 July 2009 by ChristophD (talk | contribs)
Jump to navigation Jump to search
Karma.png

The Karma Project

Rationale

Anyone with a modern standards-compliant web browser and a text editor should be able to create learning activities that can be used by anyone with a computer.

Status

Karma is a sub-project of Sugar Labs that is under active development as a part of a Google Summer of Code project. The latest examples can be seen at http://karma.sugarlabs.org. You can also check out the Karma Project blog for updates.


What Karma Is

  • Karma is a simple framework to create simple interactive learning activities primarily for Sugar but also to be viewable through any web browser that supports html5
  • Karma is used to create simple activities that run off-line w/out access to the Internet
  • Karma is for web developers who want to contribute to Sugar using their current skills
  • Karma is built on top of open web standards such as html5, javascript, and CSS.
  • Karma is built to run on top of web browsers that support html5, particularly the canvas element.
  • Karma is built around the concept of individual "lessons" and multiple lessons can be aggregated into a sugar activity
  • Karma is the evolution of OLE Nepal's work on the EPaath suite of lessons in Nepal
  • Karma is designed with pervasive and easy internationalizaton in mind and integration with moodle, particularly for monitoring student progress
  • Karma is pedagogically agnostic. Pedagogy choices are left to the lesson author.

What Karma Isn't

  • Karma is not meant to replace pyGTK as the dominant toolset for creating Sugar activities
  • Karma is not a tool for creating activities with complex 3D graphics. Karma is a tool for creating activities with simple 2D graphics
  • Karma is not meant as a basis for a WYSIWG programming environment like TurtleArt, EToys, or Logo
  • Karma is not built to support browsers that do not support html5, such as Internet Explorer and Firefox < version 3.5
  • Karma is not intended to teach programming to children though it could be used as such

Design Philosophy

A Karma lesson is composed of a valid html5 document, javascript code, and css stylesheets and optional assets such as images, audio, video and lesson plans. Karma should be very easy for inexperienced developers to understand and work with. Even non-programmers should be able to make visible changes by tweaking the code and liberal use of cut-and-paste. Complexities such as integration with pootle, local storage, and certain types of animation should be abstracted so that novice developers don't have to understand them in order to effectively use Karma. Karma strictly adheres to the Model-View-Controller Pattern and similarly to unobtrusive JavaScript. In essence. you should be able to substantially change the look and feel of a Karma lesson by modifying the CSS or you could translate the activity, without having to understand the JavaScript code.

Technical Architecture

  • Run-time - Karma will work with basic functionality on any W3C standards-compliant browser that supports HTML5 tags canvas and audio. This notably excludes Microsoft's Internet Explorer. Karma will be particularly tailored to work within Sugar's Browse activity. Longer-term we hope to extend Karma to take advantage of Sugar's collaboration features.
  • Primary Programming language - Javascript (1.8.1) Karma depends heavily the javascript library jQuery, version 1.3.
  • i18n -- Pervasive internationalization is a critical part of Karma
    • Supported types of i18n
      • Output of Native Digits
      • Image switching per locale
      • Regular text, though it is unclear how to support plural forms, grammar shifts, and gender
      • Audio switching per locale
    • Integration with pootle
  • Journal, Telepathy Integration -- method to be determined
  • Moodle Integration -- method to be determined
  • High-Level layout of a lesson
 lesson_name/
             index.html               # valid html5 -- markup only includes visual elements and links in other resources, no inline code or styling
             css/                     # css files   -- all control of presentation done in CSS
                 karma.css            # default stylesheet for Karma
                 lesson_name.css      # custom stylesheet for lesson
             js/                      # javascript files
                 karma.js             # common javascript functions for a Karma lesson
                 jquery.js, jquery.growl.js    # utility functions from jQuery
                 lesson_name.js       # javascript controlling logic for the lesson          
             po/                      # translation files
                 ne_NP.po             # example translation file for Nepal - Nepali
                 sp_ES.po             # example translation file for traditional Spanish
             assets/
                    ne/
                       images/
                       audio/
                       docs/
                            lesson plan?
                            teachers note? 
                    en/
                       images/
                       audio/
                    

Conventions

GSoC Project

Team

Felipe Lopez Toledo "SubZero" is creating a prototype for Karma as a Google Summer of Code project. Bryan Berry is serving as his mentor.


Project Requirements

  • Create a single prototype activity which could be used as a template for sugarizing AJAX activities. The GSoC participant should not create her own activity but recreate an existing activity such as one of OLE Nepal's flash activities.
  • This prototype should have the following features:
    • Simple interactive animation and audio using html5 tags like <canvas> and <audio>
    • An assessment section that stores results of student's progress and gives them suggestions on improvement. Assessment info should be persistent.
    • Has embedded pdf or pdf like document reader for activity lesson plan and teacher notes.
    • Integrates with the Journal
    • Navigation and Help elements, ideally reusing widgets from jQuery
    • Some element of collaboration using Telepathy (This could be really hard, depending on the state of javascript bindings to dbus)


Meetings

  1. Regular meeting between Felpe and Bryan every Tuesday 0200 UTC at #sugar on irc.freenode.net
  2. General GSOC meeting for participants from Sugar every Tuesday 1400 UTC #sugar-meeting

Meeting Notes

Project Plan

There are roughly 4 parts to this project plan: first get titanium running on the XO, second create a very simple learning activity with javascript and html5, third get that activity running on the XO in a roughly sugarized version of titanium, fourth extend the activity to take advantage of Sugar-specific features such as the Journal and Collaboration.

Before GSoc - June 1:

  • get familiar with Sugar
  • get familiar with html5
  • Felipe to acquire XO
  • learn more about JavaScript
  • select the appropriate js framework -- jQuery

June 2 - June 12:

  1. “Karming” the "Quadrilaterals" activity using a non-elegant approach
  2. Post blog entry detailing challenges encountered and ideas on how to simplify the animation methods
  3. Post message to jquery-en and jquery-dev mailing lists asking for feedback


June 13 - July 12:

  • Developing the first Karma widget (easy animation tool, boost animation tool from the selected js framework)
  • Getting familiar with Sugar/Browse code
  • Providing Karma + audio
  • Providing Karma + client-side i18n
  • Developing an activity template for Karma
  • Changing the original activity to include above features

July 13: Publish blog post that showcases updated activity. Explain problems encountered, what works, what still doesn’t.

July 15 - July 25:

  • Fixing bugs
  • Work on gears+karma support

July 26 - July 31:

  • Documenting examples
  • Improving documentation

August 1 - August 9: time for any eventual emergencies

Project Risks

  1. Creating interactive animations with html5 and javascript is very new technology as html5 is a new standard. It could be much harder to create animations than we expect. Risk Level: High
  2. Javascript animations could be very slow on the XO. Risk Level: Low, we don't need very complex animations
  3. It could be very difficult to interface titanium with telepathy. Risk Level: High
  4. The Browse Sugar activity uses the spidermonkey javascript interpreter, which is not optimized for hmtl5. Karma's animations may be prohibitively slow in Browse and require a version of Browse that includes the newer tracemonkey javascript interpreter.