31 Jan

Career portfolios – gathering evidence for the Field Guide

At last year’s AAEEBL conference, a new initiative was founded: Writing The Field Guide to ePortfolio. The writing part is accompanied by a series of webinars. The Field Guide is geared towards administrators and decision-makers in higher education. In essence, it’s going to be an executive briefing on ePortfolio and thus a fairly short but information-packed and valuable publication.

Why a Field Guide?

Primarily, the question “How” is going to be answered to support them in realizing the concrete potential of ePortfolios and their place in their institution not just for one department or a small group of students but at scale across the entire campus.

To answer “How”, the Field Guide author team is looking at the following areas to be covered in 12 chapters (working titles):

  1. What does it mean to move to a portfolio-based institutional learning ecology?
  2. Redesigning learning: ePortfolios in support of connected, social, and reflective pedagogies
  3. Authentic learning and teaching
  4. Reflective practice and folio thinking
  5. Learners and the digital era: Digital identity; literacy in digital forms
  6. ePortfolios and institutional challenges: Assessment, outcomes, engagement, retention, completion, quality
  7. New ways to demonstrate achievements: Warranting evidence
  8. Transition to career and career development
  9. Learning analytics and the learner
  10. Creative teaching portfolios
  11. Internationalisation and global learners
  12. How important is the technology

Career portfolios

I chose to be part of chapter 8 and look into portfolios preparing students for their career and support career development. There are four other collaborators on my team from institutions of higher education in Australia and the U.S.A.:

The five of us have the challenge to condense our ideas into three pages for the Field Guide (yes, that includes abstract and references and everything else!). Fortunately, we can link to more extensive resources and case studies elsewhere online. Some of them may sit on the companion website for the Field Guide that is going to be set up.

Our timeline is short (chapter drafts are due by the end of March) and our ideas are many. Currently, we are in the gathering phase, which will come to a conclusion soon. We decided to focus on the following areas for the gathering of articles, research and supporting arguments:

  • Why do we do what we do, i.e. work with ePortfolios?
  • Are employers demanding ePortfolios?
  • Do we need our résumé anymore?
  • Where do authentic experiences come to play?
  • How is the voice of the student translated?
  • What about assessment as work-integrated learning?
  • How is career development and not just career entering supported?
  • What about branding – self- and institution branding, self-marketing and promotion?
  • How do graduate attributes fit in?

These are a lot of areas to cover off in three short pages. During our current brainstorming phase, we may consolidate a bit more and see what we’ll include eventually.

How you can help

While we already have a good amount of information and resources, if you have research or studies or surveys that could support our writing in the above mentioned areas, please let us know in the comments.

For example, we’ve come across a couple of employer surveys from 2008 and 2013 in which they were asked about their position towards ePortfolios. If you conducted your own survey at your institution or with employers recently (within the last two years) it would be great if you could share it. Did you conduct a survey amongst students or graduates or even alumni on their use or perceptions of a career portfolio? Does your career services department have evidence of portfolios supporting students entering the workforce or continuing at university?

Or if you prepared a document for your own administration in which you highlighted reasons for implementing career portfolios and have research for us to look into, please let us know.

10 Jan

Goodbye 2015 and hello 2016

The new year is now already over a week old, but I think it’s still OK to post a review of last year. This is a short one in pictures highlighting some of the places I was fortunate to visit in 2015.

It was an exciting, joyous, adventurous but also sad year (I’m not going to talk about the latter though publicly online [yet]), and I was ready to start 2016. Let’s see what it has in stock.

01 Jan

Engaging software requirements review

A few months ago Catalyst was asked by a potential client to go through the project requirements with them in a workshop. There were about 120 requirements with the majority being “must have”, a few “should have” and a couple “could have”. The requirements themselves were mostly of a high level nature and thus providing them with an estimate that was not a ballpark was challenging. The workshop was to help us understand details of the requirements.

In this blog post I describe the idea that we implemented for the workshop, describe the material needed to run it and present its benefits. We ran this type of workshop for the first time and thus only have anecdotal evidence of its success. Nevertheless, I hope that it can serve as inspiration to you for re-thinking a similar session you are asked to run and try some of the ideas.

Coming up with an idea for the workshop

Since I heard the word “workshop”, I immediately went into workshop thinking mode. I did not want to have a session in which everyone was hunched over their multi-page 8-point font size printouts of the requirements spreadsheet or try finding the line item in the electronic document and waste time searching for items rather than discussing them.

Recently, I had also read the book Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, Sunni Brown, and James Macanufo and was all excited not do run a “regular” meeting but incorporate more visual and engaging elements.

