ColophonCards

tools for thought in development by Baldur Bjarnason - https://www.colophon.cards/

The Making of Colophon Cards

Ever had an important document or bookmark, which you know you saved somewhere, and you know was filed somewhere clever, but can’t for the life of you find again?

You try to search for it, but because you either haven’t read it yet (you filed it away to read later) or because you only glossed over it (it’s a contract or similar document that isn’t pleasure reading), you can’t come up with a search term that seems to surface it. You tagged the file, but even with tag filtering, your search terms are still too generic

But, if you were lucky enough to have gotten it via email in the first place, you always seem to be able to find it with the first search term you came up with or in the first mail folder you looked in.

Email, especially emailing something to yourself, adds another powerful mnemonic device to your toolset: Writing... Short writing helps you find your things

In the absence of designed information architecture, you have to resort to constructing the search term based on what you remember about the document.

This is why sending an email to yourself with a file as an attachment is often a better filing system than throwing it into your shared Dropbox.

This approach is called User-Subjective Information Management (The Science of Managing Our Digital Stuff is a good starter on the theory) and you don’t need anything new or expensive to use it

Do you really think you’re going to get honest feedback from everybody you work with when the entire management chain from your line manager up to the CEO can see their every keystroke? Do you really think you’re going to get very far in managing your own data and information when everybody is using a shared Notion space?

Striking a balance there, between managing your own information library and sharing the product of that management work with others, is surprisingly hard to find with modern tools. (work product)

Solving this problem is the goal of Colophon Cards

Even though the project itself isn’t open-source, I aim to work as much in the spirit of OSS as I can. This is why I plan on doing the prototyping, design, and planning work for the project out in the open in this repository. (Working in Public)

In recent years we’ve seen a micro-revolution in Personal Knowledge and Information Management systems (Digital Garden)

But, from this end user’s perspective, there are a few problems that these systems haven’t solved:

The low-end systems lack features for writing about things: bookmarking, annotating, quoting, summarising, navigating,

With very few exceptions (Ulysses app, for example), they pay very little attention to the purpose of note-taking, which isn’t just to capture and organise ideas but to improve your work.

you need to be able to easily turn your notes into documents that feed into your work.

My goal with Colophon Cards is to create a web-based note-taking app for bookmarking and reading websites, ebooks, and documents. It needs to find a balance between ease-of-use and advanced features. It should have a user-subjective sharing model built in from the start where data is shared while the organisation is specific to each. Finally, it needs to provide straightforward tools for turning notes into documents for sharing with others

Design Notes

November 10, 2021

Colophon Cards should be the marriage of Notational Velocity’s search-first navigational model with Twitter’s card stack model. (card deck)

Terminology

Threads: I’ve decided to prefer threads over stacks as, even though, they would mean the same thing when you are building with cards as a core metaphor, they’ve come to have specialised meanings in UX and UI in general.

Cards: this has also become a generic term for a UI widget

Activity/Activity Stream: often called event stream. This is a stream of the events/activities that form all of the data belonging to a particular user.

The innovation here over Notational Velocity is that each card is also a thread and therefore a completely encapsulated search space.

I am tempted to have the thread be an activity stream. Instead of just the cards, you would also have the activities on those cards listed in the thread

The created card has a name, replies (only displayed when you open the card as a thread), attachments, and a body.

“name” might be the wrong term for what is, in effect, the main text of the card and should be thought of as more akin to a tweet than document title.

Should the body be rich text, plain text or markdown (irrespective of what it’s stored as)?

Markdown is the de facto note standard but is honestly a mess of partially compatible implementations. It also forces a modality... getting rid of modes does more to make a UI feel fast than most of the performance work engineers love to throw at problems

Tags

Replies
Every card is also a thread. The replies link on the card is a link to the card’s thread.

If I go with markdown or plaintext Note Name would be used to automatically link to the note.

Automatic backlinks are not a good idea

Intentional backlinks, however, are amazing

Sharing

Designing the sharing and collaboration mode should be a separate document. But the threads and cards UI should be single user. Nothing should happen in your threads or to your cards that isn’t done by you.

Sharing Model

November 10, 2021

There are two major issues with how all of these apps implement collaboration:

• They are recipes for groupthink.
• They build on shared data repositories.

Groupthink

Another issue is that this model also downplays shared concerns, ones that members of the group broadly agree on. Instead of getting multiple explanations from multiple perspectives on why something is of concern (only one of which might actually be the explanation that clicks for others) you get the first one, usually the one that’s the most hastily written and least thought out, and a number of ad hoc ‘upvotes’.

If the goal with a collaboration is to make the most out of each person’s expertise, perspective, and experience, you need to silo their contributions from each other. (I think this works in some contexts but not others.)

Shared data repositories

Shared data repositories require information architecture and information architecture is highly complex.

None of this is necessary in a digital context because the keyword in the above description is copy. We can share the data and let each user organise their own collection. Instead of one copy going into a shared bookshelf, every recipient has their own bookshelf that they organise according to their needs and they each get their own private copy of the document

Let the original sharer act as a moderator to filter which collaborator reactions get added to the shared context.

We don’t want to:... Become a collaborative document authoring platform (among other things)

The Sharing Process

The difference between internal and external collaborators happens when the collaborator follows that link. External collaborators get a nice web page with the note, attachments, and an activity thread with the approved replies.

Internal collaborators who are signed in can file the note to a thread of their own as a quoted Card. They can reply to the shared card or any of its replies in the web UI

Both internal and external collaborators can reply directly via email, only internal collaborators can reply via the web UI.

Sharing Data Model

Organisations need to be able to revoke access to shared cards.

Users can have several Accounts, each with their own Authentication settings.

The Business Model

November 19, 2021

the goal is to create a SaaS

The straightforward approach is to have a set price per user account, per month but even then the per user pricing in the industry is all over the place:

Most of notetaking apps don’t mention anything about storage quotas in their pricing but that’s because they don’t do much in terms of storage.

The ConvertKit service took an interesting approach to developing their business model: they targeted high end users first and only expanded their offering to include cheaper tiers once they had proven both the app and the business model.

One issue that a lot of beginning SaaSes run into is that the lower tier users tend to draw all of your attention and incur higher support costs so it’s often better to not enter that market unless you’re sure you can handle it.