Thoughts on Amazon Whispercast

Recently Amazon announced - in the US only, naturally - Whispercast. Whispercast is an online tool that Amazon is marketing as a method of deploying Kindles in your school or business. Given my long-standing wish for a way to deploy electronic books to devices in a way that isn't astronomically expensive or entirely crazy-making, I was naturally interested.

As with all examples of using consumer technology in education, the devil is in the details. The question is: what does Whispercast actually allow you to do that you couldn't do before, and how does it compare to other content deployment systems?

Whispercast seems to be two things under one brand name:

• A basic Mobile Device Management tool for Kindles and Kindle Fires
• A volume purchasing system for Kindle content

Whispercast is said to work with both e-Ink Kindles as far back as the 'Kindle 2' - the last white version before what's currently known as the Kindle Keyboard - and all Kindle Fire devices although some configuration settings are not available on the original Kindle Fire and Kindle Touch. The content distribution part of Whispercast also works for the free Kindle apps on iOS, Android and the rest.

Whispercast MDM

As an MDM tool, you can now do a few useful things with Kindles, and you can do them wirelessly from a central interface:

• Enforce a passcode
• Configure wireless and proxy settings
• Block things: Facebook, Twitter, the Kindle browser and the Kindle Store
• Block factory reset, device deregistration and changes to network settings.

These are essentially the bare minimum things you might want to do when managing a Kindle. I'm surprised, though, that there's no adult content filter in this post-50-Shades world. I believe the new Kindle Fires can do this, but that it's not enforceable in configuration seems like an omission.

You may wonder how you're supposed to configure network settings on the device by a push from a remote website. The answer is that Whispercast will generate a configuration file for download that you manually install on each Kindle via USB. In this respect, it's not so different from installing a Configuration Profile through Apple Configurator. My understanding is that this step is only to configure the networking and the rest is configured via Whispercast push.

Whispercast Content Delivery

This is really the meat of any new features for these devices: can we get simplified access to books, apps and the rest? Unfortunately, Whispercast seems to fall short of my hopes and dreams: essentially, Whispercast appears to be functionally equivalent to Apple's Volume Purchase Program.

In the most basic form of using Apple VPP you bulk-purchase gift codes for specific apps, distribute them to end users and those users redeem their coupons in their own iTunes accounts to get a download of the app. As we have discussed before, this means that the end user now 'owns' that content and you have no way of getting it back.

Under Amazon Whispercast you bulk-purchase books, allocate those purchases to users and the users then see these purchases available in their account. Having spoken to some Whispercast beta testers my understanding is that, once a purchase is allocated to a user, it cannot be reallocated to another user at a later date.

The only significant difference between the Apple VPP model and the Amazon Whispercast model is that Amazon automates the "hand out the codes" step of the process. Most good MDM providers that support iOS can do the same for VPP codes.

Deployment Models

So, how could we use Kindles in school? I'm not all that interested - yet - in the Kindle Fire as a general purpose computer as it seems to suffer from many of the same problems as the Nexus 7 (in a nutshell: few great apps and none that aren't already on iOS). I am, however, very interested in finding a workable eBook platform for schools that combines ease of deployment, sensible pricing structures and year-to-year flexibility in reallocating purchased resources.

Essentially, the eBook problem comes down to: you, the publisher, want me to buy everyone a brand new copy of the book. I'm happy to do that, but you want £9.99 per copy. We're more used to paying £9.99 and giving it to 10 children over the course of years. Make your eBook £1 per copy and we can talk.

On the other hand, I'll buy 30 copies at £9.99 but I need to be able to reallocate those books next year.

Is there a way to square this circle? Maybe.

Whispercast, like the iTunes Store, requires that each Kindle have a separate Amazon account associated with it. Unlike the iTunes Store, Whispercast can bulk-create these accounts for you, which is handy.

