Mahara ePortfolio System

Planet Mahara

by Mahara ePortfolio System

the Planet is an aggregated RSS feed of blogs of Mahara developers and users. If you wish to have your blog or Mahara-related blog category added, please send us the link.

Kristina D.C. Hoeppner: Book review: Mahara ePortfolios Beginner’s Guide

Recently, Packt Publishing published the Mahara ePortfolios Beginner’s Guide. Richard Hand, Thomas W. Bell and Derrin Kent are the authors of this second edition which now focuses on Mahara 1.5, released in April 2012. The original beginner’s guide was published in 2010 for Mahara 1.2 was a good resource for users new to Mahara wanting to learn how to work with this ePortfolio system and collaborative tool.

Therefore, it is great to see that the guide was updated to Mahara 1.5. The authors kept the main principles of the book the same, but revised, clarified and added further information, examples and an entirely new section on planning a Mahara implementation.

Having been a reviewer of the book during its writing phase I saw the hard work that went into refreshing this guide and can congratulate the authors on having done a wonderful job. They keep the language light and engage the readers at all times with their conversational style that is informative yet easy to read and comprehend at the same time. The use of four different case studies allows readers from a variety of backgrounds to identify with at least one user group to find parallels in how they could work with Mahara.

While most of the book is aimed at new users of Mahara explaining what they can achieve with ePortfolios and how they can create and collect content in Mahara, organize it into portfolios and then share these with other users as well as work together in groups, the latter chapters go beyond that. These chapters explain how to work with groups in a more formal learning setting, what plugins can be installed to extend the core features of Mahara and how to install Mahara.

The new chapter of the Mahara Implementation Pre-Planner is a great resource for anyone tasked to implement an ePortfolio solution. It provides a series of questions for each planning phase that guide readers to answering easy to tough questions ensuring that they know exactly why, when and for what reason they wish to implement an ePortfolio system in their institution.

Although this updated guide was written for Mahara 1.5, it is still applicable for Mahara 1.6 which was released on October 19, 2012, because the general concepts of working with Mahara have not changed. For institutions wishing to invest in reference and training material for their users, the Mahara ePortfolios Beginner’s Guide is a great resource along the Mahara 1.4 Cookbook, also published by Packt, which provides over 50 recipes for using Mahara in various contexts. And then there is the Mahara user manual which explains the individual functionalities of Mahara in a more reference-book style.

The Beginner’s Guide differs to the manual in that it provides more of a story line and takes the user on the hand for starting out to create and collect content and then working with it to produce a portfolio. Thus, readers can work through the book and create their portfolio while they are moving from one chapter to the next.

Kristina D.C. Hoeppner: Mahara dreams in Switzerland

After a wonderful meeting with Mahara users in Heidelberg yesterday, I was ready to continue Mahara discussions with Kevin Moilar at Liip in Fribourg.

Liip is a Swiss Moodle and Mahara Partner that operates out of 4 locations in Switzerland and has approximately 70 people. A small E-Learning Team takes care of Moodle and Mahara clients and will look more closely into contributing to core Mahara from about September of this year on.

As Lausanne is not too far away, Dominique-Alain Jan joined us for the day. dajan – as he is commonly known online – is the main translator of Mahara who has also taken it up to translate the user manual. He travels a lot to promote Mahara and give workshops, but he can also program, maintains the servers at his school, teaches, writes his PhD thesis, and if his schedule wasn’t already crazy enough, he ran for political office last year. ;-)

The decision of Liip to contribute to Mahara core is exciting news because Kevin has had a number of fantastic ideas for improving Mahara that’ll be fun to look into further. Below are a number of suggestions that came up during our discussion.

Ubiquitous “Add” button

Kevin’s biggest concern is that it is not clear for users what they are supposed to put where in Mahara. The dashboard image which divides tasks into “Create and collect”, “Organize”, “Share and network” is supposed to help but not yet enough. Thus, he would like to simplify adding content to a portfolio by making it possible to create or collect content anywhere on the site without having to worry where to put it and going there first.

That means users would have a very prominent “Add” button which expands and let’s the users choose whether they want to add a file or write text etc. and then the relevant screen is displayed.

Focus on the editor