Thus, I took a fresh look at the requirements. They were categorized according to functional and non-functional areas and labeled “must have”, “should have”, and “could have”. We had also provided information on which functionalities Mahara, the open source software we were proposing for the project,

  • had available out of the box;
  • required only minimal configuration effort;
  • needed some development effort whose scope was pretty well defined;
  • would potentially need quite a bit of development effort depending on what the client envisaged.

Since the vast majority of the items were non-negotiable requirements, I decided to ignore that categorization. It was also of less importance to keep the topical categorization because we needed to look at the entire solution. Therefore, I focused on the third type of information, namely what the software could already provide and where we needed more information in order to determine whether development work was necessary and if so, how much that would be.

Focusing on the software and the elements already available would also help us show the organization how much they would already get by using Mahara as basis. Most of the time, an organization’s requirements are not a 100% match with any software and thus a minimum of customization is required. Identifying the particular items that would need to be customized is important and also having a good understanding of the effort needed in relation to the available budget in order to suggest functionality to start with and then expand on over time.

My expectations for the workshop

In preparation for the workshop, a colleague of mine in Australia and I had a teleconference to discuss what the organization wanted us to do, what we wanted to get out of the session, what information we had available and how much time we would have realistically. This session was very helpful to me in formulating the first ideas for the session and then ponder them over a weekend without the interruption of emails and other work.

The workshop would need to allow for the following:

  • Engage all participants and not have them get stuck behind computer screens or lost in spreadsheets.
  • Allow participants to get up and talk to each other right at the start.
  • Encourage participants to draw ideas and work flows on a whiteboard spontaneously to support their ideas.
  • Have the requirements that we are discussing present at all times and thus easily accessible.
  • Make it very clear what we already know and where we need more information.
  • Use our time wisely: Spend time only on the items for which we don’t have enough information rather than going through every single item. We probably had a maximum of 5 hours and most likely no possibility of extending the session due to the schedules of all the participants (there were nine from the organization and three from us).

I came up with a card-sorting idea that would take all these expectations into consideration and hopefully deliver.

Note: It can very well be that somebody else already described a similar activity in a book or online resource on facilitating meetings and workshops. I haven’t looked specifically for any. If such an activity already exists, please let me know in the comments.

The workshop objective

The objective of the workshop seems simple enough: Remind participants of all requirements, quickly deal with the requirements that only need clarification and then go over to discussing the requirements that need more information in order to understand them better and thus be able to estimate their development effort.

The workshop preparation

The preparation for the workshop consisted of a lot of copying and pasting, sorting of cards and making hand-written notes so as not to forget elements during the workshop.

Things needed

  1. Project requirements
  2. Template file that contains the cards as well as the headings
  3. White 160g/m2 paper
  4. Four colors, one for each category
  5. Printer
  6. Cutting board
  7. Post-it notes in one color that does not correspond to a category color
  8. Highlighter in category colors (or approximations of them)
  9. Sharpie and pen
  10. Two differently colored voting dots (optional)

Set up the main categories

The four categories in which all requirements could be sorted are:

  • Know / configure: Out of the box functionality, configuration, non-application requirements;
  • Double-check: Some changes may be needed depending on the interpretation of the requirements;
  • Clarify: Know what needs to be changed; no major analysis;
  • Analyse more: Need for more information to understand the requirement.

Non-application requirements such as setting up of a hosting contract, offering user support fall under the “Know / configure” category as they are well-understood and part of the contract negotiation rather than software development.

These four categories are then laid out according to their increasing difficulty and receive a different color each. Initially, I thought of using differently colored paper, but I decided against it because none of the colors that were available went well together. Using white paper and printing color accents on them gives a much more professional look in my opinion. You can even use your brand colors if they lend themselves to it. I was lucky that our color palette allowed for such flexibility and thus I did not have to search for suitable color scheme.

Create the requirement cards

This is the part that takes the longest and is the most important. I transferred each requirement onto an A6-sized card and reviewed the category into which it fell. I also transferred any additional notes that we had already provided the client. Remember, I wanted to avoid that we needed to look up information in a spreadsheet and our proposal document. Therefore, all the information had to be readily available on each card.

You can download the LibreOffice Impress template. I set up each card on an A4 slide and then printed 4 slides on 1 piece of paper to get my desired card size. Only the category headings were printed as A4. All cards come out very nicely on 160g/m2 paper because they are easy to grasp and don’t feel flimsy.

A4 paper with 4 cards on them
A4 paper with 4 cards on them

Here you can see the individual elements that went on a card. Due to confidentiality, I cannot show any of the original cards.