Perhaps the model is this: create 20 generic "First Grade" accounts (e.g. fg01@example.edu through fg20@example.edu) and buy 20 copies of the First Grade reading list. Have the students use that account for a year. When they move on, give the account and password to the next set of pupils coming in.

This is harder to do in the Apple world because the use of AppleID/iCloud is so pervasive across the system. With the Kindle system (at least on the e-Ink Kindles, if not the Fire), it would potentially be easier as there's less actual data being stored in the user's account. The pupil logging into the account the next year would - I presume - find the last owner's book locations, highlights and notes in there but that's hardly different to the common experience of getting someone else's used textbook.

Such a deployment model might work in primary education - where everyone is in the same class, likely reading the same class novel at the same time. It doesn't really work for secondary education unless you buy all the books for every account because the pupil using the account next year is unlikely to be taking the same mix of classes as the last pupil.

I don't know whether Apple or Amazon is going to get this right first but the company who finally cracks it stands to win a lot of business the education market.

My thanks to Steve Kinney for reviewing an early draft of this article.

Two Weeks with iPad mini

The first thing to get out of the way is that the iPad mini is an iPad. Even more than calling it a real iPad, I want to describe it as a full iPad. Give or take a few benchmark points, it's as powerful as any iPad that existed until the 4th-generation 9.7" iPad. This is really important. It's important because the executive summary of what I'm about to write is this: get the one you like best.

As the tablet market has developed, I've fallen into two lines of thought about tablets:

• Tablet hardware is uninteresting, except insofar as it allows the user to have wonderful experiences of software
• The question of what you want to do with a computer has never mattered more

I'm not going to reiterate everything that's been in other reviews of the mini. It's thin, it's light, it's not Retina. So what? Well, I'll tell you what I think personally and then I'll tell you what I think about the mini for school situations.

The Display

Let's talk about the non-retina display. I understand the engineering reasons behind why it's not retina but I can't pretend that I like it or that I don't notice it almost every second I'm looking at text on the iPad mini. Games, videos, photos are all fine but to my Retina-ruined eyes, text simply isn't up to scratch.

Maybe most people won't care, but I care. The iPad mini is a functional eReader that will do in a pinch but I can't imagine that any serious eBook reader would choose the iPad mini over even the basic Kindle.

I do have something good to say about the display, though, and it's this: as I expected, the 4:3 aspect ratio of the iPad mini screen puts it in a different league of usability from the 16:10 tablets that I've used in the past. The only compelling reason to build a 16:10 tablet is that it makes the device really good for watching movies. The 16:10 aspect ratio isn't really good for anything else. It's weirdly tall and narrow in portrait orientation. In landscape orientation, a widescreen device doesn't have enough height to be useful once the keyboard is on screen.

By contrast, the 4:3 aspect ratio of the iPad is, in many ways, its saving grace. With this size and aspect ratio, you get a satisfyingly wide screen in portrait and a usefully tall screen in landscape. Compared to my experience using a Nexus 7 to actually get stuff done, it's night and day.

The Size and Weight

Like other tablets its size, the iPad mini doesn't disappear into a pocket unless you wear cargo pants. It's usually noticeable but it won't make you list to one side with its weight. The weight is a crucial factor in the attractiveness of the iPad mini: for anyone who spends their time standing or walking and using an iPad - as many teachers in iPad schools do - I think the ethereal lightness of the iPad mini is going to be overwhelmingly desirable.

I have not found the mini to be unusably small, even with iOS being scaled down to fit. There have been occasional apps where certain operations have been fiddly, and I found drawing precisely with a stylus was difficult because of the relative size of the stylus tip. This might be something that can be overcome with a bit of practice but I'm not there yet.

The keyboard is perfectly functional but I couldn't say I find it as fast or as comfortable to type on as the full size iPad. Over the course of the last two weeks I've been using it, I have become much faster with it but still not in the same ballpark as the larger iPad.

This leads me to one of my main concerns with the mini in 1:1 schools: if you're going to ask pupils to spend a lot of time with this device, consider carefully how much typing they're going to be asked to do.

