This time we're sticking with our current "phast"-based website design.
There was some extensive consideration of Hugo. In the end, though, we'd need to preprocess everything and the way metadata is scattered among a bunch of different files reminded me of why I didn't support that for my Gopher implementation.
I've already used a system where I needed to extensively preprocess everything. I'm just not a fan. I've realized I'm not even a fan of HTML-based templates.
We'll be pivoting the frontpage from "categories" to "products." To do this, we first need to enhance the products page. The final front page may well contain both top products as well as top categories.
Will this also include moving some of the main page's category features to the `/c/` categories page? Maybe. I want to leverage the basic design of the current home page as the framework for the new image-heavy product page.
The redesign will have product-based blogs, or at least, an appearance of product-based blogs. The actual location of the blogs may well still reside in the `/j/` directory.
We do still want to rewrite the majority of the code using well-tested dependency logic. The current dependency code does not work reliably. That said, if we split site generation in to two distinct phases, one just the `/j/` pages and a second phase to generate the secondary links and pages, I think it should help with a lot of the dependency problems. (We could even do a dependency-based `/j/` build with a full rebuild of the secondary pages and significantly speed things compared to a full rebuild of everything.)
JSON output ===========
We're still considering a JSON metadata format, but the Hugo experiment really demonstrated that it'll just be an output format and not a change from the existing `folder.conf` metadata.
Good JSON output requires changing the way we're generating our pages. This came up with some of the earlier Hugo experiments, too. Ideally, we'd want to support standardized fields for interoperability. Adding JSON will alter how we're generating all our files. This makes it a considerably more complicated project than just shoving our current `folder.conf` metadata in to a JSON file.
`phast` has no distinction between what Hugo sees as "list pages" and "single pages." While this is smart and good, the distinction between the two might provide clarity for JSON output. That said, the resulting `phast` output for trunk nodes could not be confused for the output of leaf nodes. It shouldn't be subject to confusion.
Improved syndication possible =============================
The Hugo stuff used a combined RSS+Atom syndication file format. I'm currently only supporting Atom, but that was partly due to not being able to find a good example of the combined format.
This means I may be able to gather the information I need from the Hugo template so that I can add RSS support in to my own syndication files.
Markdown output ===============
We're also considering supporting a lightweight Markdown variant as an output format. It is an on-going experiment and would pair with an experimental multi-protocol client that is yet to be written.
Should we drop SEO? ===================
There's consideration of explicitly dropping SEO support. Is being available to search engines worthwile for independent websites?
Google in a private Firefox window gives the top result my defunct Twitter profile, but lists this website as number two. (And that dead Twitter profile does reference this website.)
The power of my username seems to give good results when searching for it. This seems to indicate we should leave SEO as-is for now.
----
Description of cover image: The word "yam655" split so that "yam" is above "655." The "y" and "6" are drawn with the same lines so the downward line of the 'y' swoops around to become the "6." There is an orange back-of-cat halo around the y-6 glyph with the loop of the '6' being the cat tail.
------------------------------------------------------------------
