Learning Articulate Storyline – Book Review

Learning Articulate StorylineEarlier this year I was delighted to be asked by Packt Publishing to act as a Technical Reviewer on their new book Learning Articulate Storyline. The book was recently published and not long afterwards a copy arrived by post. Even though I hadn’t done the hard work of actually writing the book, it was still exciting to see the finished product after having played a small part in its development.

I’m a big fan of the practical approach adopted in Packt’s books, and Learning Articulate Storyline is no exception. If you’ve never used Storyline before you can be confident that after working through this book you will be able to use it to develop elearning content.

There’s no unnecessary theory or explanations; after a quick introduction to Storyline you get stuck into building the first part of a course that you will continue to develop as you progress through the book. You’re introduced to new concepts at the point at which you use them, so there’s always a clear link between theory and practice.

At less than 280 pages you might think that the book is a little short, particularly when compared to typical IT books, but don’t let that fool you. It’s a testament to both to the simplicity of the tool and the practical approach of the book that it covers everything you need to get started – and I should be clear that getting started is what it’s all about.

The book is aimed squarely at novices and it meets their needs well, but this isn’t the book for you if you’re looking for advanced techniques. I can happily recommend it to anyone who is just getting started with Articulate Storyline.

Open Source LMS – Buyer Beware

In mid July the eLearning Network held an event called ‘The Open Source Revolution’ at which I spoke about my experience helping several organisations select an open source LMS and comparing it to similar experience with commercial systems. I was happy to report that all the projects had gone well and that relationships with suppliers had been mostly positive, but there was one major issue I had come up against which generated a lot of discussion during the Q&A.

Imagine that you have an open source LMS which was implemented by a supplier who specialises in supporting and hosting that particular LMS. Let’s call them a partner… The LMS has been in place for some time and after discussion with the supplier you decide to upgrade to the latest version. After the upgrade you discover that a plugin you have been using for some time has stopped working, not because of a problem with the plugin but because of a bug in the core LMS itself.

When you raise this with the partner who has implemented, hosted, supported and upgraded the LMS you are told that they are not liable for bugs in the core code, although they do of course offer to fix it at your expense.

It was the first time that I had been faced with a situation of this kind, and of course I immediately checked the support contract, and sure enough it absolved the supplier from any responsibility in this area. I was not happy, and judging from the response at the eLN event I’m not the only one who feels that way.

I appreciate that the supplier didn’t develop the software in the first place, but like many others they have built a business around supplying, supporting and hosting it. My view is that if they believe the software is fit for use, they should be willing to provide a warranty against bugs in the core code. If they aren’t willing to do that then any potential customer should be very sceptical about the suitability of the software, or the suitability of the supplier to support it.

For me there has been a simple outcome. I’ve updated my base requirements for procuring any open source solution to include an indemnity against core bugs as a non-negotiable. It will no doubt narrow down the choice of suppliers but I’ll have a great deal more faith in those who are left.

Gmail Compose Extension for Chrome

Whether you like it or not, email remains at the core of online communication for most of us. There are plenty of opportunities to use it more effectively and one of those is to use it solely as a communication tool – and not as a filing system or to do list. I’ve made a few changes to help me better manage email and central to that was establishing a routine of only checking for new messages three times a day, at 9.00, 12.00 and 4.00.

One of the biggest challenges I’ve faced is that between those times I still need to send emails, but when I open Gmail I get distracted by the messages in my inbox. Even if I do manage to leave my inbox without looking at the new messages they weigh on my mind, distracting me until I give in and deal with them.

Sometimes the simplest of solutions can make the biggest difference and so for the last couple of months I’ve used a bookmark to directly open the Gmail compose window, so avoiding being distracted by new messages.

Today I converted that bookmark into a simple Chrome Extension that opens the Gmail compose window in a new tab. Hopefully others will also find it useful.

 

Don’t Annoy Users

If you have even a passing interest in technology and own one or more iOS devices you’ll know that last week Google released their Chrome web browser for iPhone and iPad. It’s likely that you’ll also know that if you want to use Chrome as your default browser, you’ll be disappointed; Apple doesn’t allow this. As a result, even if you choose to use Chrome, any web links from emails or other apps will still open in Safari.

This was a point of considerable frustration for me. My desktop browser of choice is Chrome, but I’d switched to Safari solely because I get some level of integration with iOS. It seemed to me that this was a compromise that I no longer had to make, as long as I could set Chrome as the default on iOS.

