Friday, September 28, 2012

Looking for data

This is the first time I have done this. I am making a request for data... I know its got to be out there. I've looked at gapminder and I can get some of it there, I've queried Google scholar and have found a couple of documents where I can harvest some data. The question I am trying to answer is;

From a global perspective (and as percentages) how many adults go to university, how many go to college, how many develop trade skills, how many are unskilled labour, and how many have no known level of education?

The three graphs I am wanting to complete are found below. The data I have so far is from my readings from the previously mentioned sources. If you know of a document or data set that can provide me this information it would be most appreciated.

Thursday, September 27, 2012

Integrating with Open Badges

I have been thinking about how best a project or organization can integrate with open badges. This isn't the bits and bytes type of thinking, but the technical project management thinking required for the near-term (6 -12 months) success of the OBI and all projects that integrate with the OBI. Keep in mind this is a list of what I would focus upon as you work toward success. It is my approach as a technical architect and senior project manager and not Mozilla's or the OBI teams. I see these tasks as a benefit to the Open Badges project, as they will bring further insight into the design of the project, provide further requirements, and put the OBI through is paces before it is considered a production release.

1. Figure out the data model of your badge system design
This may require some technical skills and knowledge (and I suggest you find them at this time) to understand the data requirements of your badge system design. Do this without making reference to the existing OBI metadata specification, for that may compromise the vision of your badge system design. And you should stay true to your badge system design without restraining it by the existing Mozilla OBI specification. Keep in mind the OBI is in pre-release and really needs rubber-hits-the-road insights into how people want to implement badges. Once you have this data model try and map it to the OBI metadata specification for issuing a badge. If it doesn't fit, let the OBI team know via the google group, this could kick off an interesting discussion.

2. Start loading (and deleting) data
I see two kinds of badging systems. Those that already exist; like girl guide badges, khan academy badges, stackexchange badges or military badges. And the badges systems that don't yet exist. These existing badge systems have a huge number of badges already stored within them. If these badges are to make it into Mozilla Open Badges, we need to start loading them into the OBI now. This attempt to mass load badges into the OBI should come as a gift to the OBI team. Better they start dealing with the issue of thousands of badges showing up while still in pre-release than having them show up once Open Badges is officially released and bringing the whole OBI to a halt. If you are going to load data, you should also be able to delete the same data. The ability to load data should be a feature available within the OBI. A test environment should also be available, so partners can test their data loads, and delete the data that was loaded. The testing of data loading is a blog post in itself and beyond the scope of this particular tome.

Keep in mind that manually entering badges (one by one) is also a good idea as it will utilize the same process as the earners will use for adding badges to their backpack.

3. Build an automated testing approach
If you have already started working with the Mozilla Open Badges Infrastructure (OBI), or are considering it in the next short while, you should consider yourself an early adopter. And given this type of role expect things to change within the OBI, as it is currently a pre-release version. Given this early release things can change that may break the code at your end of the integration. Building an automated testing approach will yield great benefits as it will reduce the downtime of your system, increase the quality of your code, and provide early warning if the system elements beyond your control have changed. These automated tests could be built for both your internal system and the API calls you make to the OBI. Once these automated tests are built, it would also be beneficial to run them against the OBI at scheduled times to ensure the programatic assumptions made by your system are still valid against the OBI.

4. Determine where and how you want to encourage the display of your badges
Once you have badges "loaded" into the OBI and have viewed these badges in the earners backpack it becomes important to display the badges in a variety of locations. There is a growing number of widgets built for badge display and with the variety of methods for display you never know where your badges will show up. It is important to test these different display approaches and as a part of your issuing site encourage people to use specific displayers. You may also want to build or integrate your own displayer. What is important here is that you have displayed your badges in a number of different locations for testing purposes.

5. Advocate for other attributes to be added to the OBI metadata specification
Learning rarely occurs in isolation and learning is always related to other or previous learning in some way. The current metadata specification has a badge standing on its own. There is currently no attribute within the badges metadata that allow for it to link-to, be the detail of, or cluster-within another badge or set of badges. The OBIs' criteria attribute is being extended to allow blobs of data, so you could store this badge inter-relationship and linkage data in this criteria attribute. I believe this approach will store this information in the wrong place, for issuing systems would then have to store and maintain the data about these relationships of interest. A badge should know for itself if it exists in relationship to other badges.Erin Knight has created a great blog post describing the webmaker badge system design.

WebMaker Badges show a system design where badges are linked, clustered and the detail of a cumulative badge.

