Today’s apps: context-free computing at its finest

Prompted by this exchange on Twitter:

Functionality attached to the context-defining data object. Instead of an “app” silo. Now here’s a thought. :-)

— Johannes Ernst (@Johannes_Ernst) September 4, 2021

Let me unpack this a bit. Let’s say that I’d like to send a message to some guy, let’s call him Tom for this example.

The messaging app vendors go like: “Oh yes, we’ll make it super-easy for him (Johannes) to send a message to Tom, so we give him an extra short handle (say @tom) so he doesn’t need to type much, and also add a ‘reply’ button to previous messages so he won’t even have to type that.”

Which is myopic, because it completely misunderstands or ignores the context of the user. The user doesn’t think that way, at least most of the time.

As a user, I think the pattern is this:

“I need to tell (person) about (news) related to (common context), how do I best do that (i.e. which app)?”

Three concepts and a sub-concept:

• Who do I want to tell. In Joshua’s example: the person(s) I’m about to meet with.

• What’s the news I want to tell them. Here it is “I am running late”.

  • But this news only makes sense in the common context of “we agreed to meet today”. If the receiver doesn’t have that context, they will receive my message and it will be pointless and bewildering to them.

• What’s the best way of conveying that news. It might be a text, a phone call, or pretty much anything. This item is the least important in this entire scenario, as long as the receiver gets the message.

So thre are two primary “entry” points for this scenario:

1. It starts with a person. The user thinks “Tom, I need to tell Tom that I’ll be late”, and the frantically tries to find a way of contacting them while hurring in the subway or driving really fast. (We have all been there.)

2. It starts with the shared context object. The user looks at the calendar and thinks “Oh darn, this meeting, it’s now, I’ll be late, I need to tell them”. (They might not even remember who exactly will be in the meeting, but then likely the calender event has that info.)

The entry point is almost never: “how convenient, I have all people I’m about to meet with in the current window of the messaging app, they all know what whatever I’m going to type into that window next is about the meeting, and I can just simply say that I’ll be late.”

So … if we were to put the user, and their experience, at the center of messaging, messaging wouldn’t be an app. (Well, it might also be an app, but mostly it wouldn’t.)

Instead, the messaging would be a “system service” attached to the context objects in which I’d like to message. In Joshua’s example that is:

• the person I’m about to meet with (but this only works if there is a single person; if there are a dozen this does not work).

• the shared context about which I am conveying the news: here, the (hopefully shared) calendar event. Joshua’s original point.

Now in my experience, this is just an example for a more general pattern. For example:

• meeting notes. In which meeting any meeting notes were taken is of course supremely important. Which is why most meeting minutes start with a title, a date/time and a list of attendees. Instead, they should be attached to the calendar event, just like the message thread. (Yes, including collaborative editing.)

  And by “attached” I don’t mean: there’s a URL somewhere in the calendar dialog form that leads to a Google Doc. No, I mean that the calendar can show them, and insert the to-do-items from the meeting, and future meetings from that document, and the other way around: that when you look at the meeting notes, I can see the calendar event, and find out it is a biweekly meeting, and the notes for the other meetings are over there.

• projects. Software development is the worst offender, as far as I know. If you and I and half a dozen other people work on a project to implement functionality X, that is our primary shared context. All communication and data creation should occur in that context. But instead we have our code in Github, our bugs in Confluence, our APIs … test cases … screen mockups … video calls … chats … in a gazillion different places, and one of these days I’m sure somebody is going to prove that half of software budgets in many places are consumed by context switching between tools that blissfully ignore that the user thinks not like a vendor does. (And the other half by trying to make the so-called “integrations” between services work.)

There are many more examples. (In a previous life, I ran around with the concept of “situational computing” – which takes context-aware computing to something much more dynamic and extreme; needless to say it was decades before its time. But now with AR/VR-stuff coming, it will probably become part of the mainstream soon.)

The 100 dollar question is of course: if this is the right thing for users, why aren’t apps doing that?

Joshua brought up OpenDoc in a subsequent post. Yep, there is a similarity here, and apps don’t do this kind of thing for the same reason OpenDoc failed. (It didn’t fail because it was slow as molasses and Steve Jobs hated it.)

OpenDoc failed because it would have disintermediated big and powerful companies such as Adobe, who would have had to sell 100 little OpenDoc components, instead of one gigantic monolith containing those 100 components as a take-it-or-leave-it package at “enterprise” pricing. No adoption by Adobe, Adobe feeling Apple proactively attacked their business model, it would have killed Apple right afterwards.

But having OpenDoc would have sooo much better for users. We would have gotten much more innovation, and yes, lower prices. But software vendors, like all businesses, primarily do what is right for them, not their customers.

Which is why we get silos everwhere we look.

If we wanted to change that situation, about OpenDoc-like things, or messaging attached, in context, to things like calendar events, we have to change the economic situation in which the important vendors find themselves.

Plus of course the entire technology stack, because if all you know is how to ship an int main(argv, argc) on your operating system, something componentized and pluggable and user-centric and context-centric is never able to emerge, even if you want to.

(*) The title is meant to be sarcastically, in case you weren’t sure.