There is a solution, if you’re willing to jailbreak your iOS device and install BrowserChooser, which lets you set Chrome (or any other browser) as the default.

This is where the unintended consequences begin.

  1. Until now, neither my iPhone or iPad was jailbroken, as I had never seen the benefit. The opportunity to set Chrome as my default browser was enough of a push and so both devices are now jailbroken.
  2. Now that I’ve applied the jailbreak I realised that I could also install Sparrow+ and use Sparrow as my default email client (it plays better with Gmail).
  3. Which then led me to install Sparrow on my Macs in place of Apple Mail.
  4. Then I found myself thinking, if I’m going to all this trouble to get better integration with Google products, why don’t I just use an Android phone1?

It’s this last point that should be most troubling for Apple.

Jay Harrier suggested that an iPhone user wanting greater integration with Google services is Apple’s worst nightmare, to which John Gruber responded:

No, Apple’s worst nightmare is someone buying an Android phone instead of an iPhone. If you buy an iPhone, Apple wins, that’s all there is to it. Every iOS user who chooses to use a third-party app as their preferred client for web browsing, email, calendaring, etc. is annoyed every single time they click a web/email/event URL and are taken to an iOS system app that they don’t want to use.

“Don’t annoy users” is a good rule of thumb, and the inability to specify third-party apps as default handlers for these things is annoying.

Remember that. Don’t annoy users. It seems to me that we should all keep those three words in mind, no matter what we’re working on lest we bring about our own set of unintended consequences.


  1. Which would not be difficult to do as I have a Nexus S for development and testing. 

This Is Not Showbusiness

In his recent post Market failure? Blame it on the dog food, Clive Shepherd suggests that the reason that elearning content often has high production values but superficial learning design, is down to a market failure; that elearning vendors are selling to the employer, not the learner.

I agree, but how did this situation come to exist? Based on my own experience as an elearning manager within a corporate, and more recently as a consultant, I have some thoughts about why the relationship often works this way.

In his post, Clive touches on the first one:

When employers purchase an e-learning product or engage with a developer, they choose on the basis of production values rather than learning design, because they have neither the time nor the inclination to test out materials with real learners.

I’ve seen many examples of this, but it’s a problem that existed long before elearning. The same can happen when commissioning external providers of face to face training. The focus is on the delivery and collateral rather than the learning and business outcomes. Trainers are often selected, quite literally, on the basis of style over substance.

This is closely related to the second problem. When I was getting started with elearning, I was given all sorts of advice, but one of the more frequent suggestions was to produce “high profile content”; that is, content that people would talk about because it had the “wow factor”. The trouble is, that ends up being “wow those graphics were amazing”, or “wow I think 3D models are cool” when it should be “wow I’ve learned so much by doing that!”.

Who are we trying to impress with this high profile, “wow” content? It’s usually stakeholders and senior managers, because we want their buy in as way to ensure that we can do more of this.

The trouble is, once we’ve opened this box, it’s almost impossible to put thing back in again. We establish a situation where elearning is perceived as something that must have high production values, and anything else is considered to be sub-standard.

This also relates to the problem of procurement models and IT involvement. In the past, it was not unusual to see the commissioning of a piece of elearning treated as a software purchase, and for some organisations that’s still true today.

There are two problems with this;

First of all, a software purchase is usually sourced based on factors such as integration with existing systems, and the availability of support. Effective learning outcomes will not be high on the list. IT then end up making decisions about the choice of vendor; something which should be the domain L&D.

The second issue is how these things are paid for. A software purchase is usually treated as capital expenditure, and in many organisations something can only be a capital expense if it is above a certain cost (perhaps £30-£40,000). So what do you do? You make your elearning content more media rich in order to push up the cost, because you couldn’t get the budget if you wanted to spend less. Sounds crazy, but I’ve got plenty of experience of this!

How do we overcome this? Like Clive, I’m not completely sure, but I do know that it involves L&D keeping their focus on being business people rather than show people.

#SLCONF 2012

I’ll be leading a track at the first Social Learning Conference in London on 8th March. Come join me!

#SLCONF 2012 is a 1-day engaging unconference that explores the growing impact of Social Collaborative platforms in Learning & Development. The day will be highly collaborative and informal to allow delegates to ask plenty of questions and get advice from our track leaders their peers about the best practices for developing and running Social Learning and development programs. Register here.

