These Lab Notes document my research in progress. My research area is in the future of personal computing.
Notes on time
Gestural view construction
Free and easy organizations and associations
The Messy Desktop
Live items & Contextual notifications
Swappable reference views
Experimenting with the item as the core primitive
Designing systems for computer literacy and evolvability
Personal Computing Network & Devices
Mutations & Item change logs
Services & Item Drives
Today & Daily summary
Cross-reference Navigation in Obsidian
Cross-references & References cloud
The Graph OS
Why is our thinking on computers so restrained?
References box & Topics
General purpose personal computing software
User-created application and system views
User-created item views
Browsing contexts & recent paths
Universal reference containers
Universal data portability
Composing application interfaces
The Lab Notes
In LN 006, we saw how we can select any applicable view for an item, which can be supplied by any app in our system, and we explored some examples and demos.
In LN 007, we discussed how this means the app providing some data to our system can be a different app than the one that allows us to interact with that data, and we explored the many benefits of this arrangement.
Now, we can take this one step further:
Not only does the application which retrieves some data not need to be the application which renders it, but our system can gather similar items into one place, regardless of their source, or even specific data type.
One well-used example of this today is the unified inbox of modern email clients that shows all of the emails you’ve received, even if some came from an account over Exchange and some from another account over IMAP.
We can extend this into other data types, but also into higher-level constructs, so that we do not need to visit multiple views or apps for one purpose.
Consider the moment in your day when you wish to catch up on correspondence. It might be first thing in the morning, mid-afternoon, or frequently throughout the day.
Usually this means going to your email client, wading through the many non-conversational emails from various companies and services, finding those threads which have new replies in them, and sending off a response.
But then, increasingly in the last decade or so, you aren’t done — it’s off to other apps and services. iMessage, Slack, GitHub Issues, Asana, and so on. Unifying these things has been a long-standing wishlist item for many users of today’s operating systems.
In our operating system of the future, since all items are simply treated as their own self-contained things, we can put them anywhere we want.
But we can also lean on the system to gather items together. And since any item can be gathered anywhere, ongoing conversations can be gathered into a single location — regardless of their original source. And since, as we saw in LN 006, items are still rendered by their hosting applications, gathering them into a unified place does not mean we lose the capabilities of the hosting application (whether it’s end-to-end encryption, special formatting, linking to internally shared things, etc.).
This makes possible the ideal, single view for all of the conversations we care about, whether they are happening in email, Slack, GitHub, Asana, or anywhere else. Imagine going to a single conversations view that unifies all of the new threads you want to catch up on, regardless of what app each person used to send you a message.
We can also do this with notifications: Although notifications come from many different sources including email, push services, and even SMS, we can design our system to simply gather all of these notification items in one place. Imagine having one single center of notifications across your entire tech stack.
Finally, we can also do this for the things we want to read, listen to, and watch. We receive newsletters by email and RSS, podcast episodes by RSS, and we save articles and other things for later consumption. Whether it’s an email, an article, a PDF, a video, a Twitter thread, or anything else, it can be gathered by our system into one collected view for consumption when we’d like to read or watch something new.
This thinking can solve domain-specific problems too. Consider banking: US banks lack a uniform API, but when our system allows us to collect items from different apps in one place, we can gather our transactions from various banks into one local budgeting tool.
One additional note: With this arrangement, decisions about what is included as conversations or notifications are made by your local software; not a distant server. So you can configure it how you prefer — you don’t have to rely on something out of your control. Your notifications view does not have to include items that you don’t want in there (apps today can be known to abuse the notifications features on phones, for example), and you can trust that your email can be split up the way you prefer. You have the power within your local software to exclude a certain app if it contributes undesirable things to any of your unified views.