What if links weren't meant to be prose?
Hypertext is text that points at things. But point how, and at what?
I was chatting with a friend about Slashlinks this weekend, and he asked why this, rather than wikilinks? I’ve built prototypes exploring wikilinks, slashlinks, and other approaches, too. My sense is that there are multiple right answers here, because there are subtle tradeoffs and dilemmas. So, here are some of my notes on the design space.
Prose links mean modes
Many “Tools for Thought” use [[wikilinks]] to reference pages by name.
[[Wikilinks]] are embedded in prose, and have to make sense as prose, and at the same time function as an unambiguous ID. This tends to get snarled on synonyms, pluralization, and alternative turns of phrase. Wikis often end up introducing something like:
[[wikilink | front-facing text]]…to make it possible to change the rendered text of the link. This split between identifier and front-facing text isn’t unique to wikilinks. HTML and Markdown also have prose links, and require you to specify link text and address separately.
<a href=”https://example.com”>Link text</a>
[Link text](https://example.com)Markup like this implies that apps should have a distinction between an edit-mode meant for writing, and a view-mode meant for reading. This creates indirection. Editing becomes something abstract. You have to hold in your head the difference between the symbolic markup and the rendered text, and imagine the rendered text while editing. This kind of indirection might be ok for an audience-centric publishing tool, but feels like a lot of cognitive overhead for taking notes.
The split between identifier and front-facing text also tends to create visual noise in markup. [Markdown links](https://example.com), [[https://example.com | Wikilinks]], and <a href=”http://example.com”>link text</a> confuse the visual flow of prose. You have to develop “eyeball parsers” for them. You can hide this complexity behind WYSIWYG, but if you want a plain-text markup approach, the complexity is something you’ll have to accept.
Roam is worth noting, because it has a similar view-edit distinction, but with a twist. Autogenerated IDs, such as ((1cIXhy2zT)) are used to reference blocks (parts of pages) in edit-mode. An autocompletion UI helps you find the right ID by searching the text of all blocks. In view-mode, the literal contents of the block are rendered in-place. However, Roam cleverly drops into edit-mode on a line-by-line basis, blurring the distinction between modes, and reducing the cognitive overhead of modal editing somewhat.
Modeless markup
There’s another, radically simple approach to markup. Bare URLs, #hashtags, and @mentions are all identifiable within text as special forms. We could think of them as “modeless markup”. There is no distinction between the edit-mode and view-mode text. The text is the same in both cases.
Modeless markup can be embedded in prose, but it doesn’t pretend to be prose. It is clearly part of a different language game, so we don’t feel the impulse to try to work it into a sentence. Instead, we might place #hashtags or URLs at the end of a paragraph.
Modeless markup can’t hide complexity behind a mode, so it also tends to be simple, readable, and useful as plain text. Markup that is barely there.
Modeless markup is typically defined as a normalized slug, so you can efficiently do string-literal searches across text for #hashtags, or @mentions.
Modeless markup means direct editing. It can be rendered seamlessly as you type, without any jumps between view and edit mode.
What if links were never meant to be prose?
What if all this complication around edit-mode and view-mode is solving the wrong problem? Maybe links were never meant to be prose? Consider what happens when you paste a URL into Twitter:
The URL generates a kind of simple transclusion. The very first hypertext systems designed by Ted Nelson all worked this way, and we see this pattern emerge again and again in mainstream apps, including Twitter, Facebook, Discord, Slack.
Embracing transclusion might potentially simplify link markup. You don’t need a separate prose-representation if a transclude is providing direct representation of the thing you’re linking to.
This directness suggests using a modeless markup, like URLs, #hashtags and @mentions. And so… /slashlinks!
I don’t think this is the only good solution for pointing at things, but it feels like an under-explored approach within the design space:
Simple, with existence-proofs in many mainstream apps.
Plain text. Readable, you can copy/paste it, and even search for it using efficient plain-text search.
Familiar. If you know how URLs work, you know how slashlinks work.
Direct. No distinction between view and edit modes.
Literal. Leans toward a more direct representation (transclusion), rather than symbolic representation (link text).
I’m planning to try it out in Subconscious.