Dear LMS companies (and other ed tech sales people),

Thank you for getting in touch with me, and for not bothering our VP and President and CIO after I didn’t initially respond to you voice mail or email request to talk about the latest features that your LMS has to offer.  In the six years I’ve been in this job, I’ve had the opportunity to speak with many of you, both in person and via other means.  I admire the enthusiasm and patience you have in a role where I personally would struggle, especially when trying to get people like me excited about your latest offerings.  I suspect it must be very deflating to talk to people like me, and I always feel bad if I feel like I’ve wasted your time. This is actually the inspiration for this letter…

The first thing you need to know about us (JIBC) is that we are not your typical university or even college for that matter.  We are a publicly funded institute focused on training and educating people in public safety fields.  As an institute this means we offer everything from short certificates to degrees and post grad certificates.  However this also means that a big part of our education is short courses – intensive 2 or 3 day courses where students are engaged in immersive, hands-on, applied learning.  We call a lot of what we do “simulations” even though this generally means different things to different people. We try and simulate real life events (train derailments, burning buildings, mass casualty events) with or without technology, and have students immersed in these events to apply their learning.  We have an entire campus dedicated to burning things and putting out fires, in addition to a car race track, and at our main campus we have a fake courtroom, fake apartment building, and a building dedicated to scenario-based learning.  Oh, and (unusually for Canadian post secondaries) a gun range in the basement.

Interestingly, about 30% of what we do is online (for a variety of different reasons that I won’t get into here).  Our students are highly dispersed geographically, largely considered adult learners, and generally have an ongoing, lifelong learning relationship with our institution.  They come from professions that aren’t the sit-at-your-desk variety, which I label as mobile.  You may see where I’m going with all this, but let me elaborate a bit further.

  • For the most part, we don’t operate and design for a 3 credit, online course paradigm. This is what LMS’s do quite well.
  • We need a variety of tools that are well suited for short, micro moments of learning.  We’ve found that WordPress is really good at this.
  • A growing percentage of our courses are open, which we’ve found works best in open tools like WordPress.
  • We are a small budget institution with a need for a variety of ed tech tools, but not the ones that come with LMS’s – your latest eportfolio tool is not a sell.  And blowing our entire ed tech budget on a do-everything LMS is not our chosen strategy.
  • As a small budget institution, we need creative solutions to creating a non-resource intensive ed tech infrastructure.  More on that over here courtesy of @clintlalonde.
  • Our mobile needs are not met by simply app-ifying the LMS.  Our context for and view of mobile learning is very different (more on that here).
  • There are no ed tech tools (LMS or other) that are designed for synchronous online scenario-based learning. We created our own, and it is a core learning technology that is in the process of being commercialized.

So what can an LMS company do?  Well, the last time we had a vendor here, we took them on a tour of our applied learning spaces.  They showed interest but didn’t take notes even though we tried to drop them some clues as to where the dev group might want to put their heads.  For starters, I would suggest a well informed brainstorming session on applied learning – what does it look like, what do people do in it, what is the use context? Then perhaps a session that seriously unpacks what a course is or needs to be in that context.  Then I would take a group around to community colleges and vocational institutes that are doing some form of distance learning because you will probably find that they are doing some interesting and creative things with technology and program design.  Then perhaps go back to the drawing board and collaborate with some institutions on solving their problems before you try and sell them an out of the box package.  Case in point…if you had showed up at our doors 5 years ago with a synchronous, scenario-based online learning took, we would have taken a serious look at it and not bothered developing our own.  Or, if you had partnered with us in developing it, we would have found a mutually beneficial relationship.

Thanks for listening…I look forward to seeing where you go in the future.



Mobile Learning at an Applied Institution

We’ve been asked on numerous occasions about our mobile strategy–how we got there and where we are going next.  Oddly, we are rarely asked the why question, but for me that is really where it starts.

The Context

When I first came to JIBC 4 years ago, mobile was on my radar as the latest thing but I was already at that stage of ed tech dis-illusionism where everything sounded like a buzzword. But the more I learned about this peculiar institution– which boasts a relatively unusual range of course offerings, course formats, and professions and pathways–the more mobile became interesting.  When a particularly savvy program area pitched the idea of an app, explaining that it would eliminate the need to carry stacks of binders of info into the field, the lightbulb went off.  Mobile wasn’t a nice to have here, it was an ed tech necessity.

