Last Wednesday, May 9, 2012, was Global Accessibility Awareness Day. According to the website it

is a community-driven effort whose goal is to dedicate one day to raising the profile of and introducing the topic of digital (web, software, mobile app/device etc.) accessibility and people with different disabilities to the broadest audience possible.

I took the occasion to make some more inroads into my own awareness of web accessibility. Julius, a new colleague of mine, helped me set up Orca. It is an open source screen reader for Ubuntu.

Unfortunately, we didn’t get very far because my voice over didn’t want to play nice. So we concentrated on testing a site with the WAVE toolbar. That’s quite a nifty tool for me because I can see where there might be problems on a page and where accessibility could be improved.

I tested the newly created Mahara user manual to check how it fared. It is written in reStructuredText and published through yet another open source tool, Sphinx. WAVE pointed out areas of concern but also things that worked in favor of accessibility. Fortunately, mostly everything was well because I had made sure that figures had an alt text and inline images immediately take on the short name of the substitution as their alt tag.

There were three items that needed improving:

1. The search field did not have a label and thus a person relying on a screen reader might not know immediately what to do there.
2. The images of so called admonitions like “note” and “warning” were placed as background images in the stylesheet and thus would not be read aloud. That means that a person listening to a screen reader would not know that a section was coming that was highlighted but would read it as if it were regular text.
3. One thing I just realized when I looked at the output by Fangs is that my manual arrow ( -> ) comes across as “dash greater than”.

I fixed the first issue, and the search now has a label instead of text below it when it is already too late. For the images in the admonitions, I’ll have to talk to a front end developer to come up with a good solution. The third issue can be fixed by finding a nice looking Unicode symbol of an arrow that I can use in reStructuredText. I don’t know why I hadn’t done that right from the start. However, I’ll have to check how to include the Unicode encoding for the LaTeX PDF build. The arrow looks nice in HTML but not yet in LaTeX.

Then the last step will be to propose the changes for the search box and the admonitions to the community for inclusion in a future release of Sphinx.

Unless I want to add a news item to the web site of the company I work for, Catalyst IT, I do not visit the site. That was already the same for the universities where I worked because such sites are usually geared towards the general public, but not the people working there. Thus, I sometimes stumble upon hidden gems or am reminded of cool pages.

Recently, I was reminded of the page where all our open source project contributions are listed. Currently, this list has 142 open source projects listed to which current Catalystas have contributed in the past or presently. This can be small 1-5 person projects or big ones like Koha or Moodle, projects that were created for a very specific purpose and are now defunct or projects that are continuously maintained.

That’s an impressive number of projects and may actually not be all because we pull the projects and contributors from Ohloh. If a project is not registered there, our site won’t know about it and also if developers have not added their Ohloh username to our internal wiki, our web site cannot pick it up.

With more people joining the company, this list will hopefully grow more.

Yesterday was ANZAC Day in New Zealand and it was flanked by two Mahara-related events for me:

1. MUG (Mahara User Group) online meeting at 6 a.m.
2. Eportfolios in focus webinar at 10 p.m.

For both I was asked to give a presentation on new features in Mahara 1.5 which we released last week. The time slot available in the MUG meeting was a short one whereas I had 45 minutes altogether in the evening webinar to present some new features and also answer questions of users.

So many things to try

While preparing both presentations, I was very torn between a number of features that I wanted to highlight as there are so many that are really cool. So it was like “I want this and this and this and this” like a child in a candy store. Fortunately, all the features I presented are built into Mahara by default. It’s just that I had to make a tough selection for the presentations.

I was happy to have had the opportunity to talk about some new features and share my enthusiasm for this new version of the open source ePortfolio system Mahara with others.

Both were recorded. Once the link to the Eportfolios in focus webinar is available, I’ll post it.

If you want to find out about these and many other new features in Mahara 1.5, you can for example:

• read the release notes
• check out the feature descriptions in the Mahara user manual
• explore new features on the demo site

… or a new project on Launchpad was born.

On Friday, 20 April 2012, after the release of Mahara 1.5 had been out of the way successfully, we started to have another look at offering the Mahara user manual for translators to work with. I will write more on producing the manual at a later point.

Sphinx, the software we use for the documentation, allows for internationalization. It is also quite easy to generate the translation files. All you need is a one-line command in which to specify the source and the output directory:

$ sphinx-build -b gettext source potfiles

It took a couple of minutes until all files were processed and pot files generated that translators need. That was the easy part. What we haven’t found out yet is what to do with screenshots that should also be translated. The Sphinx documentation doesn’t mention them at all and my post in the Sphinx discussion group hasn’t resulted in any replies so far. Probably, because Sphinx is most often used for code documentation and the code examples wouldn’t need to be translated.

Focusing on the actual text for the moment, my colleague Richard, who also works on the Mahara project, convinced me that it would be the best to use the POT files, even if we haven’t figured out the screenshot translations yet, instead of the translators working with the original files and translating those. The latter would basically mean that the English translation would be forked as anything can be changed in it. Whereas if the pot files are used, updates can be made more easily and the translators are spared most of the code and really only see the strings.

