Like the blog? Get the director's commentary on my podcast.

Contact

Email, iMessage or FaceTime:

fraser@speirs.org

Search
My Stuff
Navigation
Monday
Jun172013

Podcast: Apple's Daniel Craig

I'll have some more to say about WWDC later once I've thought through all the many implications. Nevertheless, here's a first-impressions podcast with Bradley and me where we chat about our thoughts on the WWDC keynote.

Tuesday
Jun112013

A theory on what "App Store Volume Purchase" may be

At WWDC, one of Apple's famous 'mini text' slides appeared where they show a couple of dozen feature titles in text too small to read in the ten or so seconds the slide is up.

One of those features, for iOS 7, was entitled "App Store Volume Purchase". Naturally, I got interested but there was no more information to be had. I can't find anything on Apple's site about it, but I have a theory.

The biggest problem with the Volume Purchase Program as it currently exists is that it doesn't exist in very many places. Just last week, I was hosting a visit from some colleagues from the Netherlands. I was explaining our deployment model for next year and liberally referring to how you "just Volume Purchase that stuff".

Then I realised they didn't have the Volume Purchase Program in the Netherlands. Ooops. In fact, they don't have it almost anywhere at all. It's only currently available in the US, Canada, UK, France, Germany, Spain, Italy, Japan, Australia and New Zealand. That's really not enough and that list isn't growing longer quickly enough.

So my theory is that, instead of having to set up a whole new portal and payment system for volume purchase, Apple are going to merge it into the existing App Stores.

The App Store is available in 155 countries. The Volume Purchase Program is available in just ten.

If it were possible to buy apps in bulk through the same storefront that is already established in all these countries with the flip of a switch (i.e. an update to the T&Cs and some tweaks to the gifting process), suddenly the access to Volume Purchase takes a massive leap forward.

This is, frankly, essential to Apple's efforts in education. Right now, some of the biggest areas buying iPads have no access to VPP: the entire Middle East, all of Scandinavia, several of the more educationally progressive nations in the EU and most of Asia-Pacific.

On behalf of everyone deploying iOS without VPP, I'd love to be right about this.

A note on terminology: I don't think that this means volume purchase for the Mac App Store. Two reasons: firstly, this phrase appeared on a slide in the iOS 7 section of the keynote. Secondly, Apple is always careful to clearly delineate the "App Store" as the iOS App Store. The Mac store is always referred to as the "Mac App Store". In a section on the OS X Mavericks preview page, they explicitly state "App Store, Mac App Store, and iTunes Store" when referring to a new feature of OS X Server.

