--- title: "Way to Minimalism, Part 1: Meta Bar" date: 2026-04-26 excerpt: A blog minimalism experiment starting from the article meta bar, tucking fonts, line height, post info, and comments into lighter UI for a quieter page. tags: - UIUX updated: 2026-07-08 21:25:47 lang: en i18n: cn: /way_to_minimalism_part_1 translation: 2 --- While tweaking my blog's styles recently, I kept making changes and undoing them, especially the font family and size. Body text and headings bounced back and forth between serif and sans-serif, and I even tried out monospace and handwriting fonts, the kind I'd never use long-term but that look nice once in a while. All these experiments pointed to the same problem: reading settings need an entry point, but that entry point must not disturb reading itself. Without a UI, adjusting these settings means editing CSS variables by hand. On a PC that's barely workable, just tedious; on a phone, there's essentially no way to adjust things on the spot. So an interactive entry point is needed. But simply spreading the options across the page would easily break the quiet feel of reading. So this round of changes started from the article meta bar, the ==Meta Bar==. Meta is short for metadata, the information that surrounds the article but isn't part of the body itself, such as publish date, tags, author, license, and reading time. The Meta Bar here refers to the strip below the title on a post page: it originally just showed tags, and now it also houses lightweight interactive UI for fonts, line height, post info, and the comments entry. --- How this started: one evening a friend and I were waiting for barbecue, the shop's equipment kept breaking down, and in the end we never got to eat. The wait wasn't wasted, though. A few days earlier, while refactoring the Post metadata component, I had noticed a blank area just to the right of the Tags, and it suddenly occurred to me: maybe those reading settings could be tucked in there. So I decided to add some interactive settings to the frontend, so that adjustments like font family, size, weight, and line height wouldn't have to be exposed in the main body of the page. I could also add an info icon that shows post information on click. That way the licensing component at the end of each article could be removed too, making the layout look cleaner. I had GPT generate Blueprints for mobile and PC, one after the other. The PC blueprint was slow to generate, stuck in a queue. By the time I got back to the dorm after 11, I had forgotten about it. Looking at it now, the Popover component the blueprint uses really is a better fit: it doesn't interrupt reading the way a Modal does, and it better matches the goal of "tucking the options away." --- As mentioned above, at first I only had GLM design against the mobile blueprint and hacked together a version that "at least works." For now, both PC and mobile still use a *Modal Dialog Component*. There's still plenty to polish: unifying the design style, performance optimization, line-height settings, adapting the various components, interaction details, and keyboard shortcuts. Once it's polished, the [ABOUT](about.md) page will need an introduction too. But the about page shouldn't get too long, so maybe later I'll write a separate post covering all the keyboard shortcuts and hidden interactions on this blog. It's 03:56 AM now, too late, I'll deal with it later. Or the day after tomorrow; tomorrow there's definitely no time. ## Timeline - [x] 2026-04-26: Adapted the text-image component, switched to new SVG Icons - [x] 2026-04-26: Refactored to use CSS Variables instead of dynamically inlining styles on elements - [x] 2026-04-27: Had AI add support for setting `font-weight` and `line-height` - [x] 2026-04-27: Had Codex hide the comments component by default too, popping up a Popover Component when the Message Icon is clicked ## Interlude Chrome's DevTools can preview how a page feels on a phone, but it's not entirely accurate. So when my computer and phone are on the same LAN, I usually just visit the server running on the PC from my phone. Done manually, that means running `ipconfig` to find the computer's IP address, then typing the address and port into the phone's browser. To simplify the flow, I wrote a Nushell function. Typing `i` prints the address; typing `i 4000` prints the string with the port number appended. ```nu def i [port?: int] { let ip = ipconfig getifaddr en0 if $port == null { $ip } else { $"($ip):($port)" } } ``` In action: ```sh $ i 210.41.101.202 $ i 4000 210.41.101.202:4000 # Redirect to the clipboard; clip is another custom function of mine, on macOS pbcopy works instead $ i 4000 | clip ``` This little function has little to do with the Meta Bar itself, but it comes from the same impulse: fold away the repetitive operations and keep what actually matters up front. ## Appendix ### May.4 Lately I've been trying out all kinds of Web Fonts again. Importing them all directly would be the easiest, but it would also slow down loading, and many of them are just personal preferences. The blog doesn't get much traffic right now, so probably no one will seriously judge whether it's bloated. Still, I'd rather make these fonts an optional feature: don't load them by default, only bring them in when the user actively chooses one. The starting point for this feature is a habit left over from my earlier performance work: prefer local fonts. The problem is that Android devices offer very few local fonts, and many effects simply can't be achieved with system fonts alone, so in the end some Web Fonts still have to be brought in.