Blog

Twitter followers will know that I've been interested in Chrome OS for a while. Podcast listeners will know that I've been crazily frustrated with Apple's technology since iOS 7 shipped, particularly from a quality standpoint.

Put these two things together and it's time to experiment further with Chromebooks.

When you work in educational technology, you have to be a little like the Roman god Janus and look both forward and backward. You look backward because everyone else is behind you: pupils, parents, colleagues, administrators, regulators, government. These are the people you have to take with you into the new.

At the same time, we have to periodically make very clear judgment calls about what is happening right now - without reference to the past or the future. This is what happens in your summer refresh: it doesn't matter what's coming out in October or at CES and it doesn't much matter what you've deployed in the past - you have to sign your PO in June and the trucks roll up in August with whatever is the best possible decision at the time. Such are the hard scheduling realities of school life.

Like Janus, it's also essential to keep one eye on the future. Trends change, the conversation moves on and, if you want to serve your school community correctly and well, you have to not just be abreast of them but be leading and living those changes well before you expect others to.

This is what keeps me up at night.

When we started with iPad in 2010, the argument was around the appropriateness of "mobile devices" in the classroom. Could we manage without the standard computer tropes that adults of the time had been brought up with?

Douglas Adams:

I've come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.

I was 32 when we started with the iPad and, you know what? Douglas Adams was right.

It's odd to think back to those days and remember the heat we took for doing what is now an accepted (if not yet widely-implemented) part of the educational technology stack.

They said children couldn't multi-task on iPads. Wrong. They said children couldn't type on iPads. Wrong. They said children would break their iPads. Wrong. They said children would lose their iPads. Wrong. They said Android tablets would be better and cheaper within a year. Wrong.

What the over-35s meant was that they couldn't multi-task, type on or handle their iPad without breaking it.

Having said that, the move to mobile devices wasn't as much of a paradigm shift as some people thought. An iPad or an iPhone is, after all, a fairly doctrinaire computer of the type that Apple has made since 1984. Many people couldn't see past the introduction of the touchscreen and thought it heralded a completely new era of computing. Many thought that the tablet had to be understood from first principles rather than looking at it as an evolution of the laptop computer. While the touchscreen and the tablet form factor have enabled a number of new and important use cases and contexts, I'm not so sure it represents a completely new era. The smartphone, because of scale, reach and carrier subsidies, is genuinely fundamentally a different proposition but that's another post.

Like every Macintosh before it, an iOS device is essentially a package of processing capability, IO, sensors and local data storage and state maintenance. Later revisions brought some online syncing capabilities with iCloud. Even with iCloud, a user's "suite" of devices - their Mac, iPad and iPhone - remain three distinct bundles of local data and state, some parts of which are synchronised through the cloud but don't live in the cloud.

This distinction is crucial. This distinction is the spring from which all the confusion arises when your colleagues and relatives don't understand that buying more iCloud storage space won't solve their storage space problems on their 16GB iPhone.

Continuity and Handoff in iOS 8 and Yosemite attempts to bridge the divide between devices. While we have had data syncing for some time in OS X and iOS, Continuity is about attempting - at some level - to synchronise state between devices.

You can understand why iOS is built that way. The first iPhone had only EDGE networking and a weak battery. Any software process that depended on constant connectivity to the network was a total non-starter in the mid-2000s. Today, though, we have much more power-efficient hardware in our devices, better batteries and much faster cellular networks.

It seems to me that the prospect of a cloud-only existence is very close. Hence my interest in Chromebook.

I don't wish to reiterate the simplistic arguments about "you can't do this or that on whatever device". When we're looking at longer-term trends, rather than making tactical decisions about the current deployment, we need to think deeper. We need to avoid the human tendency to over-estimate the short term and vastly under-estimate the long term.

What I want to think about more is the idea that we are moving into a post-mobile era. Encapsulated in that phrase "post-mobile" is all kinds of opportunity for misunderstanding and erroneous refutation, so let me be clear: post-mobile doesn't connote that mobile devices are going away. Far from it. They may eventually be the only devices we own.

