My work is graciously supported by the community. Want to support my work? See memberships.
In LN 009, we saw how a user might create a new view for existing or new kinds of data items they want to store in their system.
One example was an item the user created to store their sheet music, guitar tabs, and notes on learning specific songs.
But let’s take that example further: what if the user wanted an application view to interact with these items in a way more fitting to the data within?
Consider that the user created the view for these custom items within a simple constructor interface (see the videos in LN 009). Expanding on that concept, consider that the user could similarly construct larger views, to create whole applications.
In this case, the user might come up with an application called “Setlist” in which they can create, browse, and manage their sheet music items.
Of course, keep in mind that these items can be referenced and used anywhere else in the system, as seen in LN 002 and LN 003 (among others). But this Setlist application can serve as a central hub for these data items.
Setlist is more than just our example here — it is a real application I’ve constructed, serving exactly this need in my life. It starts to illustrate what is possible with user-created application views.
This is a powerful concept that can be extended into lots of use cases, but we can take it one step further:
This kind of interface construction can be used for system views, too.
Consider the impact if a user of the operating system could freely modify, duplicate, or construct any system view, just as they can with any item or application view.
Don’t like how the welcome screen is laid out? Need a more ergonomic navigation screen for your particular line of work? It’s yours to rearrange, recreate, or modify as you wish. After all, it is meant to be a personal computer.
Should this be possible, the user is free to forge their own tools and workspace as they see fit. Just like a woodworker might start by designing and building their workbench, any user of this system can create the right workspace for their work.
In the last few weeks, I’ve rebuilt my demo operating system so that all of the system views are no longer hardcoded, but constructed with this system. Almost everything in the system can be redesigned by the user.
Incidentally, with this system in place, I now often create new system views within the system itself. But most importantly: a user can, too. The user has the power to implement ideas of their own at least as flexibly as I have.
Consider some of the implications: No longer would you have to rely on a third-party developer to make that one change which would make your day – every day – easier. For many potential changes, you could simply do it yourself.
If there is an update to a system view that you don’t like, you don’t have to accept it — you could keep your current view definition instead. Or you could combine elements of both as desired! Following this thinking, updates to system views would consist of: updated defaults or recommendations, and new components you can add to your views.
A number of considerations come to mind from this development, which I will cover in a handful of these Lab Notes. Here are a few to get started:
Today our thinking is severely constrained: “This text box is here. I can only change what’s inside it.” In fifteen years’ time, we should think of changing any data or view as “changing my stuff” — effectively the same class of action; making your software reflect your thinking, just the way you want. Today, we don’t feel like these are personal computers. The text box is there. That is up to someone else. They might change it in an update. That isn’t up to me, the user.
So often, we want to redo our office, remodel our kitchen, reconfigure our workspace, refurbish our RV. Our minds naturally consider how our environments could be improved to better our experience and effectiveness within them. Yet we don’t do this with our software — for the most part, we can’t. We spend an enormous amount of our lives on our personal computing devices, and yet today, we do not have the freedom to redesign, remix, remodel, or reconfigure our digital workspaces.
Until now, my demo operating system has served me well as a tool for thought. But with this change, it becomes more than that: it is an engine for Engelbart-inspired bootstrapping. A system with which you can, as a user, co-evolve both the tool and your methodologies simultaneously to build up better whole systems (those systems which include the human and the tool).
This is an opportunity to push for the higher, more important work: discovering ways in which people do important and hard things, their life’s work; and ways in which we might do those things more effectively, more efficiently, more intelligently, and so on. Consider: along with this OS of the future, how might we more effectively learn, think, and create?
It opens an opportunity to design not just an interface, but the processes and needed tools to do great work.
The tools we have naturally shape what we create.
For example, when the most popular web design tool of choice was Adobe Photoshop, a raster graphics editor, websites were filled with pictures as design elements. They had been edited, blurred, or used as large backgrounds. Over the years, popularity shifted to vector-based design tools. With that change, website designs changed too: the large background photographs gave way to illustrations and other design elements that could be easily expressed as vectors. The tool shapes the creation as much as the creator.
Our computers, operating systems, and apps all make up our digital toolset. But they are extremely rigid tools. All of us have vastly different kinds of work to do in our lives, yet we all have the same workshop from which to do it all.
This system I’m experimenting with would give people the opportunity to transform the tools they use to do their life’s work in order to suit that work and their own working styles better.
The impact here could be exceptional: Our tools naturally shape what we create, but our tools today are rigid and uniform. Exploring new, niche, tailored, expressive tools will radically expand what we can create in each of our fields.
As a kid, I was obsessed with the breadboard, on which I could arrange any number of switches, sensors, motors, or other items in circuits to make different things happen with a few batteries.
This concept for an OS’ user environment turns it into something of a breadboard: With provided building blocks, you could start the OS from scratch and build up any interface system you wanted. Or starting with some predefined defaults, you could swap components out. Or following the lead of someone with working styles similar to your own, you might use their published view definitions and hierarchy to get started.
The generated view definitions are items themselves, just like all other items in the system (emails, todos, and so on). Interestingly, since you can swap out or create new views for any item as seen in LN 009, you could, in theory, build a better view for modifying views, and use that instead!
Further, you could share created views with others. And since views are stored as data items themselves, just as you might be able to navigate to someone else’s published data item, you could see it in their application view constructed for that specific purpose.
We can use these view definitions in any software stack; they become a meta UI language allowing the operating environment to be written in different languages with different interface libraries for different platforms but with the same view spec as defined by the user.
This is a first exploration into some impacts this setup might have; a topic to which future Lab Notes will return. To receive them by email when they are published, sign up below.
Something spark a thought? Email me, or come chat on Mastodon or on Twitter.