In order not to confuse the documentation translations with the actual Mahara translations, we set up a new project on Launchpad and called it Mahara user manual. Richard helped me with the initial setup linking one of our existing Mahara groups and thus making some default settings which got us off the ground more quickly. In the beginning, we only set up Launchpad for the translations, but while playing around with the setup, I also activated additional features. I continued the setup yesterday and now the Mahara user manual project has:

• bug and feature tracker
• space for questions
• translations ready to go
• downloadable files
• announcements
• milestones and releases

Mahara user manual overview page on Launchpad

(The screenshot says that the project was created on 19 April 2012, but that’s UTC and not NZ time. So It really was on 20 April 2012.)

I also officially released the 2 existing versions of the manual: 1.4 and 1.5. I can still update the manual whenever I have time, push my changes to the server and update the documentation to Read the Docs, the service where we publish the manual. But in case some people do want to work with the PDF or Epub versions, I might put those files up for download in intervals. Of course, they can always be accessed on the download page for the manual on Read the Docs. Furthermore, this gives me a snapshot of the manual at these times.

There are still a few things that need to be looked into. Chief among them:

• integration of localized screenshots
• automatic creation of the POT files
• setting up the localized directories and the translation export to git

Still a bit of work, but we are getting there.

If you are a user of the Mahara manual and find things:

• that you would like to see added
• that are missing
• that are incorrect
• that are explained too difficult
• that need another screenshot

… or anything else you’d like to say, please head over to the Launchpad page and leave a bug or wishlist report or ask a question.

A little over 10 months of work on many fronts:

• new features (84 documented ones!)
• many, many bug fixes
• cool new icons and other design updates
• translations
• full user documentation

resulted in the release of the open source ePortfolio system Mahara 1.5 this nice New Zealand evening. You can view some highlights from new features and bug fixes as well as contributors and sponsors of this release in the release notes.

It was great working on this release at Catalyst IT. This is the first Mahara release in which I have commits: 3.4% in the grand scheme of the release. I helped out correcting language strings. Not everybody needs to be a developer to be able to contribute to a software project.

But actually, these commits were my smallest contribution. The product that I’m most proud of is the updated user documentation for Mahara 1.4 and the documentation for 1.5. Thus, when we released Mahara 1.5 today we also had a full documentation available.

Although I say “full documentation”, I will update it infrequently correcting things, adding small bits and pieces that are missing, hopefully also putting references to online videos etc. I hope we’ll also figure out how to translate the documentation. The text itself shouldn’t be the issue as Sphinx allows for that, but the screenshots might be trickier.

But right now, I am just happy.

Bug squashing: This is not the messy kind of hitting annoying mosquitoes or sand flies and seeing their victim’s blood drain from them. No, here I am talking about the bugs that hide in software, are brought to light by keen users and then fixed by awesome developers.

This week is global bug squashing week for Koha, the open source integrated library management system. This is a “concerted effort to get bugs and patches moving along in the right direction” all over the world. Everybody is invited to help test bugs, add comments and if all is well sign off on them.

Photo by Benny Lin, CC BY-NC

One of my colleagues, Chris Cormack, who is the Technical Lead of our Koha Team at Catalyst IT, announced this initiative on Monday at work and invited everyone to support the project.

I am not a developer, but I have already fixed a few bugs in Mahara – pretty much only language string-related – and as I like the Koha team and the software, I thought that maybe I could help as well as signing off on bugs does not necessarily require programming knowledge.

The Koha community makes it easy for people like me who cannot so quickly set up an instance of Koha on their own computer, configure it, import data etc. in that there are sandboxes that can be used for testing. What you need to do is test the faulty behavior on the latest version of Koha, the “master”. Once you have confirmed that there is a fault, you apply the patch and run your test(s) again. Hopefully, all works well and you can sign off on the patch.

Now, normally, applying a patch is something that requires some command line knowledge. However, thanks to the sandboxes, all you need to do is to provide the bug number, your email address and whether you want to start with a fresh database or not. Then all the command line magic is done for you and within a minute or so you have a fully functional Koha instance with the patch applied. Voilà.

On Monday, Chris showed me how to work with the sandbox, we found a bug that looked easy enough for me to test and tested it. As I do know a little bit about the version control system git, he showed me how to sign off “properly” with a patch of my own. At the end of 1 hour we had the patch submitted. A considerable amount of that hour was spent finding a suitable bug. In the evening, I attempted to test two more bugs and could sign off on one of them. The other one needed a bit more work.

Three of the five bugs that I tested are already merged and thus could be completely squashed. That’s pretty cool. I did require some more help from Chris because as I am not so familiar with the vast amount of system preferences you can switch on / off in Koha, I needed some prodding to look in the right direction so that I could actually test the faulty behavior correctly. It was great to get the help from him at all hours also on the community IRC channel. And it was nice to chat to other Koha developers on IRC, get updates of the weather around the world and so on. The community is very friendly and supportive.