What I mean by "post-mobile" is that we may be about to move away from the idea of local state and storage, even on our mobile devices. To a certain extent - even possibly to a great extent - most people have already done this on the desktop (and laptop). Every significant application or service that has arisen in the last ten years or more on the desktop has been a web app. The last exception I can think of is possibly iTunes and, in the broad scheme of computing, it's even debatable if iTunes counts as "significant".

I started to notice this when I started describing my iPhone as " a remote control for cloud services". It seemed that every app I touched regularly on my iPhone was an app that more or less totally depended on networking for its function. Let's look at the main ones:

Mail

Safari

Twitter

Music streaming (iTunes Match)

Google Drive

Maps

Feedly (RSS)

Pocket

Travel apps

Instagram

Netflix, BBC iPlayer, Amazon Instant Video, YouTube, Plex

Evernote

It seemed, ultimately, that my iPhone was becoming a stateless device. This hit home to me when I upgraded to my latest iPhone. Instead of restoring my backups, I set the phone up as new. There was almost no data loss: everything I had access to on that phone came back from cloud services almost immediately.

I think this is largely a function of the use cases that a smartphone is put to: communication and entertainment-oriented tasks that depend on up-to-date information. It can be done but it's not comfortable to write a Keynote presentation on your iPhone.

The iPad, however, is a different story. There, I do build movies in iMovie, work in GarageBand and create in Keynote. There is a lot of local state on the iPad and it can be quite difficult to manage at times.

So, where does my interest in Chromebook arise from? Well, ChomeOS has always felt to me like it really had the soul of Google in it, in a way that Android never did. Google is all about the web and ChromeOS is all about the web.

My interest in ChromeOS definitely also waxes and wanes along in inverse proportion to my frustration with Apple. Right now, it waxes strongly as Apple's ability to ship reliable software appears to be disappearing like snow off a dyke, as we say in Scotland.

ChromeOS isn't interesting because it's got better apps than iOS. Generally, it doesn't. It's not interesting because Chromebooks are nicer tools than Apple computers; they're not. I won't lie: Chrome OS is partly interesting because Chromebooks are 20-50% of the price of Apple computers.

ChromeOS is really interesting, though, because it's a computer whose entire existence is built around the idea that neither state nor data is local to the machine. In some ways, we had this before when we used OS X Server to manage OS X machines with auto-mounted home directories and so forth. Auto mounted home directories barely worked across a LAN, however, far less a WAN. Software just wasn't designed to talk sparingly to storage in those days.

The total decoupling of state and data from the machine and coupling it to the user's account has a number of interesting implications. The device becomes essentially disposable or at least highly fungible. It becomes secure, since there's little or no local data to attack and even logging into the computer can require 2-factor authentication.

When I first started looking at Chomebooks, they were cheap and quite weak computers. They were slow and made of poor plastics. Today, though, they are much faster and much better built and have achieved this without the kind of price increases that we have seen from the once-cheap Android tablets not trying to compete with iPad on performance and quality. Chromebooks are reaping the dividend of 30 years of development on PCs.

At its heart, though, a Chromebook is a computer built around Google Drive and Google Docs. The Drive suite is the killer app for Chromebook, and the rest the rest. It is interesting, though, that there increasingly exists a class of software that is "synchronised local state" and another class that is "cloud state accessed locally". This is the difference between Pages and Google Docs or between OmniFocus and Todoist or between iMessage and Slack.

The long-term strategic part of this is that it appears to be much harder to build a robust cloud-coordinated back-end to previously local-state software than it is to make a cloud-backed application work offline. Witness the rather sorry state of collaboration tools like iWork's iCloud collaboration, OneDrive or even Dropbox.

The flipside of this coin is that it's not just about having your state and data in the cloud; it's also about having your applications running continuously, even when you're not actively using them. There's no IFTTT channel for Microsoft Office. I'm very interested in what happens when our tools are no longer tools that we start and stop using but rather are processes that operate continually in the cloud working on our behalf and which we check in with from time to time as we need. This is the difference between Google Now and Siri: Google Now works for you when you're not watching; Siri works only when you whistle.

Phase one was about adopting "mobile" technology in schools. It worked and it's embedded now. iPad is the workhorse tool and I appreciate that very much. It just means it's no longer particularly intellectually interesting. For me, phase one is over.