The event will combine a mixture of Case Study presentations from Accenture and BP as well as interactive discussions, with some of the most innovative experts in social learning, including:

  • Jon Ingham, Executive Consultant, Social Advantage
  • Nick Shackleton Jones, Group Head of eLearning, BP
  • Priyadarshini Banati, Collaboration Strategy Lead, Social Learning Team, Accenture
  • Clare Norman, Talent Development Ambassador, Accenture
  • Tim Drewitt, E-learning Specialist, Eversheds LLP
  • Barry Sampson, Director & Co-founder, Onlignment
  • Ben Betts, CEO, HT2
  • Ollie Gardener, CEO, NoddlePod
  • Stephen Gardner, CTO, NoddlePod

For those are directly involved in their organisation’s Learning & Development efforts, e-Learning and Learning 2.0 projects, this Social Learning Event is a must-attend.

Just a few more tickets are available, and you can register now via http://www.crexia.com/conferences/social-learning

From iOS to Android – Week 3

The third week of using Android instead of iPhone is over, and it’s been largely uneventful. I think it’s taken this long to settle into the Nexus S just being my phone and using it normally, rather than it feeling like an experiment all of the time. That’s really helped prove to me the value of doing this. The only way to really understand an alternative to your current platform of choice, is to use actually use it. This isn’t something that you can experience by playing with phones in the shop, or by reading about someone else’s experience (even mine!).

I started this experiment for a couple of very specific reasons. The first was so that I could understand the Android user experience so that I could better design apps for it as a platform. The second was to give some thought to whether iOS or Android had any intrinsic advantage when it came to learning specific activity. The first is still a work in progress, and I’ve already learned a great deal. The second question I think I’ve already answered for myself; much like the old adage about cameras, the best device for learning is the one you have with you. It needs a little more thought, and that’s another post to be written once this four week experiment is complete.

I did say it was a largely uneventful week, but that wasn’t to say there was nothing significant to report. This week, I had the opportunity (which I took) to buy an HP Touchpad; you may be familiar with this as the WebOS powered device that HP launched and quickly cancelled earlier this year. Some enterprising souls have ported Android to run on it, and although it’s only an early alpha, I’ve been surprised how stable it is. Watch this space for more updates on this too!

From iOS to Android – Week 2

My second week of Android usage is over, and it’s still a positive experience. Here are a few highlights.

I love the Share Menu! If you’ve never used Android, this is a global feature that allows you to share something from one app to another. It’s contextual, so only relevant apps show up in the menu. Selecting a link on a web page gives the option to share that link to my blog via the WordPress app, to Twitter using any of the Twitter apps I have installed, to my to do list in Remember the Milk, to email, Evernote or into a text message; and that’s just a few examples.

As a Google+ user, I like the fact that I can set that app to automatically upload all of my photos and videos as they’re taken. You can choose whether they’re automatically shared or not, and I’ve chosen the not option. This integration with Google’s services, like the interface differences between Android and iOS, is another topic that needs it’s own post to do it justice. I’ll cover them both when I get to the end of this four week experiment.

The biggest find of the last week for me has been Swype. It wouldn’t be exaggerating to say this has transformed the way I use a phone. Text input on mobile screens has always been painful, but Swype’s gesture recognition approach has completely changed that. I’m amazed by how quickly I can input big chunks of text, and suddenly my phone has become a useful note taking device! I did find that once you start to trust its ability to convert your gestures to text, you just relax and really pick up the pace. This was a similar experience to getting used to iOS’s automatic spell correction. Mind you, neither of them are perfect so proofreading is still required!

The most significant change in my own behaviour has been quite unexpected; I’ve almost completely stopped using my iPad. Previously, it was used daily for reading my RSS feeds, general surfing and anything internet related when I was sat on the couch after work. I’m now using the Nexus S instead. As I mentioned at the start of the four weeks, there is undoubtedly going to be some element of novelty and that may be a factor here, but there’s more to it than that. The large screen on the Nexus S and the easier input afforded by Swype make it, for me at least, a more usable all round device than the iPhone. It’s also fair to say that the iOS5 update seems to have made my iPad slower and buggy…

