Learning Conversations

This is a follow up to an earlier post on Mobile Content Delivery, where I looked at the advantages and disadvantages of the different methods available.

I've been digging a bit further into what's available to help you get your content into mobile devices. What follows is a brain dump of my current state of knowledge... I'll be focussing on iOS devices (as that's all I've got to experiment with), but there are significant downsides to this, as you'll see below.

PDF

PDF files are probably the easiest way to distribute content that is purely static (ie. no animations) text and graphics. On an iPad you can save them into your iBooks collection. They can be read offline; are searchable; easy to browse and can contain internal and external hyperlinks.

They're also really easy to deploy; either as a download, or attached to an email.

Creating them can be as simple, or as complex as you wish. At its simplest, you can print to a pdf from any application that allows printing, including Word, Powerpoint, Keynote etc. Or you can do high-end work using desktop-publishing software in combination with tools like Adobe Acrobat.

The downside with a pdf, at least with the default iPad reader, is that you can't copy any of the text or images, nor use any of iBook's note-taking, highlighting or dictionary functions. Also, the only way to enlarge text is to zoom in on the pages - as opposed to eBooks which reflow text when you enlarge it.

eBooks

eBooks are as simple as PDF's to deploy. They have a couple of advantages over pdf's though:

• Ability to incorporate DRM (eg. as used by Derbyshire libraries - I use Bluefire Reader on my iPad to read the book, as it has some sort of integration with the AdobeID which the libraries use for authentication and DRM).
• Able to use a wider range of functions than is available in the PDF reader - eg. notes, copy, highlighting, change text size

On the DRM front, it's worth noting that O'Reilly (one of the world's largest technical publishers) does not use DRM on its eBooks, yet has still seen massive growth on sales of eBooks. From the end-user's perspective, they run the risk of losing DRM-protected eBooks they've paid for at the whim of the supplier.

eBooks are not as easy to create as PDF's. However they are not difficult, if you have a reasonable understanding of HTML and CSS.

eBooks have a standard format, known as ePub. An ePub file is basically a zip file but with a .epub extension to the filename. If you rename the file so it has a .zip extension, you'll be able to unzip it and take a look inside, where you'll find:

• A set of html or xhtml pages - these are the pages of your book. Each page is completely separate, although you can have links between them. The eBook software will handle creating the table of contents
• Any associated CSS files and images, often inside sub-folders
• A couple of XML files that contain: 1) A list of all the files in the eBook, and 2) the table of contents

It's slightly more complicated than that. For a really good introduction to ePub files, and how to build them by hand, look at http://www.jedisaber.com/eBooks/

You can be quite creative with eBooks, as shown by the ePub Zen Garden site, but you don't have total control of the layout, particularly where images are concerned, as the eBook software will shift things around to get the best fit on the page.

There are two main (free) tools around to help you create ePub files:

• Sigil - which describes itself as a WYSIWYG eBook editor
• Calibre - which is an eBook management programme, which can also create eBooks from other formats

If your starting point is a Word doc or similar, and the pages are quite simple, then look at Calibre. As long as your Word doc is nicely formatted (using styles - see Working Efficiently: Word Processing) then Calibre should have no problem turning it into an ePub file which can go straight into your eBook reader.

You'll have limited control over the output, but it's a simple process.

If you are starting from scratch, then I'd recommend Sigil. It lets you write each page in turn and builds the XML files for you. And, if you know some HTML and CSS, you can have quite a bit of control over the look and feel. You can even have floating divs (if that's what rocks your boat!)

It's best to keep eBooks as simple as possible, because not all eBook readers will support every HTML and CSS element. The more complex you make it, eg. with embedded media and imported CSS, the more testing you're going to have to do on your target devices and reader applications.

Pure native applications

By pure native application, I mean one that is crafted using the native coding system required by the device. For iOS devices, this is Objective-C. It may be built by hand, or using some sort of automated tool.

The problem I've had with this approach is that I can get so far, but no further.

For one thing, not having been brought up with Object Oriented programming, I've got an incredibly steep learning curve before I can do anything remotely useful.

