This! That was, IMO, a golden era for UI design. We've lost SOO much to the wild west experimentation brought on by the advent of touch interfaces. A really strong shared design language across apps and vendors is an unbelievably valuable productivity enhancer that lets people apply the intuition they've learned in one app to a UI in a different app that they've never seen before. When everyone tries to make their app look and feel and operate with uniqueness and visual distinction, much is lost.
Consistency in the interface allows users to transfer their knowledge and skills from one application to another. Use the standard elements of the Aqua interface to ensure consistency within your application and to benefit from consistency across applications. Ask yourself the following questions when thinking about consistency in your product:
- Is it consistent with Mac OS X standards? For example, does the application use the reserved and recommended keyboard equivalents (see "Keyboard Shortcuts Quick Reference" (page 309)) for their correct purposes? Is it Aqua-compliant? Does it use the solutions to standard tasks Mac OS X provides? (For more information on these solutions, see "Using Mac OS X Technologies" (page 61).)
- Is it consistent within itself? Does it use consistent terminology for labels and features? Do icons mean the same thing every time they are used? Are concepts presented in similar ways across all modules? Are similar controls and other user interface elements located in similar places in windows and dialogs?
- Is it consistent with earlier versions of the product? Have the terms and meanings remained the same between releases? Are the fundamental concepts essentially unchanged?
- Is it consistent with people’s expectations? Does it meet the needs of the user without extraneous features? Does it conform to the user’s mental model? (For more information on this concept, see "Reflect the User’s Mental Model" (page 40).)
Meeting everyone’s expectations is the most difficult kind of consistency to achieve, especially if your product is likely to be used by an audience with a wide range of expertise. You can address this problem by carefully weighing the consistency issues in the context of your target audience and their needs. See "Know Your Audience " (page 25) for more information on how to define your audience
You were filtering the sidebar for "consistency", that's not a search box.
From 2026 HIG:
> Create a list of common terms, and reference that list to keep your language consistent. Consistent language, along with a voice that reflects your app’s values, helps everything feel more cohesive.
> Build language patterns. Consistency builds familiarity, helping your app feel cohesive, intuitive, and thoughtfully designed. It also makes writing for your app easier, as you can return to these patterns again and again.
Oh you're right, well in that case I'd like to complain about turning the big PDF into a linked web document and not giving it an obvious whole-HIG search box. Worse experience than cmd-F 20 years ago.
What's "sad" is how slow the ollama folks are being in vendoring newer versions of ggml into their codebase. That attitude just leaves them stranded without access to newer features.
Honestly, you need a tailored one of these for each of the major LLM model/version pairs. Claude and Gemini don't exhibit all of the same tropes in the same severities as OpenAI's GPT series, and within each of those, each revision sometimes exhibits substantial variance from the stylistic propensities of its immediate predecessor.
I love it conceptually, but I can't get past the abject failure of the right edges of boxes to be properly aligned. Because of a mishmash of non-fixed-width characters (emoji, etc.), each line has a slightly different length and the right edges of boxes are a jagged mess and I can't see anything else until that's cleaned up.
Emojis mixed with ASCII-era characters are hard to get right. Some terminal emulators get it right nearly all the time (e.g. Ghostty, which has had a lot of thought and effort put into getting it right) and yet there are still open issues in the Ghostty repo about inconsistent character width. There are just so many corner cases that it's hard.
That said, the edge alignment is, I believe, caused by the fact that LLMs are involved in the process. Because the LLMs never "see" the final visual representation that humans see. Their "view" of the world is text-based, and in the text file, those columns line up because they have the same number of UTF-8 codepoints in the row. So the LLMs do not realize that the right edges are misaligned visually. (And since the workflow described is for an LLM to take that text file as input and produce an output in React/Vue/Svelte/whatever, the visual alignment of the text file needs to stay LLM-oriented for it to work properly. I assume, of course, since I haven't tried this myself).
They are treated like double width characters. All it takes is a Unicode aware layout algorithm that tracks double width codepoints. The tricky part is older single width symbols that were originally not emoji and now have ambiguous width depending on the terminal environment's default presentation mode.
That's how it should work, and does in terminals that are doing it right. Browsers, however, are looking at the monospaced font and saying "Okay, Source Code Pro doesn't have the U+2192 codepoint," (the → arrow) "so let me find a font that does." On my Linux+Firefox setup, the browser chose Menlo to render the → in the "The fastest way to go from 0 → 1" banner. Menlo's width isn't quite identical to Source Code Pro, so the ┃ character on the right of the box was every so slightly misaligned. Because Firefox isn't following strict fixed-width layout rules, and is allowing itself to use other fonts with different horizontal widths even inside a <pre> block. (I haven't looked at this article in other browsers but I bet they're the same since everyone's mentioning misalignment.)
The other tricky part is emojis made up of multiple codepoints with zero-width joiner characters and variation selectors, or other symbols. E.g. is made up of U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S, or (which should render as a single symbol, a burning heart / heart on fire), which is made up of the four-codepoint sequence U+2764 HEAVY BLACK HEART, U+FE0F VARIATION SELECTOR-16, U+200D ZERO WIDTH JOINER, and U+1F525 FIRE but should only render in one double-width block. Then there are even more complicated sequences like , which again should render in a single block but are made up of six(!) codepoints: U+1F469 WOMAN, U+200D ZERO WIDTH JOINER, U+2764 HEAVY BLACK HEART, U+FE0F VARIATION SELECTOR-16, U+200D ZERO WIDTH JOINER, and U+1F468 MAN.
The number of codepoints never did correspond exactly to the number of fixed-width blocks a character should take up (U+00E9 é is the same as U+0065 e plus U+0301 COMBINING ACUTE ACCENT, so it should be rendered in a single block but it might be one or two codepoints depending on whether the text was composed or decomposed before reaching the rendering engine). But with emojis in play, the number of possibilities jumps dramatically, and it's no longer sufficient to just count base characters and ignore diacritics: you have to actually compute the renderings (or pre-calculate them in a good lookup table, which IIRC is what Ghostty does) of all those valid emoji combinations.
P.S. The Hacker News comments stripped out those emojis; fair enough. They were, in order:
- a US flag emoji (made up of two codepoints)
- a heart-on-fire symbol (two distinct symbols combined into a single image, made up of four codepoints total)
- a woman and a man with a heart between them (three distinct symbols combined into a single image, made up of six codepoints total)
For me, the best kind of "moat" (tbh I hate that word, since it specifically implies needing to design (...scheme...) and engineer some kind of user lock-in, which is inherently user-hostile) would be staying aggressively on the forefront of DX. More important than feature churn, making it polished and seamless and keeping a smile on my face as I work is the best kind of "moat."
It requires constant attention and vigilance, but that's better for everyone than having some kind of "moat" that lets them start coasting or worse— lets them start diverting focus to features that are relevant for their enterprise sales team but not for developers using the software.
Companies really should have to stay competitive on features and developer happiness. A moat by definition is anti-competitive.