That's not to say the mini is wrong for all schools everywhere. If your model of use extends to typing a few URLs or search terms, using books and other content, the mini may well be a fine choice. I would just suggest that you think very carefully before going 1:1 with the iPad mini. I'm not sure I would.

In School

I think the dividing line between the iPad and the iPad mini is not so much "what you want to do on the device" as much as it's "how often and for how long you want to do it". The iPad mini can do anything an iPad 2 can do and, thanks to improved cameras, WiFi and cellular, sometimes it can do it better.

In an established 1:1 school like Cedars, we're all-in on iPad. We don't have a computer lab to fall back on. The iPad has to do all the heavy lifting for us. In such a situation, I really don't see that the iPad mini is a reasonable device to give a pupil. It is, in my opinion, just that side of 'too small' to be a 5-days-a-week, 6-hours-a-day tool for pupils. It is in no way too weak a computer to be used that way. I just think that the more restricted keyboard will prove tiring and the fractionally more cramped UI will show itself as problematic over extended use.

In a school where the iPad is deployed as a shared device, the iPad mini might be a fine device to use. Such deployments typically aren't so focused on extended content creation. Yes, you'll probably make a few things on the device but because they're shared, you're not going to be doing projects that span weeks or get into more detail. If you're using the iPad mini for a few hours a week, I think it will do a great job for you.

I don't see cost as a major driving factor towards the iPad mini. At current rates of device churn, in my opinion, most schools should be leasing devices these days. The difference between an identically specified iPad mini and iPad 2 is £60 which, over three years, is a difference of £1.60 per month. To my mind, that's an irrelevant saving because the most expensive computer deployment is the one that doesn't work for you. Far, far more important to get the right device.

In the end, though, the beauty is that we now have another great option for using iOS in schools. It's still the best mobile OS, with the best ecosystem, with the best support, with the best tools. I know this because at every education meeting or conference I go to, iPad is the only tablet people are seriously using. I can't stomach a future where people with iPads decide that children should get bargain-bin Android devices.

Give it Two Weeks

I initially wasn't crazy about the iPad mini. This review has lain in my Evernote drafts folder for a couple of weeks while I gained more experience with the device. Having used it more or less continuously since launch day, I can say now that I think it is - overall - a great device.

I was initially very unhappy with the display. I still am, in large part, but I am also aware of what I'm getting in return for giving up the retina display: size and weight gains. Moore's law will bring us a day when we don't need to make the resolution/battery tradeoff we make today but I can't pretend I don't constantly notice it.

For the first week, I took the iPad mini on the road. I still carried my full-size iPad but didn't really feel the need to pull it out my bag, except to deliver a presentation. I was forcing myself to use the mini and wasn't really enjoying it. It was cute that you could get the iPad flavour of iOS in this little package but it wasn't a 'real' iPad. It may seem weird to say that a week of travel didn't sell me on the device, but a travel week is always a bit of a hiatus from 'real life' and I wasn't really putting the device through its paces.

The second week, though, was different. I was teaching all week and didn't really have time to chew over questions of should-I-use-this-iPad-or-that-iPad, I just had to get my gear and get up in front of classes hour after hour after hour. It got to Friday and I realised that I had literally not touched my 3rd-generation iPad all week.

That's when it clicked. When I realised I had - without really thinking - done all the things I need an iPad to do for a whole week without being forced back to a full-size iPad, I saw that the iPad mini is just that: an iPad. No need to over-think the distinction, no real need to develop theories about it: the iPad mini is an iPad in the same way that the 13" and 15" MacBook Pro are both Macs. They'll both do the same 95% of the job: get the one that suits you best.

The iPad mini reminds me of my first MacBook Air. When the Air first shipped it was a Mac with some serious technical compromises with a design and form factor so compelling that you would re-arrange your entire digital life to make it work. The iPad mini reminds me of that except that it only has one serious compromise: the non-retina display. In every other respect, it's a full-bore iPad. In fact, I don't even refer to it as "my iPad mini" any more; I just call it "my iPad".