The necessity factor is in fact much more nuanced.  Institutional data shows that our students have a long term/lifelong relationship with the institution. There’s a lot to be unpacked here, but put simply, JIBC is embedded in professional and physical communities who send their people to us for training, who then go back to their communities, only to come back later for further training.

Screen Shot 2014-10-08 at 9.35.56 AM

The Assumptions

Once you consider this JIBC student trajectory, the method to our mobile madness makes a lot more sense.

1. We teach to professions that aren’t the sit at your desk variety.  First responders are generally on the go, in the field, and attached to some sort of mobile device.

2. Experiential learning, simulations, or active case scenarios, are a primary method of training.  These simulations take place, for the most part, outside of a classroom environment.

3.  Learning, while on the job or at the institution, has a fair bit of just-in-time characteristics.

4. The tools and resources that are used while in their JIBC program are the same tools and resources that are used in their professions.

Our initiative is based on the above assumptions and criteria.  Number 4 is critical–everything we’ve created for mobile is something that could be used by a community, a professional, or a student in our programs.  This is also one of the reasons why most of our mobile initiative projects are free or open.

The Mobile Initiative: Evolving towards a strategy

While we have a mobile initiative, I wouldn’t say that we are at a point where we can call it a strategy.  Through some donor funding, we’ve been able to create a favourable environment for experimentation and learning and failing.  We’ve done this by funding equipment, small pilots, and contributing to boosting the infrastructure.

1. We funded the purchase 2 class sets (50) of tablets for loaning and pilots.  This number also required the purchase of some Griffin charging/syncing stations, a mac mini, and covers.

2.  We funded the development of some iOS apps. None of these apps have cost more than $3000.

3. We funded the purchase of an array of program specific apps.

4. We funded some instructor/program-initiated pilots. Most of these are simple projects that can be done off the side of a desk with a little bit of pilot money for equipment, or staff or contractor backfill time.  We don’t require the pilot to succeed, we only require that lessons learned be shared.  Most of these pilots have cost less than $3000.

5. We funded some necessary IT  infrastructure pieces, such as Airwatch licenses for the mobile device management system, and technology for a “classroom of the future” that is designed with mobile in mind.

We try and make it as easy as possible for people to bring an idea to our centre and to try it out.  We make sure everybody understands that we are learning as much as they are.  We emphasize that we don’t have all the answers, but the purpose of pilots are to better understand what is needed, what should become integrated, and what we shouldn’t bother with moving forward.

The next stage is to articulate considerations for a strategy. So far what has emerged is:

1.  Good campus wifi is essential to making this work.  (We have some work to do here)

2. Although we started with creating native iOS apps, WordPress has been a very effective alternative for certain projects.

3.  The idea of a learning ecosystem is helpful in deconstructing the learning environment–for a tablet program, the tablet provides the platform for all the bits that make up the program learning ecosystem.

4.  A mobile device management system (MDM) with something like Airwatch is essential for moving from small, isolated projects to more integrated, program level thinking about mobile.  It basically allowed us to move into the big leagues.

5. Mobile thinking should probably be the default at our institution, given who are students are, where they come from, and where they are going.

Presentation for ETUG 2014
Screen Shot 2014-10-08 at 12.15.55 PM

Creating a mobile app – a year later

It’s been a year since I shared our experience at the JI of creating our first mobile app.  Since then there’s been some great uptake on this, and an increasing demand from our users to develop for Android.  BCcampus has published 2 recent articles on our efforts: the first one talks about our developments including a HazAware app and an Emergency Social Services app, both of which will be paid iOS apps. These apps are complete, but our Finance department is still figuring out the necessary financial steps that have to be worked out in conjunction with the app store, US taxes, etc.   The second article mentions our approach to mobile learning in the context of our students and the type of education we do. There is an updated list of steps we take to develop, which include:

  1. Consider whether you are designing for a desktop or a mobile learning context.
  2. Map out the concept, purpose, audience and educational value.
  3. Identify the app developer.
  4. Establish the business model you will be using (eg. paid app, free app, both).  If you decide on a paid app, get your finance people involved as soon as possible so they can take care of necessary financial set up details.  Firming up these details takes time.
  5. Gather resources and create a storyboard.  Online storyboarding tools will help with communicating your design to the developer and save on meeting time. We’ve been using Cacoo for this.
  6. Work with developer on format, design, and content decisions.  Important things to establish at this stage are localization and designing for easy updating and editing, so it can be done in-house and you don’t need to keep running back to the developer to do this.
  7. Identify logo/branding, identify name, keywords, identify terms of use
  8. Get it in to the App store.
  9. Establish a review and maintenance schedule.

