Opening up the Google Play Store to education will create a few challenges for schools especially with respect to application licencing.
The now abandoned Google Play for Education (GPfE) faced the same issues without fully overcoming them which at times made Android app management seem unwieldy compared with the ease of managing Chromebooks through Google Apps for Education (GAfE).
These issues included;
By using touch capable Chromebooks as the platform for delivering Android apps you can see how some of these issues might be addressed.
The majority of applications running on Chromebooks today are either licence free (Google Apps and many other very useful chrome extensions) or are SaaS based such as WeVideo, Securly and GoGuardian.
For those SaaS applications that require licencing the solution is fairly simple, a time limited subscription based on the school GAfE domain with the option of a fixed number of seats or a set of named users. Since all SaaS services have monitoring and user billing baked into the platform there’s very little overhead for the user or the provider.
With a SaaS application you can't have an unlicensed copy of the software so you don't have to monitor installations.
Deployment is easy. You simply advertise the URL to all parties and they’ll either be granted access using their Google account/domain or not. With many SaaS services now supporting Google Sign-in or account federation through SAML this promised a seamless experience for both users and IT managers.
Simple and easy, until now.
Most Android apps work to the store model and not the SaaS model. In this case you go to the web store and purchase an app with a perpetual non-transferable licence which then becomes part of your user account profile. Alternatively you can download a free app and get dragged into the world of in-app purchase which is an even greater hell for management.
GPfE attempted to simplify the situation by removing in-apps payments and allowing apps to be bulk purchased from the store and then allocated to GAfE user accounts as required but the process was all but unworkable at scale.
The process also required that tablets to be allocated to specific users and not be part of an openly shared resource. After all, the idea that a complex application set could be downloaded and initialised on demand to a random tablet at the start of a lesson was never a realistic option - which is a problem because that's exactly how Chromebooks are used in most schools today.
Access to the app cannot be controlled by simply installing and deinstalling the application, the process is just too inefficient in a shared device environment. The application has to be cached locally whether the user has right to use it or not and some other mechanism must act as the gatekeeper. Obviously this has implications on the amount of local storage required but Google has some fiendishly clever technology that should help with this so I’m hoping this isn't be an issue.
The gatekeeper could be as simple as allowing or denying the app to run as a GAfE policy or just hiding the icon from the user - or both.This would rely on a trust relationship or some sort of reporting API that the vendor could tap into which may or may not already exist.
Alternatively apps could fall back to the SaaS model. In this case the app is free to install but requires a backend SaaS service to be fully functional. For example a number of SaaS vendors make access to Google Drive a licenced feature. You can create a file but you can't save it.
Similarly you could licence a Google Classroom integration feature as an extension of the SaaS management console. The Android app is free but if you want to drive deployment and management using your existing classrooms (and who wouldn’t) you need a licence.
In the long term this has to be the best option. Surely the days of licensing through counting installation points and downloads has long gone. I know it worked for Angry Bird but I’m not sure you can apply that model to education without ending up with an Angry Admin.
I’m sure Google have all of this worked out so I guess we’ll just have to sit tight and wait and see.
The now abandoned Google Play for Education (GPfE) faced the same issues without fully overcoming them which at times made Android app management seem unwieldy compared with the ease of managing Chromebooks through Google Apps for Education (GAfE).
These issues included;
- A separate management console.
- A limited hardware list that didn't include many of the popular consumer tablets that schools already owned. This was imposed partly to support the ‘bump’ rollout method which although astonishingly cute was never more than a gimmick.
- The limitation of managing the application to user relationships as a simple one-to- one relationship. This made the solution look great as a demo but proved impractical when deployed at scale.
- The purchasing sub-system which although released in the US never made it to other areas such as the UK therefore removing a major benefit of the platform in a single stroke.
By using touch capable Chromebooks as the platform for delivering Android apps you can see how some of these issues might be addressed.
- Chromebooks have proved hugely successful as shared device for schools and although the hardware specifications are limited the list already includes models currently deployed into schools.
- Chromebooks already have a well established and simple enrolment procedure.
- Indications are that the management will be integrated as part of GAfE console rather than a separate portal.
The majority of applications running on Chromebooks today are either licence free (Google Apps and many other very useful chrome extensions) or are SaaS based such as WeVideo, Securly and GoGuardian.
For those SaaS applications that require licencing the solution is fairly simple, a time limited subscription based on the school GAfE domain with the option of a fixed number of seats or a set of named users. Since all SaaS services have monitoring and user billing baked into the platform there’s very little overhead for the user or the provider.
With a SaaS application you can't have an unlicensed copy of the software so you don't have to monitor installations.
Deployment is easy. You simply advertise the URL to all parties and they’ll either be granted access using their Google account/domain or not. With many SaaS services now supporting Google Sign-in or account federation through SAML this promised a seamless experience for both users and IT managers.
Simple and easy, until now.
 |
Most Android apps work to the store model and not the SaaS model. In this case you go to the web store and purchase an app with a perpetual non-transferable licence which then becomes part of your user account profile. Alternatively you can download a free app and get dragged into the world of in-app purchase which is an even greater hell for management.
GPfE attempted to simplify the situation by removing in-apps payments and allowing apps to be bulk purchased from the store and then allocated to GAfE user accounts as required but the process was all but unworkable at scale.
The process also required that tablets to be allocated to specific users and not be part of an openly shared resource. After all, the idea that a complex application set could be downloaded and initialised on demand to a random tablet at the start of a lesson was never a realistic option - which is a problem because that's exactly how Chromebooks are used in most schools today.
OK, class turn on your Chromebooks and start work. Sorry Timmy, has your Android app set still not downloaded - never mind, pretend it's a Windows laptop.The store model works to a degree for personal and 1:1 Chromebooks but I can't see how it functions for a shared class set.
Access to the app cannot be controlled by simply installing and deinstalling the application, the process is just too inefficient in a shared device environment. The application has to be cached locally whether the user has right to use it or not and some other mechanism must act as the gatekeeper. Obviously this has implications on the amount of local storage required but Google has some fiendishly clever technology that should help with this so I’m hoping this isn't be an issue.
The gatekeeper could be as simple as allowing or denying the app to run as a GAfE policy or just hiding the icon from the user - or both.This would rely on a trust relationship or some sort of reporting API that the vendor could tap into which may or may not already exist.
Alternatively apps could fall back to the SaaS model. In this case the app is free to install but requires a backend SaaS service to be fully functional. For example a number of SaaS vendors make access to Google Drive a licenced feature. You can create a file but you can't save it.
Similarly you could licence a Google Classroom integration feature as an extension of the SaaS management console. The Android app is free but if you want to drive deployment and management using your existing classrooms (and who wouldn’t) you need a licence.
In the long term this has to be the best option. Surely the days of licensing through counting installation points and downloads has long gone. I know it worked for Angry Bird but I’m not sure you can apply that model to education without ending up with an Angry Admin.
I’m sure Google have all of this worked out so I guess we’ll just have to sit tight and wait and see.
No comments:
Post a Comment