So, to wrap up: despite myself, despite my initial impressions and despite my expectations, I love my iPad mini and I find it's really working well for me. I'm a much heavier iOS user than most people and it has handled everything I've thrown at it. I have no doubt that it will work perfectly for a huge number of people. I remain a bit sceptical about pupils using it all day every day in a 1:1 situation in schools. For that application, I still think a 9.7" iPad will be easier and more comfortable to use.

Still, it's great to have options.

Teaching Programming on iOS

I have been working for some time on a plan to move my programming classes off Macs and onto iPads. It's finally happening this year. A few people have asked me to write this up, so here goes.

As everyone knows, there are no fully-fledged software development environments for iOS. The closest is a game programming environment called Codea which, while good, doesn't easily map to the kinds of things we currently teach in exam-level Computing courses.

A few years ago, I used to teach using RealBasic on OS X. RealBasic is a fairly standard clone of VisualBasic, the language and IDE that (I guess) most Computing courses are taught with. I hated it. I hated it because the evident link between the code you wrote and the way it executes is quite obscure. I spent as much time explaining where you should type in the code as I did explaining the actual code itself.

Two years ago, I decided to change things. I switched to teaching in Ruby and I switched to using a text editor (TextWrangler) and Terminal. The simplicity is glorious! A simple link between code and result, and no magic glue in-between. I fully appreciate that libraries, frameworks and runtime support are all essential to scale software development up to real-world dimensions but that's not the game I'm playing.

Enter iPad

One of the astonishing results of our iPad 1:1 deployment has been the dramatic decline in the use of the Mac. Within less than two years, I am the only teacher still using the Mac on a regular basis. This was never part of the plan and I didn't expect that it would happen so soon. I thought it might happen eventually - perhaps in 3-4 years, certainly after one more refresh of our Mac setup.

Today, it quite seriously looks like we won't buy more than a handful of Macs again. We’re not cutting our teaching to fit what the iPad can do either - we have never done more with ICT, with better outcomes and deeper learning than we are doing now with iPads in everyone's hands.

Taking Programming Mobile (and Virtual)

So, how do we take Ruby programming mobile? Turns out, it's not so hard (assuming you understand AWS cloud computing infrastructure, IP addressing, SSH configuration and Linux sysadmin, naturally).

The basic idea is that we are going to set up an Amazon EC2 instance, SSH into it and edit and execute our code over there. There are several really nice SSH clients for iOS. My personal favourite is Prompt by Panic, but the idea is the same regardless of the client.

AWS Basics

In case you're not all that familiar with virtualised cloud computing, here's a basic run-down.

Amazon EC2 allows you to spin up a virtual Linux or Windows sever running on Amazon's computing infrastructure. You can start and stop an instance as you need it, and you only pay for the time the instance is running. Instances can run in one of several geographic areas and prices vary slightly from region to region. For my deployment, I used the EU (Ireland) region because we are going to be working interactively and want the lowest latency possible.

The per-hour prices vary by the capability of the virtual machine but, for our purposes, we don't need massive power. The per-hour costs for the smaller instances are incredibly low. An on-demand "Micro" instance costs $0.02/hour. Two cents per hour. So you fire up one of these EC2 instances in August and shut it down the next June, you're going to pay about £80. If you only run it during the school day, it's about £20 per year.

Given that we're deploying iPad anyway for all the other parts of the school, you can see how provisioning a lab just for a programming class isn't an easy conversation to have. By my calculations, my subject now costs the school £10.80 per pupil per year to run. If I had to keep buying Macs just for Computing, the per-head cost would be over £160/year.

Benefits

I'm a huge fan of strategic outsourcing. We are rapidly moving towards a situation at Cedars where we will have essentially no infrastructure in the school except for WiFi (and possibly not even that). This is deliberate: I am the only technician, systems administrator and network manager in the school. I simply don't have time to deal with deploying and looking after servers on the premises. Neither do I want to. I would much rather spend my expensive and valuable time working on things educational rather than things technical.

