Typewriter 17.2 Blickensderfer Typewriter; the Scientific keyboard 25.6 Burroughs Moon-Hopkins Typewriter/Calculator 01.9 Experiential Typewriter 05.3 Experiential Typewriter 21.0 Henry Mills' Typewriter 17.0 IBM Selectric Typewriter 11.2 Pneumatic Typewriters 45.6 Typewriters, reactionary use of antiquated 21.1 Typewriters: the Comptometer, the Numerograph, the book typewriter 45.2 mechanical typewriter
https://web.archive.org/web/20190305042816/http://www.deadmedia.org/notes/index-cat.html#tw
Bruce Sterling lists them in his Dead Media file, a catalog of defunct media devices and platforms.
Rather than dealing with the invariably convoluted process of moving my content between systems — exporting it from one, importing it into another, fixing any incompatibilities, maybe removing some things that I can’t find a way to port over — I drop my Markdown files into the new website and it mostly Just Works.
What if you just dropped your pre-rendered static assets into the new system?
@1:10:20
With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]
NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.
@48:20
I should actually add that the PDF specification only specifies the file format and very few what we call process requirements on software, so a lot of those sort of experiential things are actually not defined in the PDF spec.
the tools can be distributed within static web-pages, which can easily be hosted on any number of exter-nal services, so researchers need not run servers themselves
data can be exported from airtable, but the logic and UI can't
I wrote about my idea for Library.json a while back. It’s this idea that we might be able to rebuild these monolithic centralized services like Goodreads using nothing by a little RSS.
See also this thread with Noel De Martin, discussing a (Solid-based) organizer for your media library/watchlist: https://noeldemartin.social/@noeldemartin/105646436548899306
It shouldn't require Solid-level powers to run this. A design based upon "inert" data like RSS/Atom/JSON feeds (that don't require a smart backend to take on the role of an active participant in the protocol) would beat every attempt at Solid, ActivityPub, etc. that has been tried so far. "Inert"/"dead" media that works by just dumping some content on a Web-reachable endpoint somewhere, including a static site, is always going to be more accessible/approachable than something that requires either a server plug-in or a whole new backend to handle.
The litmus test for any new proposal for a social protocol should be, "If I can't join the conversation by thumping on my SSG to get it to produce the right kind of output—the way that it's possible with RSS/Atom—then the design is fundamentally flawed and needs to be fixed."
Wordle's spread on social media was enabled in part by its low-tech approach for e.g. sharing scores.
One low-tech approach that could've been used here for data persistence would be to generate and prompt the user to save their latest scorecard in PDF or Word format—only it's not a PDF or Word format, but instead "wordlescore.html" file, albeit one that they are able to save to disk and double click to open all the same. When they need to update their scorecard with today's data, you use window.open to show a page that prompts the user to open their most recent scorecard (using either Ctrl+/Cmd+O, or by navigating to the place where they saved it on disk via bookmark). What's not apparent on sight alone is that their wordlescore.html also contains a JS payload as an inline script. When wordlescore.html is opened, it's able to communicate with the Wordle tab via postMessage to window.opener, request the newest data from the app, and then update wordlescore.html itself as appropriate.
there’s an ancient and powerful technology at work here
Documents should offer the same granularity.
That neither content creators nor browser vendors are particularly concerned with the production and consumption of documents, as such, is precisely the issue. This is evident in the banner that the majority of the work has occurred under over the last 10+ years: they're the Web Hypertext Applications Technology Working Group.
No one, not even the most well-intentioned (such as the folks at Automattic who are responsible for the blogging software that made Christina's post here possible), see documents when they think of the Web. No, everything is an app—take this page, for example; even the "pages" that WordPress produces are facets of an application. Granted, it's an application meant for reading the written word (and meant for occasionally writing it), but make no mistake, it's an application first, and a "document" only by happenstance (i.e. the absence of any realistic alternative to HTML & co for application delivery).
You can do less with media that’s merely digitized than with the real thing
Though its format can be copied and manipulated, HTML doesn’t make that easy.
In fact, HTML makes it very easy (true for the reasons that lead Mark to write that it can be copied and manipulated). It's contemporary authoring systems and the typical author-as-publisher and the choices they make that are what makes this difficult.
The future of rich media lies in striving to be more like dead media (or at least mining it for insights by better understanding it through thoughtful study), rather than the misguided attempts we've been living inside.
(This is something that I've done a 180 on in the last year or so.)