The ephemeral context

Over the holidays, I've read a nice outlook by FJORD and an awesome rant by Maciej. Though the two publications could not be any more different in any sense, they touch on a similar topic:

The re-emergence of context

Back when I was studying mobile application development, it was all about context - changing texts and pictures, structure information, optimize information to location and usage, cram information on a small screen, those things. With responsive, atomic and material design, the focus shifted more and more into grid systems and ordering components efficiently, under the assumption that screens converge so much that all information is equal.

While responsive design works beautifully in many situations, the technical difficulties and trade-offs** superseded the initial idea of contextual design. However, with the "disappearance of apps", context becomes more important than efficient design. With smarter notifications, smart watches, the aggregation of information into other streams and more participatory and collaborative software service usage patterns, giving the right information at the right time becomes the major value proposition. Uber and Airbnb (with new Google Maps ads), Amazon (with Echo), Tinder but really anything that shapes an environment into a service, like IKEA, Google Now (as in Her) or Nest, are on the forefront of this movement. They don't respond to context, they create their own, ephemeral, context.

Reverse CQRS

This means mobility and analytics, in the form of deep learning, merge more and more. Mobility brings its knowledge of context into analytics, turning the flow of applications around. This makes event sourcing the new user interaction, separating the query (as in CQRS) from the command - the event becomes the query, really, and the command, as in the interaction, is executed on an interesting result.

From a service design perspective, this means we need to build stronger mental models, but as concept are harder to reason than to visualize, we need to find a way to explain them better first. We can't just respond to a demand, like opening an app, but must provide different entry points (not just API's) to services, that provide their own feedback loops. Not only, as mentioned above, as entry points via operating system hooks, like notifications. Rather with completely new, independent behaviour, starting from where we see it today for secure logins on a risk basis (e.g. the new Captcha) or proximity-based suggestions. A service design flow looks very different if there is more inputs than outputs. There is a reason SAP looks into interactive programming, and I hope Tesla's ideas for carsharing and using cars for autonomous tasks will soon be reality.

As usual, I believe communication can solve this - call it patterns, guidelines, or I've written about wrong proportion recently, but you need to establish loosely coupled "atomic" interactions, or agents, that can react to "reverse CQRS", like Redux advertises it. The analytics is actually rather straight forward, it could even start with a simple subscription model, but splitting your application flow down will be hard work - especially for all the responsive web apps that used plain old MVC and hard-wired their controllers with the overall flow.

*) Disclaimer: I work for Accenture, which is the parent company of FJORD.
**) I have myself just been on a very service/product-driven software project where we had many of those