To my mind, phase two - the next five years or so - is about making full use of the cloud in schools. I hope Google moves ChromeOS beyond the laptop form factor, so that we don't lose some of those benefits of mobility. I sure hope Apple decides to be part of that conversation at all.

So iOS 8 is upon us and it brings many of the features that I've been waiting in iOS for a very, very long time.

So what's wrong with iOS 8? I've already criticised the bugs, and bugs are bad, but bugs get fixed. What about the design choices and feature set?

Safari and the Web

On our podcast, and online, Bradley and I have criticised Safari as one of the areas of iOS that is materially holding the platform back. Safari's compatibility with the majority of websites is very good. No real complaints there.

The remaining issues centre around two things: web designers being either too clever or too dumb for their own good and file transfer over HTTP.

The first is harder to fix. How do you convince web designers to take touch seriously? The current solution for most is to basically hive off touch compatibility into an m.example.org ghetto. It's not that the desktop web is unusable on an iOS device; it's more that many navigation designs that depend on things like mouseover actions on page elements are extremely non-obvious on touch devices. Despite the fact that a touch, then a second touch usually makes the element work, it's indistinguishable from "broken" in many cases.

The second issue is that the browser isn't just about loading and rendering HTML. Many productivity tasks involve downloading files from, or uploading files to, the web. It could be updating a website, filling in an online expenses form, or whatever.

The download part of this problem has been kind of solved for a while now. You can download one file and, when it's done, use Open In... to send it to another application. This is functional but basic: you have to wait for the file to complete downloading before you can do any action on it, or open another tab (which risks overwhelming Safari if you open too many).

A download manager for Safari would be most welcome. Even better - and Google is starting to do this in Chrome - would be a "download this URL into my iCloud Drive" in which Apple's servers would download the file directly into your Google Drive account from where you could later access it.

The big blocker right now is file upload. Since around iOS 6, it has been possible to upload photos to a website through Safari. This mechanism needs to be generalised to any file. Today, the procedure for any company wanting to accept arbitrary file uploads from iOS looks like:

Design, build, test and ship an iOS app.

Enable it to accept and upload files via Open In... or picking from iCloud Drive.

We now have a filesystem-like representation on iOS - it's called iCloud Drive - so it should be possible to pick any file from iCloud Drive and upload that through Safari.

All of this, by the way, should also apply to Mail on iOS when it comes to picking attachments.

Inconsistent File Presentation

I do a lot of work on iOS and I use a wide range of apps. What I see right now is a highly inconsistent approach to file handling in many apps. This is not unexpected as developers have spent substantial time over the years building custom integrations to services like Dropbox, Box and Google Drive.

What needs to happen soon is for Apple to seriously tighten up the App Store Review guidelines on file presentation. Everyone needs to use the iOS 8 document picker to present file operations to the user.

Here's a concrete example: I use Auria by Wavemachine to record our podcast. It's a great, powerful app for editing audio on iOS. When I'm done with the mixdown, I'm presented with a fixed range of export options that is, in full: Dropbox, Soundcloud, AudioShare, email or none. We use Google Drive to transfer the audio files for the show, but there's no way to get there directly from Auria.

Basically, all of these custom integrations need to go away and Dropbox, Google Drive, et al should be presenting themselves as iOS 8 Document Providers. To their credit, Dropbox already does but too many apps right now do not present the user that option when moving files around.

Back to the Mac

As iOS evolves, I keep using the same question to gauge its progress: what is it that keeps me going back to the Mac? The list is shorter now than it's ever been. Clipping to Evernote is now easy in iOS 8 with their Safari extension. Using 1Password is now as slick and integrated on iOS as it is on OS X. There remain a few stumbling blocks, but not many.

I ask myself what it would take for me to completely eschew owning a Mac. I'm not there yet and I'm not even all that close to it in practical terms. Like your pal that doesn't have a car but who can only do so because you give him a lift, I could possibly do without my own personal Mac only because I have access to Macs at school.