Also, a disclaimer: I'm writing this at 1500BST on the day after the keynote. This is purely my speculation based on four words on a keynote slide and what I think needs to be done. I know nothing that anyone else who watched the keynote doesn't also know. Nobody has disclosed anything whatsoever about this to me. Please do not redesign your deployment based on the contents of this post (I can't even believe I have to say that but I do).

Tuesday
Jun042013

iOS 7 Education Wish List

I wrote recently about my iOS 7 "power user" wish list. Those were not education-specific but borne out of experience trying to push how much I use iOS personally.

Here are some additions that I think would be incredibly helpful for education specifically. For almost all iOS users in 1:1 schools, I would say the 'power user' enhancements would be highly beneficial too.

Master Passcodes

We can enforce a passcode on the device but for basic classroom management - particularly in the earlier years - the teacher needs to know the passcode. This leads to (a) lists of passcodes being kept and passed around by teachers and (b) policies against regular changing of passcodes.

An alternative approach would be to allow a master passcode on the device. I mean by this that each device would have two pass codes that would unlock it: one set by the user and regularly changed and another set by the administrator (possibly only by Configuration Profile) and known to staff.

Screen Brightness Limits

One of the main causes of battery problems in schools is children cranking their iPad up to maximum screen brightness and leaving it there. In almost all cases, this is not necessary and it would be helpful if administrators could limit the brightness to, say, 60% of maximum to preserve battery.

Expanded MDM Inventory

In a personalised 1:1 model, it would be helpful to know a bit more about the state of the device through MDM.

For example:

  • Is Find My iPad on?
  • Date of last iCloud Backup
  • Currently running app

It might also be useful to be able to enforce some of these things in the same manner as passcode requirements can be enforced by configuration.

App Blacklisting

In personalised 1:1s, students have the right to install their own apps on the device. Typically, we control what they can install by enforcing an age-appropriate rating by configuration. However, sometimes there are apps that are within the age rating that you don't want people to install.

For example, say you don't want people installing Netflix or Snapchat on school devices. These apps are rated 12+, which is within the rating we would allow for personal users, but we can't block those apps specifically.

If it were possible to deliver an "app blacklist" Configuration to a device, we could do this quite easily. Right now, we depend on the alerting capabilities of our MDM system to let us know who has installed certain apps.

Arbitrary Grace Period for Passcode Lock

Right now, the choices for passcode locking are 1, 5, 15 minutes, 1 hour or 4 hours. I think 15 minutes is too short and 1 hour is too long. Let us set custom durations.

MDM-based recall of apps and books

This is the big one: scaling Apple Configurator's deploy-and-recall capabilities for apps to large deployments. Being able to get licenses back is important in many schools but bringing the devices back to Apple Configurator is costly in terms of staff effort.

MDM servers can currently distribute VPP codes quite effectively but there is no recall capability. The codes, once redeemed, are gone. Changing this would go a long way to making deployments even more scalable.

MDM App Install on Institutional Devices

Currently, when you push apps to a supervised device, the user has to enter an Apple ID and password on the device. This is fine for personally-managed devices but, for institutionally managed devices, you don't normally give the end-user the Apple ID and password. As a result we have to split our app management between Apple Configurator for institutional model devices and MDM-push installs for personal model devices.

It would be ideal if we could unify this into our MDM server without having to give the users the Apple ID password.

Control over OS Updates

iOS 5's over-the-air OS updating has been a great thing. However, it would be valuable to allow administrators to control when the updates happen. I imagine this taking the form of two new MDM capabilities:

  • Be able to turn on Software Update on the device
  • Push a command that updates the OS

With the former, it would allow administrators to 'hold back' an OS update until some testing had been done or, at least, research on how to support the users through the transition. The latter would allow admins to remotely start software update for devices.

Force the user's name or device name to appear on the lock screen

When you have 20 or 30 iPads, all in the same case, it's handy to have a way to distinguish them. Labels on the cases only last so long (i.e. not very long at all) so another way to distinguish them would be desirable.

Apple Configurator allows you to specify a photo for the lock screen and either the user's name or the device name. This works but the implementation is flawed. What Apple Configurator is doing is rendering the name on a PNG and setting it as the lock screen image.

This means that, if the user changes their lock screen, the user/device name information is lost. Unfortunately, the first thing most kids do is customise their lock screen! If the OS could display the device name on the lock screen over the top of an arbitrary lock screen image, this would really help identification.

Additionally, if there were an "admin mode" that would also display QR codes of the various device identifiers (Serial, UDID, WiFi MAC) on the lock screen, that would be great for inventory.

Lower Case Keyboard

This one's for the younger users. iPad's software keyboard shows capitals on the keys but younger users typically don't learn capital letters right away. If a version of the keyboard with lower-case characters were available that would help a lot.

These are just some ideas that come up from a few years' experience in using iPads in an educational setting.

Monday
Jun032013

Podcast: Carrot and Stick

It's Monday, so it's time for another episode of Out of School. This time, Bradley and I talk about Mobile Device Management (MDM) servers.

What does an MDM server do? Why might you want one? How do you decide which one works best for you? In particular, I detail my recent research into trading off the Casper Suite and Meraki.

Listen here: Episode 38: Carrot and Stick or subscribe in iTunes.

Monday
May272013

The Butcher's Bill

So we are coming up on three years with the iPad 1. I thought it would be interesting to look back at our damage rate and see how things went.

I've kept a log of when devices were replaced and why. These numbers are based on a deployment of 115 iPads and all the repairs were handled through the Genius Bar at our local Apple Store.

1 Sep 2010: Dead Digitiser

A pupil reported that her iPad was not responding to touches in one area of the screen. I checked and there did appear to be a ‘dead band’ the width of the screen about one fifth of the way up where drags across the affected area would not be recognised. The iPad acted as if the user had lifted their finger from the screen.

8 Sep 2010: LCD Failure

Our Primary 4 teacher reported that one boy's iPad had developed rainbow stripes across the screen. No evidence of any physical damage to the device.

1 Nov 2010: LCD Failure

Another pupil's iPad is displaying similar video issues to the above.

16 Nov 2010: Home Button

An iPad is exhibiting a sticky home button. Clicks are not always registering.

22 Nov 2010: Broken Headphone Jack

A Primary 1 pupil accidentally broke off a headphone jack in the socket. As a result, the iPad thought there were headphones plugged in and would not play any sound. Neither I nor the Genius Bar could extract it, so the device had to be replaced.

23 Aug 2011: 4x4 Farrago

An iPad was destroyed by accidentally being run over by a 4x4.

23 Aug 2011: USB Failure

An unassigned device that had been stored over the summer was unable to be recovered from DFU mode, consistently showing error -1604 in iTunes.

29 Aug 2011: Cracked Screen

An iPad developed a crack in the lower corner of the screen due to being stacked horizontally under too many other iPads.

10 Nov 2011: USB Failure

An iPad stopped responding to cables being plugged in. Reboot or DFU failed to fix.

11 Jan 2012: Drop Damage

A pupil dropped her iPad right on the power switch. The aluminium case was dented and is mechanically interfering with the operation of the sleep/wake button.

27 Apr 2012: LCD Failure

A pupil's iPad developed black and flashing lines on the screen.

1 Sep 2012: Cracked Screen

An iPad had a cracked screen.

2 May 2013: Sleep Button

A pupil's iPad had a depressed sleep/wake button, making it difficult to turn the device on and off.

2 May 2013: Sleep Button

Another iPad developed a bad sleep/wake button.

Summary

  • 3 LCD failures
  • 2 sleep/wake button failures
  • 2 connector failures
  • 2 cracked screens
  • 1 digitiser failure
  • 1 case damage
  • 1 home button failure
  • 1 headphone jack
  • 1 bad interaction with a motor vehicle

So, over the course of three years, a total of 14 devices have been replaced. That works out at as an overall replacement rate of 4% per year.

Of these devices, half were for what we might call failures - damage not resulting from user action - and the other half were damage. Interestingly, our battery failure rate remains at a steady 0%.

I'm no mechanical engineer, so I can only guess at reasons why we may be seeing such a low damage rate. For one thing, I'd say that the iPad 1 is very robustly built. It doesn't have such a sharp edge as the iPad 2-style case, which can be vulnerable when the device is dropped.

The second thing I think contributed to our low damage rate was the fact that we have carpet in almost every classroom of the school except the science lab.

Another factor is that there just isn't that much to go wrong. A laptop has a complex hinge, more than 100 switches on the keyboard, a moving hard drive, a fragile power socket. The iPad has four switches, a charging socket and solid state storage. The 30-pin connector has proven reasonably robust but I expect the Lightning connector will be even more reliable.

Finally, I also believe that being 1:1, and building a culture of responsibility around that, makes a massive difference to the way pupils treat computers. When your name is on it, when your data is on that device and when its damage or loss will directly impact you, you tend to take good care of it.