Currently, when you add text content, you have a small editor window and need to know that you can click on a little icon to expand it into fullscreen mode to have the entire screen filled with the editor. Kevin wants to get rid of all the “clutter” that is around a small editor window and distracts from the actual task. He referenced iAWriter as example of uncluttered writing in an editor. I have used OmmWriter that can help in the thinking process when you don’t have anything else on the screen that could be distracting but can reach all controls easily. He imagines a restyling of the editor, offering auto-save for the content and in general make it a better experience and not just your standard TinyMCE.

Select internal files

Of course, when talking about the editor, the selecting of internal files from the repository instead of having to hunt down the URL came up. That has been a long-standing feature wish and would be nice to get implemented.

Combine CPD and plans

The plans functionality is a basic implementation of a ToDo list that is a great start. The Continuing Professional Development plugin took it a bit further. The code was taken and added onto to count up the hours spent in professional development over a specific period of time besides a number of other changes. I would love to see that functionality in core and combine it with the plans. Settings could regulate whether you want to have a standard plan or want to enhance it with additional information such as time spent on the individual items of the plan etc. Furthermore, linking internal and external learning evidence into the plans would be great for easily referencing those.

Chatty chat

A chat function is missing from Mahara which would allow users to communicate syncronously on the platform like they are now used to from a number of other web applications they use, e.g. Facebook and Google. A number of users have already remarked on that and would love to this this happen.

Saving bits and pieces

A place where you can keep bits and pieces for dealing with them later would be great. That would be similar to a “Read me later” list where you can collect anything that you don’t have time to look into right away. It’s an unstructured ToDo list in a number of ways that can be accessed really easily and content can be put into it fast. Some users may already use external services for that. Thus, being able to import the RSS feed of these items if available would be nice to display and work with them in Mahara.

If Kevin wouldn’t have had to go back to Moodle migrations that his colleagues were working on, we would have found more things to dream up or discuss existing wishes further. I am very much looking forward to hearing and seeing more from the Liip developers and take the ideas to the brainstorming and then implementation level.

Kristina D.C. Hoeppner: Mahara in Baden-Württemberg and Rheinland-Pfalz

“Welcome to Germany, the developing country for ePortfolio usage” was the greeting that I received in the train station in Heidelberg. I was to meet a bunch of people who are interested in ePortfolios and especially work with Mahara for a few hours to discuss the software with them and get to know what they are working on. Christian Kleinhanß from Medien und Bildung organized the meeting and was able to gather a great group of people in the middle of summer. We met in a cafe and talked shop for over 3 hours touching upon many topics that concerned them and where they had questions.

Emerging themes

Data / privacy protection

This is probably the biggest issue that schools who want to implement Mahara (often alongside Moodle) face as the schools can’t control easily what students put into their portfolios. The Ministries of Education fear that students misuse the platform for unsavory purposes and that teachers won’t know about it immediately. Furthermore, if more than one school is on a Mahara instance, students are able to write to each other and that should not happen. A few times we referenced the isolated institutions plugin, and the consensus was that if that were available, schools would be able to share one Mahara instance as individual tenants as they can control whether their students should be allowed to or not communicate with other students. As a result of today’s discussion, the issue will be followed up and information gathered on what would have to change in Mahara to pass the stringent data protection review of Ministries of Education in Germany.

Local periodic gatherings to talk about Mahara in person

Similarly to the initial Mahara User Group that was founded in New York last year, today’s group also favors small, local meetings where people then also know each other and where they can discuss topics that are common to them. Thus, the South-western German Mahara User Group will have its first official meeting later in the year. Today you could say was the pre-founding meeting. ;-) There will be a MUG discussion forum in the German community, but there’ll also be overlap with the U.S. MUG and users will talk to each other there as well.

I also enjoy these face-to-face meetings as some topics can be discussed more quickly are more productively in a shorter amount of time and because I get the chance to meet users of the software and find out more easily what they are doing especially if they are reluctant to post questions or opinions in forums. Giving them a space where they feel more at home for participating is a great thing. We’ll also list meeting times on the MUG wiki page in case there are also outcome documents, recordings etc. that can be shared with other users.

