After working on the badges system that I outlined in a previous post, it has finally reached a point where it is functional enough to be ‘released’. It should be noted, though, that it is neither fully functional ‘out of the box’ and is by no means a shining example of development practices at their best. The mini-project of looking at how a system such as the Mozilla Open Badges platform could be used in higher education has suffered tremendously from scope creep and the underlying code (at the moment) reflects this. Over the past few weeks I’ve been through the following phases:

• Consider how Open Badges (or similar) could be used in higher education.
• Create a prototype system to be used in higher education.
• Develop a more stable system that could be used in a trial run within our university.
• Develop the system in such a way that it could be picked up and used in a variety of institutions or situations with minimal reconfiguration.

Initially, I considered creating a small database to hold ‘objectives’ that need to be met in order to be awarded badges, along with the bare minimum of APIs in order to interact with the database and the Open Badges framework. After starting out down this path, I started to realise that there was far more potential in a badging system within a higher education institution than I had originally thought and began to think of more features that would be useful.

At this point, I started to develop an application rather than a group of APIs that would provide a far more usable method of managing badges and associated data. After discussions with others around the university and on the open badges mailing lists it seemed that there was potential to use badges (or something similar) to recognise skills developed at university, as well as extra-curricular activities that may form part of the HEAR (Higher Education Achievement Report) or similar. This led to me considering the reuse of any system I developed in other institutions, which altered the way I implemented a few features in the system.

In its current state, the application allows you to login via 2 alternative methods: local registration or via oAuth (which we use at the University of Lincoln). Obviously the oAuth settings would need altering if you were to implement it in this manner in your own institution. Once logged in, admin users (who currently need the admin flag setting manually in the database) are able to create badges, objectives for badges, create a source of badges (could be different departments within an institution) and mark objectives as being complete for a given user or set of users (the application calculates if users are then eligible for the awarding of a badge). When logged in as a ‘standard’ user (although admins can earn badges, too) you are able to see your badge ‘profile’, which shows badges that have been earned and are ready to be claimed, badges that are partially complete (i.e. you have met 1 of 2 objectives for the badge) and badges that have been completed and claimed by you.

Badges that are ready to be claimed can be sent to a backpack (currently beta.openbadges.org) or downloaded as an image, so that they can then be uploaded to another backpack. Badges that have already been sent to a backpack can also be downloaded as images, thus allowing you to add the badge to another backpack if you so wish.

There are still a few features that need to be added to the application and known bugs that need fixing, such as:

• Feature allowing password reset needs completing
• The ability for admin users to grant other users administrative privileges
• A ‘single use’, first-run admin login, thus allowing the initial user to grant admin privileges to somebody. When combined with the previous point this will remove the need for users to manually edit records in the database.
• There is a known bug with marking objectives as complete for a user ID that has yet to login to the system. Assuming the unique ID of a user is known (currently envisaged as being the staff or student number), objectives can be marked as complete for that user. If the user is eligible for a badge due to the completion of the correct objectives before logging in, the badge currently gets stuck in limbo, as it cannot be awarded as the application does not have the users email address. A simple fix would be to have a “I think i’ve earned this badge” button on the partially completed badges section of the user’s profile.
• Functions within the code itself need tidying up, because of the amount of scope creep there is likely to be a few functions that are no longer used etc.
• The user interface needs working on. At the moment ‘it works’.

Here are a few screenshots of the application:

The code for the application is available on Github and is released under the GNU Affero General Public License, documentation for the application (such as it is) is also available on Github – I’ll be working on the documentation over the next couple of days. At present there are two branches to the repository: master and develop. The master branch *should* remain stable, while the develop branch will be used to implement the features, and fix the bugs, discussed earlier.

Now that the application is reasonably stable, we’re starting to think of ways that we could trial the application. At the moment it looks like a couple of potential ways are to mimic what may appear in people’s HEAR reports for extra-curricular commitments etc, or perhaps recognizing skills that are developed and presented in non-assessed environments, such as workshops that help develop practical skills etc. However, with the end of the student year fast approaching, it is more likely that I will continue to tinker with and improve elements of the system before trialing it in some form or another from September onwards, with the return of the students.