Wednesday, December 26, 2007

We have linux on schools, so now what?


Teachers usually prepare their classes at home, so they need the same software there that it is installed at the school they work in, with the same version of any app. As they do with books, teachers need to make agreements on the software they install in computer labs. This is not just a pedagogical, but a technical and a management need. This is the first problem the have to face.



In Spain, due to political reasons, regional governments are in charge of the technical issues that deals with computers involved in education. So they select most (or all) of the apps you find in a computer lab of any public school. This is one of the reasons we have been so successful in promoting free software at schools. It is a political decision and teachers support it (although it takes time). But other countries do not have global solutions for this, since each school or teacher have independence for choosing the applications to work with at school. This is not an advantage from a managing or a supporting point of view (it doesn't have to be a disadvantage either if there is a good coordination).



Let's assume that this problem is solved.



Supporting the software and creating documentation around a single app is hard to do and takes time. To teach teachers and students to use the software chosen takes a while too, so it is impossible for edu projects to follow short release periods, as software libre distributions do. They soon get out of date, unsupported. So teachers and students end up having at home newer versions of the software they have at school. This is already a problem for those teachers that already have good skills using linux.



In addition, each distro have its own politic related with repositories and versions of packets they include and support in any release. Even if a single (or group) of schools follow it, still there is a problem with what people have at home.



One of the things that should be done by schools or regional govs. in order to reduce the impact of this problem is to create and maintain their own repository of packets to ensure they all use the same version of the same app they have at school. This is a good point for students also.



In my opinion, this repository should be distro independent, so teachers (or students) can install the distro they want (from the official distro repository, or from a installation CD), and add this edu repository, so they have the same version of any app. This can also include Windows versions of edu apps. This doesn't work at 100% but there are technical ways of getting close.



This is a better approach than preparing a complete edu distro and having to support the installation process, hardware drivers, desktop configs, etc.. Distros already take care of that and they do it well because they have the experience.



What makes the difference if you use KDE, and I think the best thing this can be done, is to be able to download and install from the edu repository the profile (configured with kiosk mode) you have in school (if you use KDE), with all the apps, so teachers have the same configs and apps in a semi-independent desktop.



By doing this, what people in charge of edu projects can do, is to put more effort on spreading their experience selecting and configuring the desktop (improving usability), on promoting a community around the software they install and on connecting that community directly with distro, desktop and apps communities, instead of putting so much effort on technical stuff related with live CD installation, hardware configurations, release periods etc. in uncontrolled environments. To deploy, update and maintain the software on computer labs and other dependencies in schools (controlled environments) is already a huge project that takes many resources.



This is not the politic big edu projects are following in general. They are promoting that people at home install the same complete distro they have at school, adding an unsustainable and non scalable effort to the technical people they have. That politic have to change if we want to give response to the increasing demand we gonna face during the following years. Specially, if computer stores begin to sell machines with linux preinstalled, so regular users won't have to install that whatever linux operative system they (or the store) choose anymore (probably different than the one they have at schools).

Saturday, December 01, 2007

wiki, kile, kontact, RT...and voila!

Wikis, kontact, RT and kile are four of the basic tools I use everyday. Some of the guys I work with have been worried for a long time about integration of tools in one interface so they can work with them in a wiki way.

When I first heard about this I didn't think it was a great idea, but now I'm 100% convinced about the need of such a tool.

When people begin to use computers need clear and easy to use interfaces, where all the information is placed in text boxes with big names with one screen for each concept, like kontact does. Is the groupware way. Kontact is a great tool because integration between tools has always been a concern for the developers. Part of it success is because of that.

Wikis are terrific tools. They make the difference, specially when you are part of a big team. Bugtrackers are also useful in those cases. Is not only a tool for developers but for all kind of people. Workers are much more efficient when they can list the activities they have to accomplish ordered by priority. To coordinate teams is much easier when you can take a look to everybody's contributions in a wiki and list their assigned work.

Kile is a basic tool for me. It makes easy to use tags in LaTeX.

So, why not to take the best of each one of them in a single tool (or a single interface)? I want a tool like kile but not for writing LaTex but for writing in a wiki.

Let's say I'm writing a text that I want to send to somebody, so I select that text and introduce a tag (|body| my text|/body|). When I press save, the tool detects the tag and, since I haven't specified basic information to send the e-mail, it ask me, lets say, in a panel at the right side of the screen. Of course I could have defined it while writing the text with the tag |to|e-mail address|/to|, for example. The same can happen with names, phone numbers, etc.

All the information tagged can be found in the wiki page where I wrote it but, since the tool recognice the tags, specific information can be listed in a specific page automatically. So if I look for the name of a travel agency, for example, it shows me all the names (information tagged with |name|) associated to the information tagged with |company_type|. I also can decide which information associated with the tag |company_name| I want to be shown.

This works very well with bug reports. We integrated long time ago Twiki with RT by defining specific tags in the wiki that opens or close new bugs (tasks) in RT, all identified with diferent colours (red for open tasks, green for closed tags, etc). We cannot live now without it.

The calendar can work perfectly this way. I can define a meeting by writing in a wiki page something like this: |meeting|Talk about KDE|/meeting||hour|8:30|/hour||place|tenerife|/place|. Since it is hard to remember the tags(there would be tons of them), we need an kile like interface to list them all. There has to be a special wiki page where you can list all the meetings or list what you have to do today, ordered by priority, date or whatever. You can also assign tags to information that relates it to other information so you can list it all together in one wiki page. Wikis do this quiet well with a whole contribution, but it should be possible to do it with a single piece of information.

The point is be able to introduce different kind of information without switching from one interface or tool to another one. You have them all in one (from the user point of view).

This is a more natural approach than the one we use now. When you are in front of your computer, you begin to write a text, for example. Part of that text has to be sent as an e-mail (so you tag that part as |body|) where you have included a contact and a task (you tag both). Right now you have to copy the text and paste in a new e-mail (you open a mail client), then open the tracker and create one task, write the contact information in a specific tool (so you keep record of it) and attach it to the e-mail and then send it. Too many interfaces for basic actions, in my opinion.

Making such a tool attractive to beginners would be hard, I know. Anyway, I want something like this so I asked for it to the Three Wise Men.

Have you get the idea of what I want? Is it an impossible dream? Do you know a good approach to this idea?