In order to run my class with computing resources on-site, I would have to manage a suite of laptops or desktop computers, with some kind of file server and directory infrastructure. Alternatively, I can pay Amazon a penny an hour and I don't have to care about hardware at all.

The benefits go beyond the infrastructure and finance, though. It's never been possible for me to set actual programming homework before because few families have development tools installed on their home computers. Now, though, because I know the device that's gone home and I know that the server environment is available from anywhere, I can start to set programming exercises to do at home.

Workflow

The basic programming workflow for the student looks like this: we use Prompt to connect to the server over SSH and execute the Ruby code over there. Up to now, I've been having the students edit their code using the nano text editor over a second SSH connection as it's relatively approachable for new users of command-line editors.

After some more investigation and help from Twitter pals, I realised that both Textastic (which we've used before for teaching HTML editing) and Diet Coda can edit a file and save it back to an SFTP server relatively transparently. There are advantages and disadvantages to both: Textastic is a far better Ruby editor, but Diet Coda has both editor and terminal integrated in the one app. I'm probably going to go with a combination of Textastic and Prompt for now, since we've already deployed both of those apps.

I think that programming is going to be that one special case where a hardware keyboard on an iPad is really important for two reasons: firstly, several common programming symbols are only accessible through the 'mathematical' keyboard on iOS. To type a "<" symbol, for example, you have to hit the '.?123' key, then the '#+=' key and then type the symbol. Prompt allows four customisable soft keys above the keyboard but there are often more required in programming. Textastic does have a special 'symbols bar' that allows quick access to many symbols, so it will be interesting to see if clever UI design can mitigate this problem.

The second reason for using an external keyboard is to recover even more screen space on the device. Programming using the software keyboard is possible in a pinch - great for doing something quick on the go - but you want as much screen space as possible for code.

The Evolution of iOS

I'll let you know how this goes, but I think this is a fascinating step in the evolution of the use of iOS in education. We're starting to solve some of the harder parts of the curriculum. Computer programming was one thing that people said the iPad would "never" be suitable for. Certainly, a lab of 27" iMacs would be preferable but the simple truth is that Computing Studies is not a sufficiently important part of the curriculum that the requirements of that subject can dominate the whole-school approach to IT. It's iOS's world; we just live in it.

In a sense, yes, I'm cheating in that I'm not actually programming on the iPad itself but so what? The entire point of mobile devices is that a good proportion of their power comes from being always connected to the Internet. You wouldn't say that you can't search the web with an iPad just because you can't store and search Google's index database on the device.

The idea of not owning infrastructure is really interesting and important to me. I want to stay as agile as possible with our technology and buying only what I need when I need it is an important part of this.

The Big Redeployment

We are currently two weeks away from opening. This summer, we decided to redeploy our devices from scratch. Same 115 iPad 1s but it was time to reset everything.

I made a big mistake last summer that started to cause some trouble as the year wore on: I didn't reset the devices to zero. The result was that kids were running out of storage space on their devices by February. One child, for example, had created 5GB of paintings in Brushes alone. Our kids create a LOT of things on their iPads (and they don't even have a camera yet!).

Before the summer, I had hoped to be able to move towards a deployment where the students have their own Apple IDs and we would be able to deploy apps to them directly. Unfortunately, we still don't have access to the Volume Purchase Program in the UK yet so that plan has had to be shelved for another year. There's no way you can re-work your deployment approach in the middle of a school year, so we'll move to individual IDs when we refresh our devices next summer. That is, assuming VPP access has arrived by then!

Before the end of term, we had the students email any work the teachers wanted to keep to their Basecamp portfolio. That the new Basecamp provides the ability to upload files by email is a huge win for this.

My approach to redeployment was basically this:

