Foreword
This essay introduces concepts that Finn and I kindled while we were prototyping a web browser in July 2024. The key idea was that the browser played an active role in modeling your intent as you used it; making sense of your browsing activity and history, the browser would guess the tasks you were trying to complete, the intentions you had during a session of browsing, and the long-term goals that these intentions may have fed into (more here). With this intent model, the browser would then,
infer the task behind a tab (for example, to an open tab of movie theater showtimes, it can infer the task “Book a ticket for Mickey17”), making it easier for you to find and retrieve the tab,
mark a task as being complete or incomplete,
complete an incomplete task on its own (with your permission!),
passively organize tabs into “paths” that lead to a long-term goal (eg situating research rabbit-holes within a broader context of “niche HCI Research”)
assist in planning a new browsing session, where it might nudge you to “pick up where you left off” based on the tasks it knows you didn’t complete (without judgment!)
Using tab groups, profiles and bookmarks, you can create an intentional browsing experience. But you also need to practice immense patience and restraint to do so, because you have to do this all on your own.
In addition to doing what you want to be doing - completing tasks and realizing your goals - you have to manage the system to act in alignment with your intention - grouping, regrouping and ungrouping tabs, moving tabs to the right order, closing tabs, bookmarking. All of this is manageable if you’re willing to do the work, but at some point, it becomes too difficult to manage, and you’re doing this all on your own.
To address the problems described above, we needed new conceptual language to reason about it more consistently. Using the lens of complexity science, we formed the concepts of meta-task, reasoning cost, interface system dynamics, complex data objects, which are introduced below. We hope you find them useful.
To think about long-term behaviors with interface, we can characterize an interface along two dimensions:
Agency over the System, which measures the degree to which a user can enact their intentions on a system,
System Complexity, indicating both the number of possible actions and the number of objects to act upon within the system.
When we mapped this space, we identified three interface usage regimes:
Human-Scale regime (high agency, low complexity)
We also called this the “designer’s ideal” regime, as it reflects the conditions designers likely envisioned when creating the interface.
Reach-Exceeds-Grasp regime (low agency, high complexity)
Here, system complexity surpasses our cognitive capacity and the available tools to manage it. This regime is synonymous with experiencing "information overload" and is common across browsers, home screens, email inboxes, issue boards, and messaging apps, the digital spaces we seem to find ourselves in.
Tamed-Complexity regime (high agency despite high complexity)
A theorized optimal state, which tools like the intent-model aim to help users achieve.
The diagram also claims a movement between regimes. While we begin in a human-scale regime, we slip into the reach-exceeds-grasp regime as the system complexity increases, and then spiral deeper into it, experiencing less and less agency and more and more complexity.
Our objective is to create tools and interfaces to allow people to exit this spiral, and move out of the reach-exceeds-grasp into the tamed-complexity regime. We call this restorative spiral "curl”.
But what is responsible for making things more complex? We call them, “complex data objects”.
A data object is complex in that it grows unbounded in size unless regulated by explicit user action. Common examples of these actions are naming data, deleting data, sorting data into categories, and managing the categories themselves, common language for these actions is “busywork” or “checking off boxes”, but we will call them “meta-tasks” as they are in the way of but still required to perform activities with a system.
Performing each of these meta-tasks is marginally inexpensive in reasoning cost. For example, the decision to delete a “LinkedIn: Update from your network” email object happens once per email object. From this, we say that decision is marginally O(1) in reasoning cost. But since we do this N times over the course of processing the complex data object of the inbox, we can say that the management of a complex data object (an overloaded inbox) is O(N), where N is the number of data objects contained within it.
Processing a large data object, as you can imagine, amounts to a dull and fatigue-inducing user experience because there are so many objects to work with, and the actions aren’t especially interesting (16,789 unread emails means you decide to perform the delete decision 16,789 times). The prospect of doing dull, repetitive and fatigue-inducing work, for users who aren’t “the Organizing type”, isn’t the most enticing thing.
The user then postpones performing these meta tasks to a later date, more objects accumulate in the time between now and the later date, and when, on that later date, the user is greeted with even more things to do ... they postpones it again, and we spiral deeper into the reach-exceeds grasp regime.
This spiral into the reach-exceeds-grasp regime can be observed in many of the interfaces where we spend most of our time - file systems, email, issue boards, message channels, follow lists, browser tabs / history - and each interface names the problem in their own way: file clutter, flooded inboxes, stale tickets, unread messages, and tab overload, respectively.
In another post, we’ll show you how we used the concepts above to conjure the Complex Data Object’s antidote, the Shared Data Object. This is first example of an interface pattern that suggests how, by sharing data objects between user and System, meta-tasks on the object can be offloaded to the System through input and instruction from the User.
Preview: your Following list as a Shared Data Object
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.