In addition to developing apps, we’ve been piloting the use of mobile technologies for our training.  Image

The Pacific Traffic Education Centre is piloting the use of G-force apps on car mounted iPad minis in its driver training.  Initial testing has found that this system is as accurate as the previous system that was being decommissioned.  As part of this project, we also had to test the ability of the car mounts to secure the iPads for accurate measurement.  As an added bonus, they can also switch from paper evaluations to iPad ready evaluations using fillable forms, which can then be submitted immediately following the test.  Since the driver training track is located in an area without wifi, iPads with 3G had to be purchased.  A part of this teaching experience has been enhanced in a pretty low cost way.

Lastly, in the School of Health Sciences QR codes are being used to give students access to just-in-time learning via JIBC-created Youtube videos that demonstrate difficult to learn procedures in our Paramedic training.  The QR codes will be inserted into simulation manuals and on equipment, and can be accessed via any mobile device with a  QR code reader. The nice part about this project is that the videos were created with two instructors and two paramedic students.  The effectiveness of this as a learning tool has yet to be evaluated but we are confident that it will be, since students have been requesting the availability of this type of information in a convenient way.

Creating a mobile learning app–what we learned, what’s left to learn


Today the JIBC’s first mobile learning iOS app got the Apple App store blessing and is now available for downloading.  The app is a multimedia glossary for Emergency Managers (more info that kind of training here and here ).You can grab it via this page (it’s FREE) if you are interested. The iPad version is a couple days away.

We used this project as a way of gently introducing ourselves to the world of mobile learning, having recognized that for our students–who need just-in-time information and tools while working in the field–it really couldn’t ignored.  We called this project a ‘proof of concept’ to give ourselves the space to fail or succeed, and we learned a few things along the way.

There are a lot of similarities in the instructional design/course design process and in the mobile learning iOS app design process, but there were also some important differences.  Here are some of the things we learned and the steps we took.  We in this case are 2 fabulous Emergency Management Division (EMD) JIBC staff:  Darren Blackburn and Jerome Rodriguez, with a bit of myself in the development phase, and a TELT staff Dennis Yip and Tech Services staff Alex Popov in the Apple Store phase.

Step 1:  map out the concept, purpose, audience and educational value

When we started this project a year and a half ago (yes, more on that later!) we began with both a problem to be solved and an opportunity.  The Emergency Management Division at the JIBC had an Innukshuk funded project with a deliverable of providing an ICS  text glossary. It made sense that this kind of information be available on a smartphone (which most EM people have) and be available for access without an internet connection (standalone) .  The deliverable had to be an OER, so the app had to be free.  The scope was small, manageable, and since apps technically are small pieces of software that do one thing really well, this seemed like the perfect marriage.

Step 2:  Identify the App developer (this should technically come later)

The next step was to find an app developer, since we didn’t have in-house resources with the time to take this project on.  We found one who was willing to learn with us, and that was really key in this project.  He worked with us on storyboarding our idea, but storyboarding wasn’t as big a deal as it would be for a multimedia or a video production project, since essentially a glossary is a type of storyboard.

Step 3:  Identify the platform for the app (should really be a decision in Step 1 since it also might determine who will be your developer)

When we started this project 18+ months ago, Android apps weren’t really where they are now, and Blackberry app developers weren’t very visible.  The iPad 1.0 was shiny and new and we really saw tablets being part of this app’s future.  So that’s how we made this decision.

Step 4:  Gather resources/storyboarding

The developer coached us through this in Step 2, but a good way of communicating what you want to do to a developer is to find a similar app.  So we poked around a lot of apps, and you realize quickly that there is a pattern to app design this is a bit like an instructional design template.  Glossaries look a certain way and have certain functions, so it was pretty easy.  At this stage the developer wanted to see what content we were going to put into it, so we gathered all that–graphics, text, and eventually video.

