Andrew Hinton's Understanding Context

[dnj]

I’m reading Andrew Hinton’s fascinating 2014 book Understanding Context. The key idea is that much of the complexity and difficulty that we face when using an app (for example) arises from confusions about the context in which we find ourselves, and the signals we receive from the environment in interpreting that context.

In a wonderful opening chapter (which you can read under Look inside me on the book’s Amazon page), he describes the experience of navigating an airport checkin. One example: he tries to figure out if he qualifies for “SkyPriority” (an accelerated checkin lane) but doesn’t know how it relates to his “SkyMiles” status. The checkin involves a whole raft of overlapping contexts, which Hinton depicts in this diagram:

I’m pondering the connections between these ideas and the ideas of concept design. From a concept design point of view, I would say that each of these personal status questions (do I have “SkyPriority”?) is a question about a particular concept, cast in this form because companies tend to formulate access to services in terms of status, and their marketing departments create a panoply of names for these statuses.

What makes a concept like SkyPriority confusing is that it involves an obscure action in which the airline grants you that status, and that action is hidden from you, and executed by synchronization with other concepts (so that if you reach a certain status level in your SkyMiles, for example, or are flying business class, the action occurs). So the complexity arises in part from the way in which multiple concepts are sync’d, and to understand the system as a whole you have to understand those synchronizations.

Imagine in contrast if SkyPriority was simply a fast line that you had to pay for to access by swiping your credit card on entry; then they could have a sign saying “faster TSA line, pay here to enter.” Of course, this would not serve the airline’s purpose of rewarding certain customers, but it illustrates what would make the concept easy to understand.

Note also that this (admittedly unrealistic) redesign localizes the concept in the physical space, and this is in part what makes such a concept easy to understand. When I try to enter my building at MIT nowadays, sometimes the door won’t unlock for me because of some glitch in the app that processes my COVID PCR tests (and the daily attestations I’m required to submit that I am symptom-free); this makes facing the door and trying to understand what’s going on much harder than a traditional door (even a “Norman door”) where any mechanism I need to understand is right in front of me.

Hinton explains that much of the complication of virtual systems comes from the separation of physical space and digital functionality, and seems to imply that traditional physical spaces rarely have overlapping contexts. This seems right to me, and a good explanation of much of the sense of disorientation the airport experience induced.

But it has made curious to find examples in which traditional (ie, non-digital) concepts overlap in the physical world. Here’s one example that occurred to me. When you’re on vacation in Italy and you enter the local duomo, you might find a service going on. How you behave now involves two overlapping concepts, one related to your role as a tourist making a visit, and the other related to your religious affiliation. If you’re a practicing Catholic, you might join in prayer; if you’re not, you would likely not, and you would take special trouble to be even more quiet and respectful than you would be visiting at other times. Either way, your behavior is governed by these two concepts overlapping in the same physical space.

Thanks to my friend Geoffrey Bock for telling me about Hinton’s work.

[dnj]

Another example from Hinton: Facebook’s ill-fated Beacon system, which surprised users by (for example) reporting their purchases on their news feed. Hinton depicts this in terms of two linked contexts:

As with Hinton’s SkyPriority example, the problem can be viewed in terms of concept synchronization. Synchronizations by definition cross concept boundaries, and force the user to understand two concepts at once. If, as I argued in EOS, synchronization is a key aspect of automation, then this explains why automation often exacts a heavy price in terms of comprehension.

Hinton’s contexts add a new aspect to my analysis, by recognizing that is not just the unexpected synchronization that is problematic for the user, but the fact that the synchronization happens across social domains. I wonder if concept design might fruitfully be enriched with a notion of domain to which each concept could be assigned, perhaps using the definition of domains from problem frames.

Note that a single concept can offer automation too, but in the context of just one concept, it’s rarely confusing. If I click on the “follow” button next to a question in a forum, I won’t be surprised to get notifications when new answers come in: that’s the basic operational principle of the subscription concept. I’ll be a bit more surprised if I get notifications about questions I just looked at (because the app synchronized by reading the question with an implicit execution of the follow action)—that’s an unexpected cross-concept sync. And I’ll be even more surprised if I get notifications about questions posted by users who happen to be my friends in a different app, which might be viewed as a sync across concepts in different domains.

[dnj]

