For the last week, I’ve been modifying the checklist rather than posting individual progress updates, but with that list narrowing now, its worth checking in and discussing the thornier bits that remain.
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇
The front page and nav menu are now in place. I’ve successfully tested several different site deployment schemes, so I’m ready to adapt to whatever tools are supported by the webhost I end up choosing.
The big questions remaining mostly involve making decisions about how I plan to use the site, rather than how to make the plan work.
I’ve implemented a system where I can flag a project as ch-archived. Adding that flag moves it out of the active nav system and into the “warehouse” part of the site, meaning it is no longer listed individually on the Projects menu and will instead be accessed from the Archive page. But upon deeper consideration, that’s not flexible enough.
When I’m “done” with a project, that could mean several different things: I may have finished it and put it in a box, I might have published it, or abandoned it, or even just lost interest and moved on, and each case needs to be treated differently.
When a book gets published it is no longer being actively developed, but it shouldn’t be characterized as “archived” either. Similarly, a game that has been launched needs to be treated quite differently from one that I abandoned before completing it. Launched books probably need to appear in a different part of the site than launched games, both of which should be featured in some kind of site “showroom,” while abandoned electronics projects should probably be moved to the equivalent of my attic.
So rather than indicate that a project is simply finished, I need to instead indicate where to move it when the active phase is over. In the current implementation, a project is considered active by default, so it doesn’t need an explicit deployment flag and will be shown in the Projects menu. That part already works and there’s no need to change it.
The next phase will be controlled by a new ch-deploy-foo flag. If foo is “attic,” then the project is being abandoned, boxed up, and put away. Then there are projects that are complete enough for my purposes, but I’m not planning to release it commercially so it doesn’t need to be promoted or highly visible on the site. Those will get deployed to the “basement.”
All other values of foo will be considered showroom names. So for now there will be ch-deploy-books and ch-deploy-games, and each will get its own dedicated menu in the nav system. But at any time in the future, I can create new showrooms by simply assigning a new deployment tag, like ch-deploy-apps or hell, maybe even ch-deploy-movies.
A key element of this system is that none of these tag changes will have any effect on the URLs of the pages related to the project. Project frank’s content will always be accessed under /projects/frank, regardless of which showroom it winds up in. The only thing that changes is where the project appears in my navigation menus. That way, incoming links to the site will never break.
When I first wrote the countdown checklist, I threw in a task for setting up a blog page. I knew that I would want a place to put stuff that wasn’t specific to a project. A joke. A rant. A rumination on the state of childhood entertainment. I was thinking of it as my mental water-cooler, where I can chat about life, the universe, and everything. But as soon as I set it up, I immediately wanted to start using it as an “acceleration lane” for a nonfiction book I’m nibbling at. A blog would be a great venue for some introductory essays, maybe a place to summarize my findings from a literature review on the subject, report on related resources I discover, etc.
And then I decided that such a blog would have to be single-purpose. People who wanted to follow my stream-of-consciousness notes on the fall of capitalism wouldn’t want that stream to include funny things my grandkids say. So that meant I’d need two blogs. And if I ever decided to start an essay stream for another book idea, that would require a third…
Which is about when I realized that I was reinventing my project system. Each project is already a topic-specific blog. The only difference is that the kind of updates I make on an electronics design project will be different from the kind I post to a book of nonfiction essays.
So I’m happy to report that I already have the general water-cooler blog set up. But it’s currently got the wrong face on it. I need to figure out how to put a more blog-like face on the projects that are more blog-like in nature. In particular, they probably want a banner image rather than just a thumbnail, and I may decide to point a dedicated domain name at those subpages. But I’m going to draw the line there. No custom themes or anything like that. This is one integrated site for multiple projects, not a switchboard for accessing multiple sites.
The last thorny bit is that I need to create pages for my previous projects: the books, the cartoons, a couple of different streams of videos… In going to announce the site to my newsletter followers when it goes live, and I don’t want anybody coming here and thinking I’ve abandoned their favorite things.
Step one will be to implement the deployment scheme outlined above, which will give me the infrastructure necessary to add these projects quickly. From there it should be a matter of cutting and pasting content from the previous site and/or the various places where these projects can be found online.
And that’s about it. Thanks for listening. This has been a really productive chat. I’m going to go revise the countdown page to reflect these changes now and then I can get on with the implementation.
Creating online communities is easy; but doing it ethically is not.
Over the last few decades, we’ve developed many hacks and tricks - a playbook, if you like - for tempting communities of like-minded humans to gather into online echo chambers, where they can be manipulated in demographically unified buckets. So before I go too far, I need to ask myself an important question: Is blogging inherently evil? Or is it possible to thread this needle without crossing over to the dark side?
Refactoring the shadowmaker has become a bigger headache than I had originally anticipated, but it’s for the long-term health of the system, so I’m sticking to my guns. This weekend added further drama when I finally stopped running away from frontmatter and embraced it for all my metadata. Sure, scattering #ch-command directives throughout the body of the notes was insane, but fixing it is going to mean more than just adding a few metadata fields. I may have to completely change the way I use Obsidian.
While trying to integrate the many episodes of CaveTV into the site, I realized that the ontology was getting cramped. It needs to be revised to better distinguish between internal projects, external brand identities, multiple deliverables within a brand, and distinct showrooms.
What follows is the scheme we devised for what the abstractions are, how they should be tagged in Obsidian, and how the files will be managed within Hugo.