Step 5:  Work with developer on format, design, and content decisions

This is where there was some back and forth, not unlike course development work, with the developer.  The EMD folks on this project had it all ready to go already, so this step didn’t take very long.

Step 6:  Identify logo/branding, identify name, keywords, identify terms of use, identify business model

This is where it gets tricky, because if it hasn’t already been established at your institution, you have to run around and consult with the right people to make sure your app represents the institution’s existing branding.   Then of course you have to make sure you’ve covered off any institutional legalese.  Name and keywords are tricky because you only have so many characters, and they have to be meaningful to a broader audience (and still represent the institution).  If you are charging for your app, you might have to get into discussions about the business model, sustainability, etc.  So this step is really where the can of worms gets opened potentially.

Step 7:  Get it in to the App store

So you might be surprised to learn that all of the above took about 10 days. So why did it take a year and a half to get it in the App store?

Well, you can’t really just have your app developer submit it for you, because ultimately the institution has to hold, maintain, and sustain the app, especially if you are taking money for your app. Submitting it under a developer ID doesn’t really make the app ‘yours’ in a variety of subtle ways.  So even though we would have loved the developer to submit it and do all the hard stuff for us, he wisely recommended that we needed to get our own developer account and submit it that way.

The signup for the developer account was a bit confusing. First I signed up for what I thought was a developers account but it really wasn’t because I had to do the second part where you really sign up and pay your 99$.  Apple had to verify that the JIBC was a legit organization and that I (as the individual named to the account) was legit and had authority to do what I was doing.  This took a few weeks, and somebody (to this day I have no idea who) answered a call and said yes.  Then we were in, but as a non-techy (remember, we approached this project as instructional designers), I had no idea what to do!  So at this stage you need to give the info to your developer to wrap everything up, or find somebody in your institution who can finish it all off.  I sat on this for a long time, until finally Dennis and Alex took care of the details.

Step 7a: The details

Dennis and Alex had to do some Apple verification steps, which picked up some coding/design issues that  had to be resolved to make it easier for the JIBC to update and ‘own’ the app.  So this was a really important step.  Once they submitted it was about a 2-3 week wait to see it in the store.

Final thoughts

Creating this app was surprisingly simple, until Step 6.  Our developer was fast, great to work with, and willing to work in our budget.  Apple’s distribution process was a bit of a rub with me and felt a bit anti-web. At the time it was also surprisingly anti-mobile from an elearning perspective.  For example, I wanted to see a non-itunes integrated ‘store’ where students can grab the apps, documents, books, videos, audio, whatever associated with that institution (is this what the new itunesU is promising?).  It really needed to be simpler and quicker. I also felt a little bit like I felt in early HTML days, where creating a web page was such a big deal.  I really don’t understand why there isn’t a program where you can drag and drop content into a template (eg. glossary), add features, publish, voila, for app development.  Where is the WordPress for creating standalone apps?

Next Steps

We are well into our second development which involves scrapping an online course and redoing it entirely as a mobile learning app (with no intention of continuing to offer the online course.  More on this later…

IADIS 2011 mobile learning: the meta takeaways

This conference wasn’t big, nor full of headlining Big Names In The Field.  It’s been a while since I’ve haven’t been to a conference where Big Names filled the rooms and where presenters, having travelled from afar, were feasted on like leftovers.  I have to say that this is one of the things I appreciated the most about this conference, where every session I attended drew equal amounts of participants and everybody seemed to be on a level playing field in terms of what they had to offer.  The attendance was incredibly globally diverse, and I couldn’t get enough of the diversity of contexts that we work in ranging from “our institution had an iPod program” to “in my country no institution has a hope in hell of having an iWhatever program, so what advice do you have for me?”  It was one of the few conferences where at least one presenter didn’t have to be dragged off the stage because they were overtime but still had 10 critical slides left, and where every question and answer session was fairly engaging.  I had expected a little more display of flashy gadgetry, but again, the mobile learning problems that presenters focussed on were real, and not really about the “look what we are doing with all our toys” variety.  So my biggest takeaway is that stepping outside of your usual conference circuit and into the smaller, less headliner sphere can be really rewarding.  And definitely for a topic like mobile learning, there is perhaps more to be learned from developing countries than from countries where gadgets know no boundaries.

Avila, Spain