Here’s an example that Hinton analyzes (Understanding Context, p. 213) where concept design would offer a different take. Google Buzz was a social media app that automatically populated a user’s friend list from their Gmail messages. Hinton discusses this in the context of ontologies, and concludes: “Buzz was working from an ontology that defined friend too simplistically.”

From a concept design perspective (at least mine!), I would say that the problem here is (again) the unexpected synchronization: the user does not expect their actions in reading and writing email messages to be automatically synchronized with actions that make other users into friends. If the synchronization were much more sophisticated, and extended (through some Orwellian nightmare) to all aspects of the user’s life and thoughts, so that the inferred friend list corresponded much more closely to what the user would have created manually, I don’t think that would have solved the problem. In fact, most users might have been even more upset by the violation of their privacy.

Nevertheless, Hinton’s observation is clearly right in the sense that a user will be perturbed that the system gets the notion of “friend” wrong. This raises a big question about design which is of central contemporary importance. Would we be happy with tools whose mechanisms are completely inscrutable but which end up, much of the time, with good results? As a theory of usability, concept design takes a contrarian position on this, and associates transparency and simplicity of the mechanism with usability and effectiveness.

The growing deployment of machine-learning-fueled apps makes this question an unavoidable one. My own current take is that for almost everything that matters, I want concepts that are transparent and reliable. I don’t want my microwave to guess how long to cook my food for. But for things that either matter very little, or for which I can check the results easily myself and correct them—for example, Adobe Lightroom labeling my photos with the people in them—an opaque concept may be fine.

[SiegristJ]

Hi Daniel,

This discussion reminds me of the boundary object from Star and Griesemer: https://en.wikipedia.org/wiki/Boundary_object

Also, your idea of introducing the notion/concept of domain is an important one as domains are the logical equivalent of physical spaces - you have a red button in one physical room and it is understood as distinct from the red button in another one. Likewise a “folder” concept in one domain doesn’t mean the same as in another (think paperclip manufacturing domain vs computerised file system vs paper file management).

[dnj]

John – Welcome to the forum!

I hadn’t known about boundary objects, and the idea does seem very relevant to understanding how domains interact.

One of the interesting questions that arises in concept design is how different concepts interpret objects passed between them. In most cases, concepts share only an opaque reference, and the same object can play completely different roles for different concepts. For example, the Comment concept, a comment is a holder of content that is related to something else (eg, a post); that same comment is just a target of approval or disapproval to the Upvote concept. I discuss some initial ideas on the different kinds of objects and the roles they play in my book (EOS, pp. 231-234); the idea of boundary objects might be a useful extension to this.

[Henri]

Hello Daniel,

This is a great discussion.
In your framework, I guess “SkyMiles” would be an app, provisioning different services available to the consumer like “SkyPriority” depending to a “status” concept. The problem is indeed for people to understand apps, i.e. rules of synchronization. You seem to prefer “unbundling”, but I would answer that very often consumers require the bundling of different attributes in a simple marketing concept. They don’t have patience for understanding and choosing among a long list of options. I worked some years in Marketing, and while unbundling is fairer and clearer, actually consumers may often go to the more opaque and costlier solution !

So people work it out by marketing “hints” and “customs”. You know for example that a “gold” status is usually OK for most features and a “bronze” one rarely so. “Silver” is the tricky one, so many marketing programs just shunt it !

Bottom line: design concepts have an heuristic role to help people navigate in the complexity. As you cannot always put five “like” buttons, you tolerate ambiguity. A great branding and communication is often one which convey the right intuitions of the consumer on how the app will work. I insist it is a cultural and therefore time-sensitive device.

Now, what computing is great for, is to force the marketer to clear up her mind, and that makes the conceptual analysis you call very useful as behind-the-scenes thinking, and distinguish basic concepts from synched up apps. But I doubt it will ever become frontline reality.

As to physical overlap of concepts, I would say this happens very often, as most concepts are not “design” oriented. This come back to our email discussion on natural concepts like the one of a “dog” or a “pig”. Usually we dress “things” around us like pigs, dogs, and duomos with multiple purposes. I can take multiple actions towards my dog Fido, take it for a walk, train it to be a vigilant guardian of my house, play with it, and so on. These actions correspond to different purposes, and they may clash, eg I may wish to give Fido some sweets because I like it, or keep Fido hungry because I want it to be agressive at night to keep the watch.