A sample requirements card
A sample requirements card

  1. Provide the number of the requirement so it can be found easily in any document if needed, give it a short title and colorize the background according to the category into which this requirement falls.
  2. Write the word “could” or “should” in this circle if this requirement is optional or use any other word that your client uses to identify additional functionalities that would be nice to have. You may need to shorten a phrase to one word.
  3. Paste the full requirement in this box. If it is very long, adjust the font size. Everything needs to fit onto the front of the card.
  4. If you provided a response to the requirement to the client in the proposal document, paste it in here. This is done in a slightly smaller font to set it apart from the actual requirement’s text.
  5. If this item relates closely to another or is a duplicate, note this down here by mentioning the requirement’s number. This will help you group the requirements later more easily, though you don’t have to think about grouping yet. That is done later.

Transferring the information onto the cards also gave me the opportunity to think about questions that I might want to ask during the workshop for the cards in the “Clarify” and “Analyse more” categories.

Once I had transferred all requirements and additional information onto the cards and verified that they all had the correct category associated (represented by the colored bar), I printed and cut them giving me a nice little stack of cards to process further.

I jotted down my questions and comments on the back of cards for which I did not want to forget a question or additional comment during the workshop.

Group the cards

I now had all my cards and could start on grouping them into themes. These were partly themes taken from the requirements document or very loose themes only to help review the cards more quickly during the workshop. For example, I grouped all green cards relating to graphic design and all that dealt with support questions. I laid out all cards, took a Sharpie and my little post-it notes and went to task. I did not print out any little cards for this task because I wanted to be able to stick the notes to the cards easily and also make adjustments on the fly if needed.

Not all cards ended up in groups. I did not force the grouping but only used it where it was beneficial.

The following shows an approximation of what the cards looked like when we had them on the table at the beginning of the workshop.

The cards all categorized on the table
The cards all categorized on the table

You can see that there are a few green and yellow cards in the “Analyse more” red group of cards. I decided to put them there so that they’d be together with the other requirements that were very close so they could all be discussed together.

The workshop itself

On the day of the workshop, my two colleagues and I arrived early so we could set up the meeting room for the card activity. It does take a bit of time to lay them all out. We also brought flip chart paper, flip chart and whiteboard markers, blue tag and voting dots along. Due to the room’s layout and size, we ended up not using the flip chart paper and only had a narrow walk way between the table and the whiteboard.

The workshop started with the usual introductions of the participants and the aim of the session. After we had outlined the idea for the workshop to all participants, they were game for it and we started right away. As we were informed of the time constraints of some of the participants, we made a couple of adjustments to our plan and left out the voting of requirements which I’ll explain as an option later.

We asked all participants to stand up and take a look at the requirements and their categorization. This was to familiarize them with the requirements again and put cards into a different category if we happened to have them categorized incorrectly. This wasn’t the case though and we could move on to the next phase after about 10-15 minutes. This phase was not intended to re-read every single requirement, but to just get an overview again and take in the requirements that were grouped differently now.

We confirmed that we did not need to discuss the cards in green in the category “Know / configure”, and we could put them aside. Initially, we left them on the table, but during a short break, I put them all on a pile to have more space available on the table. This also had the nice side effect that the participants could see how many requirements were already fulfilled in the size of the stack.

Size comparison of the requirements
Size comparison of the requirements

We went quickly on to the cards in the category “Double-check” and could deal with them within a few minutes as we only needed to double-check with the workshop participants that we understood the requirements correctly. Where no additional work was needed, I took a highlighter pen and marked the card green. I also noted down the result of the discussion on the card itself. We did the same with the cards in the category “Clarify”.

This now left the rest of the workshop to focus on the cards in “Analyse more”. Initially, I had wanted the participants to rank the cards so that we could discuss them according to their priorities. Everyone would have received five voting dots that they could have distributed onto the cards. The cards with the most votes would have been discussed first. For the end of the workshop I had envisaged participants receiving a second set of voting dots in a different color and voting on the cards again now knowing more about the functionality and maybe revising their priority.

However, since I had grouped the cards already, we had reduced the number of topics. Furthermore, one of the participants had to leave early and thus we discussed the topics that were of most interest to him first.

We reviewed each group of cards and discussed their functionalities, what the participants expected of them, why they were important, what work flows they envisaged and where it fit into their program. This was not a detailed review of the functionalities, but did go deeper than the line items in the requirements document and gave us good insight into the reasons for wanting the functionality and what the workshop participants tried to solve. The discussion also gave the participants the opportunity to discuss their ideas further with their colleagues under some different guiding questions and looking at their initial ideas in a new light.