6. Encourage the completion of badge validation
Over the last year there has been much discussion regarding badge assertion or validation. The idea being that it can be determined if a badge is still valid through time. A number of approaches have been tabled, and agreement to the value and approach to implementation of this feature has yet to be agreed upon. I believe it is an important feature, for it would be nice to click on a badge from within the backpack or a displayer site and be notified if the badge is still valid.

If you have further questions or require assistance please do not hesitate to contact me. I will be very happy to assist. 

Tuesday, September 25, 2012

Curiosity, patience and grit

I've been following Doug Belshaws' work around defining digital / web literacies and I admire his persistence and broadness with this endeavour.
I have found his taxonomy / matrix / domain missing the required pre-beginner / prerequisite information. And thankfully, this has now been added to the discussion. I have been teaching digital literacies to kids, youth and adults for over 20 years. Mostly, it started with my wanting to be a teacher and working for small computer stores and giving volunteer workshops to the parents of my (now 16 year old daughters) school. Since this beginning I have taught in many places online and off, at many different levels including workshops for faculty and graduate student with Memorial University; Teaching digital literacies at these different levels taught me the importance of encouraging people to let go and develop curiosity, patience and grit in their approach. I honestly believe if people can't develop this kind of a mind set when approaching their digital literacy, they won't be successful.

The essential foundational capabilities for developing your personal digital literacies are;
  • have the curiosity to figure out how something works by taking it a part, moving things around, breaking it and getting it working again.
  • have the patience to stick with it until it is done, when something (an experiment) doesn't work out you need the patience to try again and again without losing focus through frustration.
  • have the grit to see the bigger picture and stick with it. Many things will push you away from being successful in developing digital literacies. Have the grit to stay with it long term. Digital literacy is an ongoing practice. As new technologies and approaches emerge, remaining literate will require an ongoing practice.

Saturday, September 15, 2012

Open Badges FAQs

Over the last few months I have been working on updating both the General and Technical FAQs for the Mozilla Open Badges project. My process was as follows;
  1. Read all the document sources regarding Open Badges I could find. This included;
    • mozilla open badges wiki
    • github open badges site
    • google group
    • monitoring of social media
    • attending the weekly community calls
    • listening to the Mozilla IRC
  2. With all this reading I began to identify trends in discussion and frequently asked questions
  3. I harvested these trends into the Mozilla wiki as new FAQ entries
  4. I continued my work and moved my work over to general and technical etherpads until I completely reviewed the google group in its entirety.
  5. I then edited these etherpad entries and put them into a staging area for review. Once the review period was over I moved them back out to respective wikis.
  6. These two wikis can be found at the following two links;
  7. Now I look for new FAQ entries as I continue to monitor all the Open Badges community sites and resources.
Highlights and Trends
What do I see as the highlights and trends (or lack thereof) within the discussion around the beta release of Open Badges?
  1. Most technical questions are with implementing the issuer role.
  2. Non-technical people seem to struggle with the technical issues. This would seem obvious, I do believe the Open Badges partners and community are a less technical and a more pedagogical crowd. This should be expected due to Open Badges playing more in the educational space. The technical challenges should also not come as a surprise given the beta release. I have every faith the open badges platform will become easy for the non-technical badge implementer.
  3. Badge integrity and validation (assertion) is important to people.
  4. Badge systems design is important and still at its early stages. I believe this is due to the broad variety of learning situations badges can be issued.
  5. People are wrapping there heads around badges both from a skills and knowledge perspective and a resume, cv and job search perspective.
  6. People are really interested in how open badges are going to work and be displayed within the whole social media landscape.
  7. Life-long learning seems to be the largest consideration for where badges will be utilized and hold most benefit.
  8. Discussion around assessment and alternate accreditation hasn't yet materialized in force.
  9. Project seems to be trending toward higher education and academia. Its an attractive place to play. I'd hope it would stay focused on the more common places of life-long learning.
  10. Not every FAQ entry harvested needs to have an audience, particularly some may disappear due to open badges being beta.

Monday, September 03, 2012

Community Engagement

Tuesday September 4th at 10 am EST and again at 8 pm EST I will be hanging out in Google+ and discussing Community Engagement approaches of the Open Badges team. I am going to use the following slide deck to prompt discussion. If you are new to open badges or want to listen in on an introductory discussion on open badges, message me. This hangout will also be live broadcast on YouTube and can be viewed via my Google+ profile.

The open badges team uses a collection of online tools and approaches for community engagement. This collection of tools is used for a number of different contexts. They range from open community engagement with a large number of participants to small one-on-one engagements. The tools offer both synchronous and asynchronous approaches.