The next big event in the conference calendar for Mahara users in Germany will be the MahoodleMoot early next year in Munich. The idea is to have Mahara represented more prominently – hence also MahoodleMoot and not only MoodleMoot. ;-) Christian and I talked briefly – before the train doors closed abruptly – about the possibility of a hackfest right before it / on the first day(s) during the pre-conference workshops. He envisaged a get-together of Mahara users to work together on something, e.g. help with the translation of the software language file or the documentation or discuss other things. This is a great idea that has also been discussed in the MUG meeting at Purchase College in July. There the focus was on developer involvement to write a plugin or get started on a core feature. The German community has fewer developers in its ranks and thus the user side is more prominent, but a hackfest would nevertheless be great for them as well to get more involved with the community and the software and work together on something

Liip: Thoughts on the MaharaUK conference

Returning from the rather excellent MaharaUK 2012 conference in Lancaster, I'd like to share some thoughts and findings.

Half a year ago we at Liip had the feeling Mahara wasn't really going anywhere. We suspected there were not enough contributing developers and generally not enough interest in Mahara outside of New Zealand. The user experience and it's tie-in with institutions (as opposed to easily available services like tumblr, wordpress, facebook etc) is not where it should be for students to genuinly embrace Mahara as their own. Also the underlying idea of Mahara as a platform for life long learning never really seemed to get a chance, due to the lack of independent Mahara instances actually providing a life long hosting option. The only option going in this direction now is the occasional allumni instance provided by some institutions.

There was one very positive signal recently to counter this impression of stagnating Mahara commitment: the quiet arrival of comprehensive documentation for users and administrators via manual.mahara.org. It puzzles me somewhat that there wasn't more noise around this wonderful tool.

Then there was the release of Mahara 1.5 with important improvements that pointed in a positive diretion, coupled with the announcement of a faster, more regular release cycle and work on the next version advancing nicely. These improvements, the plans for the 1.6 release and some very interesting plugin developments were summed up passionately by Dominique-Alan Jan's keynote presentation. One of them should make those people happy wanting to have more control over learning goals and outcomes: An adapted version of the Moodle checklist plugin to work with Mahara. The other was Extresource, making use of oEmbed which should make its way into Mahara core soon, to ease the use of embedding external content.

There were more positive examples of Mahara usage by Jon Bowen from St. Peter's College in New Zealand, listening to Jon really made me feel Mahara was THE way forward for how pupils collect, display, discuss and submit their work from an early age.

A bit of a downer came from the brief discussion that ensued from Jon's presentation about government backing of the NZ Mahara project, where Richard Wyles said after the recent departure by a key figure in the department of education the government backing was everything but certain. Both Richard and Jon assume the NZ Mahara project is now "too big to fail". A lot of us had assumed the NZ nation wide Mahara project had been initiated and backed by the government from the start and could be used as a role model for other countries. Sadly this was never so. The project was driven by individuals from the start. I'm pretty convinced Mahara needs to be available life long from a trusted provider and I don't see who else but governments could do this. In Switzerland I believe we still have a chance to get there, but discussions have been dragging on and I feel time is limited.

During the technical workshop we had some discussions about making adding and editing content more central, maybe by changing the look and feel of the TinyMCE editor or using a different editor to get a more modern look and feel. I think much work needs to be done on user experience and I saw some interesting work in that direction by Mike Kelly from the University of the Arts London and I hope he gets this into Mahara core soon! Mike also presented a new use or feature rather with the listings directory he built for the art students. Their site is public and well worth a visit on workflow.arts.ac.uk.
Gregory Anzelj presented his work on the repository plugin for Mahara which is almost complete. It allows the use of external repositories like Dropbox, Box.net, Flickr, Google drive, Windows Sky Drive, Picasa.
Simon Story presented the use of SimpleSAMLphp to integrate Mahara with other systems. I have yet to understand in what way this adds to, extends or replaces Shibboleth.

We often hear that Mahara's too complicated for users. Again at this conference. I agree to an extent, there's too many clicks involved for many things, you can get lost, adding content is not central enough. Inline editing would be great to have. Just click on a text you want to change and immediately start typing, including autosave. There was a good input from Steve Wright (trials and tribulations of using Mahara as PhD learning journal) suggesting a simple step by step wizard for first time users when logging in to Mahara to set up the profile, create the first entry, share.