As I was facilitating the workshop, one of my colleagues offered to take notes. This is very important so as not to lose information and also to be able to consolidate the information from the cards with the notes later on.

We finished reviewing all requirements satisfactorily in just about three hours and everybody left on a high note knowing that their opinions had been heard, discussed and that we had focused on the important ideas that needed discussing instead of blindly going through the requirements catalog from beginning to end.

A couple of participants remarked explicitly that they enjoyed this workshop and that going through requirements had never been as much fun before. One of them also wanted to trial this idea in the future. Needless to say that I beamed for pride and was very happy that I had achieved what I had hoped to accomplish with this session.

Take note

There are a few things that you should be aware of to avoid last-minute panic. Some things may be more out of your control than others and you’ll have to make the best out of what you have available. Improvisation is after all an important part of the job.

  • Venue: If you have the chance, check with the meeting organizer that you have a room available with a big enough table, whiteboard, projection screen, Internet access and also enough room for the participants to navigate. Our room was fairly small with a table that was too large for the room thus making it difficult for people to move. There was a big TV available as projection screen, but it took a bit to figure out how to log in.
  • Review the cards: Have your cards ready at least one day in advance and go over them with a colleague who’s attending the meeting as well. You might spot a card that has the wrong category color or is missing information.
  • Last-minute changes: If you do need to make changes to your cards, know where you can print them if you can’t do so in your office. Our workshop didn’t take place near one of our offices and thus printing changed cards proved to be more difficult.
  • Bring all your supplies: This is a no-brainer for most people, but should still be taken into consideration especially if you do not facilitate workshops often. Bring all the supplies that you need so you know you have everything and don’t depend on the venue. Whiteboard markers tend not to work if there are any available and usually flip chart paper is also nowhere to be seen when needed. Also take along extra white cards in case a new requirement pops up and needs to be added. Also have the requirements and proposal documents available electronically.


The benefits of running the workshop as I did were clear to me during the session and also afterwards:

  • All participants were engaged the entire time.
  • Nobody got lost in requirements documents, but had all necessary information in front of them on the table.
  • Participants saw visually how many of their requirements were already fulfilled and how few only needed to be discussed.
  • We stayed on track during our discussions as we knew exactly what we had already accomplished and what we still had ahead of us.
  • We finished early because we didn’t spend precious time discussing items that didn’t need attention.

If you think this idea might work for a workshop that you are facilitating, please give it a try and let me know how things go and what changes you made. I’d be interested to learn if it works for others as well.

Update: A slightly less “stream of consciousness” version can be found on the Catalyst blog.

25 Feb

Growing Mahara community

For 2013, our chief Mahara designer Evonne created a series of Mahara merchandise with the Mahara logo in various incarnations. We have the plain Mahara logo, but also various Mahara characters representing community members / roles. I love these special logos because they show that Mahara is not just a software, but that people are very important in it. People make the software and contribute to it to make it better.

Spot the difference in the image of the two laptop skins below. What has happened between 2013 and 2015?

Mahara community then and now

Mahara community then and now

Yes, It’s a different computer. I switched from silver to black. Fun fact on the side: The Mac Air only has a 13″ screen, but is even slightly wider than the Lenovo X1 Carbon which has a 14″ screen.

But back to the subject matter: The one on the right is more crowded because a bunch of Mahara community members joined. We now have the following contributor roles represented (starting at the top of the Mahara m):

  • Ninja: The all-around bug reporter, person answering questions in the community; bug fixer and all-around super contributor;
  • Student / user: Mahara user;
  • Robot: Not really a human person, but an important part automating things;
  • Translator: People who take on the big task of making Mahara available to non-English speakers;
  • Instructor / teacher / assessor (new): Complementary to the student;
  • Designer: People with magic skills making things pretty;
  • Packager: People involved in getting the codebase ready for release to the community;
  • Tester: People who test new or changed features before they make it into the codebase;
  • Writer: People who contribute to the documentation, no matter whether user or technical documentation, written or through screencasts and so on;
  • Organizer (new): People who organize Mahara conferences or user group meetings etc.;
  • Code reviewer: People who examine the code closely while it is in review. They comment on it to make it better before it is being put into the codebase;
  • Core developer: People with mad programming skills implementing changes in the core code;
  • Support (new): People who give support either in the community or also in their own organizations;
  • Security guard: People who make sure that Mahara is secure by either reporting issues, examining them or fixing them.

It’s amazing to have all these people in an open source project contributing to the improvement of it and working together towards a common goal.

