Mobile medley

Disclaimer: the following blog is written from a developer’s mindset. So it may be great reading for other developers in elearning, but perhaps also for anyone interested in a developer’s point of view and observations.

Progressive… POW! Disruptive… WHAM! Just in time… BOOF!

We like the phrases above, don’t get me wrong, but we (developers) tend to leave them to the learning designers as, frankly, they can back up the words with more articulation than us. These phrases are indicative of the fact that elearning has slowly but surely been making its way into the mobile environment, and rightly so. It’s now more the norm… finally.

As developers we’ve found (as many developers may already know) that there are some important points throughout a project where we need to ‘touch base’ with the whole project team; this is particularly important when the roll out environment is complex (BYOD, multiple LMSs etc).

When we head to the build of an elearning course, we need to be clear about what is and isn’t possible, and what’s efficient and feasible, when developing learning content for mobile. Other than the obvious screen real-estate differences and method of interactions, there are a few other factors that need to be discussed between all parties at the table.

 

Progressive

Moving to mobile immediately spurs thoughts of great new things for elearning modules. The newer technologies – which are also mostly available in newer desktop browsers – have great features that enable us to offer a much improved user experience and journey. Designing for this is a great idea, but be wary early on if the client throws an old browser into the spec… you’ve just increased your load.

An early conversation between design and development can help in utilising such features in the most effective

 

Disruptive

The shear amount of devices out there means we can unwittingly fall into the trap of having to test on too many devices.

Define what you will and will not be testing for.

In an ideal world the elearning would work on everything, and developing to best practice should get you a long, long way there, but testing on everything is neither feasible nor efficient (check the pricing and slow test speeds on BrowserStack!).

If the client has analytics on previous elearning modules, specifically how employees access learning content and the devices they use, this can help whittle the list down.

If this isn’t available then targeting the most common devices is a good starting position. You’ll then be able to add devices the company may have procured for employees.

There are great resources out there to streamline testing across devices if you don’t physically have access to them, like BrowserStack, though the preference is definitely to test on real devices.

 

Just in time

You can get a good idea of what you’re in for from the initial request from a client. This is the most important time to have the discussion over what the build might look like.

Talk about devices, interactions and overall functionality.

… including that ol’ chestnut – autoplay of media. It’s amazing how many people still assume this is a standard.

Experienced developers will know the limitations across various devices. These are important to flag at the beginning of a project. Pointing out the obvious is okay as it will make sure that no unspoken expectations or assumptions are left on the table and found out about later.

For those not aware, autoplay on mobile devices, specifically Apple, is not possible. The reason for this is that it stops users from unknowingly using their data and incurring cost… and possible bill shock. To achieve an autoplay experience on these devices we need to capture an initial user interaction with the content. The trick here is to make it feel seamless.

These are just some points to consider, there are many others and some of them may come from fleshing out the above. Getting it right in the beginning will save you a lot of headaches and patching on your path to a truly mobile/cross platform experience.

My one key takeaway from this is: Keep a conversation going.

---

Brendan is The Learning Hook’s Lead Developer / Project Manager. Brendan develops and manages elearning projects. His eye for detail and commitment to quality products is invaluable to elevating The Learning Hook’s reputation for award winning elearning.

Kevin is The Learning Hook’s Senior Developer. Kevin brings a very pragmatic and logical element to the team, and is keen for creating great processes.

 

Follow TheLearning Hook here
Or get in touch – contactus@learninghook.com.au