[HN Gopher] Uniwidth Typefaces for Interface Design
___________________________________________________________________
Uniwidth Typefaces for Interface Design
Author : fanf2
Score : 257 points
Date : 2021-01-29 12:43 UTC (1 days ago)
(HTM) web link (uxdesign.cc)
(TXT) w3m dump (uxdesign.cc)
| alexchamberlain wrote:
| Isn't supporting multiple languages, which have different numbers
| of characters a bigger issue?
| corty wrote:
| While this might be useful in certain cases, don't get your hopes
| up: i18n will break your carefully laid out equal width layout.
| E.g. many german terms will be longer than the english
| equivalent, causing all the same problems, just even more
| annoying because you as an english-speaking developer won't
| notice until it hits your foreign users.
|
| 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).
| LukeShu wrote:
| I think you're missing the point. i18n is just a change in the
| static content, which is mentioned in the article, but is
| pretty quickly dismissed:
|
| _> 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...
| asiachick wrote:
| I think you missed the point of the OP? Let's try it
|
| https://jsfiddle.net/7ysgdpf2/
|
| Failed for Arabic, Sanskrit, Telugu. I'm only guessing those
| languages are not easily writable with fixed size units
| leephillips wrote:
| The jsfiddle shows it working perfectly in my browser.
| asiachick wrote:
| This is what I see
|
| 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.
| leephillips wrote:
| Interesting. It renders in a width-invariant way on my
| machine (chromium on Ubuntu).
| FreeFull wrote:
| In this case, the problem is that the Recursive font
| doesn't actually contain the Arabic and Japanese
| characters, so the browser is falling back to another font.
| If you use a uniwidth font that actually contains all the
| characters, this should work.
| jfk13 wrote:
| Whether it'll work or not for the various non-Latin scripts
| will depend what fallback fonts the browser happens to
| pick, so people's results will vary.
|
| 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.)
| kevincox wrote:
| This is true for static layouts. However I think the compelling
| use case is when the font weight changes dynamically such as on
| hover or focus. In this case it can be useful to avoid having
| the layout shift (especially on hover where the shift risks
| moving the hover target and creating an unwinnable game of cat
| and mouse).
| IggleSniggle wrote:
| It becomes _even more important_ for i18n. When you've worked
| out your maximum character width for each element across all
| languages you support, every pixel counts. Knowing that
| applying _bold_ is not going to cause a reflow in one of the
| languages you're not currently working with is a huge boon.
| sradman wrote:
| This is not a monospaced font used for code:
|
| > 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.
| Naac wrote:
| "Monospace typefaces give each letter the same width"
|
| "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.
| dandelany wrote:
| It's literally the 3rd and 4th paragraphs, in bold, with
| examples.
| [deleted]
| PostThisTooFast wrote:
| Whatever font you use, don't use one without crossbars on the
| capital I. That's not an I; it's a lower-case L.
| nicolaskruchten wrote:
| Ahh, very satisfying to learn the name of this property.
|
| 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.
| jack_jennings wrote:
| Also called Lining Figures, this property is a lot more common
| than "duplexed" alphabetical glyphs -- even if they are not the
| default, most text fonts now support them as an opentype
| feature.
| nicolaskruchten wrote:
| My understanding is that the term "lining" refers to numbers
| with the same height, (which is also common and appreciated
| in data tables!) and that "tabular" refers to numbers with
| the same width, so not quite the same thing:
| https://creativepro.com/typetalk-know-your-figures/
| jack_jennings wrote:
| Yep, you're right. My mistake.
| crazygringo wrote:
| Fonts in general usually keep their numerals and certain
| punctuation characteres all of equal width, and of equal width
| between regular and bold (even when their letters get wider in
| bold).
|
| 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.
| JulianMorrison wrote:
| This seems like it might be useful for people who are doing DTP
| type work and don't want their entire document to reflow itself
| because they changed the font weight of one word.
| sn41 wrote:
| I started reading thinking that uniwidth is the new politically-
| correct term for monospace :)
|
| 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:
|
| https://en.wikipedia.org/wiki/Zero-width_joiner
| [deleted]
| carapace wrote:
| So... automatic bad kerning?
|
| (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?
| leephillips wrote:
| Of course. This is an obvious tradeoff. For just this reason, I
| don't think these typefaces are ideal for regular text, but can
| be an improvement for labels, buttons, numbers in tables, etc.
| jfk13 wrote:
| Alternatively, choose UI design ideas that don't involve
| changing the font weight on hover. What's wrong with changing
| the colour and/or background instead? Or (for an element like
| a button) give the element a fixed width that is sufficient
| for either weight of the text.
|
| Sometimes, if a design idea turns out to cause problems,
| maybe it's time to reconsider the design.
| carlmr wrote:
| >What's wrong with changing the colour and/or background
| instead?
|
| 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.
| jfk13 wrote:
| This is a pretty weak justification for what seems like
| it'd usually be a design gimmick.
|
| 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.
| hkai wrote:
| As a hack, if you can't use a uniwidth font, you can simulate
| bold font by having a `text-shadow` of the same color offset 1px
| to the right.
|
| This is helpful for UI elements that need to become bold when
| selected.
| john-doe wrote:
| But then it's a faux bold, and it's a no-no in typography.
| Her's a better technique: https://css-tricks.com/bold-on-hover-
| without-the-layout-shif...
| hexo wrote:
| Uniwidth is the new monospace? Or?
| corytheboyd wrote:
| The distinction is made very early in the article:
|
| > Uniwidth typefaces, on the other hand, are proportionally-
| spaced typefaces, but every character occupies the same space
| across different cuts or weights.
| Veen wrote:
| No, as the article explains at length. In monospace fonts every
| character occupies the same line space. In uniwidth fonts, the
| characters occupy the same space across different weights, e.g.
| a bold "w" occupies the same space as a regular "w", but they
| may differ in width from each other.
| pgtan wrote:
| Good crafted monospaced (especially so called office-) fonts
| do not differ. There is no need for the term "uniwidth" at
| all.
| LukeShu wrote:
| Sure there is, it's a different thing. Many monospaced
| fonts are also uniwidth, sure. The article is promoting
| fonts that are non-monospace but _are_ uniwidth. It would
| be wrong to apply the term "monospace" to these fonts, so
| a second term certainly is needed.
| kevincox wrote:
| All (good) monospaced fonts are uniwidth, not all uniwidth
| fonts are monospaced.
|
| 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.
| cat199 wrote:
| except that uniwidth describes a different thing?
| Veen wrote:
| You have misunderstood the important difference between
| uniwidth fonts and monospaced fonts. Uniwidth fonts are
| proportionally spaced; monospaced fonts are not (by
| definition).
| dgellow wrote:
| It's a different property
| crazygringo wrote:
| Conceptually, this is certainly intriguing. Unfortunately, I
| don't see it as being of much practical use for two reasons.
|
| 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, 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.)
| phkahler wrote:
| >> The solution to this problem: "uniwidth" typefaces, sometimes
| also called "equal-width", "duplexed" or "multiplexed" typefaces.
| And no, I am not talking about monospaced fonts here.
|
| 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".
| jack_jennings wrote:
| Somewhat interestingly, there is a great deal of inconsistency
| in naming in the type design world -- both in marketing
| features like this, but also down to terminology for specific
| parts of letters. I agree that it would be very useful, but for
| whatever reason it never seems forthcoming. My assumption has
| always been that type design is a fairly distributed discipline
| (at least amongst latin-alphabet-using countries), but remains
| niche, so there's more or less only regional terminology
| without much consistency. (This is purely observational, so
| take from this what you will)
| CharlesW wrote:
| > _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._
|
| 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...
| Rumudiez wrote:
| Fonts designed in this manner have been around for awhile, so
| it's not really a new concept, except in its application to
| every glyph in a type family. The term I've used with type and
| other designers is actually "tabular," which contrasts with
| "proportional." Look up tabular vs proportional numerals for a
| topic that's been around since printing presses ruled
| publishing.
| a1369209993 wrote:
| Tabular numerals are actually more like monospace than
| uniwidth[-as-defined-here]; it's a font where all characters
| have the same width... _as long as_ those characters are
| numerals. Variations like "weight-tabular" or "numerically-
| tabular" might work, although it's less obvious which
| properties "tabular" is holding constant (namely width;
| technically also height but noone varies that anyway).
| GreedCtrl wrote:
| Case in point: one of the fonts mentioned, recursive, has been
| on HN before (with 108 comments), but I only found one comment
| that explicitly talks about this property, and it doesn't do so
| by name. https://news.ycombinator.com/item?id=23934409
| joshxyz wrote:
| Yep I initially thought "uniwidth" is synonymous with
| "monospaced" fonts.
|
| 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
|
| [0] https://www.recursive.design/
| krsdcbl wrote:
| I kinda want to call them "weight agnostic", but that might be
| even more confusing
| jarym wrote:
| This is what I love about HN: Wake up, read a well written
| article and learn something new. Thank you!
| leephillips wrote:
| I agree. I'd never heard of uniwidth typefaces. It's good to
| know about.
| jacobp100 wrote:
| A few of Matthew Butterick's from Butterick's Practical
| Typography fonts are duplexed.
|
| - 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.
| chrismorgan wrote:
| Though Concourse isn't _entirely_ duplexed; [?]
| https://mbtype.com/pdf/concourse-type-specimen.pdf#page=7:
|
| > _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.
| drannex wrote:
| I love the concept of uniwidth typefaces, but the problem stands
| that almost every single uniwidth font looks fundamentally
| _differently_ when you bold them or not.
|
| 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.
___________________________________________________________________
(page generated 2021-01-30 23:00 UTC)