The Local Yarn

Re: “I wish it longevity so…”

Path did not achieve longevity or shabbiness:

“On May 28, 2015, Path announced it had been acquired for an undisclosed amount by Kakao.

“On September 17, 2018, Path announced its termination of the service. From October 18, 2018, existing users are no longer able to access the Path service.”

Path (social network) on Wikipedia
Joel Dueck

Re: Future Proofing

The web, as it appears at any one moment, is a phantasmagoria. It’s not a place in any reliable sense of the word. It is not a repository. It is not a library. It is a constantly changing patchwork of perpetual nowness.

You can’t count on the web, okay? It’s unstable. You have to know this. …If a sprawling Pulitzer Prize-nominated feature in one of the nation’s oldest newspapers can disappear from the web, anything can. “There are now no passive means of preserving digital information,” said Abby Rumsey, a writer and digital historian. In other words if you want to save something online, you have to decide to save it. Ephemerality is built into the very architecture of the web, which was intended to be a messaging system, not a library.

Adrienne LaFrance, Raiders of the Lost Web

I can envision only one sort-of-practical way the web can be “preserved” in any meaningful sense of the word: a giant microfiche archive with a card index. Yes, it would be inconvenient to use. It’s also the only option likely to be useable at all in 100 years.

Joel Dueck

Re: Why America Should Conquer Canada†

Apparently there was a brief period in the 1920s when America and Canada were both secretly drafting plans to invade each other. Tracy Mumford, reporting for Minnesota Public Radio:

“In 1921, a Canadian lieutenant by the name of Buster Brown drafted ‘Defence Scheme No. 1.’ Despite ‘defense’ in the title, it was ‘a full-on invasion plan,’ according to Kevin Lippert, the author of War Plan Red… In the end, he proposed a five-pronged attack. In the west, Canadian troops would take Seattle and Portland. In the east, the Quebecois would occupy Albany. Maine would be reclaimed, as would the Great Lakes. In the Midwest, Brown’s plan called for ‘Prairie Command’ to swing through Fargo and then head south to invade Minneapolis and St. Paul.”
“Defence Scheme No. 1” from War Plan Red By Kevin Lippert
“Defence Scheme No. 1” from War Plan Red By Kevin Lippert
Joel Dueck

Pollen Targets

I’ve been digging into Pollen. It’s early days yet, but it seems very promising. So I was surprised and glad to see this happen today:

“New Pollen tutorial: how to generate multiple outputs (e.g., HTML, plain text, LaTeX, and PDF) from one source file.”
Matthew Butterick (@mbutterick) in a now-deleted tweet

I tweeted earlier today that this is probably the best web/writing news of the summer, if not the year. Yes, that’s subjective. But anyhow, let me explain why I think it’s great.

For at least a few years now I’ve been trying to figure out how a good way to generate a web site and a print-ready PDF book from the same source document (because reasons). Before Pollen, the best route seemed to be: write the documents in Markdown, and then use a tool like Pandoc to convert that source to HTML and to PDF (via LaTeX).

The biggest problem is that Markdown is not actually great as a source format. Yes, it’s readable. Markdown documents, being plain text, can have a good shelf life. But in practice it’s just not very smart, and no one agrees on how to educate it. For example, suppose you want to specify a class for an image, so that it floats right. Markdown doesn’t provide a way to do this. Some variants of it have added support for it, but no one agrees on what syntax should be used. Whatever variant you pick, you better hope that your whole toolchain supports it (in the future as well as now). Just about every editor and processor and previewer out there supports their own 92% of what you need from Markdown and they each pick a different 8% to leave out. As an author, you really have no facility for doing things the way you’d like. Brett Terpstra has some good advice for coping with this, but it basically boils down to “keep your source documents as simple as possible to avoid running afoul of incompatibilities.” I say boo to that.

To use a graphics analogy, using Markdown as a source format for web and print is like creating art as a GIF and then trying to upscale to SVG. Pollen offers a completely different way of doing things:

  1. You decide what kind of semantics your documents need.
  2. You design the markup your documents will use.
  3. You decide exactly what output that markup produces.

Here’s an example excerpt of one of my documents in Pollen:

#lang pollen

◊(define-meta title "Two Voices in a Meadow")
◊(define-meta doc-publish-date "25/08/2015")
◊(define-meta author "Richard Wilbur")

In ◊hyperlink["
imageinterview.htm"]{an interview}, he said "the milkweed's speech is
indeed written in one of my voices and was used for the sister's funeral in
a genuine and appropriate way. But the other voice --- the 'slob' voice of
the stone, is also one of my voices."

◊verse{◊poem-heading{A Milkweed}
Anonymous as cherubs
Over the crib of God,
White seeds are floating
Out of my burst pod.
What power had I
Before I learned to yield?
Shatter me, great wind:
I shall possess the field.}

The ◊tags above are all functions I write. The ◊verse tag is a good example of an advantage of Pollen over Markdown, because Markdown has no facility for typesetting poetry (at least, none for setting it differently than source code). For now I’ve defined my ◊verse tag to place its contents inside a <pre class="verse"> tag which I can style with CSS. Someday I might find or need a different way to structure poetry in HTML; if so, I can simply edit the function and regenerate the site, without having to change the source documents at all. Another good example is YouTube embeds. I could create a ◊video tag that would take a YouTube ID and use their latest embed code. When YouTube changes I can update my code to match, the tag remains the same.

Pollen was compelling enough when HTML output was all it did. But as of today, you can specify multiple targets for your documents, and code the output behavior for each. This means I could take a bunch of files like the one above and generate a web page, and a book-ready PDF, and a plain-text (dumbed down) Markdown version. If my requirements for any one of those target formats should ever change, I simply edit my Pollen code. The document itself can remain unchanged.

There are other things you could do, too. With some programming and some text-to-speech facilities, you could include .mp3 files as a target, and auto-generate an RSS feed, thus making everything you publish in written form into an automatic podcast as well.

With Pollen I finally have a tool I can use to publish to multiple formats where I have complete control over both the source markup and the finished result in every format. Of course, you have to learn LISP programming to make full use of it, which can be daunting, but I’m having fun doing so.

Re: Future Proofing

Unlike with other digital expressions, format is not the problem: HTML, CSS, and backward-compatible web browsers will be with us forever. The problem is, authors pay for their own hosting.

…Keeping your website active is probably the last thing your family will wish to focus on in their grief. As they move on, attending to your digital affairs may not be high on their task list.

Joel Dueck