One of the reasons for this is that the Mac is how you recover an iOS device. If your device turns up its toes completely, one way to get it back is to plug it into a Mac and perform various incantations to revive it. If your iOS device ends up totally full of images and video, the fastest way to solve that problem is to plug it into a Mac and download them all through Image Capture.

You may wish to argue that a "mobile OS" doesn't need to have all the features and power of a "desktop OS" but I disagree. For many, the mobile OS is their first OS. It may even be their only OS. I argue that these devices need to be a superset of desktop functionality, not a subset. They can't be that today because of power, CPU, storage and bandwidth constraints but the gap is closing fast.

It's no secret that I have been a huge fan of iOS since its inception. It brought many great improvements in security, stability and approachability for the beginner-to-moderate computer user.

Unfortunately, it increasingly feels like those days are at an end. The iOS 7 and now iOS 8 rollouts have simply not been up to the quality of earlier releases.

For sure, iOS 8 is highly ambitious. I have long been an advocate for many of the features that iOS 8 brought: extensions, interoperability and so on. Sadly, complexity has brought with it fragility.

We have seen problems with apps not being updated in a timely manner. We have seen issues with crashing, devices rebooting, rotation glitches, keyboards playing up, touch screens not responding. Indeed I'm typing this while babysitting the full restore of an iPad that one pupil "broke" - through no fault of their own - while updating to iOS 8.

In times past, I was happy to let students update their OS as they saw fit, since it was generally a highly reliable operation and a safe thing to do. No more.

iOS does not provide a way for administrators to block users from updating their operating system. It's never needed it until now. Today, though, I regard it as a critically missing piece of a large-scale iOS deployment.

When iOS was a simpler beast, I tried to see beyond what we had "lost" in terms of, say, multitasking in order to appreciate what we had gained in these other areas I mentioned in the first paragraph. Today, we have regained much of the power but are in danger of losing one of the main pillars of what made iOS great in the first place.

In terms of features and capabilities, iOS 8 brings me a lot of optimism. In terms of robustness, stability and reliability, it's giving me new reasons to worry.

I recently gained access to the first version of Google Classroom, Google's classroom management system for schools.

The obvious comparison in my mind is the comparison with iTunes U as the other first-party classroom management platform. It's interesting to look at where both of these platforms are today.

Obviously iTunes U is a far more mature product, having had nearly three years in production to gain all of its refinements. Google Classroom is a brand new 1.0 product, so bear that in mind as we go through this.

The Common Stuff

Both platforms do the student management stuff similarly: have students enter a random course code to be added to the class. This is by now pretty standard stuff in edu platforms.

Google Classroom allows the teacher to add people to the course but, strangely, only by picking from your Gmail contacts or previous correspondents. There's no way to upload, say, a CSV of class IDs. iTunes U doesn't have any way for a teacher to add people; it has to be done by self-enrolment.

Both platforms allow teachers to share materials with students. iTunes U requires the teacher to upload from their local storage into a "materials" space in iTunes U. Google Classroom allows upload but also picking from the teacher's Google Drive or searching YouTube. Both platforms support attaching URLs to assignments.

Google Classroom doesn't have any way of attaching materials to a class without attaching them to an assignment. In iTunes U, you can add materials to a course for students to access without making that item an assignment. iTunes U only allows you to attach one item per assignment whereas Google Classroom allows multiple. This is a really nice feature.

iTunes U has tight integration with eBooks through its connection to iBooks. Books are treated as a distinct upload type and gain some special features, such as two-way notes and highlights sync with iBooks. Classroom doesn't appear to do anything special with eBooks at all.

The Learning Model

The way that iTunes U and Google Classroom put their parts together is very interesting. They're actually quite contrasting approaches to the problem of "learning management" (which is a hateful term but at least broadly understood).

iTunes U is built around the idea of a "course". A course contains an outline, posts, notes and materials. The posts are attached to one of the top-level items in the course outline. This is a reasonable way to structure things but can sometimes be over-structured for some of the more ... ah ... fluid teaching approaches I have seen in action.

Google Classroom is much more focused on the assignment as the basic unit of education (helloooo America!). The class is essentially a stream of "announcements" and "assignments" in reverse-chronological order. It's difficult to see how you could use Google Classroom to deliver a substantial amount of structured learning content, the way you can do in iTunes U. Again, this feels US-centric to me: the course material will inevitably be in the textbook, so why bother putting it into Classroom?

