My colleague Mark Wilcox, now the product manager for Oracle Virtual Directory but formerly a developer at WebCT, wrote me with some good advice to mLearning developers:
I wrote the first mobile app for WebCT as my last presentation at WebCT’s user conference before leaving. That may have been the first ever mobile app for any LMS, now that I think about it.
Here is the advice I would give for apps that are thinking of a mobile strategy:
- Focus on having a decent experience using the Android and iPhone browser. Luckily it’s basically the same browser. Nozbe – which is a new Getting Things Done service – does this very well. I have it linked off my iPhone home screen and it looks/acts just alike an app at that point.
- If your app has data that updates – for example discussion forums, calendar reminders, notices of new assignments – make sure those area available as RSS/Atom feeds. This makes it possible to consume them in a number of different formats and opens possibility to get a mobile app using one of the app-generation services like AppMaker or MobileRoadie.
- I would stick with a mobile web only strategy unless you have a true compelling reason to build an app. One reason could be that you need to send push notifications – a mobile Web can’t yet do that, but a mobile app can. Another could be to control the brand experience. For example you don’t want people to have a bad idea about your product because you let a 3rd party app be the mobile app and it’s not implemented well. I wouldn’t try to prevent those apps if you have a public API , but I would want to make sure I had the best app optimizing the experience. I think EBay has done this particularly well. Oracle has also released a few iPhone apps which give an idea of how to take subsets of functionality and optimize them for the mobile phone.
This is all good advice. I’d add a couple of things:
1. Get down with HTML5
The WebKit-based browsers on iPhone, Android, WebOS, etc. have varying degrees of support for HTML5 technologies that can make web apps nearly as nice as an installed app, including things like canvas, client-side storage, and the application cache.
The application cache is a great example: the web developer can produce a manifest telling the client which files to cache locally, and via javascript, can distinguish between online and offline operations.
On iPhones, some additional Apple-specific sugar allows the user to “install” the web app to the home screen with a nice icon. Neven Mrgan’s Glyphboard is a great, simple example of this technique; it works just fine offline.
If I were designing mobile access to, say, a course management system, I’d use application caching and local storage to improve the launch experience: it would launch almost instantly from cache, display some data (say, a course list) instantly as well via local storage, and then grab newer data if the user has network access.
2. Embrace constraints
One great thing about the emerging work on mobile interfaces is the opportunity to critically reexamine user experience. The constraints of the small screen and varying network access are an invitation to be thoughtful about what functions are actually important to users in a mobile context, and how to present them with simplicity and clarity.
Put more bluntly, it’s kind of a thrill to get away from the feature-bloat and weird usability curves of some of the established e-learning platforms and do something clear and simple instead.