This is the production log for the website itself.
Adding favicons was surprisingly easy with the use of modern Web tools. The last time I tried to do this for Intergrid, it took some time to figure out and configure and put out. It seems that I’ve used a worse tool back then. This time, I put "favicon" into search, and one of the sites that came up was this one, called Favic-o-Matic. Silly name, but it did its job superbly well: I am now equipped with all kinds of icons for all kinds of purposes.
One of the things I did immediately was optimize the PNG icons, given that they each had a bit of heft to them that I wasn’t comfortable with. They are by no means perfect right now, but they’re perfectly workable, and each of the PNG icons weighs under 1kB. I achieved this (from their usual 3~5kB) by reducing the colors down to 4: testing with different color sizes made it apparent that 2 was too few for a pretty image (it was all jagged at angles, which is where half-pixels reside), while 4 made for tiny yet nice ones. Any more, and the quality does not change significally for the better, yet the size grows noticably.
The ICO file itself – the format that used to be the foundation of site icons for a while – is 34kB, but I’m not worried about it, given just how widely browsers support PNG icons nowadays. As long as it isn’t a major obstacle to getting the site to work (which it isn’t), I’m content with letting it stay as it is while I work on other items.
Since adding favicons required me updating every live page, I thought I might as well add the "jump to content" link. This is useful for people who navigate the Web via keyboard: pressing Tab lets you jump to the next anchor (which is usually a link) on the page. "Jump to content" links allow keyboard users to skip navigation menus and such (which, in my case, is directly "in front of" the content, so to speak) and move directly to the thing they may have come here to see. This should also help those users who rely on text-to-speech for navigating the Web, but I don’t have enough data or experience to say that with certainty.
Something I’ve been thinking about for a while is exposing my redlist. A redlist is a list of things to fix, named so because red is generally the color of errors and priority messages. Exposing the redlist online is in line with my policy of exposing my errors, in ways that both helps others learn (nobody is perfect; in an age where everything is tempered towards utter perfection, this is refreshing to learn and be mindful of) and allow me to improve (when visitors suggest ways to fixing this or that problem).
Given how much maintainance this site already takes, I’m considering publishing the redlist raw, in the same way I take care of it: a Markdown file, with idiosyncratic notation and terminology, sans any styling. Making it into its own well-formatted HTML file after every change feels like another task I’m not up to, considering it is, after all, an internal document. (Build automation might help with this when it comes.)
I’ll have to think about it.
Incremental change is an important aspect of working on the website.
Without it, whatever ideas I have for it will forever remain useless, buried beneath dozens upon dozens of boulderous tasks. One task, in itself, is feasible; together, all at once, they may seem unbearable. Working on something this difficult is neither pleasant nor desirable.
This is why I was okay with launching something that, though complete and usable, was far from the finish line. I have lots of things to add to it, big and small. Without being able to do so incrementally, step after step, I may never be able to.
There’s a distinguishable pleasure in making a big thing work, but there’s also its own pleasure it making small, often unnoticable things to work. Adding small animations here and there, inconsequential to the user at large, makes the whole experience slightly more flavorful. It’s what UX designers call "sparking joy": giving the user little details to enjoy while they work with the main thing, like flowers along the road you walk to work every day. None of the flowers on its own adds anything noticable to your experience, but together, all of them, provide the background you need for a fuller, more satisfying experience. It leaves a lasting feeling even if in the end you left unsatisfying with the problem you came to solve.
Things compound. It’s important to recognize that. Small things, good and bad, in large masses add a lot more volume, synergetically. In Web design, in keeping your home clean, in talking to people. Unnoticable, often untracable, lasting effect that guides you without you ever noticing.
Too much of anything is bad. Finding the balance is important. The first release candidate of this website had arrows on every list-like item: in the navigation menu, on the front page, on every list of every category… Far too many arrows. I added a little code complexity – a separate style declaration for navigation-bar lists – to create a lot more visual space on the page. Now, not everything screams for your attention: only the parts that, I would argue, need it. A little more work for me, a lot more pleasure for the visitor – or, a lot less noise, depending on how you look at it.
There’s still a lot of work to do for this virtual place. Some of it would require JS enabled in-browser – something that I know not everybody wants to have, what with oh so many malicious agents tracking and fingerprinting and injecting and profiling the user without their consent or notice. Most users have JS on by default, which means most users will get the features I want to present them with – like "back to last", which takes the visitor to the last page they’ve been reading, to the exact position they left the page on. Some portion of users – those with JS off – won’t even notice the features are not there. It’s called "progressive enhancement": let those who can use it use it, and fall quietly back to having none for those who can’t.
There’s a lot of small things, too. The favicon is still missing, for one thing. Or, today I added styles for inline arrows, which are distinct-enough from their block counterparts that you have to have a separate declaration for them. I’m not planning on using them any time soon, but they may well be of us, and it would be nice have it figured out and ready for use when I need them.
Building Mythos by hand is already proving to be a major pain. Writing a single entry is fine, but then I have to update all the other entries to reflect the one. There aren’t many right now, but if Mythos is to become what I want it to be, it will soon become unmaintainable by hand.
I could, of course, come up with a still-manual solution that reduces effort on my end – like only ever showing the entries of any given caterogy when the user is on that category’s "side of things", so to say – but that’s would be bullshit solution. I didn’t spend a month refining the site just to slide into complacency. This either works well or is not present online.
Such a circumstance pushes me that much harder to find or come up with a solution to automate the HTML production process. Like with any static site generator, I want the process to be dead-simple: I write the data, and an autonomous system/server agent converts it to the HTML you’d eventually see online.
The tool should one of those that enable its users, in a way that proliferates whatever it is they’re doing: in my case, maintaining and expanding a static website. There aren’t many of those around. Most tools allow you to do more without rendering the process any easier. Human brain can only reliably process so much data because judgement starts to collapse.
This raises another issue I want to shine the light on over at Mythos… but right now, it would take a lot more energy than I can afford it.
Theoretically, some of the more basic static site generators ought to do the trick. I’m not doing anything bleeding-edge or experimental with the site yet: all its contents ought to convert nicely from Markdown. Have to give it a shot: worst case scenario, I’m where I was (rather than set back), and some lessons have been learned.
These logs have proven to be a somewhat contentious among users already: not because of their contents, but because they’re outrageously long by default (this is me writing), and the pages that host them are also outrageously long as a result. Some of the early visitors suggested pagination or a similar content drawering, which I agree with.
I’ve initially modelled the logs on Indigrid’s progress reports because it was the only model that corresponded with the goal. As always, real-world usage provides the developer with feedback: models are never the items themselves.
What I’m thinking of at the moment is separating logs by the weeks to which they belong if the longs are information-intensive, like this one. (This entry, for example, would belong to "July 6—12, 2020".) Slower entries could instead be separated into monthly or yearly drawers: intensity of approach should correspond with intensity of the task.
Collapsible sections (based on the heading) is also an option, for the majority of the users who have JS enabled in their browser. I know not everyone does that, and I want as many a user to feel comfortable using this site as possible. JS-based enhancements are always meant to be progressive in this instance, in that they only apply to those who can afford them and disappear quietly and seamlessly for those who can’t.
I’m also considering hiding production logs somewhere, so that the general user needn’t be confused by them. Production logs are not meant to be general-audience-accessible: these are professional notes for those who has the expertise to understand them. They’re there to share the insight, in hopes that it may help those in a similar position. Such an insight is sorely lacking in many areas of expertise. I may not be an expert, but I am solving problems – and someone else might need this or that idea to solve the problems they are facing.
I wanted initially to hide the site’s prodlog completely, as an easter egg of sorts for others to find. It isn’t "main information" – not for general audience, who may be here for the stories or the games – so I thought it wouldn’t fit into the rest of the content. In the end, I’d decided to publish it along other pages because discoverability is a bitch sometimes, and I’d rather some users be put off by this wall of text than the users that may need it not find it.
It may be a good idea to separate "main information" from "specialist information" in the navigation sidebar visually: two spaced-apart lists where you could tell which is which based on the context of the list as a whole.
One task I can’t yet get my hands on is the favicon: the website’s icon that you see on the browser’s tab or in your browser’s history and bookmarks. It’s not necessary to have one – as is currently evident – but it feels rather barren to have my site stand out in this negative yet baseline fashion. I have an idea for what the icon ought to look like, but it may be a while until I get to making it.
Added sticky positioning for timed lists’ time detail (the date-time designator on the left). Works well on desktop, but on mobile, last items of every list are being covered by the time detail. Another one of those "doesn’t hurt, but doesn’t look good, either" issues. Not sure how to fix it yet. Perhaps keeping headings/time details sticky on mobile is not that good of an idea.
Just like I predicted in the entry from Jul 02, 2020, removing the
<label>bit me. Chromium-based browsers render
<input>-attached pseudo-elements just fine, but Firefox didn’t, which meant that users of Firefox on mobile devices couldn’t use the navigation menu. Thankfully, I found out immediately after sharing the address.
It took a while to confirm – I wasn’t sure the issue was precisely related to the checkbox that control the navigation menu – and it took its own while to add back the required elements and styles to all the pages.
Further experiments show that
overscroll-behavioris also unsupported entirely in Safari browsers, both desktop and mobile. This is the type of "unsupported" I feel at ease washing my hand of: while not ideal, it doesn’t hurt the user, and I’m in position to either implement it on the browsers’ side or mine. Safari over appears to be full of such idiosyncrasies: many a web dev I’ve spoken to give up trying to wrestle with Safari if their goal is wide support, not simply that of Apple device users.
After some consideration, I’ve reverted to using a full, complete Inter font file. It’s enormous compared to the subsetted alternatives, but at least you only have to load it once. After that, the font is cached into your browser’s memory and won’t require refreshing for a while. That’s the theory, anyway: I haven’t configured HTTP caching policy yet.
My only saving grace is that this site won’t be seen or used excessively in the beginning, which gives me time to do things well while they remain good-enough. Loading ~300kB of fonts is no pleasure, especially coming from someone who cares deeply about performance, but at this stage, this is acceptable. Won’t be so for long, but within the limits of my work ethic, I have a bit of time to tinker and fix this part.
The reason I went back to full files is because (A) tabular numbers didn’t work with my subsets, for whatever reason, (B) (and I’m astonished I didn’t notice it from the get-go) the subset fonts looked horrible. They looked like the browser’s rendering engine experienced a sudden onset of dementia and spilled pixels around. I’m sure these are solvable issues, and I’m sure I’ll be able to reduce the font file sizes without sacrificing quality – I just need to apply some effort to learning how it all works.
After that, I’ve accidentally forced myself to come up with the timed-list design that I’ve been avoiding for a few days. I’ve decided to work on updates – a feature transferred from the first version of my website that allows users to keep track of the site’s new content without having to go through every single page manually. So far, the updates themselves are entered manually – but they do reside on a dedicated page you could visit every once in a while to check out the new stuff.
Updates page’s presence forced me to figure out how a timed list – one where entries are accentuated by the dates said entries were created on – would work. Without the date-time approach, the page simply wouldn’t work. Figuring it out was not difficult at all, which says volumes of the strength of procrastination when you remember that it was for several days that I contemplated taking up the task.
(You can see the results on this very page.)
Finalized navigation design for mobile devices today. It mostly consisted of manually applying the same number of elements to all pages. This is the part that one automates sooner rather than later, or gives up doing entirely. It’s why I’m looking for a very particular suite that would let me control precisely how raw data is transformed into Web-presentable pages.
Given that my needs are specific and these sorts of software are rarely made to fit, I may well end up writing that part myself. This website is but one instance of the DIY attitude I’ve been feeling throughout most of my life: if it doesn’t exist, make it; if it does, edit it to your needs, 'cause it certainly doesn’t come fitted. My own build tool fits the bill. I have no idea how that would work, but I’ve learned things from scratch before: it’s confusing in the beginning, but soon enough it starts making sense.
And with that… The website is ready. It’s been a while since I started working on it – about a month before this log started – tending to the particular and fitting my vision of it with the capabilities of HTML / CSS stack. At times I started feeling like giving up on it, so slow was the progress, but the desire never came to be strong or meaningful: it was simply an expression of disappointment with the fact that things aren’t already as I wish them to be. It passed as soon as I realized I wasn’t making progress because I was fooling around instead of working on the parts that led to a fuller website – category and project pages, specifically – and started working on those.
It may also serve me well to remember that, while I enjoy solving problems, this website is not something of itself: it’s a vessel for information about the things I do. It’s an interface between my productivity and the world. It’s meant to serve a purpose, not lie around pretty. I wouldn’t to be confined in my efforts by the difficulty of presenting it to the world because my website is a mess to work with. It’s a good idea to engage with while doing something that is in itself rewarding.
It turned out that
overscroll-behavior– the CSS feature that dictates how scrollable elements behave relative to their parent element – does not prevent chain-scrolling if the element itself is not overflowing (i.e. if there’s enough space on the screen to fit all contents). Chain-scrolling is what occurs when you try scrolling an element, reach this element’s top or bottom, and scroll further: parent element now scrolls instead. This is confusing behavior: you apply effort to one thing and move another one instead.
overscroll-behavior: containis supposed to prevent this, but apparently no scrolling happens if the element is not overflowing. It’s difficult to blame the property: it does precisely what it advertises, which is dictate overscroll behavior, rather than control how scrolling in general is treated.
This may be an issue with my layout. If so, I’d need to rewrite a few basic things – and then hustle about fixing all the little details broken when said basics had shifted. I’d rather avoid doing this right now, but it may be a good thing to experiment over and adopt whatever positive results may come out of it.
Other than that, I’ve added pages for Tools (both the category and the specific items) and Games, and worked on refining Mythos’ classification further.
Added content to the links towards production log and the wall.
Neither is currently implemented, in as much as neither appears on the page in the way I would ultimately like. The plans are simple: make entries into organized date-separated list items. While the HTML composition ought to be equally simple, precise definitions currently escape me.
My concern is not in building a page alone: the HTML has to be accessible. This means: not only sighted users should be able to use it comfortably, but also sight-impared, and users on slow connections, and those who experience trouble with extended motion… For this particular issue, right now, the concern is with delivering straightforward, reliable information using established standards for accessibility for sight-impared users who rely on text-to-speech software to render the Web.
There are guidelines for how to do much of the Web in accessible fashion. I’m going to consult them in order to determine how to make sure I provide date-time data in a way that both lets me decorate it in a way I’d want to and doesn’t impair text-to-speech generation. I wouldn’t want someone using such software to drown in the garbage of excessive nesting and non-semantic elements because I can’t be bothered. That, and the fact that semanticity is an important aspect of information delivery for me.
Right now, both the wall and the production logs are transformed into HTML manually. Ideally, I’d have a system in place that would let me produce content and automatically have it transformed into the desired format – HTML, in this case. The less work I have to do to produce content, the easier it would be for me do so – and anxiety is a big detriment to productivity if allowed to fester. Content itself takes priority, but I’d like to eventually figure out a way to automate the rendering process for the base HTML – with templating and custom markup – so that all I had to do is write thing I want to see in, say, Markdown, and press a button to see it online.
Other than that, I was able to reduce the navigation menu folding’s code by a bit. It turned out you can assign pseudo-elements to the
<input>element directly, without having to have
<label>accompany it and carry the burden of interactability. This may bite me down the line, as these things have in the past: it may very well turn out that, while the latest browsers support this arrangement very well, slightly-older ones struggle and cough up the results as an unnavigable mess. We’ll have to see.
My aim is to support the modern generation of browsers. I’ve already gone this far by using flexbox and CSS variables. Neither of those two requires extensive support, but it does mean that some of the outdated browsers – what few are still in use – may experience the website quite a bit worse.
Started working on Mythos today. I was postponing the implementation for a long time because I felt like I didn’t have a good structure for it. A couple of days ago, however, I stumbled upon Johnny.Decimal from within the depth of my "sort out later" bookmarks, and it’s proven to be what I needed to make Mythos work as a structured document. I’m going to make a few changes, but by and large, it’s a good framework for structuring my thoughts. Now, instead of linking with slugs that may change over time, I could link to a path in the hierarchy of ideas.
The concern here is that the structure has to be set early on, otherwise the reliability is lost. The beauty of Johnny.Decimal, however, is that it affords the user a certain leeway of extensibility across time. Worst case scenario, I can "escape" into the hexidecimal territory, but I don’t think this will ever happen. Like J.D documentation says, it probably means I’ve made the categorisation too broad.
Minor editing. A bit of a clean-up, UI-wise.
Making sure the virtual space – the excessive scrollable space beneath the content – calculates correctly takes a surprising lot of maintainance during development. I’m sure it will behave by the time of release. Right now I’m adding different new structures to the content to make sure it could accomodate project descriptions the way I see them, nevermind all the adjustments for existing details, and that – naturally – breaks the flow of things here and there.
The latest example of virtual space calculations breaking is comments for items on the list. All the development around lists led me to believe that the only comments that should have margins at the bottom – to space list items themselves nicely – are the last comments for items that are themselves not the last in their list. Properly setting this in terms of CSS, however, has proven a bit of a challenge. Nothing to throw me off completely, but not something I’d figured out immediately, either.
I’ve also come to realize today, after browsing the previous iteration of the website, that I’d like to have updates separate from the website’s production log. Where the log is to show the thought process behind solving some of the issues during design process, updates would allow users new and regular to know what’s changed in terms of content.
If there’s a new project or a new feature, it’s going to go into the updates. If I have something new to say about the design of the website – elaborate on the new feature, perhaps – it goes here.
Another thing I’m looking to implement is the various descriptions and interlinks for each project, tucked into their own pages. Project pages are meant to quickly familiarize the viewer with what the project is about, but it’s not unlikely that, after reading the description, they could be looking for more – and boy, do I have more to say. Things like extended feature description, design paradigms (similar to Indigrid’s design philosophy), FAQs…
At this stage, however, I find that I’m postponing the launch of the site with features that could comfortably be added later, at the expense of nothing. Any of it could be implemented once the basic information is available on the site.
Made additional optimizations to the Inter subsetting. The original Inter files are over 100kB each, which usually translates to long loading times; not long enough that it would delay the page on desktops with decent connection, but long enough that user would see the fallback font flash, which can be a little jarring.
What I realized today was that reducing the main font file to all of the subset symbols combined (all the Latin letters and numbers and all the extra punctuation) still provides files of acceptable size, between 20kB and 25kB. I wanted to find out the final size because the font flash still occurred with secondary subset fonts, such is when entering the Contact page which contains an
@symbol. Loading a single foundational font file, with all the common and uncommon (but not rare) characters included, still causes a delay, but not nearly as significant as previously.
This does, of course, mean that I’m going to update the font (or load a separate one) for non-Latin scripts, as well as for some parts of Latin script that I didn’t include.
I’ve also tried a different way of rendering the arrow decorations.
Previously, shortly before the log started, I’d already tried to move to relative-only positioning for the arrow pseudo-elements. While it could’ve been fine-tuned to work as currently, it would make for a system that’s far too brittle and requires too many calculations compared to the current setup.
The reason I wanted to work on it was because of the fact that it seemed a little excessive to me to have that one CSS declaration for
.arrowelements which only states one thing:
position: relative. Not a bad thing in itself, but it does feel as if it doesn’t have enough of a weight to exist in the code; like it could be done better.
This time, I tried using floats as an alternative to current absolute positioning, in two different ways.
Initially I tried to accomplish the same result using floats only, discarding non-static positioning completely. It worked just fine for "after" arrows (the ones that succeed the text they’re attached to), but moved contents of "before" arrows-containing elements (such as the one front-page paragraph) too much without really giving me the capacity to adjust its spacing.
The only problem there, really, was the fact that I couldn’t adjust its padding in a way that would let me overlap the arrow’s effective cursor area (the area that would still activate the hover effect, even though it’s ostensibly empty space with no content) with the container’s content. Overlapping the padding would mean you can hover over the area you would expect to be active (such as the space between the arrow and the content once the arrow does move) without experiencing the hover flicker. Hover flicker is when you hover over an element and it moves in such a way that it no longer registers the hovering (such as when the element is no longer under the cursor), so it tries to move back, then registers the hover again… ad infinitum.
(Now that I think of it, I could’ve fixed it by extending the padding. While it does appear to be a sound solution on paper, in reality the related CSS would have to be extended by something like a third to accomodate for this behavior.)
The second solution – something I’ve only considered as I wrote these words – was to combine floats and relative positioning. This worked surprisingly well: with a little adjustment I could make it work site-wide and get rid of the excessive one-liner declaration.
The problem with that approach turned out to be in the way I handle diagonal arrows.
The travel distance for all arrows is relative to their static offset, the latter being what determines how far arrows stand away from their associated content. The distance adjustment is done with an independent factor by which the offset is multiplied to produce travel distance. For diagonal arrows – which move in two directions – two "separate" movements combined appear excessive, even though they’re computationally correct (i.e. adhere to the values exactly). As such, they’re given a lower adjustment factor, which results in less overall movement to the point where diagonal movement appears roughly equivalent to orthogonal.
Long story short, these reduced values are stored in variables of their own, and I need to use them for proper float-plus-relative positioning. Given that these variables are further modified by the reduced factor on diagonal arrows, the overall result is a sudden jump in diagonal arrows’ distance from content. This cannot be fixed without rewriting the rather complex system of computations arrows use.
That said, if I ever do solve it, it may well be a viable solution to the "excessive declaration" problem. It adds more lines to the code, but my neat-freak mind makes it appear justified. The way I’m currently doing it – with absolute positioning – is clearly simpler and more effective, and I can live with that one line of CSS standing out. Perhaps I can come up with a system more refined than this, and reduce the necessary code even further, which would be the better solution still.
One other thing I did today was streamline some of the content block styles. The idea initially was to use blocks – based on HTML5 sectioning elements, such as
<footer>, among others – partially for semanticity’s sake, and partially in hopes of eventually coming up with a way to automatically generate a table of contents for any given page or a project. (That’s the idea behind sectioning elements to begin with. Their aim, as described in the HTML5 reference, is generic for all documents: blog posts, news articles, content aggregators… My goal is to latch off the generic structure and be able to produce anchors and reference points that are specific to my website’s structure.)
An unexpected obstacle presented itself in the form of browser defaults. Chromium-based browsers, for example, significantly reduce the size of heading elements (
<h6>) within sectioning elements. This is surmountable, but is an unexpected hinderance all the same.
For now, I’ve reduced the sectioning elements’ styling to any element following a
<header>, any two
<footer>when following any other element. The styling itself remains about spacing. Whether these will be extended into something more meaningful remains to be seen.
Most work for the website proper is done.
Added the Writing category page, thus setting an example for how category pages ought to go.
In my head, I envisioned something closer to a no-arrow list of plain project descriptions (title, status, and a short comment on what it is). Didn’t work out that way because (A) there’s already a pattern for how pages ought to go (short first line, then the rest of it), (B) the regular arrowed list style worked out fine.
Point (B) is important because it feels valuable to keep the stylesheet small and abstain from introducing specific classes unless work becomes more difficult otherwise. Introducing classes breaks that little requirement I have for how the HTML should look like. For this project – the website itself – it’s supposed to be minimal and streamlines: the fewer additional attributes – more than is required for the markup to work – the better.
Adding classes doesn’t just mean adding and editing the CSS, or making sure the class is assigned properly, and supporting it down the line: it also means extending the HTML a little with something that needn’t be there. It’s a minor concern, but one I feel is worth addressing in this instance: it is, after all, my website – a reflection of myself, to a degree.
Still some things to tweak – like separating major projects from minor ones (e.g. episodic ones from short stories) – which sounds like it would, in fact, warrant at least one separate class.
I’d considered using
<ol>for a secondary list element, in vain hopes that it could eliminate the need for
<ul>classes, but this creates more problems than it solves, from the perspective of semanticity and longevity. There’s also the
<menu>, which currently renders as an unordered list in most browsers, but it appears as though its purpose is distinct enough to avoid for rendering lists alone.
Some lists appear to need the arrowed layout, while others may be better off without it: like the navigation sidebar project lists, where each element under the category is an item on an "invisible" list. Currently the consideration put forth for where to display arrows for list items is whether the list is in the content section (
<main>) of the page. Using a separate class for an arrowed list may add versatility, but also increase complexity – a lot for me as a developer, but also a little for viewers. It may create a degree of confusion I’d rather avoid.
In other news, I’ve updated the included Inter font towards subsets, where each subset is a small portion of symbols (common Latin letters, exotic Latin letters, punctuation). Each subset now loads only when the page contains the symbols: e.g. the "symbols" subset for punctuation only loads when non-common non-letters (like
@) are on the page. The goal is to reduce the delay between entering the page and seeing it typeset in Inter (as opposed to fallback fonts).