Assignment Workflow

iTunes U has never done anything to help a teacher manage the process of digital hand-in, grading and return of assignments. Google Classroom takes up this challenge and leverages Google Docs for much of the interesting bits of it.

When the teacher attaches a Google Doc from their Drive to an assignment, they can choose three options: "Students can view file", "Students can edit file" and "Make a copy for each student". iTunes U, being based on a download model, defaults to "Make a copy for each student" always.

From the student's point of view, the assignment submission workflow is - to my eyes - a little complex. The complexity starts when the "Turn In" button on Google Docs that Google's preview video showed only appears in documents that you have been given by a teacher through an assignment, or that you created from the "Create file" button in Google Classroom. There's no general way to "turn in" an arbitrary Google Drive document directly from the editing interface.

In most cases, though, it seems that the idea is that you use the Google Classroom interface to pick a file (or multiple files) to turn in for an assignment, either from your Google Drive or via upload.

The only support for marking a document that Classroom supports is the standard Google Docs mechanisms of shared editing and comments or edit suggestions. No harm in that; they're powerful tools. It's just that, if the upload is a PDF, photo or video, you'll need to find some other tool to annotate the document.

The teacher can give a numeric grade in the Google Classroom interface and this grade is reflected back to the student in their "Assignment" tab. It's possible to attach comments to all of these: a comment on submission, a comment on the grade being returned and so on. This is quite a nice touch and similar to existing systems like Showbie.

Working with iOS

(At the time of writing, I'm not actually able to log into Google Classroom in Safari on my iPad, so this is a guess at how things will work.)

The interface to Classroom is entirely web based, and it appears to be fully functional within the constraints of Safari on iOS. The big limitation is probably that uploading things is tricky.

I assume that using the Google Drive app on iOS, you'll be able to put files into Drive from various apps and, later, select that file to turn in for an assignment. That's a lot less elegant than hitting a "Turn In" button and, with that amount of file handling involved, a bigger opportunity for students to "lose" a file.

I'm also assuming that the Google Docs and Sheets iOS apps don't know about "Turn In" via Classroom but they might get that ability in a later update. It's not clear to me how Docs knows when to show that button or what makes a given Docs file "Turn In-able".

Living with Classroom

There are a few features that iTunes U has gained over the years that Google Classroom currently lacks which might make it a little difficult to live with in real-world situations right now. These features mostly relate to supporting the way that schools and teachers organise themselves.

Classes are often taught by more than one teacher. iTunes U allows two teachers to share a class and edit it together. Currently, Google Classroom only allows one account to own a class.

Teachers change over the course of a school year. iTunes U allows a teacher to transfer ownership of a course to another teacher. This capability is not currently present in Google Classroom.

iTunes U also supports sharing courses. That is, making a duplicate copy of a course and sending that to another teacher. This feature might not be so important for Google Classroom, given its greater focus on managing assignments. In iTunes U, this feature allows one teacher to write a whole course and then give it to a team of teachers to teach to separate classes.

Conclusions

Google Classroom is clearly very much a 1.0 product while iTunes U has been through a few years of actual use in the field. I don't believe the comparison is unfair, though. My EdTech philosophy is that you have to evaluate what's right in front of you at the time you deploy without making assumptions about what a product might become in the future.

I've tried to tease out where the heart of Google Classroom lies. My initial reaction was to categorise it as "Google's iTunes U" but it really is not. It's more like "Google's Showbie".

Classroom definitely needs work and needs refinement, but it is a promising system if you're looking at something that's Google Drive native. The file handling for assignment hand-in was initially confusing but it's a workflow that students will learn without too much trouble. It's probably too fiddly on iOS right now - Showbie is a much better option for iOS-centric deployments.

I don't know who runs Google's education initiatives but it's clear to me that they are a super-pragmatist. Between Chromebooks, Drive and Classroom, they're building a system to very closely service the needs of exactly what schools do right now. They're on course to deservedly take a big bite out of the "Windows laptop you use to type reports on" use case that many schools still see as the primary use for computers in the classroom.