I buy the argument, will repeat some of it and will try to tease out some of the identity implications.
First, a bit of a recap of Scott's argument (or my interpretation at least)
- Whereas on a desktop we might have had ~10 installed apps, on a phone or tablet we might have ~100. Users have to manage this list. It is trivially easy to install apps from the app stores. That’s great from the app developers PoV, it minimizes the pain of installation and so allows for Users to play and experiment. But from the Users PoV there is a price to be paid for easy experimenting – the application remains. SSO between these apps helps but the problem is bigger than just authentication.
- Offline mode will become an antiquated concept as connectivity becomes ubiquitous. ‘CEO on a plane’ will disappear as an important use case when every plane has wifi. Consequently, the current advantage native has over browser models with respect to supporting offline via device storage will become less relevant.
- As more and more objects become connected (IoT), the nature of mobile applications (through which we’ll interact with those objects) will have to change accordingly. When my fridge, dryer, furnace, air conditioner, microwave, and thermostat etc are all connected and desperately want to interact with me – do I want a unique app for each of them? And what about objects outside the house – coke machines, point-of-sale terminals, bus stops schedules, restaurant menus, gas pumps etc
The problem is that the current native application life-cycle looks like
This sequence places a heavy burden on the user and is very static – not particularly applicable to a ‘Just in time’ model (as Scott puts it) where I might interact with an application once and never again.
Clearly this isn’t viable in an IoT world where we will constantly be presented with previously unseen connected objects. We’d spend our days installing apps and by the time we were ready to interact, the opportunity will have passed (somebody else would have grabbed the last Dr Pepper etc)
IoT demands an application interaction model that is far more dynamic, something like
- Sense – my device must be constantly on the lookout for IoT connected objects and, based on rules I’ve defined, determine whether & how best to interact with them
- Notify – based on rules I’ve defined, prompt me to know that I can now interact with the object
- Authenticate – the object may need to know who I am, but this obviously has to be seamless from a UX PoV. (the object may have to be able to authenticate to me as well)
- Use – I interact with the object. This can’t require an ‘install’, instead whatever unique application functionality must be downloaded and run in an existing app designed with this sort of flexibility – ie a web page running in a browser
- Cleanup – as there was no install, there are no artifacts (except perhaps some state to simplify the next interaction) to be cleaned up, ie no uninstall
The Internet of Things would appear then to be pushing us towards a future where
- The pendulum swings back to the browser (& so HTML5 comes into its own)
- The importance of browser means Web SSO remains relevant
- SSO (in the sense of facilitating seamless user authentication to all the various IoT objects) is absolutely critical.
IoT won't scale without SSO to the T.
Imagine I have a smart toaster that I want to interact with on my phone to determine if I need to empty the crumb tray (this needs to happen Science!!)
- does the toaster advertise its presence to the phone?
- is the user invited to interact with the toaster?
- toaster data (crumb tray status etc) get sent to the toaster cloud for analysis
- toaster data (crumb tray status etc) get sent to the phone for display