A Better Journal

I’ve an app with this name once before, and it wasn’t good enough for me to use, even though I put a lot of work into the design (conceptual and visual) and performance. I have a hypothesis for why it didn’t work out:

1. It had time tracking as it’s core feature. It turns out, I don’t care how exactly I’ve spent my time! It’s very important, of course, but I can just measure it by looking at a calendar. How many days of this year have passed? Simple as. The thing that does matter is output, being able to see what the time amounted to, well enough to judge if it was worth it.
2. It was based on text entries. I hate looking at plain text. It’s such an impoverished medium. I feel nothing when looking back on entries that describe something I’ve made or work I’ve tracked. I hate writing them even more, they don’t capture enough.
3. I was trying to make it easy to add entries. But that doesn’t matter if I never look back on it. Writing about past is just not that interesting. Intrinsically, it has no hold over my mind the way the present does. Nor is it worth thinking about, relative to the future.

To improve over these problems will require a new approach that includes multiple representations that make it feel good to gather retrospectives material, and look at it later. Alongside solving this design problem, I would also like to find ways to add The Future to this application’s concept space.

Conceptual approach

When thinking about presenting information in ways that are resonant enough to look back on, while also avoiding the act of writing; a simple solution presents itself:

Images

In particular, screenshots — perhaps the most underrated digital record of our era given their ubiquity and sheer ease of use.

When thinking about media that can survive millenia, I’m more confident in diagrams that communicate through visual patterns than in any kind of digital file format that depends on a working decoder to be visualized, or in a single language as the chosen vehicle for information. The Rosetta Stone, through visually paired symbols, transmitted distant languages in a redundant format that could be deciphered in the far future with minimal context. If computation is the execution of algorithms on structured data, then screenshots may prove naive. But if computation is the shepherding of information through space and time, then they may prove essential.

During the opening of the conference, Omar honed in on the subversive nature of the screenshot. In popular computing, it circumvents the app siloes that define our contemporary digital ecosystems. A screenshot doesn’t need a log in, bypasses DRMs, and is interoperable between practically every single computational device. Even in the “high- culture” of computing, where text is dominant, screenshots prove subversive. The screenshot is unstructured information which must be parsed to offer the tidy data best suited to computer hacking. They are seen as verbose and unwieldly, despite universal adoption. The Tao of Unix is text files, not bitmaps.

cristóbal, tweeting

This supremacy is partly a result of the failures of the URL:

The dream of URLs—open, permissionless sharing—is fading. I can’t paste URLs into my AIs or send them to my friends and be sure that they’ll see what I see. But you know what does work? Screenshots! Screenshots are the successor to URLs. Open, permissionless sharing.

zooko🛡🦓🦓🦓 ⓩ, tweeting

And their “resonance factor” completely trounces text. Even without invoking the old adage about being worth a thousand words, just looking at a grid of images is a more pleasurable activity than if it was lines upon lines of uniform words. I have verified this empirically too: I actively enjoy looking back at my LOG note in Bear, which is can be thought of as version 0 of this app. When I just wrote text entries I never scrolled down to old ones.

So this new journal will use the image as it’s primary object. Outputs and in-process work can all be captured by screenshots. In fact, a series of screenshots can act a blink comparator of sorts, making it easy to feel the change.

Text may accompany the image to provide explicit narrative context, and also to enable…

Categorising through text search

As even a fledgling ontologist knows, tags are a dangerous thing. Unless carefully hatched in a context of use, they can spiral into infinite combinations of generic descriptors. They also (usually) need a relational database of some kind to implement well.

We will not be using tags; instead relying on fast text search across all entries in the journal. When I add entries like “Published worknote for Better Journal” and “Design first UI for Better Journal”, they are both trivially gathered into one project by the search term “journal”. The more tag-crazy among us might even resort to #journal hashtags, but I’m hoping the simple capabilites of a prose description proves enough to discourage them.

Of course, commonly searched terms can be saved as one-click actions, such that they feel as good as using tags.

Days as the unit of time

Because I’ve never found myself caring about anything more granular than that. In the long run, you will not care if you did something by 6pm or 6am, just the fact that it was done.

Predictions for calibration

How can one bring the future into a system that is focused on creating good pictures of the past? My answer is “calibration practice”.

You can create Predictions, entries dated in the future, that say “I will have done X by date Y”. On the day you make a journal entry about actually doing it, you can connect the prediction to it. This can be used to calculate a Brier-eqsue score for timeliness predictions in your personal life. Fun possibilities for graphs here, including being able to see if how your prediciton ability itself changes over time.

Implementation details

Interface

As always, iteration will prove invaluable. So even if my ideal client is a native Mac app, I will build it in Tauri first.

I will try to design + prototype at least one layout per week, starting in September, and record the initial design ideas here:

Data model

An entry is just a combination of text + image/video:

version: 1,
text: "Example caption"
media: 
  - type: "image/png",
    path: "screenshot.png"
  - type: "video/mp4",
    path: "screen-recording.mp4"

Honestly, all I’m doing is asking the question “what if Twitter was the best journalling app?”. Except, instead of threads, things are connected by searching for text terms instead.

This simplicity is necessary to keep from spiralling into an everything app. If you don’t draw hard lines in the sand, you end up trying to build universal timelines and operating system interfaces based on time. They’re cool, but they don’t share my goals of far less ambitious goal of restrospection.

I’m pretty sure I can develop a file-based protocol that allows for client freedom. And it will be ATProto-friendly in it’s design, since an entry is basically equivalent to a tweet (each entry has a unique ID). A filesystem model makes for clunkier sync than a custom database-backed protocol, but should not pose too much of an issue, given that it’s a single-user app. In the worst case, I’ll just do what Bear does (compare-and-swap, create a fork on conflict).

Features like OCR, color filters, etc. should be left up to the client instead of being added to the core data model.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail and respond within 2 days.