Regarding the phone itself – Battery life has been acceptable, but can’t compete with the iPhone 4. It does continue to outperform the iPhone in its ability to actually make and receive calls! I’ve also noticed that despite heavy usage, the screen on the Nexus S stays much cleaner than the iPhone. I probably wipe the Nexus screen one a day, whereas with the iPhone it was after almost every use. I don’t know if that’s to do with the quality of the screens or something to do with me!

From iOS to Android – Week 1

Last week I posted here about my plan to spend the month using an Android phone, a Nexus S, instead of my iPhone 4.

I’ve jotted down here my thoughts after the first week. Bear in mind that these are impressions after seven days of use, and it’s quite possible that these views may change over the coming weeks. This is about regular daily use, not side by side testing.

Set Up

Considering that this is a Google phone and I use a whole bunch of Google services, such as Gmail, Calendar and Docs it’s no surprise that getting them all set up was incredibly easy. A couple of minutes after entering my ID and password and all my important data was synced to the phone.

I then spent a couple of hours looking through the apps on my iPhone and finding suitable replacements on Android. This was a two part process, because I also took the time to remove what was installed on the iPhone that I hadn’t used for a long time. Once the cull of unused apps was complete, it was pretty straightforward to find what I needed. As expected, in most cases the app was available on Android anyway (Evernote, Twitter, BBC News, etc.) and where it wasn’t I was easily able to find a suitable replacement (such as a planner for the London Underground). The only app that I didn’t add to the Nexus S was Docs To Go, partly because I didn’t want to pay for something I may not use very long, but mostly because on iOS I use it with Google Docs and Android already has a Docs app that does a better job.

Finding my Way Around

Although iOS and Android are quite different in many ways, there are enough similarities to make getting around pretty easy. Elsewhere, it was intuitive enough to work out what to do.

The most notable difference to get used to is that iOS apps usually keep their navigation on screen all the time (back buttons in the header are the norm) whereas Android has a dedicated back button. I want to spend more time thinking about the differences in convention between the two OSs, so I’ll write more about this later in the month.

Flash

The decision to give Android a go hadn’t changed my general feeling that HTML5 should be preferred to Flash for video, so I was initially disappointed to find that the iPlayer app required Flash. Still, I decided to give it a go, and as I watched a couple of shows it almost felt like a guilty pleasure! Quality was excellent, there was no lag (for reference, I was on wifi) the phone didn’t overheat or crash and I’m fairly sure that god didn’t kill any kittens just because I used Flash.

The Handset

Most of the other comments I have it this point may be more related to the handset than the OS, although sometimes it’s hard to completely separate them.

Screen – When I told a friend of mine about this experiment, he said that he couldn’t use another handset because the screen always looked blurry compared to the iPhone 4’s retina display, and I was a little worried about this before the Nexus S arrived. I needn’t have worried though; side by side the iPhone screen is definitely crisper, but in regular use I have no complaints about the screen on the Nexus S. In fact the extra real estate (4″ against the iPhone’s 3.5″) more than makes up for any difference in resolution.

Build Quality and Design – There’s no denying that the iPhone 4 is a thing of beauty, but the Nexus S is no ugly duckling either. I guess that really comes down to personal taste, so I’m not going to dwell on it now. One thing I must mention is that the iPhone 4 seems to be built like a tank; it’s been in my pocket or bag without a case for a year, been dropped about a dozen times and it doesn’t have a mark on it. The Nexus S doesn’t feel as robust to me, probably because it’s bodywork is plastic, but I guess the flip side is that any damage is easier and cheaper to repair! At the moment I’m waiting for a decent case.

Calls and Coverage – Without a doubt the Nexus S wins here. Despite all of the other things it does so well, for me the iPhone 4 has always been terrible as a phone. The Nexus S picks up a signal where the iPhone can’t, and I actually receive calls. One problem I’ve had with the iPhone from day one is that even when I do appear to have a signal, it often didn’t ring when people called, and I would then get a voicemail notification followed by a missed call message! It’s worth noting that the SIM card in the Nexus S is the one from my iPhone (in an adaptor to make it fit).

Battery Life – I’m reserving judgement on this for now, although I think the iPhone may be better. The reason I’m leaving this for the moment is that the Nexus S is my new toy, so it is getting used more than it would usually. It’s also worth noting that the iPhone does have a great battery, but I was only able to get the calendar app to work with Google Calendar by switching on push notifications, so it wasn’t that great.