Uniwidth Typefaces for Interface Design
uxdesign.cc
uxdesign.cc
I'm not into web design but I think the core problem here is lack of accepted terminology and even awareness that this type of font is a thing.
The article certainly brings awareness to something I didn't know is a thing but seems very useful.
My mind wants to say "weight invariant" or "style invariant" but those suggest the thing doesnt look any different rather than just the size not changing with other characteristics.
It's probably obvious that I don't like "uniwidth", but at the moment I can't think of anything better that isn't super wordy, like "font with style invariant width".
It seems useful to name the property where character widths are consistent along their weight axis, but another case in point to support the sibling comment: I see only one other significant use of "uniwidth"[1], from 2015.
I also find "uniwidth" a poor and confusing name for this property, and "duplexed" and "multiplexed" even worse.
If I had to suggest a better alternative, I think something like "width-invariant" or "width-invariant proportional" would be clearer.
[1] https://www.fontshop.com/people/david-sudweeks/fontlists/uni...
Edit: Like most font terminology, I think it has historical roots predating digital type, and refers to the way styles or weights might sit above one another on the matrices.
The most 'correct' version would be 'font with weight-invariant width', but that's a bit long.
But these uniwidth fonts can have Sans and Mono variants like Recursive[0], so methinks these could've been just called what they are: "no-reflow" fonts? lol
Also, nominally monospace fonts often end up having character-dependant width anyway (ranging from blatant bugs like substiting fallback characters without forcing them to the correct size, to completely legitimate-ish variations like CJK ideographs with integer multiples of the normal character width). So, I'd still say tabular numerals are more like a weaker form of monospace than a stronger form of uniwidth - constant width across styles may or may not be relevant, but if it is, it's table stakes (no pun intended).
> also called non-proportional font, is a font whose letters and characters each occupy the same amount of horizontal space
instead, it preserves the width if you apply a weight like BOLD:
> Uniwidth typefaces, on the other hand, are proportionally-spaced typefaces, but every character occupies the same space across different cuts or weights.
This allows visual cues other than color in interactive text such as the :hover CSS pseudo-class.
"Uniwidth typefaces preserve the width across different weights ( Bold, etc. ) although each letter may not necessarily be the same width."
I feel like the above short summary should have been more easily visible in the article. From skimming the article I couldn't figure out exactly what Uniwidth typefaces were.
It’s especially important in data tables when coupled with tabular numbers (essentially mono spaced numbers) so you can e.g. bold a cell without having the thousands or decimal separators get out of alignment in a column of numbers. Spreadsheet programs use fonts with this property.
It's not really something special spreadsheet programs do or select for. It's just how basically all workhouse body typefaces operate, like Helvetica or Times New Roman or Calibri, precisely for the reason you list.
Which is why when IKEA chose it as their main branding font (in their print catalog, no less!) to replace Futura, there was such an outrage among graphic designers, as it was such a terrible choice. (IKEA no longer uses Verdana anymore though.)
First, with internationalization, your carefully selected label widths will be destroyed anyways. Because translated strings frequently take up more space, you should always be designing your interfaces with plenty of extra room/flexibility anyways.
And second, with the idea of bolding on hover -- that's really not a great UI pattern to begin with.
From a fundamental design point, bolder strokes require more separation between them, which is why fonts are generally slightly wider as they go bolder. These "uniwidth" typefaces just look uncomfortably squeezed. It's aesthetically not a great solution.
Rather than bold-on-hover, better hover effects include lightening/darkening, underlining, outlining, highlighting, inverting, etc. But if for some reason you're absolutely determined to bold on hover, then just use some layout magic to accomodate expanding the width of the label (likely centered rather than left-aligned, if in a horizontal list) without disturbing items around it.
I will note, however, that fonts often ensure their numerals and certain punctuation remain the same width -- Times New Roman's letters change width if bolded, but its numerals do not -- as it's common to have certain rows in a financial report be bold, and you don't want the numerals to be misaligned with non-bold lines. So numeric tabular data seems like the main use case here, really, which fonts already help take care of. (If you have lots of tabular data with letters and need bold, then you should just be using a monospaced font.)
You are also slamming hard the idea that this would ever be interesting, and yet almost every single communication app I've ever used has chosen to use bold to mean "unread", and it definitely makes sense that if you click on something to read it it shouldn't pop or cause a layout change.
- https://practicaltypography.com/concourse.html
- https://practicaltypography.com/century-supra.html
- https://practicaltypography.com/valkyrie.html
No UI fonts, but could still be useful for links within web design.
> Duplexing. In type, duplexing means matching the widths between styles so that each character occupies the same space on the page. This way, you can easily change the weight and style without affecting your layout. In Concourse, weights 2, 3, 4, and 6 are duplexed to each other. (For this reason, the three lighter weights all use weight 6 as their bold style by default.) Every italic is also duplexed to its roman, including weights 7 and 8.
So yeah, all normal use is duplexed, but it has a couple of extra-bold weights that don’t fit that way.
This also draws attention to the other area you may want to think about this with: italics. Definitely depends on the style; broadly speaking, serifs won’t want to duplex their italics (they’ll most commonly be narrower), but sans-serifs might.
But, I agree with the author - it's a great concept to be emphasized especially for tabular displays! Does it work for other languages, e.g. Indian languages with complex ligatures? Also, the following is a major pain point in the correct display of Indian languages:
The aspect of bolding in normal fonts makes them easier to see, and increases the spacing to accommodate, but nearly every uniwidth bold font fundamentally changes the font to shift them to a new font that is marginally based on the non-bold.
I'm not saying I entirely dislike them, or that there aren't good uniwidth fonts out there, but it's just that in almost all cases the difference in the same font set is fundamentally different.
gnulib/libunistring has the uniwidth API for ages. It computes the display width of a unicode grapheme cluster, a glyph. https://www.gnu.org/software/libunistring/manual/html_node/u...
This is helpful for UI elements that need to become bold when selected.
Give up on pixel-perfect design or give up on i18n. You cannot have both (or rather you cannot afford a redesign for each new translation).
> While this feature allows for some creative layering in static typesetting, it is decidedly spectacular for interface design, where things tend to quickly go awry with only small changes. As an example, changing the weight of a single menu item on hover usually results in an erratic twitching dance of the whole menu as it tries to adjust for the change.
> this feature is nothing but a nice gimmick in static typesetting,
The point is that when the font attributes change dynamically when using the interface; like hovering over a button makes the text bold. If that dynamic during-interaction change changes the size, it might make everything else move around too, which would be bad.
The problem being addressed isn't so much being able to get the page to look just so, but being able to make it not jitter around while you interact with it.
Here's the animation from the article that I'd use to get the point across (top is a non-uniwidth font, bottom is a uniwidth font): https://miro.medium.com/max/1400/1*eUu31P1t6Ez6xwD56BQJaw.gi...
https://jsfiddle.net/7ysgdpf2/
Failed for Arabic, Sanskrit, Telugu. I'm only guessing those languages are not easily writable with fixed size units
Your jsfiddle also fails even for English in most browsers, because you didn't load both regular and bold weights of Recursive. As a result, you get a browser-generated synthetic bold effect, which varies between browsers and in most cases (but not Chrome, IIRC) will alter the width.
(To fix that aspect, you need something like "family=Recursive:wght@400;700" in your Google Fonts link.)
https://pasteboard.co/JM3MBN4.png
For it to have worked each pair of lines should be the same width. They are not. Tested on MacOS 11.1 Safari, Firefox, Chrome and Windows 10, Firefox, Chrome. All failed.
(I try to avoid cheap low-brow dismissals here, I know it's lame, but the word "kern" isn't on the page, nor in these comments as I write this, so somebody was going to say it first, and today I guess it had to be me.)
Seriously though, it seems to me like your thin text is too far apart and the thick text too close, no?
Sometimes, if a design idea turns out to cause problems, maybe it's time to reconsider the design.
As mentioned in the article, accessibility for the color blind. Which are a sizeable percentage of the population.
Color should always only be one of at least two differentiators.
It's perfectly possible for a colour change to be accessible for the colour blind, if you do more than just modify the hue. (Extreme case: change white-on-black to black-on-white. Or more generally, swapping foreground and background colours would usually be adequate, unless there's a serious lack of contrast in the first place.)
Or add an underline, or a border around the element. Point is, there are safer options than font-weight; changing weight is pretty fragile unless you tightly control other aspects of the design/content.
Monospaced is important if you want multiple sequences of the same length to line up, uniwidth is less restrictive of the font (because "l" and "w" can be different widths) but allows you to bold without changing the visual length.
> Uniwidth typefaces, on the other hand, are proportionally-spaced typefaces, but every character occupies the same space across different cuts or weights.