Now if you want to participate, there are still 61 bugs that need sign off (maybe fewer when you see the list) and every contribution counts as the users make the open source community and improve the software.

On a related note: Yesterday, the Mahara team released the Mahara 1.5 Release Candidate 1. We invite everyone to test the software and give us feedback if you find a bug that should be fixed before the stable release is produced.

Last week, the German MoodleMoot 2012 took place in Münster. Sigi Jakob-Kühn organized the session entitled “Mahara-Netzwerk – Austauschworkshop für Akteure und Neugierige”.

I was honored to have been asked by her to give a virtual presentation and be available for Q&A afterwards. Thankfully, Sigi could get a time slot that was not too bad for NZ time. Thus, I could stay for the entire session and learn how Mahara is being used in Germany and in Austria by schools and universities through mini presentations.

This event showed me that I should practice presenting in German more as I stumbled through some of the words and sentences more than I would have wished for. Being used to speaking English all day, I am a bit rusty in German. Following the presentations of members of the audience was much easier.

There’s also a recording of my presentation which includes the 2 minutes that I could not be heard in Germany due to Skype losing its connection and me not realizing it as I was in presentation mode.

Oskar-von-Miller Schule Kassel

Claudia Schmidt reported how the Oskar-von-Miller Schule in Kassel uses Mahara. The students keep their electronic portfolio in Mahara and use it as basis for face-to-face discussions with their teachers. They have certain activities to fulfill that they post on their pages.

The students also keep an application portfolio with which they school has had great success (after a great deal of convincing of potential employers to consider them).

Pädagogische Hochschule Wien

Thomas Strasser showcased how his students use Mahara to document their experience of their student teaching for their practical studies. They do not only use one type of portfolio, but depending on the purpose, there are three types that are important:

• showcase / presentation portfolio
• reflection portfolio
• process portfolio

They experiment with a number of ideas from the Mahara 1.4 Cookbook to make the portfolio work more relevant for the students. The portfolio is not seen as assessment portfolio but rather as vehicle for giving constructive feedback and discuss it with peers instead of just with an instructor. They also emphasize social interaction and encourage their students to publish hobbies and special interests on their profile pages for others to discover and connect with them.

Language Center of the University of Leipzig

Kátia Aiko Murata Arend outlined how she uses Mahara with her Portuguese language students. She uses it with her students to collect and reflect on texts for media and text analysis thus keeping all her teaching and learning material in Mahara. The students add to that throughout the semester and are highly motivated using this medium in their studies.

KAMahara in Karlsruhe

Norman Mewes and Sigi provided some examples of how they use Mahara in the school context. KAMahara is a Mahara installation for a project which is used by a number of schools to explore its potential.

Students use the ePortfolio to apply for jobs, for example. They also do not wait to make their pages available to their teachers until they have finished their portfolio, but give them access throughout the development process to invite feedback and improve their showcase portfolio which they are going to use for their job application along the way.

Sigi showed us a couple of examples highlighting students who use Mahara to document and reflect upon their internships in the real world. She showed how different the portfolios of the students can be depending on the preference of the students and how they wanted to express themselves.

During the MoodleMoot, a number of presenters had another presentation slot in which they went into more detail regarding their use of Mahara. But already these brief showcases allowed me a glimpse into how Mahara is being used in German schools and German and Austrian universities. The variety of uses is fantastic and also the getting together of the practitioners to share their ideas and discuss them with each other.

By now already some time ago, to be precise from January 9 to 20, 2012, we ran the second instalment of the Catalyst Open Source Academy. This is a summer program for high school students in New Zealand in which they can learn about open source and related topics as well as participate in the further development of open source projects.

During the first week, the students had a lot of input in the form of introductions and workshops to open source concepts, programming languages and tools. In the second week, they chose a project to work on more closely and were mentored by developers who work within that project on a frequent if not daily basis.

As the coordinator went on a conference during the second week, I was lucky to replace him in “overseeing” the Academy. That gave me the chance to get a better idea of what the students were doing and how they progressed. It was great to see that they could show off first results already on the first day and didn’t have to wait until the end of their time in the project to see results.

Some open source software projects the students worked on were:

• aCal (Java for Android)
• Drupal (PHP)
• Kiritaki Koha (Java for Android)
• Koha (JavaScript, unit testing)
• Map of CPAN (JavaScript)

One student started to contribute to Mahara and has been doing so since then which I find very awesome being involved in the project myself and like to see bugs fixed and new features developed.

One of the very tangible results of the Academy is that the code students contribute to an open source project can be used around the world by any user of the software. The bug fixes and features the students have worked on are to a large degree directly visible to users of the software (instead of being code fixes on the backend). Thus, they can show their family, friends and teachers exactly what they have been working on and how they have improved software.

Last year, we had 17 students from Wellington participate in the Academy. This year it was already 23, and some of them were out-of-towners. I am looking forward to the Open Source Academy 2013 and also the preparation for it as we will take the feedback from the students into account to make some changes and improvements.