Last year for Mahara Hui we asked the participants during the registration with which of the above roles (minus the new ones) they identified and displayed these on their name tags. That way, anyone looking at them knew directly how they were involved in the project and had an easy conversation starter.

Mahara Hui name tag with contributor roles displayed

Mahara Hui name tag with contributor roles displayed

How do you contribute to Mahara or another open source project?

18 Feb

Scary document morning

When it comes down to working with text documents collaboratively, I’m a happy user of the track changes and comment functionalities because they allow people working together on a document to easily communicate about the text and see each other’s changes.

Over the last few days, a colleague and I have been working on a long document in LibreOffice. The document contains a number of tables and we’ve been making extensive use of comments as well as tracking our changes in this 40+ pages document. Last night, I was working on the document and accepted changes to a table as well as deleted some comments while the changes were still being recorded. I worked away at the document saving frequently. I left the document open over night since I wanted to work on it some more this morning. All went well until I closed the document.

Before sharing it with my colleagues, I wanted to double-check something in the document, but could not open it. Instead, I was presented with the following error message: Read-Error. Format error discovered in the file in sub-document content.xml at 2,4879(row,col).

LibreOffice error message

LibreOffice error message

Before going into panic mode, I tried the obvious: Closing the document and trying to open it again: No luck. I then sent it to a colleague to check if he could open it: Still no luck. Since I don’t know XML well, I went in search of someone who might be able to provide help.

That’s when my luck turned around since the first person I asked for help (actually rather if he knew who might have some more knowledge) was Grant McLean. He offered to take a look and if he could find the cause quickly, fix it for me. We conducted a quick search that revealed that it might be a problem due to an attribute being used twice in the style definition. The instructions didn’t prove too helpful, but Grant whipped up something very quickly which I’m going to share here for others to use if they are in need and for me to refer back to if I ever come across the problem again.

The instructions are for a Linux-based environment, in my case Ubuntu 14.04.

  1. Open the LibreOffice ODT file in the Archive Manager.
  2. Drag the content.xml file out onto the desktop to extract it.
    At this stage, the xml file displays everything in one long line which is not really helpful for debugging. So Grant used a little Perl script to make the file more readable. Since we were only interested in parts of the file, this script was sufficient and put in some line breaks.
  3. The script finds every instance of “/>” in the document and replaces it with a line break before “/>”. That preserves the syntax of the document itself, but allows us to get at least some line breaks in there making the document more readable. In the terminal at the prompt, type the following:
    perl -i -p -e ‘s{/>}{\n/>}g’ content.xml
  4. If you don’t have XMLLint installed, you can get it via:
    sudo apt-get install libxml2-utils
  5. Run the XML file through XMLLint to check where the error is. Note down the line number:
    xmllint –noout content.xml
  6. Open the file in your favorite text editor where line numbering is turned on:
    vim content.xml
  7. Navigate to the line with the problem. In my case, we saw the “office:name” attribute twice for one content item. Once it was removed, I could open the document again and continue editing.

But that’s not where the story ends. That would have been too easy. 😉 Since we saw that the problem was close by to / in a table, we assumed that the problem might lie there. So I located the table and removed all formatting, saved the file and could not open it again. Next I deleted the table from the file that Grant had sent me, re-created it manually, but still no luck. After some more tries with Chris Cormack who could open the file and edit and save it, we updated my LibreOffice to the latest version hoping that the bug might have been fixed. No such luck. So I went back to Grant to get the above instructions from him on how to fix this issue as it seemed that I would not be able to erase the problem quickly, but would need work on the document and after each closing run through the procedure to open it again. For the sake of being able to continue working, I was willing to use that workaround and leave the document open as much as possible.

Grant explained the steps and we jotted them down. While we looked at the document, he also showed me a neat trick:

If you open the document in vim, navigate to an attribute and press Shift+*, you are taken to the next place in the document where the same attribute is used. That’s how we found that the issue was actually with the annotations / comments and not the tables. Somehow working with annotations (possibly in a table) and deleting them while the track changes functionality was turned on, caused a problem.

Now I could get rid of the issue entirely: I deleted all comments in the document, and I could open it correctly again without dabbling in XML.

We assume that this is a LibreOffice bug, and I am happy to report it. Unfortunately, I have not yet been able to reproduce it in a small test document. It works fine there. I’ll probably need to create a longer document similar to the one that I’m working on and see if I can re-create the problem.

I’m thankful to Grant and Chris for their help, and also to LibreOffice whose files are actually archives and include an XML file that you can open in a simple editor and manipulate when you can’t open it in LibreOffice itself.