💾 Archived View for soviet.circumlunar.space › rwl › gemlog › 2022-01-24-recursewithless.gmi captured on 2023-05-24 at 18:39:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
I've spent the last few days sinking far too much time into making this:
It's a revamp of my "professional" website, which used to just host a boring resume, based on a template that someone else created.
Now it's more personal. It still contains my CV, but not on the main page. It reflects both sides of my quasi-professional existence: on the one hand, my ongoing journey as an academic philosopher and academic-adjacent programmer; and on the other, my interests in retro computing, Unix, and the possibilities of hypertext.
If you visit the site without JavaScript enabled, you'll just see a normal HTML document. All the data is there for you to read top to bottom, scrolling as you normally would. (Contrast this with today's JS-only "writing" sites -- e.g. Medium or Substack -- that won't actually show you any text if you don't load their massive pile of interface code and spyware.)
But if you visit with JavaScript enabled, you'll be presented with a shell-like interface which I wrote myself. This interface is based around the idea of treating a single document as something like a Unix filesystem. (In fact, many basic Unix shell commands like "cd" or "ls" work, though they're implemented as aliases for the commands listed in the help, to be friendlier to non-Unix visitors.) It's a hierarchical namespace, a tree of named nodes. Just like in a shell, you always have a position or "working directory" in this tree, and by default, most other commands operate on your current position. This lets you jump around in the hierarchy (using "goto", i.e., "cd") and then just view the parts you are interested in ("show"), instead of scrolling through.
The names in the hierarchy are all just "id" attributes in the HTML. Occasionally, I use a "data-tocd" attribute to add a description which is displayed by the table of contents command ("toc"). Other than that, all the data is just normal HTML markup; the shell interface is just a different way of viewing and interacting with it.
The whole interface is implemented in 500 lines of completely unoptimized JavaScript:
https://recursewithless.net/lib/js/tui.js
It's basically a couple of pre tags and an event listener for keyUp events. There's not much in the way of parsing, error checking, or generally being responsible. Because this was about having $fun, for that odd value of $fun I seem to be keyed into.
There's still a lot of things I'd like to implement. Some sort of find/grep command is high on the list, since searching for the information you're interested in is a lot more important when all content is hidden by default. But I will probably start with a "bling" command to change the color scheme. ;) Suggestions welcome!
One thing I've learned by implementing this interface is that a shell is not necessarily a *good* way of interacting with a document. For a simple document, you can often find what you're looking for much more easily by visual scanning. Our visual systems are powerful tools. Certain visual distinctions (between headings, lists, images, paragraphs of normal text, etc.) are immediately obvious in a browser, and those distinctions get lost in a shell interface. When *all* you can use to decide what you want to read more carefully are names and descriptions, it is very important that those names are well chosen: they must be easy to scan and understand.
On the other hand, I think the shell approach might prove more useful as the underlying document gets larger. Even a Wikipedia article often seems like "too much text" if you're trying to find something quickly. A journal article or a whole book would be hard to make sense of as a single traditional Web page. As the amount of text increases, it tends to overwhelm the visual distinctions, and it becomes much more important to have an explicit hierarchical structure and an implicit, shiftable location in that structure. (This is something that those building text-focused tech like Gemini should keep in mind, I think. It should be easy to see and interact with a table of contents!) This makes sense: the original home of the shell is an entire operating system, containing many documents created and shared by a whole team of people -- though the original filesystems of those operating systems probably held less data than a single Web page sometimes does today.
My shell interface is a first attempt at finding a way of interacting with documents that combines the best of both approaches. But I haven't found it yet.