For another, even though I've now upgraded my Mac from OSX 10.4 (thanks to Apple store: Meadowhall for all their help with this), and have now got XCode (the development environment) installed, I can't deploy even the tiniest test app to my iPad or any other device without paying $99 per year for the privilege, and going through incredibly convoluted deployment processes.

I'm not sure I understand the philosophy behind this, apart from Apple's desire to control the flow of apps. It creates a barrier to entry that only allows through those who are really serious about app development, with no room for those who are trying it out for size.

Yes, the Android Marketplace is a mess, with no quality control whatsoever more of an open market, with market-drive controls [updated following conversations with someone who's got more experience here than I have]. But, it does mean that the new generation of developers are going to get their formative experiences (when they've got no money) with Android devices.

Anyhow, assuming you have a paid-up Apple Developer account, you've got a number of options to create content-based apps:

• Handcode using Xcode - but this is not for the faint-hearted!
• Use an online tool like Buzztouch or Google's App Inventor - which provide a building-block approach to app building. Buzztouch is multi-platform (although the most recent version is currently iOS only), whilst App Inventor is Android only. They help you to create the code, and then allow you to download it to tweak offline and then deploy.
• Use a high end toolset like the Adobe Digital Publishing Suite to build highly interactive, content-based apps, like the Guardian iPad Edition - which certainly is extremely good-looking, and highly usable - but very expensive to produce unless that's all you do...

Web applications compiled as native applications

The alternative to learning native code is to build your content using HTML, CSS & Javascript - just like a website - and then package it in such a way so it can be deployed as an app.

Building the content then becomes the easy bit (as long as you follow good design practice, often using grid-based CSS which can adapt to the available screen size, eg. Less Framework, Frameless Grid, or Magazine Grid). You can even add a lot of interactivity using Javascript such as the Sencha Touch framework - although this can get complex quite quickly - it's best if you're reasonably happy with tweaking Javascript.

You then need to wrap it in some code which the mobile device will recognise as pure app code.

This has already been done for you.

PhoneGap lets you deploy to multiple platforms, and lets developers make use of the specific features of those platforms, eg. accelerometers or GPS. Deployment can be simple (eg. to Nokia S60 platforms) or complex (eg. to iOS devices - as described above). You will need to know a little bit about your target platform's native code to get the best out of PhoneGap.

Alternatively, if you're using iOS, and you're just deploying content, then look at the Baker eBook Framework. It's similar to ePub, in that you create all your content using multiple html files in a single folder. But the Baker Framework then provides the Objective-C code which transforms the pages into apps that can be sold through the App Store, with built-in navigation and page turn effects.

The Laker Compendium takes things to the next stage, by combing the Less Framework (for design), the Baker Framework V2 (for deployment), JQuery (for interactions like double-taps and swipes), and JPlayer (for playing rich media). It really is very simple to use, and quite beautiful to work with. It's a great way of creating magazine-type apps. But, again, it relies on you having an Apple Developer Account if you want to actually have people using it.

Pure web applications

If you don't want to use any of the device-specific App Stores you can just use the tools above, like Magazine Grid and Sencha Touch to create what are essentially, mobile friendly web-sites. But, with the right bits of code, these display as applications within the device.

The key thing to remember, is that, unless the site has been programmed to save all the content to the device, your users will need to be online to view the content.

The other thing to think about is whether you want payment for access to the content. If you do, then you'll need to build some sort of back-end system that has a user management and authentication process. That's not at all trivial. The OpenAppMkt provides an optional payment mechanism, although it's difficult to know quite how that works, since the developer just provides a link to their mobile-website - which is on the open internet anyway. I'd welcome some enlightenment on that one...

If you don't want payment, then you can put web-apps on the open internet. For a great example of what's possible, see: http://www.asidemag.com/ - best viewed on an iPad.

Content creation services

The final option for creating content, particularly when it's geared around learning, is to use an existing service that already has an approved app in the App Store. Examples include Xyleme's Pastiche, Epic's GoMo, and Upside Learning's Upside2Go.

All of these offer tools to help you create content, quizzes and other interactions, and then to deploy them through an existing app.

Although these services provide a lot of capability, they do also limit what you can do. You'll end up with quite a templated approach, which may become frustrating if your target audience develops faster than the service provider - a situation that is increasingly common with the rapid pace of technology adoption.