Context based programming
In our daily communication, most of the information is conveyed through context, only a little through text.
Consider this text: “Don’t drive home”. What does it mean?
Your first guess would associate that message with a responsible bar tender.
With a change of context, the meaning changes dramatically. Imagine this text being framed in orange colored neon light midnight on a road to a major town … it brings a tired driver warm sensations connected to a bed-and-breakfast.
Or, it can be an angry reminder from a busy wife to her husband at work who forgets to buy diapers for the baby. It means “Don’t drive straight home”.
All the different connotation of the same words: drunk-drive, B&B, diaper. They’re all up to the context.
Humans are naturally good at reading context. Therefore, verbosity comes only when the context is unusual, like this message on the wall of a public place: “the management cannot be held responsible for disposing of abandoned shoes in the sauna room”, or, when the speaker wants to bring forward a different context: “yesterday we were having a party in Barney’s. It was all music and light and all of sudden there came this loud siren…” When a situation is well presented between two parties, however, it’s natural to expect the opposite. Like in a hospital delivery room, a husband with a labouring wife, a look between them conveys all the information.
Computers, on the other hand, were designed to be precise. Computers take commands, not interact within a context. An “rm -rf” reliably deletes, no matter if the user had checked what is to be deleted first. In fact the manual pages of “rm” in the 80s intentionally avoided using the word delete or remove, as such implies intention, not action. The manual defines rm a tool to “unlink” - disassociate the file from the system.
This has a damaging effect when the user think that it is “interacting” with a computer. This can be demonstrated with the example of a developer “interacting” with git.
Imagine that a developer first getting used to “git”, a software management tool, hits “checkout”. The graphical user interface asked the developer if he intended to discard the changes, as there were too many of them. What does “the changes” mean here? Does it mean if the user wants to discard the changes introduced by hitting the “checkout” button, or does it mean that all the changes the user did to the software before using “checkout”? What is “too many”? Is it that the changes brought forward by “checkout” are too many for the computer to handle, and the computer “wants” to discard them, or is it that the user has made too many changes that are going to be affected by “checkout” and the computer was kind in preventing mistakes?
It seems natural, given a specific context, for the developer to believe it meant the former, however the manual clearly stated that it is always the latter case: “checkout” acts like a reset button causing all local changes to be discarded. The word “checkout” is spoken from the computer’s perspective, to check out a clean state overwriting the existing one made dirty by the user’s changes; not from a user’s perspective, to check out what the computer has to offer. There are similar uses of such opposite wording commonly accepted, like Credit card, which gives users debt instead of credit, and Debit Card, which stores users’ credit, not debt, because they are invented from the bank’s perspective, not users’.
Thus it came not as a surprise when the developer complained on an Internet forum, he got mocked for trying to interact with a computer, getting meaning from context. An Internet commentator joked in reply: “if you want to have a conversation, go find a mate. It’s a computer you are dealing with!”
The same assumption could not be said of the communication between a smartphone and its user. The word “smart” in smartphone implies that it knows what you mean instead of taking commands. Thanks to the context communication of human nature, smartphone’s capacity to know what the user mean is largely depending on its awareness of context.
A smartphone is portable, without a manual and most intimate with the user so it is expected to know the context. In fact, given the information it can capture, it is often more aware of the context than the user. For example, it knows that its user is walking into a hospital even if the user himself mistakes it as a hotel. It also knows if its user rushed, or strolled to the hospital.
Yet the mobile interface is designed much like any other computer. How many times have we try to sift through the irrelevant functions and menus on the mobile? How little does a mobile phone react to the context? A banking app, for example, greets users in the same warm tone: “Would you like to do a transaction today?” in the early morning over a coffee table or at midnight in a speeding taxi. It shows the same face for the first attempt to transact a small tip as for the 10th desperate attempt to go around a daily limit to transact a substantial bailout.
Much of hope of improving the smartphone user experience is placed in AI, but AI can’t learn the context if it is not given to it. A mobile phone doesn’t have the bandwidth to transfer all the data to all the AIs run by different service providers. In the future, when mobile bandwidth is close to limitless, it is still questionable if the mobile should constantly send sensitive data like current position and driving speed to an energy company, only for its AI to compute the optimal home energy saving plan. A lot of decisions willl inevitably be made locally, in the mobile phone.
Relying on a server’s AI is what I call “design laziness”. Today, an event app knows which room the user is in, a train schedule app knows how far away the user is from the train station. These are all provided by current technologies. They don’t need a server’s AI — just good design — in order to communicate with the user in the best manner.
To give an example by context: I travel a lot, and whenever my mobile phone was taken out upon detecting a hotel’s wifi for the first time, it inevitably is used to show the booking ID and the spelling of my name, yet none of the travel app is prepared for that task. Instead, I need to by pass a lot of holiday recommendations, goes to “My Bookings” and locate the relevant entry. Doing the right thing here doesn’t require AI and was never achieved.
What is needed is a context-based programming approach for smartphones, an approach that organizes functions not only by user action, but also by context and intention.
An app on using a building facility, for example, should function differently if the user is a visitor, a registered user, an owner or a ticket holder looking for registration. It should function differently if the user visits the venue for the first time or is coming back. It should be guiding the user if the user has a previous booking for a meeting room, or providing the user with the option to do so if they haven’t.
A banking or blockchain wallet app should behave differently if a transaction is for an ecommerce website or a buddy, if the transaction is for payment of a deliverable service or a delivered service, if the user is in a hurry for quick confirmation or not. A lot of such information is readily available on the mobile phone itself.
What we need is a context-based programming framework. All context-based behaviors urs should be organised in a table, so that the user experience experts can go through a checklist of desirable interaction outcomes. Instead of “Activities”, its user interface could be categorized by “Context”. Instead of “methods”, its function could be organized by “behavior”.
Such a programming framework is yet to be created. Designing a blockchain app gives us the first opportunity to experiment with building this new framework. First, blockchain app’s use-case encompasses all the scenarios I described about mobile interaction. A token holder, say, with the right to drive away a rented car on the street, should be guided to approach the car, get the car to toot for its location and open the car door with the app. Second, by using proper blockchain cryptographic technologies to encapsulate information for decisions, it is not supposed to delegate everything to a server-side AI in a privacy invasive way. It’s the opportunity to make a change.
This is the first of a serial of posts. I’ll post the design of the context based programming approach in the following posts as my work progresses.
Weiwu Zhang is the CTO of Smart Token Labs, AlphaWallet is a next-generation blockchain wallet in the making. https://twitter.com/AlphaWallet
