Teleological Software
“I’ve spent some significant part of my life building technology to essentially go from a human concept of a goal to something that gets done in the world.” -Stephen Wolfram
There are many answers to the question of what kinds of problems can software solve. Even very narrow answers to this question have proven extraordinarily successful. “Software should deliver music,” or “software should deliver retail products,” or “provide auctioning services” are some prominent examples. More general attempts to provide a complete “software worldview”, a walled garden containing tools for any user purpose have been offered by the platforms of Microsoft, Google, Apple, and other big name players. Yet in each of these cases the purpose of the user is presupposed. These apps are designed by engineers who spend their workdays thinking about what users want and then accommodating them based on those studied assumptions. What if there was another way to approach development, one where the the user’s needs weren’t anticipated once and for all, but gradually assessed and worked into the software?
As computer systems become more sophisticated they’ve become more cognitive. They become, in a word: knowledge machines. Most software to date have scarcely any autonomy on their own, but rather express a purpose that was designed into them initially. Self-modifying code is still a new frontier which has seen significant advances in recent years with improvements to machine learning and convolutional neural nets. Knowledge machines, in contrast, exhibit an ability to match the user’s own cognitive schemas, and so naturally serve as an extension of relevant parts of the user’s thinking. Nine thousand years ago the most advanced technology for externalizing cognition was the humble clay tablet, capable of only holding an imprint of symbols that could otherwise only be held hazily and fleetingly in the mind. Now consider what a knowledge machine might bring to the table: a doubling of the user’s capability to deploy knowledge and information for the furtherance of their goals.
As useful as the clay tablet was, it was still a static, constrained medium that had no helpful behavior by itself. It was a passive tool, merely a storage place. Nothing stored on it would mingle or be put to work when a user wasn’t reading it. This was the trend with most knowledge storage devices for thousands of years. Only recently has it begun to change in ernest. What IBM calls cognitive environments and others call cognitive technology are structured workspaces designed with the user’s cognition in mind. These systems correspond to the salient points of the user’s thinking and goals.
For most of history until very recently tools were designed with the user’s goal held separate and distinct from the implementation. I can give you a fishing rod knowing full well what its purposes are and what you might intend to do with it, but I cannot after that point fundamentally alter the rod if you should wish to use to for some esoteric purpose outside its intended use. With goal-processing software tools, the machinery you use is self-modifying in order to fluidly adapt to the goals indicated by the user’s manipulation of the device. This is a giant leap once you consider what kinds of resources such software is connected to, and how rapidly and usefully it can summon those assets for usage on the fly.
Arguably the key of UX design is anticipation of the user’s goals. A well designed interface seems to place what’s important where it is most natural for it to be (a principle of comfort-in-use perhaps best exemplified by Apple’s design approach). The user simply acts in an intuitive way and the resource they need appears before them. The key difference here is that these intuitively accessible affordances were designed by human engineers. With the rise of AI we may soon enter a period where a “one size fits all” approach to UI design is no longer standard. Are there means to detect whether a user favors a sidebar on the left or the right of a page? What tooltips would they make most use of, and which would they be more likely to ignore? And how can we arrange information accordingly? What are the pieces of information most relevant to this user’s goals? Not everyone will use an interface in the same way, so there's no reason to impose a static structure. While we see the rudiments of this personalized goal-oriented software in many of today’s sophisticated software products, there’s no set limitation on where it can go.