Firstly, I reset one device and completed the iOS setup wizard. I skipped the part where you create or supply an AppleID, since we're not really going to be using iCloud this year. I then captured a backup of this device using Apple Configurator - this "Master" backup being nothing more than an activated iOS 5.1.1 device. There's no point in adding configuration profiles at this time as they won't be restored to other devices anyway.

Next, I connected each device to Apple Configurator to update them all to iOS 5.1.1. Apple Configurator is the only tool that can parallelise iOS installations on devices, so this was a big time saver. After the erase-install, I restored the Master backup to every device and set the name to "iPad". I also installed our base configuration profile, which contained settings for:

• App Store age restrictions
• WiFi password
• A web clip for Wikipedia
• Calendar subscription to our school calendar
• CardDAV account for our shared address book

One of the problems I ran into was that I wanted to also enrol all the devices in our MDM server at the same time. Enrolling in an MDM server requires WiFi access to complete the hand-shake between client and server. Unfortunately, I couldn't figure out how to convey to Apple Configurator that there was an ordering dependency between the 'core' profile and the MDM enrolment profile: the core profile needs to be on first to set up the WiFi so the MDM profile could install.

The workaround was to put the MDM profile in iPhone Configuration Utility and install it there manually after Configurator was done. Ugly, but it works. At this point I have 105 iPads all activated and enrolled in MDM with no apps on them. Time to set that up.

Each classroom in the school has an iMac which acts as the 'sync' station for the iPads in that class. The first thing I did was to log into that iMac and trash the existing iTunes library. We still have access to the apps we bought, but I want each teacher to pick the apps that they would like for their class. This will save space on the devices and allow a more customised approach per class, even without individual Apple IDs.

I wanted to make sure install was working though so, in each classroom, I downloaded iBooks and iTunes U to the computer, then synced each iPad. The iPads were already activated but I still had to give them a name, configure the syncing, and provide a password to encrypt the backup files. I also re-labelled the devices at this time because I'm not necessarily giving each pupil back the exact device they handed in. I also took this time to create a new device allocation spreadsheet so that we know which pupil has which serial number.

Start-to-finish, this took me a day and a half to do for 105 devices. What remains is for each teacher to come in before school starts, pick the apps they want their kids to have and sync their class set once.

Next week is all about my own teaching preparation, then teachers come back the next week and we're doing some intense preparation work on iTunes U.

iTunes U Enrolment and Apple IDs

As I mentioned in my last post, there are some new arrangements for iTunes U courses, specifically the ability to distribute an "enrolment code" and have students sign up to the course in the iTunes U app using their Apple ID.

This seems like the obvious way to do things but in many school deployments, students are not in control of the Apple ID that their device uses. Sometimes that's because the devices are shared (in which case, using iTunes U is going to be difficult anyway) but more often it's because the school is in a country that doesn't have a Volume Purchase Program yet. That most countries still don't is another grumpy discussion for another time.

Anyway, at first glance it seems that you absolutely need individual Apple IDs to enrol students in a course now. I've always been keen on handing over as much IT autonomy to the student as possible, and that's where I think we should all be aiming, but changing your AppleID structures is a once-a-year thing to do and no small matter. Is there a workaround in the meantime?

It turns out that there is: to create a course that students can subscribe to without entering AppleID credentials, you have to:

• Create the course in Course Manager - this creates a private course with an enrolment roster.

• Submit the course to the person who controls your institution's iTunes U Public Site Manager

• Have them 'hide' the course in PSM.

This creates a course which has a direct URL for subscription (it's referred to as the 'Audit URL' in iTunes U) but which does not require Apple ID credentials to subscribe to.

This isn't an ideal solution as it requires coordination between all the course authors at an institution and the person running the Public Site Manager. Still, it works for now and the future is ever more clearly heading towards individual Apple IDs for individual students. That's where I'm recommending all new 1:1s start their thinking but, still, always the two stumbling blocks of no Volume Purchase and COPPA's lower limit of 13-years-old for an iTunes account. I hope we can get these things ironed out soon.