SchoolTool packaging for NEXS

SchoolTool is a suite of free administrative software for schools. Since it can be installed easily and used with no licensing fees, SchoolTool can be used by schools for a single purpose, by individual teachers or small teams within schools, or as a whole-school comprehensive student information system, encompassing demographics, gradebooks, attendance, calendars and reporting. (Source: http://schooltool.org/)

In our continual effort of improving our systems and providing tools to support digital education, we were presented with a new requirement — providing schools a software based tool for classroom management and grading. After evaluating a few available tools, we encountered SchoolTool which was the foremost candidate meeting most of our criteria:

  • Web based
  • Different user levels: admins, teachers, students
  • Student information system
  • Calendars
  • Attendance
  • Grading
  • Localizable
  • Open Source

Though being the right candidate, SchoolTool had a few of the shortcomings for us — the tools is readily available (as a set of installable package) for Ubuntu only and had a lot of dependencies. As our plan to integrate the tool in the NEXS (School Server software based on Fedora Linux) infrastructure, a lot of packaging work had to be done, which included:

  • Developing a hierarchy of dependent packages for schooltool and its plugins.
  • Finding source tarballs for each packages.
  • Writing RPM spec files for each package and build binary RPMs against the spec.
  • Testing the setup.

It was daunting to perform all of the tasks manually, so we followed a semi-automatic approach — a script based automation and manual intervention where necessary. But writing spec files for building RPM packages for each dependency had to be manual, meanwhile a difficult task as well. Hopefully, we need not have to author spec files for around 80 dependencies; thanks to Robin ‘Cheese’ Lee for writing a few of them. Nevertheless the rest of them had to be authored, built against and tested; and it took us a good time performing these tasks iteratively until we arrived a stable stage. Now we are ready to pilot SchoolTool (localized in Nepali) in a few of the OLPC deployed schools.

We have built binary RPM packages for Fedora 13 and Fedora 9, for both 32 and 64 bit architectures. Additionally to encourage developers to test their own builds and to contribute in porting the tool to Fedora based distributions, we have made the packaging sources available under non-restrictive license. If you would like to test my builds, the RPM repository is hosted at http://ftp.schooltool.org/rpms/. Also there are ready to use repo files for Fedora’s yum package manager. To set up the repository:

The packaging sources (spec files and patches) are available at my git repository at http://gitorious.org/schooltool-rpm/schooltool-rpm/. We would like to see more people testing our builds and our specs and reporting back bugs. HAPPY TESTING!!

Special Student Teaches Us

Meet Santosh, he is an integral part of OLE-Nepal although he is not a member of our ‘Content Development Team’. Observing him playing and learning on the laptop helps us with planning of the future learning activities.

Seven-year-old Santosh is the most special one from among all the children that come to our lab to play because he had never used a computer before and he can keep doing the same activity for hours without getting bored; 5 hours is his record although he is usually on it for upto an hour or so most of the time. He is also special because he has been completely deaf from birth. He presents us with the additional challenge of developing activities for children with impairments.

Technical note #1: Introducing ‘The Problem’ and our Squeak-based solution

We want to introduce One Laptop Per Child computers into the government school system to assist kids with their usual studies and to provide them with a whole new world of opportunities. To do this we need to produce the necessary content to make the computers fit into the Nepali classroom environment. It’s not the glitziest part of the job but someone’s gotta do it!

Specifically our goal is to produce interactive learning material to cover the whole government curriculum for math and english in grades 2 and 6. This is a lot of material: we’ve started with the revision exercises for the first two weeks of second grade math (arithmetic, continue the series, match the quantity with the numeral, etc) and even that is a lot to do. To reach our goal for the next school year we will have to be extremely productive: we need to produce the content almost as fast as it can be consumed!

This seems to rule out having professional programmers do all of the work in our office — there’s just too much of it. We need a solution that allows designers, scriptors, and programmers around the world to collaborate to design, prototype, and perfect learning activities on their own initiative, and for the results to fit into a coherent teaching framework

We especially hope to collaborate on developing content with the other Open Learning Exchanges currently being created in other countries.

We’re only a couple of weeks into the implementation project, this is a very early status report!

The direction: Squeak

Arithmetic activitySqueak (also known as Etoys, in reference to its end-user programming features) is the extremely promising direction that we’ve taken. The images on the right are intended to put the words below into context.

Here’s the idealized workflow we’re developing with Squeak:

  1. Designer (skillset: web design, Powerpoint, Photoshop, etc) creates a learning activity on the screen using Squeak’s drag-and-drop WYSIWYG interface. The designer will choose screen layout, produce suitable graphics and sound effects, and so on.
  2. Scripter (skillset: any programming – BASIC, Javascript, etc) adds prototype dynamic behaviour. For example: a script detects when the correct answer is given and plays a sound and displays a message of congratulation.
  3. Programmer (skillset: object-oriented programming – Smalltalk) adds any features needed to ‘productize’, for example: automatic creation of randomized new puzzles, score keeping, escalating difficulty level, etc.

Series of shapes activitiy Some good features of this approach are:

  • There’s a low barrier of entry for designers: anyone can try it on their own.
  • The skills required to script designs into functional activities are relatively easy to acquire. The developers of Etoys and their colleagues are regularly teaching these skills to classes of ten year old children.
  • A production team of designers and Smalltalk programmers can incorporate the most appropriate designs into the main courseware repository.

Squeak itself has many more virtues worthy of mention:

  • Portability: The activities can will run identically on a wide range of computing platforms: Windows, Unix, MacOSX, Sugar on the OLPC XO. The activities will even run directly in a web browser provided that the suitable plugin is installed.
  • Squeak is one of the five supported programming environments included with every machine from One Laptop Per Child.
  • The Squeak community are already heavily involved in the development of One Laptop Per Child and have done extensive work to integrate with Sugar and its evolving interfaces.
  • Stability: Squeak has been in continuous development and use for over ten years and serves as the basis for serious applications such as Croquet, Scratch, and Seaside.

Early experience

We’ve been alternatively wearing the designer, scripter, and programmer hats and so far everything feels extremely productive. We can drag and drop an interface template together quickly enough to hold the attention of someone sitting and watching ("did you mean something like this?") and we’ve been able to add most of the necessary dynamic behaviour by way of drag-and-drop Etoys scripts.

It takes about two hours to teach a (non-Smalltalk) programmer to design and script Squeak/Etoys activities like the ones we’ve built. The skills are passed on very easily by way of face-to-face demonstration but they’re difficult to pick up all by yourself. We must discover or produce more effective materials for people to teach themselves Etoys – please point us to anything that you have found especially helpful!


Next steps

  • To take the work we’ve done so far and to publish it as a traditional open-source project accessible to the wider Squeak community.
  • To finish a fully ‘productized’ activity complete with scoring, randomized puzzles, increasing difficulty levels, and so on. It will be interesting to see how much time and effort this takes and how much of the work is reusable for future activities.
  • Find a professional graphic designer and teach them to use Squeak. (For now we’re programmers borrowing all icons from Gcompris or images.google.com — thankyou artists!)
  • To create more activities and invite other people to join us!