The dwindling distinction between docs and apps
Hail, fellow explorer! Last time I wrote about joining DXOS.
One doc, many apps, many views
I'm intrigued by the idea of sharing a single "document" between applications, where each app can be good at the thing that it's good at. Unfortunately, this is not where we find ourselves today. Software is structured around application silos, each with their own private data. And every app wants to own more and more of your data and your time.
In my own workflow, I feel this pain.
Each week, I write down my weekly plan in a markdown file on my local machine. I use todo items from GitHub-flavored Markdown but I also sprinkle in prose, headings, sub-bullets, etc. Here's an example from a few weeks ago:
As some of you know, I'm also a lover of Kanban boards and would love to view this file as a board. Now, how might I do that today? Well, I could adopt some tool that supports local-first text files and has a "board" view. And friend, there aren't many. Even then, I'd be locked into that application's interpretation of my weekly plan markdown file. I don't want that! I like my format! What to do?
How hard can it be to build something like this?
To find out, last November I built a tiny tool for myself that I call todo.kanban. It's a Svelte-based web app that uses the browser's FileSystem API to open a markdown file on your device and render it as a Kanban board, complete with drag-and-drop toggle of todo status. Give it a try yourself here.
If you're into "how I built this" narratives, I have a play-by-play thread on twitter of my experience building it.
My favorite thing about working with DXOS is that it natively enables an interoperable application architecture. ECHO, the DXOS distributed data store, provides a shared data substrate that apps read/write from directly. The data lives in the user's vault rather than in the application's database.
Rebuilding todo.kanban in DXOS has been delightful. I livestreamed my work session on it this past week.
ICYMI: Stuff I've worked on
A few months ago, I outlined my current thinking about how protocols get adoption; I think this problem doesn't get enough attention.
I sketched out a pattern language for a new computing environment and I keep coming back to it as a gestalt of the system I want.
Glimpses of the future
Dynamicland captivates as a living example of an alternative computing environment. Programs are tangible elements in the physical world, people huddle around the table, poking and prodding, thinking and experimenting, working out loud. How effective could we make such environments? Folk.computer, based in Brooklyn, is two former Dynamicland collaborators pushing the boundaries of what's possible with a room-shaped computational medium. They're working on low-level problems like building hardware devices to map programs into the physical environment and generally trying to make the environment more expressive through the creation and refinement of new primitives. I visited their office in Brooklyn last week and it's inspiring stuff! Check out their updates on substack.
I'll be setting up my own folk.computer in my home office. Stay tuned!