14 December 2021

This is an archive of the writing and research surrounding the Colophon Cards project.

The initial work on Colophon Cards was funded by The Icelandic Centre for Research’s Technology Development Fund. I had originally hoped to get a grant to further develop the project from that fund, but that fell through. I’m still hoping to restart work on the project, but in the absence of funding the scope will inevitably be much more limited and is likely to look very different from the vision presented in this archive.

Working Spaces: Using Cards to Make Cards

The problem space

One facet of my undiagnosed but almost certain neurodivergence is that, when it comes to work, out of sight is very much out of mind. I like big desks with notes, sketch pads, dot grid pads, post-its, and other scraps of paper spread out all over. Pads with notes to extend my working memory. Pads with sketches for whatever it is I’m working on. Diagrams for interaction models or class hierarchies. Database modelling. Ideas. It’s spread out, displayed, taped to walls, and then discarded upon irrelevance. I like whiteboards or chalkboards and big spaces to tape things on.

Even when I have been working in shared spaces, like an office, I’ve always had to do a little bit of the work at home, where I usually have had a wall set aside for notes and sketches that are taped to it and spread out so I can see them all at once.

For me, space = thought. Which is where index cards come in.

I like index cards. A stack of index cards and a big, big table is great when you want to figure out:

This is great for writing (where “system” = “narrative structure”) and for software (where “system” = “design”).

I prefer index cards for this over post-its as index cards are less fiddly and less disposable. With index cards, the exact spatial relationship isn’t that important (the stickiness of a post-it gives position a unwarranted heightened importance). It’s more about rough distances and piles and those can be documented on a separate card or by marking the cards themselves. You can also always put post-its on an index card to the two tools are somewhat complementary.

That way the index cards can be filed away and revisited. The work continues.

Using index cards for this also lets you pull in your index card notes such as your reference or idea cards.

Which is why I still prefer index cards over post-its even when I only have a wall available and not a table. Just use easy-to-remove paper tape and spread them on the wall.

If you haven’t guessed by now, I loved the original, classic-era Mac, spatial/object-oriented Finder. It was a rare case where the conceptual design and affordances of an app fit my mentality, personality, and way of working perfectly. (Or as perfectly as software can get.) But the software world moved on and we need to adapt with the times.

Here’s one of the main gambles with Colophon Cards: if I design a note-taking app that suits my own neurodivergence, will I be relegating the app to a tiny minority who, quite literally, think differently from the rest?

Or, as is often the case with making software and services more accessible, will making it usable for people like myself expand the capabilities of those unlike myself and make the app more adaptable to varying needs?

Too early to tell but you can tell which I’m betting on from the fact that I haven’t given up yet.

This means that there are some basic capabilities that the default view of a collection of cards needs to have:

Tinderbox is the only app that offers broadly the capabilities that I’m aiming for but it also offers much, much more, in a package that has a steep learning curve. I’m also hoping to make Colophon Cards more bookmark-, document-, and reading-oriented. But Tinderbox is a great app, you should check it out. I used it quite a bit back in the day myself.

The open questions are:

The approaches

In existing note-taking apps, multiple views of the same note collections happen broadly in one of three ways:

Each approach has its uses, strengths and weaknesses. Supplementing a complex, power user main view with helpful visualisations can work well. Implementing different views as essentially their own documents can help you support a wide variety of use cases in a single design—provided you have the resources to implement a de facto app ecosystem wrapped up in a single environment. Finally, multiple representations of the same data works well if the views broadly share affordances while offering distinct visualisations and navigations of the same data. For example in the macOS Finder, how you interact with the files and folders is quite similar across representations but it lets you represent a folder of images with big icons, a deep hierarchy of documents with a column view, and a large directory of downloads as a reverse-chronological list with details.

If you can’t tell, I’m still a huge fan of macOS’s Finder, even though it’s evolved a bit from my ideal.

The downside of the representational approach is that it’s easy for the app to devolve into a cluster of complex apps that share little.

The upside is that if you pick the right representations, the ability to switch views can strengthen the user’s conceptual model: shared affordances get reinforced.


What the cards tell you, take one

A collection of index cards stacked into two piles. One is labeled structure and has the cards: Stack or Thread, Editable Card, Attachment (downloadable), Attachment (readable), Bookmark, and Piles(?). The other is labeled representation and has the cards: Map, Thread + Pinboard, Tile, Thread, Pinboard, Document (Blocks), Outliner, and Graph
The first version of a rough categorisation of structure versus representation.

A few notes on this initial set of cards:

What the cards tell you, take two

A collection of index cards stacked into two piles. One is labeled structure and has the cards: Stack, Card, Attachment (readable), Attachment (downloadable), Bookmark with Annotations as a post-it, and Piles(?). The other is labeled representation and has the cards: Pinboard Column, Pinboard Rows, Graph View, List View, Tile View, Outliner View, Map View, Document (Blocks), Time line View, and Spreadsheet
The second version of a rough categorisation of structure versus representation.

That’s a lot of options; a lot of potential representations of a single stack. Let’s see if I can’t whittle it down.

Cutting the deck

First, let’s sort them in order of priority.

A collection of index cards stacked into two piles. On the left-hand side we have: Representation, Pinboard Column, Pinboard Rows, Outliner. On the right-hand we have: Document (Blocks), List, Map, Timeline, Tile
With priority ordering. Cut off representations on the right.

The rest are all candidates for future work but well beyond the scope of the initial version. Even the Outliner View is probably not going to be in scope for the initial prototype.

Implementation notes for future reference

The next step is to sketch up these three main views and figure out a testing strategy. For the sketching, I might have to break each view down into individual cards as I did here. (Hierarchy!)