I've heard the request for better mobile integration a couple of times from our clients, now there's good news courtesy of Jon Sharp and Roger Emery presenting MaharaDroid app version 2 . Now you can do all the essential stuff like adding a journal, messaging etc from your Android device. There's nothing for Apple's iOS yet. The responsive theme I've been dreaming about might help there, but what users seem to want is a native app with on-screen "badge" notification etc. A good solution for the meantime would probably be blogging by email. This would be really helpful particularly for students reporting from work experience or research in the field.

It was a pleasant surprise to see a presentation of Mahara for midwives on the programme, as one of the universities we work with have shown interest in exactly this. I missed the presentation though because I was on the other stream with a refreshing presentation by Toshifumi Sawazaki on Mahara usage in a more rural part of Japan, where several universities and private colleges (!) have collaborated to create an e-learning platform using Mahara and Moodle inside a custom portal (F-LECCS). Apparently there is no Mahara partner in Japan, so there was a steep learning curve involved in setting up and maintaining this setup on university infrastructure.

One of the more stirring presentations was a remote one by Kristina Hoeppner on how new features make it into Mahara. She was presenting from Wellington NZ and a strong earthquake occurred in the middle of her presentation, throwing things about in the room she was in. Kristina was very brave in continuing her explanations on how to submit and track feature requests, development cycles, priorities and progress in Mahara development.

Richard Wyles presented the Open Badges project they're working on in conjunction with the Mozilla Foundation. I have yet to grasp the use for this, but judging by Richard's enthusiasm it probably makes sense :)

It was a good conference, I'm glad I attended and I hope I can bring the drive I now feel behind Mahara home to Switzerland and our new e-learning team at Liip so we too may innovate and commit to Mahara again. At the moment we're swamped with Moodle V2 migrations, so it won't be easy to keep up the momentum.

Thanks and respect to all the good people involved in organising MaharaUK 2012 and to those who presented, - great work.

Melissa Draper: The Cat’s Tongue

Documentation is good and all, but it’s not much good if you can’t understand a word of it. I’ve often said that man pages are great if you’ve learned how to read man pages, and people often cite man man as a way to learn how. You know what, you still need to know how to read them (and know that the jargon file exists) to read that. Have you seen its synopsis?

With the recent release of the 1.5 series of Mahara, we’ve been putting a lot of work into making the manual translatable so that users don’t necessarily need to learn English to be able to benefit from the Mahara manual. Currently, the manual is hosted on readthedocs.com but sadly the site doesn’t yet have support for generating translated versions on the fly.

Overall, we needed to:

  • Have translated versions of the manual.
  • Have the screenshots be translatable.
  • Limit the learning curve for translators.
  • Avoid maintaining multiple copies of the source
  • Make it automated
  • Avoid having to re-deploy every time a new translation is started
  • Should be via apt-get, not via easy-install etc.

Sounds like it should be simple? I wish! There were quite a few hiccups in getting this all going:

  • The first challenge was to get Sphinx to use the translations we had. And after a ridiculous amount of fiddling and cursing, it turns out that in Ubuntu releases preceding 12.04, the .mo files did not get packaged with the locales.
  • Unicode support isn’t very well supported in the default sphinx setup, so I decided to swap over to XeLaTeX. This involved a substantial amount of tweaking.
  • Docutils changed its api (in version 0.8 onwards, which is in Ubuntu 12.04) and thus began reporting, for example, ‘ngerman’ instead of ‘de’. Sphinx wasn’t expecting that. This is fixed in the bleeding edge version of sphinx, and via a patch in ubuntu precise/quantal and debian sid.
  • If a language isn’t supported natively by Sphinx, it will not apply the gettext translations to certain build types.
  • I had never used Sphinx, rST or LaTeX before, and my python is effectively non-existent, so I have no idea what I’m doing.

Finally, after working out how to get around some of those, I think I have it all working. The resulting solution:

  • Uses packages in the Ubuntu repositories
  • Grabs the .po files from launchpad (where the translating happens), converts them to .mo files and places them under the necessary paths in source/locales
  • Grabs the translated image sets from git and drops them over the default english version in source/images
  • Patches the generated LaTeX source and its pdf Makefile to use XeLaTeX cleanly.

You’ll need to install:

gettext, git-core, bzr, make, ttf-wqy-microhei, ttf-freefont, mendexk, texlive-latex-extra, texlive-fonts-recommended, texlive-latex-recommended, texlive-xetex, ttf-indic-fonts-core, texlive-lang-all, python-pybabel

For grabbing the .po files from launchpad, I wrote a little bash script which gets passed a version number ($1 = the mahara version, such as 1.5):

#!/bin/bash

if which bzr >/dev/null; then
echo "Starting import of translations..."
else
echo "Please install bzr before continuing."
exit
fi

if [ ! -d launchpad ]; then
echo "Checking out the launchpad .po files"
bzr branch lp:~mahara-lang/mahara-manual/$1_STABLE-export launchpad
else
echo "Updating .po collection from launchpad"
cd launchpad && bzr pull && cd ..
fi

echo "Cleaning up from last time"
rm -r source/locales # msgfmt will do merging otherwise

for dir in launchpad/potfiles/*; do
echo "Creating $dir .mo files"
for file in $dir/*; do
mofile="$(basename $file | sed s%.po$%%)/LC_MESSAGES$(echo $dir | sed s%launchpad/potfiles%%).mo"
mkdir -p "source/locales/$(basename $file | sed s%.po$%%)/LC_MESSAGES"
msgfmt "$dir/$(basename $file)" -o "source/locales/$mofile"
done
done

To avoid the translators being dumped into a pile of Sphinx configuration and rST source, I set up an external git repo with the necessary assortment of image directories. From there, I added it as a git submodule. Getting the images is now a case of using another small script (again, $1 = the mahara version):

#!/bin/bash

if which git >/dev/null; then
echo "Starting import of localised images..."
else
echo "Please install git before continuing."
exit
fi

echo "Updating the image submodule"
git submodule init
git submodule update
echo "Updating image collection from gitorious"
cd localeimages
git checkout $1_STABLE
git pull
cd ..

That’s the external data fetched, now the real fun begins; the main makefile of sphinx required quite some mutilation.

I needed to teach it about locales and give it a way to pass in the Mahara version, since there are several versions of the documentation:

MAHARA        =
CLEAN         = bn cs da de en es et fa fi fr hr hu it lt lv ne nl pl pt_BR ru sk sl sv tr uk_UA
PATCHED       = ca hi ja ko zh_CN zh_TW
UNSUPPORTED   = hi
TRANSLATIONS  = $(CLEAN) $(PATCHED)

All of these can be overridden when invoking Make.

  • “mahara” is the mahara documentation version we’re building.
  • “clean” means patching of the LaTeX and generated Makefile is unnecessary.
  • “patched” means the LaTeX and generated Makefile need some extra tweaking to do what we wanted.
  • “unsupported” means that it’s a language not supported natively by Sphinx.
  • “translations” is just a grouping of the patched and clean collections for convenience.

Then I tweaked the cleanup and added a new make call for getting updates without blowing everything away.

clean:
-rm -rf $(BUILDDIR)/*
-rm -rf source/locales/*

update:
git checkout .
git checkout $(MAHARA)_STABLE
git pull
sh generate-mo-files.sh $(MAHARA)
sh get-localised-images.sh $(MAHARA)

For each manual format, I needed to make it iterate over the translations. This is the example for the html export.

html:
$(foreach TRANSLATION,$(TRANSLATIONS), \
git checkout source/images ; \
cp -ra localeimages/$(TRANSLATION)/* source/images/ ; \
$(SPHINXBUILD) -a -D language=$(TRANSLATION) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/$(MAHARA)/html/$(TRANSLATION) \
;)
git checkout source/images
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/$(MAHARA)/html/."

And that’s roughly how it looks for all the formats…

Except the latexpdf option.

It genuinely surprises me how clumsy LaTeX is when it comes to unicode (yes, I know TeX predates unicode, but still!), and it surprises me more that sphinx doesn’t use a more unicode-friendly parser such as XeLaTeX. Hence, to get a more unicode-friendly process going so that we could use trivial things such as Writing Systems That Aren’t Latin and do fun things like “→” instead of “->”, I used the Japanese support as a guide. It has its own separate pdf compilation script in the LaTeX Makefile, so I took that and made it awesome by converting it from pLaTeX to XeLaTeX, and use it for ALL the locales.

All the locales get modified by patches. There’s a patch to swap out the pLaTeX Makefile stuff with XeLaTeX, and tweak a .sty that was overriding the heading font. The .tex file is modified by another patch to make it work with XeLaTeX. Finally, a handful of patches get applied to a few individual translations to ensure that they are using decent fonts for their writing systems and other select tweaks.

The majority of the XeLaTeX changes could be put into the preamble in the conf.py file:

latex_preamble = '''
\\RequirePackage{ifxetex}
\\RequireXeTeX
\\usepackage{xltxtra} %xltxtra = fontspec, xunicode, etc.
\\usepackage{verbatim}
\\usepackage{url}
\\usepackage{fontspec}
\\setmainfont{FreeSerif}
\\usepackage{amsmath}
\\usepackage{amsfonts}
\\usepackage{xunicode}
'''

The resulting Make incantation is thus (and not for the faint of heart):

latexpdf:
$(foreach TRANSLATION,$(UNSUPPORTED), \
mkdir -p source/locales/$(TRANSLATION)/LC_MESSAGES
cp -n /usr/share/locale-langpack/en_AU/LC_MESSAGES/sphinx.mo source/locales/$(TRANSLATION)/LC_MESSAGES/sphinx.mo \
;)
$(foreach TRANSLATION,$(TRANSLATIONS), \
git checkout source/images ; \
cp -ra localeimages/$(TRANSLATION)/* source/images ; \
$(SPHINXBUILD) -a -D language=$(TRANSLATION) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION); \
cp patches/makesty.patch $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION); \
cp patches/tex.patch $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION); \
patch --directory=$(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) -p1 < $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION)/makesty.patch; \
patch --directory=$(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) -p1 < $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION)/tex.patch \
;)
$(foreach TRANSLATION,$(CLEAN), \
make -C $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) all-pdf-ja \
;)
$(foreach TRANSLATION,$(PATCHED), \
cp patches/$(TRANSLATION).patch $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION); \
patch --directory=$(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) -p1 < $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION)/$(TRANSLATION).patch; \
make -C $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) all-pdf-ja;  \
patch -R --directory=$(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) -p1 < $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION)/$(TRANSLATION).patch \
;)
$(foreach TRANSLATION,$(TRANSLATIONS), \
patch -R --directory=$(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) -p1 < $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION)/tex.patch; \
patch -R --directory=$(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION) -p1 < $(BUILDDIR)/$(MAHARA)/latex/$(TRANSLATION)/makesty.patch \
;)
git checkout source/images
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/$(MAHARA)/latex."

In summary, what this does is:

  • Copies an existing sphinx.mo into the locales directory for Unsupported languages
  • Makes sure the images are default as per git, then copies the localised images over the top of the default ones for each translation
  • Then runs sphinx-build
  • And does the common patching
  • Invokes make on the locales that do not need additional patching
  • Performs the additional patching
  • Invokes make on the locales which did need additional patching
  • Reverses all the patches
  • Makes sure the images are clean as per git once more.

After all of that, cron (or whatever triggers the build) should run something like this:

make update html epub latexpdf MAHARA=1.5

Once we have a server for this to live on and more people contribute translations, there are undoubtedly some edge cases that we’ll come across that I haven’t accounted for (I just don’t have the data right now to find them,) and the process will need tweaking.

I’m pretty sure there are better ways to do some of this (since I was learning many of the components while winging it,) but this is what I’ve ended up with. What started out a seemingly simple task, wasn’t.

Liip: Mahara ePortfolio what for?

For various reasons, people don't really know what an ePortfolio is and/or what the Mahara ePortfolio system could be used for. I will try and explain:

Mahara is...

 

... a web based tool to track, nurture and document your learning path.
... a container to store your artefacts (textfiles, audio files, movies, pictures) in one place.
... designed in a user centered way, giving you (and only you) full control over your content, with easy tools to share only what you want to share.
... ecouraging self reflection, self learning and learning in peer groups.
... designed to practice and encourage peer review with a system-wide feedback functionality.
... designed as a kind of reversed "walled garden", giving you easy control over the "gardens" you work in.
... made for social networking without distraction in a controlled environment.

Mahara use cases

The most obvious use case is in education. Mahara is made to accompany you throughout an educational career, from primary school, higher education to further education and vocational training. Mahara is made for life long learning.

Since you have your CV, diplomas, awards, journals, feedback and discussions all inside Mahara, a job application is easily assembled, choosing from the elements in your Mahara that fit the job you're applying for. This leads to the use case of Mahara as a software for job agencies , - to manage and "sell" their clients. 

Easy to create forums, groups, institutions, feedback forms (wherever you want them) and the option to have several blog instances per user, let you create a social networking site out of the box.

Drag & drop embedding and arranging of movies, photos and audio files make it fun to create, work with and share your content. In the primary school use case, Mahara can be used to train media skills, by having a class work with Mahara on small research projects like gathering, reporting and sharing nature observations or a day at the zoo, museum etc.

Speaking of nature, Mahara can be a platform for breeders and growers (...), to document, discuss and show off their "items", be that cattle or flowers.

Mahara is an ideal place to document and report on work placements (which is often a requirement in higher education), voluntary work and political or environmental activism. Any example where you want to have discussion as well as documenting activities illustrates this use case really. You can write a journal, embed video, photo galleries, run discussion forums, share with and invite people to join - all inside Mahara.

I'd be happy to read about further examples of how to use Mahara, please leave a comment.

Find more information on the Mahara website mahara.org. A good place to start is manual.mahara.org

Dan Marsden: Awards Time?

With nominations soon closing for the NZ Open Source Awards I’ve just heard about Packt Publishing’s Open Source Awards – It looks like Moodle and Mahara aren’t eligible, but if you’re aware of any open source products that you think should be recognised make sure you nominate them! – Packt are offering cash prizes to the winners and runners-up.

The NZ Open Source Awards are a bit more flexible and a wider range of projects will be eligible but nominations are closing very soon!

Dan Marsden: New Mahara book

Packt Publishing just sent me a copy of the new Mahara book:
Mahara 1.2 E-Portfolios: Beginner’s Guide

It’s been a while since I’ve sat down and read through a text-book, my eyes tend to glaze over and I find something else to read instead! I’ve also never been very good at sitting down and “studying” – This book surprised me, I was expecting a book detailing the different features in a dry step by step manner, but what I found was quite different. The first paragraph of the content in the book made me feel a little uncomfortable:

So, you’re interested in Mahara? Maybe you are already using it, but you are wondering if you are using it well. Maybe you’ve recently heard of Mahara and you are wondering if this is actually the ePortfolio solution you were looking for? Or, maybe you have been told you have to use it and you just need to get a sense of what Mahara is all about?

The book seemed to be talking to me – that’s not supposed to happen is it? After reading further I began to almost see the writers at the front of a computer lab speaking to me sitting at a PC – this easy to read tone engaged me in the book and the blend of content, hands on activities, and reviews made it an interactive experience – not what I’ve come to expect from the reference manuals I normally have on hand! The book has some great use cases and full detail without overwhelming the reader. It’s split up into logical bite-sized chapters that could be tackled one at a time when the reader has a quiet moment. Packt release this book as an eBook which I found useful – it meant that you could switch over to a web browser and run through the activities on the demo site provided specifically for readers of the book. I have a multi-monitor display which made this easy – some readers will definitely prefer the hard copy. Unfortunately the urls in the eBook weren’t live urls so I had to copy/paste them, but that didn’t take too much effort.

I’d recommend this book to anyone new to ePortfolios or new to Mahara – it gives the reader a really good detailed knowledge of not only the features of Mahara, but how they can be used in a variety of ways for very different groups of people. The book is great for real users – teachers/students/educators – it gives a much “easier to digest”, concise guide than the mahara.org online documentation. It’s not aimed at Administrators or Developers but if you haven’t implemented Mahara yet it gives some good information for new administrators or those considering Mahara’s suitability towards the end of the book. I’d highly recommend that any organisation running Mahara grabs a hard copy of the book to lend someone when they walk into your office and ask “so what’s this Mahara thing?”

It’s available on Amazon, but cheaper from Packt Publishing who sell the eBook as well.

Last updated on 15 January 2013, 11:00 AM
Feedback
*