19 November 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.
Questions That Need To Be Answered
- How to design backlinks?
- Do we call them threads or stacks?
- How do we label and distinguish a card’s text and a card’s body? Do we just keep it simple make them the same? Then the name can be the first line and the body is the rest of it?
- Will exposing the account’s activity stream work as a design feature?
- Or should we just go with cards with no activities?
- How do I present and position bookmarking versus archiving versus attachments?
- What is the conceptual model for attachments in the first place?
- Should the card body be plain text, HTML (rich text), or markdown? I keep changing my mind on this, so I think this can only be settled by making HTML prototypes.
- Do we have a separate editing versus reading mode for the card body?
- Do we implement the first run at the reading features on the card body’s reading mode?
- Or do we need to add something like EPUB support from the very start?
- Should the user be able to have multiple top-level threads, each a separate workspace? Or do the child cards of a solo top thread serve the same function?
- How should cross-referencing work?
- What specific kinds of annotation should this support?
- Should cards have colours or some other form of non-tag typing or labelling?
- How are tags presented on the card?
- How exactly should the system track reading position?
- How should it be presented?
- How should we price this?
- Does ‘mark with attachment’ make any sense as a feature?
- How much of an issue will storage be?
- Will a web app (Progressive Web App) be viable on its own as a service or will I have to have some sort of native app on the roadmap? (Suspect the answer to this question might change, anyway, over the next few months.)
- People are going to expect to be able to interact with card stacks in some way that reflects the metaphor, aren’t they? Something like Apple’s piles idea might work. Maybe a child card menu? Is that too simple?
- Except piles is a great idea for an UI feature on its own, so it’s more a matter of rhyming with it than copying it wholesale.