Let me guess your answer: you would say that we should distinguish two dogs concepts, “leisure dog” and “watch dog”, and synching them in my Fido “app” requires me to be very clear about the balance I want to bring about in its behavior, which determines in return how I will educate it, and how much sweets I can allow Fido?..

This also work for the duomo case by the way. The duomo becomes an “app” synching its religious concept with the touristic one. This is negociated in a concrete schedule, rules of behavior of the public, budgetary planning, and so on.

Henri

[dnj]

Hi Henri,

Sorry for this very belated reply. I totally agree that users need simple views of things, and having many little concepts sync’d together in complex ways may not help at all. My current take is that we compose smaller concepts into larger composite concepts with higher level purposes. Thus a forum like this might have concepts such as “post”, “reply”, “upvote”, “notification”, etc, but we somehow understand them all as part of a “forum” concept which has its own purpose (“support rich dialog amongst a group of people with shared interests…”) that is then supported by each of the purposes of the individual component concepts (eg, that notify let’s you know when something got posted). So in the SkyMiles case, the problem is that there are too many concepts that are not sync’d together into a coherent way to form a small number of coherent higher level concepts. To do that, you’d have just one concept that tracks your status and it would work in all contexts. The reason airlines don’t do this presumably is that it requires coordination, and it’s easier just to let each department do its own thing, but that makes a huge mess for users.

–Daniel

[hemalvarambhia]

Hello, Daniel. I see a relationship between

“The key idea is that much of the complexity and difficulty that we face when using an app (for example) arises from confusions about the context in which we find ourselves”

and Eric Evans’ bounded context.

[dnj]

Hi Hemal,

Welcome to the forum!

My understanding of bounded context in domain driven design is this: that rather than trying to construct an enterprise-wide model or ontology, a team should focus on the view of the world that they need for the functionality they support and not get worried about creating needless consistency with the views of other teams.

This seems to me a valuable and practical idea. The lens of concept design would refine it, and suggest that you don’t create a specific concept for your own team when a standard one that is already well understood will suffice, and will be consistent with everyone else’s. For example, if your team builds an app for buying movie tickets as part of a larger movie distribution company, you wouldn’t want to invent new concepts for Movie (use IMDB?), Ticket, Payment, etc. Once you start to identify concepts, there will be less and less of the data model left to specialize, so perhaps concepts help you identify the parts of the context that actually need to be bounded.

Hinton’s contexts are more about the different and sometimes incompatible experiences that users have as they move through the world. The connection between these two notions is indeed interesting. Could it be that the kind of conceptual confusion that Hinton reports (eg, when our hapless air traveller tries to understand whether their SkyMiles award status will give them access to a fast lane in the airport) would be reduced if the contexts of those developments were less bounded?

It’d be great to get Eric’s take on this! Maybe you can ask him to chime in and set us right here :-).

[winter]

I have a physical world example of overlapping contexts. My company conducted a fire drill. I knew it was a fire drill. When the alarm went off, I was near a fire exit that I could only use if I broke a glass tube. I wasn’t sure whether to break the glass or not. I decided to break it.

[dnj]

Wow, @winter! How did they react to that?

Can you help explain more – what are the overlapping contexts here?

[winter]

I mentioned it to my manager, and he was fine about it and “let somebody know”. Nobody else said anything to me about it, and the next time I looked (a few days later) the glass had been replaced. When I exited, I found that the door shut behind me in a way that made it impossible to open from the outside. Some of the overlapping contexts were different policies that I was supposed to abide by. I was supposed to protect the physical infrastructure of our site (e.g. not leave a door unlocked such that someone malicious could get in) and also respect the fire drill (e.g. exit the building calmly and quickly).

Some questions I asked myself were: Does a fire drill count as an “emergency”? What are the security implications to our building of opening this door? Will I get in trouble? How expensive will it be to replace the glass tube? Would I get in trouble for not smashing the tube and/or not using the nearest fire exit? Would it be good for me (and the organisation) to test this exit? Could I hurt myself breaking the glass?

I decided to break the glass because I felt that I could explain my reasons for doing so, I didn’t think I’d hurt myself, I thought the exit should be tested, and for my personal interest I wanted to see how (and if) the exit worked. I can also admit that it was thrilling to have a reason to (literally) break the normal conventions.