Rethinking Text Resizing on Web(medium.com)
medium.com
Rethinking Text Resizing on Web
https://medium.com/airbnb-engineering/rethinking-text-resizing-on-web-1047b12d2881
170 comments
The new Reddit login modal is a disaster even on an iPad mini in landscape mode. Does nobody test anything anymore?
Everything in Reddit is disaster.
They push the usage of mobile app so hard.
Soon the time comes when old.reddit.com is no more and that is farewell.
Soon the time comes when old.reddit.com is no more and that is farewell.
I was so sad when they droppped the old /.compact interface which was heavenly
The new login is showing up on old.reddit.com
Just noticed that yesterday. Almost made me give up on logging in and posting. The day old reddit is gone will probably be the day I can't tolerate it any longer.
I can't tolerate it now
why bother when there are no competitors and you make all your money from the endless google stream?
I already avoid Reddit search results in Google because the site is crap, unless there's no other option (and then I force it to Old Reddit), just like I avoid the sites full of popup ads.
Without users writing new content (because the site is crap) the Google stream will dry up too.
Without users writing new content (because the site is crap) the Google stream will dry up too.
Bots will generate content on Reddit using LLMs for years to come. It will be an uncanny valley full of apparent UGC and interactions. People who still use search will be pointed there and say, see, you don't need to use these new-fangled chatbots! But they'll be looking at pre-generated chatbot output. The bots will get stuck in a reinforcement loop where reddit content generated by bots is used to train the LLMs for the next generation of bot, and "reddit recommendations" will devolve in old wives' tales, stuck in the past, the echo of the voice of a generation long gone, repeated by mindless zombies.
So, same as talkradio?
So, same as talkradio?
The whole Reddit app is terrible.
Their latest update on my iPhone 15 Pro (so the most vanilla configuration) has some kind of reverse padding on posts that will drag them under the previous one.
Their latest update on my iPhone 15 Pro (so the most vanilla configuration) has some kind of reverse padding on posts that will drag them under the previous one.
> Does nobody test anything anymore?
Sure they do. You're just not the target audience. You're stuck in the A/B testing phase where the A side gets Advertisements and the B side gets the B-rated website.
Sure they do. You're just not the target audience. You're stuck in the A/B testing phase where the A side gets Advertisements and the B side gets the B-rated website.
If you are using Reddit's web interface: this is deliberate. They seem to make effort to make it so annoying that people might be nagged into installing the app. I assume it works on enough people that it is worth it to them to loose people like me who walk away without installing the app.
Move fast and break things....
As someone who has worked in compliance testing for tightly controlled software platforms, things like this piss me off. These problems have known solutions.
Works on my <1yr old iPhone phablet. Ship it.
But the known solutions are old, and new is always better
I still use the Galaxy S8 with a 5.8" screen as well. It is actually quite amusing that nowadays this is considered "Small phone". I find it to be the perfect size and refuse to carry a brick around with me. Good thing in my country we still have 2G for when this breaks :P
In medium to big enterprise you usually ask someone to give you the resolutions that's you're supposed to support.
These re resolutions are usually significantly higher then the iPhone mini. usually The product owner or UX/design make that decision because you need to make a cut somewhere, and almost nobody uses small phones anymore. So they're making the judgement call that these people aren't worth the money creating the design, testing that every flow works correctly etc.
It's definitely annoying to be outside of the target demographic however, I know the feeling well.
These re resolutions are usually significantly higher then the iPhone mini. usually The product owner or UX/design make that decision because you need to make a cut somewhere, and almost nobody uses small phones anymore. So they're making the judgement call that these people aren't worth the money creating the design, testing that every flow works correctly etc.
It's definitely annoying to be outside of the target demographic however, I know the feeling well.
I'm not sure what you mean:
- Their intent isn't small resolution, they're discussing increasing font size beyond the default on a standard premium smart phone[1]
- Retina displays came out when I was still in college...2010? At that point, resolution is meaningless, things like dp (Android parlance)/pts (iOS parlance)/points (Adobe or font parlance) rem are what you have to hang your hat on
- if you're making "someone else" (?) tell you what resolutions to support, are they technical enough to understand that?
- The invocation of "medium to big enterprise" is carrying a lot of weight, the big enterprises I've worked at certainly didn't do this, but it was Google
I think this is something more depressing that I saw constantly through the eyes of someone who started at SmallCo then went to Google: designers didn't know enough about view layout to explain this, engineers didn't care enough to explain because it was a "design thing", and if you were an engineer who cared enough, you were seen as troublesome / sticking your nose in the wrong place by your fellow engineers.
This isn't an idle observation: by sticking my nose in the wrong place continually, I learned enough about design to make a new dynamic design system that no one cared about until VPs needed one, and then it got in on the branding for Material You/Material 3.
[1] iPhone Mini is 5.4", the post you're replying to is recommending 5.8", that's a pretty de rigeur smart phone screen, even for premium smart phones in high income countries
- Their intent isn't small resolution, they're discussing increasing font size beyond the default on a standard premium smart phone[1]
- Retina displays came out when I was still in college...2010? At that point, resolution is meaningless, things like dp (Android parlance)/pts (iOS parlance)/points (Adobe or font parlance) rem are what you have to hang your hat on
- if you're making "someone else" (?) tell you what resolutions to support, are they technical enough to understand that?
- The invocation of "medium to big enterprise" is carrying a lot of weight, the big enterprises I've worked at certainly didn't do this, but it was Google
I think this is something more depressing that I saw constantly through the eyes of someone who started at SmallCo then went to Google: designers didn't know enough about view layout to explain this, engineers didn't care enough to explain because it was a "design thing", and if you were an engineer who cared enough, you were seen as troublesome / sticking your nose in the wrong place by your fellow engineers.
This isn't an idle observation: by sticking my nose in the wrong place continually, I learned enough about design to make a new dynamic design system that no one cared about until VPs needed one, and then it got in on the branding for Material You/Material 3.
[1] iPhone Mini is 5.4", the post you're replying to is recommending 5.8", that's a pretty de rigeur smart phone screen, even for premium smart phones in high income countries
I used the term resolution as a stand-in for how the question is asked, as I thought everyone here would understand it easier like that.
Ofc the person isn't asked which pixel density, pixel ratio, resolution etc should be supported - they're asked what the smallest device is they should support. And this is usually the iPhone, and raising issues if a design doesn't work on a iPhone mini gets reprioritized into the backlog until someone closes it as won't fix.
And yes, I'd wager these multinational giga corporations like MAMA (Microsoft, Apple, Meta, Alphabet) are very different in culture, but I can't speak from experience, Ive never applied to work for any of them
I believe my nation classifies small enterprise to be <50 employees, with large starting at 250. That's a very different organisation structure then you get in a corporation with tens of thousands of employees, spanning multiple nations.
Ofc the person isn't asked which pixel density, pixel ratio, resolution etc should be supported - they're asked what the smallest device is they should support. And this is usually the iPhone, and raising issues if a design doesn't work on a iPhone mini gets reprioritized into the backlog until someone closes it as won't fix.
And yes, I'd wager these multinational giga corporations like MAMA (Microsoft, Apple, Meta, Alphabet) are very different in culture, but I can't speak from experience, Ive never applied to work for any of them
I believe my nation classifies small enterprise to be <50 employees, with large starting at 250. That's a very different organisation structure then you get in a corporation with tens of thousands of employees, spanning multiple nations.
5.8" is "smaller" screen? So what will you tell about my 4.5" BQ Aquaris E4.5 Ubuntu Edition, which I use for daily web browsing? 5.8" is huge, it cannot fit in the pocket!
My designer will do that, and is pretty good. The problem is my product team, who have very little technical background. They look at the designs are start messing with everything. I have to constantly remind them of AA compliance. They flat out don't get it.
They also don't understand that people will visit your web site with their phone, even tho we have a native app.
They also don't understand that people will visit your web site with their phone, even tho we have a native app.
And then imagine how it all appears on my 4inch-screen iPhone, if 5.8 inch is already too small.
I use an iPhone SE (4.7") with slightly larger default text size (accessibility settings) and have the same experience. Everything more or less "works" though, so it's not as bad as it could be --- the visual issues basically just help me spend less time on my phone.
I don't think I've ever seen a website respect my phone's text size, and frankly I didn't know it was posisble, this Airbnb blog post is cool and makes me want to update my own sites.
I don't think I've ever seen a website respect my phone's text size, and frankly I didn't know it was posisble, this Airbnb blog post is cool and makes me want to update my own sites.
I remember having a heated discussion with an LLM about this. For some reason "web" doesn't even consider to respect dpi and angular sizes and instead relies on "breakpoints", which "is important to remember to test on all sorts of devices".
That's just bs. As a maker of UI, I want to get a rectangle, put my controls on it with the sizes in cm/in/° as I see fit and then to just slide right-bottom to see what happens on different screen sizes. One doesn't have to buy a foot-high stack of smartphones and tablets to test an effing label.
The whole issue stems from the fact we can't measure things correctly, cause the whole measurement system bases on ideas from winword era.
That's just bs. As a maker of UI, I want to get a rectangle, put my controls on it with the sizes in cm/in/° as I see fit and then to just slide right-bottom to see what happens on different screen sizes. One doesn't have to buy a foot-high stack of smartphones and tablets to test an effing label.
The whole issue stems from the fact we can't measure things correctly, cause the whole measurement system bases on ideas from winword era.
> For some reason "web" doesn't even consider to respect dpi and angular sizes
Maybe I'm not sure what you mean, but this is not correct. "The web" is definitely DPI-independent. Specifying a width of 16px will render 32 physical pixels on a @2x display.
Maybe I'm not sure what you mean, but this is not correct. "The web" is definitely DPI-independent. Specifying a width of 16px will render 32 physical pixels on a @2x display.
What's stopping you from using cm/in as your unit (which is actually also what px is based off of in the web, not physical pixels)? ° doesn't make sense until you pick a viewing distance, at which point you're really back to some scaled value of cm/in.
Fixed size layout runs into problems where you're working with displays that aren't at typical desktop / laptop / mobile distances from the retina.
The two obvious examples which come to mind are mounted displays (from wall art and signage to billboards), and glasses-based displays.
A 1cm font size on a mobile device is ludicrously large. On outdoor signage it's invisible, and quite possibly below pixel size. It might be appropriate on a desktop display for some major title or site branding. It's going to fill the entire field of view on a face-mounted display.
The simple truth is that design has to respect not only device capabilities (your colour-palette likely works poorly on monochrome e-ink devices, ask me how I know), and reader capabilities (colourblind? glaucoma? cateracts? presbyopia?, macular degeneration?) but also the specific use case and environment, all in ways that the author of a site or design often has no possible insight on. Client specifies design is the only option which works in all of these instances, and yes, this means that the more complex your site / SPA (o hai ubrz) the more likely it will be to break irreparably in a large number of instances.
The two obvious examples which come to mind are mounted displays (from wall art and signage to billboards), and glasses-based displays.
A 1cm font size on a mobile device is ludicrously large. On outdoor signage it's invisible, and quite possibly below pixel size. It might be appropriate on a desktop display for some major title or site branding. It's going to fill the entire field of view on a face-mounted display.
The simple truth is that design has to respect not only device capabilities (your colour-palette likely works poorly on monochrome e-ink devices, ask me how I know), and reader capabilities (colourblind? glaucoma? cateracts? presbyopia?, macular degeneration?) but also the specific use case and environment, all in ways that the author of a site or design often has no possible insight on. Client specifies design is the only option which works in all of these instances, and yes, this means that the more complex your site / SPA (o hai ubrz) the more likely it will be to break irreparably in a large number of instances.
What's stopping you from using cm/in as your unit
Not gonna rewrite or patch a whole CSS framework to make a dashboard. One can avoid using it in the first place, but then has to cope with elusive y-scroll in line inputs, misalignments and so on. There's always something strange out of box even if you target a specific browser.
Not gonna rewrite or patch a whole CSS framework to make a dashboard. One can avoid using it in the first place, but then has to cope with elusive y-scroll in line inputs, misalignments and so on. There's always something strange out of box even if you target a specific browser.
Which CSS framework out of curiosity? I don't know many that won't let you use px, which is 1/96th an inch at any DPI, and if it really doesn't let you use the most basic sizing element on the web then the problem seems more with the chosen framework than anything to do with browsers :p.
> cm/in as your unit (which is actually also what px is based off of in the web, not physical pixels)? ° doesn't make sense until
Nope!
A CSS pixel is 96 DPI at 28 inches from the viewer.
px is fundamentally angle-based. 1/47 of a degree. And sure it's a "scaled value of cm" at some point but this way the scaling is more obviously handled on a per-device basis.
Nope!
A CSS pixel is 96 DPI at 28 inches from the viewer.
px is fundamentally angle-based. 1/47 of a degree. And sure it's a "scaled value of cm" at some point but this way the scaling is more obviously handled on a per-device basis.
expecting to use cm/in for digital design is ludicrous.
Endlessly-replagiarised blog posts about Bootstrap and friends will talk about breakpoints as though they're the greatest thing since the printing press. Outside the hypey framework world, they were only ever in vogue for long enough for us to realise that they didn't really work that well. By that time, we had flexbox, and grid followed shortly after.
Nobody who knows their salt has been using breakpoints (as a first resort for the past decade). There is no point arguing with a predictive text model about it.
Nobody who knows their salt has been using breakpoints (as a first resort for the past decade). There is no point arguing with a predictive text model about it.
The blog post design/airbnb site are pretty reliant on @container breakpoints. Even with flex/grid layouts you usually want to change things up significantly when it gets down to single column.
I just found out container queries are widely available, nice!
I should subscribe to some "new web features you can actually use now" newsletter. Any ideas?
I should subscribe to some "new web features you can actually use now" newsletter. Any ideas?
Why? Reading order is page order, so it should just work.
Though, @container breakpoints are at least justifiable. Back when people keyed everything off viewport width (the approach that I'm sure the computer was regurgitating – and the approach used by every version of Bootstrap since 2), things were very fragile.
Though, @container breakpoints are at least justifiable. Back when people keyed everything off viewport width (the approach that I'm sure the computer was regurgitating – and the approach used by every version of Bootstrap since 2), things were very fragile.
It's easier to see if you play with it on the actual site rather than look at the images and try to deduce what could be different. It's not really related to things like order or positioning of boxes, that's an extremely easy problem to solve. Some of it is loading progressively space saving assets e.g. the logo goes from "${icon} airbnb" to "${icon}" to "" depending on how much space there is, the search bar simplifies so you have space to actually type, and some content border elements are removed so there is more room for the actual content e.g. rather than blindly always show content boxes with rounded borders, spacing, and other attributes you can gain a lot of space back on small displays by stretching the container's content to fill that part of the screen completely. This is particularly useful if you combine this with getting rid of certain UI elements from earlier.
HN also does what's described at the end using media queries - if you make the page small your topbar fills the entire top and changes element layout while the post content area fills the entire rest of the screen.
HN also does what's described at the end using media queries - if you make the page small your topbar fills the entire top and changes element layout while the post content area fills the entire rest of the screen.
And if you make your page slightly bigger than the threshold for triggering HN's "mobile view", there's still padding in the top bar but the page is 53 pixels too wide, and you have to scroll horizontally. Hacker News is an example of why we don't use media queries to hack in a responsive layout. Websites are responsive by default, unless you're using <table> layouts (as HN does) or the <div>pocalypse (as every other website seems to, these days). Building different versions of your site for different widths is not a solution.
The more subtle things you describe seem quite sensible. I'll probably steal those ideas, if it comes up.
The more subtle things you describe seem quite sensible. I'll probably steal those ideas, if it comes up.
> Building different versions of your site for different widths is not a solution.
I think about it as building different sites for different form factor. What you do on a phone is different from what you do on a desktop. Or a tablet. I don't like using the amazon website on mobile because it's so cluttered, when what I want is usually searching for a product, or checking my cart for a product. I'm not managing my account in there, nor do I want alternative recommendations.
I think about it as building different sites for different form factor. What you do on a phone is different from what you do on a desktop. Or a tablet. I don't like using the amazon website on mobile because it's so cluttered, when what I want is usually searching for a product, or checking my cart for a product. I'm not managing my account in there, nor do I want alternative recommendations.
What you do on a phone is different from what you do on a desktop. What if I want to do the "mobile" activities on a desktop, or zoomed in enough to trigger the viewport changes? What if I want to do the "desktop" activities on a mobile? If you want to make a separate mobile site, make a separate mobile site: don't use effective screen resolution as a proxy.
Yeah, you can definitely fuck it up, but the same can be said for flex/grid/masonry layouts yet you wouldn't say "and grid spanning errors on resize are why we never use grid". HN does a lot "wrong" in its design (like the aforementioned table hell) but that doesn't mean every mistake it makes is a universal thing to avoid and inherent to the way it was implemented. Reddit, YouTube, Facebook, Instagram, Netflix, X, Amazon, and most modern sites do the same kind of content box snapping on either the header or content area (or both) via breakpoints. Most do it a lot better than HN :). The top site I know that doesn't really do that (but it does do the minor breakpoint things) is Yahoo.com.
The vertical candybar formfactor of smartphones really is just a total nightmare when it comes to usability. Coupled with the fact that touchscreens are a nadir of effective user input design, it really feels like phones were a regression in every respect except fit-in-your-pocket portability. Here's hoping that whatever eventually disrupts smartphones turns out better.
As someone who’s lost much ability due to an illness, the touch input, accessibility features and intimacy of my phone have been a lifesaver.
Desktop web versus phone/tablet/tocuhscreen? I’d take the innovations and how forward they’ve moved us and society over anything in the past… they’re not just about input but forced new solutions and took us to new places.
Can anything be implemented better? Of course, and I agree with you: the next disruption will be better.
BUT will also expose more challenges in how we deal with tech, each other, and the planet.
Desktop web versus phone/tablet/tocuhscreen? I’d take the innovations and how forward they’ve moved us and society over anything in the past… they’re not just about input but forced new solutions and took us to new places.
Can anything be implemented better? Of course, and I agree with you: the next disruption will be better.
BUT will also expose more challenges in how we deal with tech, each other, and the planet.
I really disagree with this.
Touchscreens are not necessarily the best input device for any one task, but they are the second best input device for pretty much all tasks. They are very versatile - you don't need to define all your inputs up front, instead you can add new controls dynamically as needed (such as a keyboard that only shows up when you're inputting text, and even adapts to the type of text you're working with). When working with a desktop, you have a range of specialist input devices, from mice, keyboards (which themselves are a combination of different input devices for different tasks), drawing pads, trackballs, etc. A touchscreen will never be as good as any of these devices, but it can do the job of all of them, and switch between them as necessary.
Obviously there are limits to how useful this versatility is. A touchscreen in a car, for example, can control a lot of different aspects of that car from one place, but it makes finding those controls more complicated. So controls that need to be accessed regularly or quickly still need their own separate physical buttons. It's why volume buttons tend to still be physical on most phones. But you'd equally not want to control your car with a keyboard and a bunch of different shortcuts - understanding the tool that's best for the job is key.
And the point here is that the touchscreen is the best tool if you want something versatile.
I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material. Again, it has its disadvantages as well, but most phones can switch between vertical and horizontal modes as necessary. Vertical screens also tend to have the largest accessible space if used in one hand - look at how far your thumb can move side-to-side vs top-to-bottom when operating a phone in one hand.
Smartphones are the form and size that they are because it works well: it is largely accessible, it's convenient, and people find it convenient to use. And it's not like it's just the first thing that we tried that stuck - there are a myriad of failed smartphone concepts that have been tried out but just aren't as convenient.
That's not to say that you have to find the smartphone concept convenient yourself, but it's valuable understanding why they work so well for so many people.
Touchscreens are not necessarily the best input device for any one task, but they are the second best input device for pretty much all tasks. They are very versatile - you don't need to define all your inputs up front, instead you can add new controls dynamically as needed (such as a keyboard that only shows up when you're inputting text, and even adapts to the type of text you're working with). When working with a desktop, you have a range of specialist input devices, from mice, keyboards (which themselves are a combination of different input devices for different tasks), drawing pads, trackballs, etc. A touchscreen will never be as good as any of these devices, but it can do the job of all of them, and switch between them as necessary.
Obviously there are limits to how useful this versatility is. A touchscreen in a car, for example, can control a lot of different aspects of that car from one place, but it makes finding those controls more complicated. So controls that need to be accessed regularly or quickly still need their own separate physical buttons. It's why volume buttons tend to still be physical on most phones. But you'd equally not want to control your car with a keyboard and a bunch of different shortcuts - understanding the tool that's best for the job is key.
And the point here is that the touchscreen is the best tool if you want something versatile.
I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material. Again, it has its disadvantages as well, but most phones can switch between vertical and horizontal modes as necessary. Vertical screens also tend to have the largest accessible space if used in one hand - look at how far your thumb can move side-to-side vs top-to-bottom when operating a phone in one hand.
Smartphones are the form and size that they are because it works well: it is largely accessible, it's convenient, and people find it convenient to use. And it's not like it's just the first thing that we tried that stuck - there are a myriad of failed smartphone concepts that have been tried out but just aren't as convenient.
That's not to say that you have to find the smartphone concept convenient yourself, but it's valuable understanding why they work so well for so many people.
On a touchscreen, every use case is equally painful compared to more precise input methods. That's only an advantage if your users spend a significant fraction of time in unexpected input situations.
Personally, while I am able to do most everything I do on my computer on my smartphone, I almost never enjoy doing so – one big exception being content consumption. And even then, not being able to quickly make a note or comment on what I'm reading feels constraining.
> I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material.
One seems to be strictly a consequence of the other.
> most phones can switch between vertical and horizontal modes as necessary.
Horizontal mode is usually horrible, both in terms of being able to hold the phone with one hand, and in terms of UI. On iOS for example, Safari's UI becomes extremely wasteful in horizontal mode.
> And it's not like it's just the first thing that we tried that stuck - there are a myriad of failed smartphone concepts that have been tried out but just aren't as convenient.
I think it has at least as much to do with industry momentum. Even if I'd personally prefer another form factor, I won't have many apps optimized for it if it's not in line with mainstream phone usage.
Personally, while I am able to do most everything I do on my computer on my smartphone, I almost never enjoy doing so – one big exception being content consumption. And even then, not being able to quickly make a note or comment on what I'm reading feels constraining.
> I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material.
One seems to be strictly a consequence of the other.
> most phones can switch between vertical and horizontal modes as necessary.
Horizontal mode is usually horrible, both in terms of being able to hold the phone with one hand, and in terms of UI. On iOS for example, Safari's UI becomes extremely wasteful in horizontal mode.
> And it's not like it's just the first thing that we tried that stuck - there are a myriad of failed smartphone concepts that have been tried out but just aren't as convenient.
I think it has at least as much to do with industry momentum. Even if I'd personally prefer another form factor, I won't have many apps optimized for it if it's not in line with mainstream phone usage.
> On a touchscreen, every use case is equally painful compared to more precise input methods.
Touchscreen input could actually be quite precise if it was based on specialized gestures such as swiping and pie menus. Extensions of Fitt's law (that mouse-based interfaces are heavily based upon) have been developed that are applicable to swiping tasks, viz. https://en.wikipedia.org/wiki/Steering_law
Touchscreen input could actually be quite precise if it was based on specialized gestures such as swiping and pie menus. Extensions of Fitt's law (that mouse-based interfaces are heavily based upon) have been developed that are applicable to swiping tasks, viz. https://en.wikipedia.org/wiki/Steering_law
I'm curious about alternative inputs like swiping and pie menus, or two-finger inputs, or inputs relying on corners and edges. Do you know any apps that use specialized gestures?
Either PocketBook or FBReader for Android used pie menus in at least some versions.
I'd used it on an old Android 5 device where the pie menus were present for some functions. They don't appear on my e-ink Android 10 device. Not sure if that's the device / Android version or an app update.
<https://pocketbook.ch/en-ch/app>
<https://fbreader.org/android>
(Not positive which it was, though I think it was PocketBook. Device is not presently accessible.)
As for the pie menus: they were useful in some cases, but aren't a universal panacea for all touch UI problems.
I'd used it on an old Android 5 device where the pie menus were present for some functions. They don't appear on my e-ink Android 10 device. Not sure if that's the device / Android version or an app update.
<https://pocketbook.ch/en-ch/app>
<https://fbreader.org/android>
(Not positive which it was, though I think it was PocketBook. Device is not presently accessible.)
As for the pie menus: they were useful in some cases, but aren't a universal panacea for all touch UI problems.
> They are very versatile - you don't need to define all your inputs up front, instead you can add new controls dynamically as needed
That's pretty much the last thing I want. I really like the turn page buttons on my Kobo. My previous kindle did not have them and it was a pain. Somethings like iPod wheel can replace a lot of current touch screen interactions (it's technically touch, but could be a dial) in small screen.
> I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material
My non scientific answer is that it tiring to read a long line. A smaller width gave us more visual landmarks to rest our eyes on. And yes, a vertical form is easier to hold in one hand, but with how big phones are getting, most interactions is two handed.
> it is largely accessible, it's convenient, and people find it convenient to use.
And that's their only strong point: convenience. Ergonomics for a particular task does not translate well to others. If you only have to do one task, a smartphone is always the worst choice. A smartphone is more accidental usage than planned usage. If I know I'm going to take a lot of photos in an event, I want a camera, not a smartphone. If I'm going to write all day, I'm bringing a laptop, not a smartphone...
That's pretty much the last thing I want. I really like the turn page buttons on my Kobo. My previous kindle did not have them and it was a pain. Somethings like iPod wheel can replace a lot of current touch screen interactions (it's technically touch, but could be a dial) in small screen.
> I also think there's a big advantage to the vertical form factor for many applications - just look at how we've settled on a vertical format for almost all reading material
My non scientific answer is that it tiring to read a long line. A smaller width gave us more visual landmarks to rest our eyes on. And yes, a vertical form is easier to hold in one hand, but with how big phones are getting, most interactions is two handed.
> it is largely accessible, it's convenient, and people find it convenient to use.
And that's their only strong point: convenience. Ergonomics for a particular task does not translate well to others. If you only have to do one task, a smartphone is always the worst choice. A smartphone is more accidental usage than planned usage. If I know I'm going to take a lot of photos in an event, I want a camera, not a smartphone. If I'm going to write all day, I'm bringing a laptop, not a smartphone...
I agree. With the form factor: you either have reasonably sized content that requires abbreviated design and lots of interaction, or heavily packed content that's hard to see and easy to fat-finger.
And regarding touch input: there's no physical feedback. Touchscreens are inferior to buttons you can feel the edges of, or keys you can push and hear as they click. Most of the older people in my life still struggle with touch inputs.
Smartphones are so convenient and versatile, though. I can't imagine any kind of device replacing them.
And regarding touch input: there's no physical feedback. Touchscreens are inferior to buttons you can feel the edges of, or keys you can push and hear as they click. Most of the older people in my life still struggle with touch inputs.
Smartphones are so convenient and versatile, though. I can't imagine any kind of device replacing them.
An always-with-you terminal is nice. What we need is not replacing them. It's making them simpler. We're cramming features into these things that doesn't need to be there, and it's a pain to remove them. That's what make them so confusing. What I do when I'm seated in front of a computer is different from what I want to do on the go. That's why I like my single-use devices (like my kitchen timer), because they tend to do that one things well. The iPod classic was great in that regard.
I'm hoping for the hand terminals from the Expanse: Project images into the space around you.
Should be awarded with the typical HN comment badge - smartphones effectively replaced PCs for most of the population, but what a regression nevertheless!
I think the format is perfect for consumption. That this became so separated from creation is another problem.
I think the format is perfect for consumption. That this became so separated from creation is another problem.
Replaced? I'm pretty sure for the majority of smartphone users, it is their first computer. You have to be above 25 and and live in a developed nation for you to have had a PC before a smartphone.
In a developing country here. For people below 25, the majority are only familiar with smartphones. I think this comes down to the versatility of these devices(Camera, media consumption, browsing social media, ... ), and sadly that is most, if not all, of their needs in computers ...
The problem with most "resize/zoom" solutions is that they assume everything needs to be resized, which is not ideal. This approach makes well-known buttons and text unnecessarily large, reducing overall visibility.
For Gmail, I use this small extension [1] that only resizes the message text and subject line, keeping other elements like the search bar, buttons, and labels unchanged. I wish every website does this way.
[1] https://chromewebstore.google.com/detail/email-zoom-text-rea...
For Gmail, I use this small extension [1] that only resizes the message text and subject line, keeping other elements like the search bar, buttons, and labels unchanged. I wish every website does this way.
[1] https://chromewebstore.google.com/detail/email-zoom-text-rea...
One great feature on laptops' trackpad which is hard to get on a mouse is the pinch-to-zoom thing. It zooms you in without changing the layout or anything.
macOS has an accessibility feature where you can hold ctrl (or something) and use the scroll wheel to zoom the entire screen in.
Not quite the same, but works really well for not breaking any layouts because it just scales the entire display out of the viewable area.
Not quite the same, but works really well for not breaking any layouts because it just scales the entire display out of the viewable area.
There is also a great piece of software that allows you to use ctrl+scroll to do the trackpad pinch-style zoom (and some other mouse-related things): https://macmousefix.com/
ctrl+scroll on Windows generally scales the text only. Even the built-in magnifier is extremly clunky and zooms only to 200%, 300% ...
On mice, that's usually available via the scroll wheel.
(Something ... notably missing from Apple's desktop mice.)
(Something ... notably missing from Apple's desktop mice.)
Firefox on desktop supports "zoom text only" feature. But it's the only browser doing so. Because obviously it can break designs.
OTOH Opera mobile supports text reflowing after zoom (to be enabled in settings). It's a compile time feature of Blink and I'm baffled why one else supports it. It eats a bit more battery to reflow on each zoom but come on.
OTOH Opera mobile supports text reflowing after zoom (to be enabled in settings). It's a compile time feature of Blink and I'm baffled why one else supports it. It eats a bit more battery to reflow on each zoom but come on.
Looking at the example near the bottom of the page, they seem to be making the common mistake of thinking that if I want 16px text turning into 32px, then I also want 24px text turning into 48px.
I really really don't. I'm already much shorter of screen space than the designer planned for, and huge headings make that much worse.
I really really don't. I'm already much shorter of screen space than the designer planned for, and huge headings make that much worse.
Accommodating inconsistent content-- especially in variable-shape elements like navigation link lists or headlines-- on many screen sizes and aspect ratios is really difficult. It's easy to look at a janky combo and assume incompetence, but someone probably pored over edge cases until their eyes bled to even get it that usable. If you change one thing, 3 other things break.
That's why you don't. Designers often want to assume fixed sizes for their designs and the result is beautiful, but not flexible. You want to assume that everything is reflowable and define devices classes. Optimize for use cases instead of branding/marketing.
> Optimize for use cases instead of branding/marketing.
Even if a company had in-house people for both branding/identity and interface design, which isn't common, they probably wouldn't even go to each others meetings, just like a database administrator wouldn't go to front-end dev meetings. My having professional experience in both is the exception, not the rule.
The overwhelming majority of the interface work I've done was for applications published by a nonprofit that didn't give a shit about branding or prettiness. They needed their interaction-heavy applications to be very visually parseable and have things like action status and next actions be clear and intuitive instantly. That doesn't happen by accident: you must delve deep into the minutiae of what you communicate with information hierarchy, implied relationships through gestalt or implied lines, and other visual cues that help people subconsciously understand what they're looking at. While these things are very important to everyone trying to use an interface, it's triply so for people that aren't used to staring at dense screens of text all day long, which is why other developers are the only ones that don't hate interfaces made by developers. Branding people care about very general look and feel and are usually satisfied if you use the appropriate colors and typefaces. Interface design is the hard part with layout, has little to do with aesthetics, and is 100% about the use case.
Even if a company had in-house people for both branding/identity and interface design, which isn't common, they probably wouldn't even go to each others meetings, just like a database administrator wouldn't go to front-end dev meetings. My having professional experience in both is the exception, not the rule.
The overwhelming majority of the interface work I've done was for applications published by a nonprofit that didn't give a shit about branding or prettiness. They needed their interaction-heavy applications to be very visually parseable and have things like action status and next actions be clear and intuitive instantly. That doesn't happen by accident: you must delve deep into the minutiae of what you communicate with information hierarchy, implied relationships through gestalt or implied lines, and other visual cues that help people subconsciously understand what they're looking at. While these things are very important to everyone trying to use an interface, it's triply so for people that aren't used to staring at dense screens of text all day long, which is why other developers are the only ones that don't hate interfaces made by developers. Branding people care about very general look and feel and are usually satisfied if you use the appropriate colors and typefaces. Interface design is the hard part with layout, has little to do with aesthetics, and is 100% about the use case.
Interface design do seem a thing of the past. It’s always a pleasure to use a properly made application. But a lot of business only cares about being pretty and mix that with abysmal technical performance, and the result is usability hell.
There are probably more active interface designers now than ever in history. It's easy to see interfaces of yesteryear through rose-colored glasses, but it's nostalgia speaking. There is and always will be plenty of shit design in the world, but the idea that usability in applications is declining is just not supported by the interfaces we use. The problem with good interface design is that its entirely transparent-- since we use so many more interfaces than we used to, we notice more interfaces that don't meet our expectations, and at the same time, our expectations for interfaces have grown. Also, with time, fewer interfaces prioritize what developers want in them. The interface features desirable to people with a working mental model of software are often orthogonal to what everybody else wants. That's why the nearly the only end-user-facing open source projects that even approach the popularity of their closed-source equivalents-- e.g. Signal, Blender, Firefox-- are grant funded projects with people overseeing the UX. In contrast, Eclipse is also grant funded but I don't see any designers on their team, and based on the experience of using it, that tracks.
I don't mind paying for software, but not for the current crop. It was once expected to get training for a tool. But now the trend is for the tool to become a toy. Just play with it until you get light and sounds. And for safety, we will reduce the set of actions you can take. Fine for a single purpose application, but not great when you want versatility.
> I don't mind paying for software, but not for the current crop.
Nothing about this is specific to commercial software. I've got 5 digits of hours in FOSS contributions.
> It was once expected to get training for a tool. But now the trend is for the tool to become a toy. Just play with it until you get light and sounds.
Your stance is pretty common among developers. The fact is that we use so much end-user-facing software for which we don't even think about the interfaces... we just accomplish whatever task you need the tool to accomplish and move on. Think about every phone app, screen, website, ordering system, electronic appliance-- all of those things have designed interfaces. Do you think it's reasonable to require customers to read instructions on using an ordering terminal at a quick serve restaurant? Their phone email app? Web browser? Messaging clients? If every one of those interfaces was assembled according to the developer's fancy rather than someone who knows how to utilize people's existing mental models and cultural understanding, well, that's a whole lot of "RTFM" time that would be better spent on actually getting something done. Most people will never read a single line of software documentation in their entire lives for the same reason they'll never need to learn how to use a Bobcat for yard work-- it's just not necessary for non-professional work. Developers have a fundamentally different perspective on software and it's not 'better.' Needing docs for basic application functionality is the right tool for some jobs, but not for most jobs.
> And for safety, we will reduce the set of actions you can take. Fine for a single purpose application, but not great when you want versatility.
You're conflating bad with intuitive with well-designed. An interface that doesn't let expert users work efficiently is a bad interface. Almost invariably when you see an interface that looks 'designed' but it's not functional, it's because a developer went looking for nifty UI mockups on Dribbbbbble and copied it so they could tell people about the beautiful interface they designed. They think that works because they think UI design is about aesthetics rather that making your interface as useful as possible. Great designs aren't even always intuitive to non-experts. Lots of times it has to be fast and efficient for people who know exactly what they're doing, and training might be appropriate for important, complex interfaces... but complex expert-targeted interfaces are not the same things as interfaces that are confusing because they were assembled rather than designed by someone who knows what they're doing. One of those things looks like the console for a modern X-Ray machine. The other looks like the interface for the Therac-25. I use vim (or, vim keybindings in other editors) these days because it's a great expert tool, and it's about as far from intuitive as you can get. If someone said "make an efficient text editor for people who will spend many thousands of hours at keyboards, there's a good chance interface designers would come up with something just like that, though probably with better visual cues.
Nothing about this is specific to commercial software. I've got 5 digits of hours in FOSS contributions.
> It was once expected to get training for a tool. But now the trend is for the tool to become a toy. Just play with it until you get light and sounds.
Your stance is pretty common among developers. The fact is that we use so much end-user-facing software for which we don't even think about the interfaces... we just accomplish whatever task you need the tool to accomplish and move on. Think about every phone app, screen, website, ordering system, electronic appliance-- all of those things have designed interfaces. Do you think it's reasonable to require customers to read instructions on using an ordering terminal at a quick serve restaurant? Their phone email app? Web browser? Messaging clients? If every one of those interfaces was assembled according to the developer's fancy rather than someone who knows how to utilize people's existing mental models and cultural understanding, well, that's a whole lot of "RTFM" time that would be better spent on actually getting something done. Most people will never read a single line of software documentation in their entire lives for the same reason they'll never need to learn how to use a Bobcat for yard work-- it's just not necessary for non-professional work. Developers have a fundamentally different perspective on software and it's not 'better.' Needing docs for basic application functionality is the right tool for some jobs, but not for most jobs.
> And for safety, we will reduce the set of actions you can take. Fine for a single purpose application, but not great when you want versatility.
You're conflating bad with intuitive with well-designed. An interface that doesn't let expert users work efficiently is a bad interface. Almost invariably when you see an interface that looks 'designed' but it's not functional, it's because a developer went looking for nifty UI mockups on Dribbbbbble and copied it so they could tell people about the beautiful interface they designed. They think that works because they think UI design is about aesthetics rather that making your interface as useful as possible. Great designs aren't even always intuitive to non-experts. Lots of times it has to be fast and efficient for people who know exactly what they're doing, and training might be appropriate for important, complex interfaces... but complex expert-targeted interfaces are not the same things as interfaces that are confusing because they were assembled rather than designed by someone who knows what they're doing. One of those things looks like the console for a modern X-Ray machine. The other looks like the interface for the Therac-25. I use vim (or, vim keybindings in other editors) these days because it's a great expert tool, and it's about as far from intuitive as you can get. If someone said "make an efficient text editor for people who will spend many thousands of hours at keyboards, there's a good chance interface designers would come up with something just like that, though probably with better visual cues.
It's highly unlikely someone pored over much of edgecases as it's pretty common in such discussions to realize that there isn't even awareness of many cases
As you say, people in different roles don't even have the same meetings
As you say, people in different roles don't even have the same meetings
As someone who's been on several teams that have and also spent a whole lot of time digging into responsive interfaces on all sorts of hardware, my experience differs. Unless either of us get some sort of broad numbers, which is probably impossible, we're just going to have conflicting anecdata.
Indeed, that's also what threw me off with the accessibility rule "when text is scaled 200% (2x) of its original size." focused on %
I find the experience of Airbnb user hostile. The last time I checked, the app pushed irrelevant search results on me with no option of turning that off. Now they give advice on UX? The advice might be sound, but it comes from an authority in marketing, not UX
The other day I was with my girlfriend trying to book a listing in Airbnb.
She couldn't add her phone number to her account, because her phone number was already registered in an old (2013) account of hers that she didn't remember existed, and she didn't remember the credentials.
Once she found a way to log into the old account, she was unable to remove her phone number from it without adding in a new number. We had to add my phone number to her old account so that we could use her number in her current account. We couldn't add a 'fake' number because it requires SMS verification.
So, I guess I will not be able to add my phone number to Airbnb if I ever want to use it.
I suppose they do it like this so that phone numbers can be used as username, but they end up pushing this kind of problem onto their users. We were in a hurry and it really was not the appropiate moment for Airbnb to act stupid.
She couldn't add her phone number to her account, because her phone number was already registered in an old (2013) account of hers that she didn't remember existed, and she didn't remember the credentials.
Once she found a way to log into the old account, she was unable to remove her phone number from it without adding in a new number. We had to add my phone number to her old account so that we could use her number in her current account. We couldn't add a 'fake' number because it requires SMS verification.
So, I guess I will not be able to add my phone number to Airbnb if I ever want to use it.
I suppose they do it like this so that phone numbers can be used as username, but they end up pushing this kind of problem onto their users. We were in a hurry and it really was not the appropiate moment for Airbnb to act stupid.
Everyone enforces phone numbers everywhere now due to spammers and scammers and other assholes. We can't have nice things.
Airbnb has some of dark patterns that I guess are pushed by the product team and the engineers accept, and that's infuriating as a user, but as an engineer I still have a lot of respect for the Airbnb team's open source work in frontend web tech. They really do know what they're doing and there's a ton to learn from them. You can do that while choosing not to use the company's products.
You are right. I edited my comment to remove the negative sentiment towards the advice itself. I also admire the craftsmanship there. Still, the dark patterns are just increasingly unbearable. Same can be said about many market leaders in other categories.
One of the side-effects of text scaling is content will be pushed further down the page. So if you place promoted content on top as most do, the normal content will fall below the fold. That "small" ad then becomes the only thing the user sees.
They don't actually use their namesake eslint rules.
Using the default 12px text size is a pretty good indicator that a website's entire engineering team is under 40.
… the default is 12 pt, or 16px.
I can somewhat comfortably read HN (though it is a touch small); it's 12px/9pt. I wouldn't recommend anything less than 10pt myself for normal text.
I did hit a site recently whose main copy was 9px, and that was quite annoying, I agree there.
I can somewhat comfortably read HN (though it is a touch small); it's 12px/9pt. I wouldn't recommend anything less than 10pt myself for normal text.
I did hit a site recently whose main copy was 9px, and that was quite annoying, I agree there.
No, there is no global default. It can be customized by users and the defaults can vary on different devices.
https://nicolas-hoizey.com/articles/2016/03/02/people-don-t-...
https://nicolas-hoizey.com/articles/2016/03/02/people-don-t-...
Every time I set up a new computer it's always shocking to me what the 100% zoom size looks like on websites. ALWAYS have to jam it up to 150%.
I'm the opposite. Everything seems to keep getting larger, with more and more wasted space (padding, margin), unless I do something like connect a 4k+ screen and disable scaling.
Not necessarily, I still run small fonts because that's all I've known. In the 90s we had very tiny resolutions so we needed to get as much info on the screen as possible.
I think you missed their point. Most people end up needing reading glasses as they age. I tried to look for a specific number, but the consensus on who eventually needs them seems to be: everyone.
And yet I can't read a literal web design + accessibility website because the font size is too large and there's no way to shrink down the font size.
https://www.smashingmagazine.com/
The headlines are so large that I have to move my head to read them.
And zooming out doesn't reduce the font-size, it just makes headlines narrower to the point where they're one word under another while I still need to move my head around to read them. Except when zoomed out, I still need to move my head horizontally, but now vertically too.
https://www.smashingmagazine.com/
The headlines are so large that I have to move my head to read them.
And zooming out doesn't reduce the font-size, it just makes headlines narrower to the point where they're one word under another while I still need to move my head around to read them. Except when zoomed out, I still need to move my head horizontally, but now vertically too.
There’s a graphic with giant text that claims that “200% Zoom = 1/2 Viewport”.
If I’m understanding them correctly isn’t it worse than that? 200% Zoom leaves you with 1/4 of the space you had at 100% I think.
If I’m understanding them correctly isn’t it worse than that? 200% Zoom leaves you with 1/4 of the space you had at 100% I think.
I'd be interested to see what his sample graphic looks like after his "font scaling" solution. It is 1/4 the total space.
It's a quarter the total space, yeah. He probably meant half the viewport width though, since that's what you really run up against trying to make sites accessible on phones.
I guess nobody bothers to mention the text size issues on this very site anymore knowing it won't be fixed.
Zoom is what you need. I have it at 150% on my 24 inch screen. The default size is ok for my phone as the distance is usually smaller.
On my android phone using Firefox, I either have to scroll 2x the default witdh to the right, or zoom out completely to fit the text on the screen. The text is barely readable to begin with, becomes impossible when the whole thing fits. Zooming is not a solution because the text won't reflow.
Does it not behave like this for you? I think Chrome handles it better. What browser do you use?
Does it not behave like this for you? I think Chrome handles it better. What browser do you use?
Yeah, HN responds well to zooming.
While not directly related to the post, I have found that a surprising number of people with limited vision do not know about iOS’s Display Zoom feature, which is much better supported than Dynamic Text given the former only relies on developers handling different screen resolutions properly.
While it doesn’t blow things up by 200% like what AirBnb’s approach supports, it’s a quick way to make a big difference for people.
While it doesn’t blow things up by 200% like what AirBnb’s approach supports, it’s a quick way to make a big difference for people.
On iOS, if devs are building with UIKit or SwiftUI, Dynamic Text can be well supported by just using parameterized fonts or font sizes alongside SF Symbols, no need to concern oneself with specific resolutions. With a little extra work, custom fonts are capable of this too[0]. Apps built this way will work well on devices with new resolutions or even form factors with little manual involvement on the dev’s part.
[0]: https://developer.apple.com/documentation/uikit/uifont/scali...
[0]: https://developer.apple.com/documentation/uikit/uifont/scali...
I've set it up for an elderly person, and it backfired terribly — they lacked dexterity to reliably turn it on and off, forgot the feature existed, and then one day accidentally zoomed in screen by only a few percent, and though the phone broke, because "the status bar has disappeared".
That I think is a different feature. I am talking about the one that changes the resolution of the phone, essentially.
Display & Brightness -> Display Zoom
Display & Brightness -> Display Zoom
[deleted]
> the same screen shown at 200% showing the search and categories are cut off entirely and not able to even see the first listing.
Well, duh, that's because you retain so much useless whitespace where you can only fit a single short word "Display" (~30% width vs 70% whitespace) in a line
And the example in the video isn't much rethinking - instead of hiding crucial info with "California" becoming "Ca..." not only can you fit more info if you squeeze the overly wide ... (so readable Cali would fit), but also you could expand into the half-empty 3/4 lines, where a price unit could also be moved to a separate column instead off "night" being repeated, that would fit the whole California right there at high text size (and again you could fit more relatively valuable text if you remove some of the relatively less valuable spacing)
Well, duh, that's because you retain so much useless whitespace where you can only fit a single short word "Display" (~30% width vs 70% whitespace) in a line
And the example in the video isn't much rethinking - instead of hiding crucial info with "California" becoming "Ca..." not only can you fit more info if you squeeze the overly wide ... (so readable Cali would fit), but also you could expand into the half-empty 3/4 lines, where a price unit could also be moved to a separate column instead off "night" being repeated, that would fit the whole California right there at high text size (and again you could fit more relatively valuable text if you remove some of the relatively less valuable spacing)
The tldr is basically that if you size your text in `rem` but everything else (the grid, whitespace) in `px`, you allow the user-agent to increase font size _without_ zooming in everything else. Which can be useful for those who can't read small fonts, especially on small (mobile) screens.
If you size _everything_ in rem, then user-agent font scaling ends up doing pretty much exactly the same thing as user-agent zooming, which is less useful than allowing user-agent font-scaling and zooming to do _different_ things, each of which may have a different context of use.
This seems obvious once said -- but is there an argument against it? I don't think it is the common advice -- I feel like there was a _lot_ of talk about sizing _everything_ using `rem` for accessiblity (that began back before most people knew about sizing anything with rem). And that this is what most people (including me) are doing -- using rem for all sizing. And what many design frameworks (bootstrap?) have and are doing.
It's making me think the standard advice should be as in OP instead, rem for text, px for everything else. And of course to maximize accessibility benfits you then need to actually test under text-scaling (on small screens), but to begin with (and avoid the need for a huge refactor later), it seems like you should start with `px` for grid spacing etc, contrary to much current common conventional wisdom?
If you size _everything_ in rem, then user-agent font scaling ends up doing pretty much exactly the same thing as user-agent zooming, which is less useful than allowing user-agent font-scaling and zooming to do _different_ things, each of which may have a different context of use.
This seems obvious once said -- but is there an argument against it? I don't think it is the common advice -- I feel like there was a _lot_ of talk about sizing _everything_ using `rem` for accessiblity (that began back before most people knew about sizing anything with rem). And that this is what most people (including me) are doing -- using rem for all sizing. And what many design frameworks (bootstrap?) have and are doing.
It's making me think the standard advice should be as in OP instead, rem for text, px for everything else. And of course to maximize accessibility benfits you then need to actually test under text-scaling (on small screens), but to begin with (and avoid the need for a huge refactor later), it seems like you should start with `px` for grid spacing etc, contrary to much current common conventional wisdom?
I'd never heard of this approach before and I can't think of any downsides. I'll probably start using this with my new work.
Websites should set the base font size to the browser default, and scale that only for text other than body default: larger for headings, smaller only for truly superflous text, or notional elements such as super- and sub-scripts.
Readers who are aware of the ability to set a browser-level font default will be annoyed at any other behaviour or choices. Readers who are unaware of that capacity, the overwhelming majority, are a lost cause regardless, but will likely use other mechanisms to zoom pages to a comfortable reading level.
Otherwise, Air UI/UX are Beyond the Bend.
Readers who are aware of the ability to set a browser-level font default will be annoyed at any other behaviour or choices. Readers who are unaware of that capacity, the overwhelming majority, are a lost cause regardless, but will likely use other mechanisms to zoom pages to a comfortable reading level.
Otherwise, Air UI/UX are Beyond the Bend.
> Moving from pixel-based values to rem units as a company-wide change in CSS practice can be a significant challenge, especially when working across multiple teams.
What bothers me is why does a company find itself in this situation. Why does it not include web accessibility in the building of its product from the start? Why do designers talk to developers in pixels instead of checking how their design decisions on different screens, in different browsers, and with different accessibility settiongs?
What bothers me is why does a company find itself in this situation. Why does it not include web accessibility in the building of its product from the start? Why do designers talk to developers in pixels instead of checking how their design decisions on different screens, in different browsers, and with different accessibility settiongs?
200% font scaling sounds so innocent and fundamental. Is it hard because they waited too long and have too many teams / frontend systems? Or is font scaling CSS just tough for everybody?
It's the intersection of a few problems.
- Scaling / reshaping a UI is a fundamentally hard problem that people love to pretend is easy. There are all kinds of tradeoffs that need to be made based on the layout. Which text needs to be preserved? When is it appropriate to show ellipsis? Should padding be dynamic? Apart from CSS another major attempt was GridBagLayout in early Java, which was also a mess.
- Designers tend to be visual arts people who aren't of the correct personality type to dive in and solve all of the nitty gritty issues when making their design. They also like to make complex designs to show how creative they are. They also use their superior social skills to rope high level people to develop and approve the designs with them so that things are final before a dev gets to have a look. Once that happens ego comes into play and they can't be simplified.
- CSS fundamentally doesn't have the correct tools to solve a lot of the issues. CSS first came out in 1996. Line clamping seems like an obvious problem to solve. Yet 28 years later we're still stuck with a prefixed -webkit-line-clamp. In general CSS sees overflowing text as a problem it doesn't want to deal with.
- Scaling / reshaping a UI is a fundamentally hard problem that people love to pretend is easy. There are all kinds of tradeoffs that need to be made based on the layout. Which text needs to be preserved? When is it appropriate to show ellipsis? Should padding be dynamic? Apart from CSS another major attempt was GridBagLayout in early Java, which was also a mess.
- Designers tend to be visual arts people who aren't of the correct personality type to dive in and solve all of the nitty gritty issues when making their design. They also like to make complex designs to show how creative they are. They also use their superior social skills to rope high level people to develop and approve the designs with them so that things are final before a dev gets to have a look. Once that happens ego comes into play and they can't be simplified.
- CSS fundamentally doesn't have the correct tools to solve a lot of the issues. CSS first came out in 1996. Line clamping seems like an obvious problem to solve. Yet 28 years later we're still stuck with a prefixed -webkit-line-clamp. In general CSS sees overflowing text as a problem it doesn't want to deal with.
From the WCAG 2.1 specification they cite:
> The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.
> The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.
It is tough for everybody. It's one of those pernicious things that sounds simple until you try it and start to realise just how many assumptions about the relationship between things are baked into both your mental model, as well as tooling.
A lot of things in UI are like this, but given the way the web has developed, it's particularly true. The article goes over some of this, although I think it kind of assumes the reader is more or less familiar with some of the issues that come up, but it could probably still give a naive reader some idea.
A lot of things in UI are like this, but given the way the web has developed, it's particularly true. The article goes over some of this, although I think it kind of assumes the reader is more or less familiar with some of the issues that come up, but it could probably still give a naive reader some idea.
Things were heading in the right direction in the early 2000s. Browsers had default font sizes built in and everything else could be scaled with the font using the em unit. Then browsers made zoom increase the pixel size. That was it. They fucked it. To this day it's still broken.
Now you get phones where the zoom in does something utterly useless and people still can't reliably set their own font size.
Now you get phones where the zoom in does something utterly useless and people still can't reliably set their own font size.
I’m not sure if this is related, but recently I began to *omit* this viewport <meta> tag from the <head> of my sites, so that I can pinch-and-zoom instead of having a fixed scale set and needing to mess with text size controls:
<meta name="viewport" content="width=device-width, initial-scale=1" />
I find it makes sites much more pleasant to browse.
<meta name="viewport" content="width=device-width, initial-scale=1" />
I find it makes sites much more pleasant to browse.
Wait does viewport `width=device-width, initial-scale=1` prevent pinch-zoom?
I thought it just set the initial zoom with initial scale, but didn't prevent zooming in further? But I don't pinch zoom websites much, and maybe I haven't tested my own in a while... googling the usual sources are not clarifying to me the interaction of all these things according to standard.
I thought it just set the initial zoom with initial scale, but didn't prevent zooming in further? But I don't pinch zoom websites much, and maybe I haven't tested my own in a while... googling the usual sources are not clarifying to me the interaction of all these things according to standard.
Looks like you can enable zooming with the maximum-scale property:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=5.0">
> so that I can pinch-and-zoom
Without requiring horizontal scrolling?
Without requiring horizontal scrolling?
Zooming in far enough does require horizontal scrolling.
Still, I find it preferable to messing with font sizes as I hate reading on the phone and want to spend as little time as possible looking at the small screen, so I usually zoom in to what I want to see/read/click on, switching phone orientation if necessary for a 2nd option for the text size.
I could be wrong, or in a minority opinion group.
Still, I find it preferable to messing with font sizes as I hate reading on the phone and want to spend as little time as possible looking at the small screen, so I usually zoom in to what I want to see/read/click on, switching phone orientation if necessary for a 2nd option for the text size.
I could be wrong, or in a minority opinion group.
I used WAVE browser addon on the Airbnb website and it showed 37 errors, 1 contrast error and 98 alerts. And they want to talk about accessibility?
Accessibility aside, their website is an unusable, resource-hogging mess which doesn't even use proper cursor pointers for <a> tags and tries to mess with my scroll.
Accessibility aside, their website is an unusable, resource-hogging mess which doesn't even use proper cursor pointers for <a> tags and tries to mess with my scroll.
I miss the way the original Opera handled scaling which was to resize the entire draw surface after rendering. So everything, including pictures, kept the same relative sizes and there was no reflow or jumping around. That meant you had to horizontal scroll but so what?
This is the worst possible type of zoom. It's like zooming into a PDF or PNG image. You can't read like that, constantly scrolling left and right.
This is the problem though, unfortunately. People aren't even talking about the same thing. Users need to increase their font size so they can read comfortably. But so many people seem to think "zoom" should do what you describe (like zooming in to see small details?). I suppose the best is that web browsers offer both modes. But unfortunately text zoom requires some understanding from the web developer to work (or just a simple web site; a little knowledge is a dangerous thing). So we get stuck with stupid zoom because half the web breaks if you dare to change front size.
This is the problem though, unfortunately. People aren't even talking about the same thing. Users need to increase their font size so they can read comfortably. But so many people seem to think "zoom" should do what you describe (like zooming in to see small details?). I suppose the best is that web browsers offer both modes. But unfortunately text zoom requires some understanding from the web developer to work (or just a simple web site; a little knowledge is a dangerous thing). So we get stuck with stupid zoom because half the web breaks if you dare to change front size.
Opera also had a mode where it reflowed individual div's to fit the screen, without reflowing the entire page. I remember looking for an alternative browser with this feature back when, but never finding one
Actually it did reflow the entire page. In particular, it inserted line breaks where ever text was being laid out, without ever messing with the width of divs or other elements. It then made a seamless jump with the viewport to keep the point of interest where you expect it to be on the screen. That's years ago when the Chromium version came out, however. I don't know how or if it works today, or how it was implemented in Presto before then.
The version with per div reflowing might have been before android. My Sony P1i ran symbian I think, can't remember actually. It was way before reactive webpages were a thing. And it worked really well for making most desktop pages usable on my phone. I also missed the scroll wheel and the rocker keyboard for the longest time
You can do this on Firefox if (and only if I think) you have a multi-touch input device. So on my trackpad (a Wacom tablet) or my touchscreen laptop I can pinch to pan and zoom like this. But I don't think there is a way to trigger this with a keyboard and mouse.
I don't think I prefer it most of the time, as scrolling is annoying. But it is super useful for sites that break the browser-default scrolling.
I don't think I prefer it most of the time, as scrolling is annoying. But it is super useful for sites that break the browser-default scrolling.
In Firefox, you can configure the mouse to scale-zoom. In `about:config`, change `mousewheel.with_control.action` to 5 (default is 3 if you want it back). Holding Ctrl and scrolling will zoom in on the cursor location like a touchscreen pinch.
Credit: https://superuser.com/questions/1659519/firefox-pinch-zoom-w...
Credit: https://superuser.com/questions/1659519/firefox-pinch-zoom-w...
Pinch zoom on Firefox (Linux, desktop) does that for me.
Apple’s own webpage[0] doesn’t properly resize text on my iPad using safari with the text set to 125%.
[0]: https://www.apple.com/shop/buy-ipad/ipad-pro
[0]: https://www.apple.com/shop/buy-ipad/ipad-pro
[deleted]
Image and text resizing both seem rather broken in HTML/CSS. Especially images. If I care somewhat precisely about how a mixed-media site is going to show on different screen sizes, I have to set up React and start calculating stuff based on window dimensions.
I think the change in browsers from text-only zoom to whole-page zoom was a huge mistake. At least Firefox still gives you the option.
Front-end developers: test your layouts in Firefox with "Zoom text only" set. It should work for all settings from 50% to 200%.
Front-end developers: test your layouts in Firefox with "Zoom text only" set. It should work for all settings from 50% to 200%.
Annoyingly, Firefox on Android lacks these options completely. You can't even control zoom for individual websites, it's all or nothing. It gets even worse on a foldable phone where you have two different displays. It's a bit off topic, but I am not aware of any browser that has reliable sync, working ad block, and per site zoom control on both Android and Windows.
The solution to text resizing according to AirBnB engineering is CSS in JS.
These frontend web dev tendencies are devastating to me. I feel like these people haven't lived through the CSS Zen Garden days or the fight for semantic HTML.
I still love the web, but the current frontend culture is batshit.
These frontend web dev tendencies are devastating to me. I feel like these people haven't lived through the CSS Zen Garden days or the fight for semantic HTML.
I still love the web, but the current frontend culture is batshit.
The output is actual an CSS file - so it’s not quite the same as other CSS in JS libs
That’s not at all what they said.
Here's what I used in my app [1] to do scaling with CSS only, no breaking points or JS complicated needed. All sizes of fonts and elements (like cards) are derived from the visible viewport and the golden ratio:
[1] https://news.ycombinator.com/item?id=40408418
:root {
--gr: 1.618;
--font-baseline: clamp(16px, calc(5.725vh + 5.725vw), 72px) !important;
--font-baseline: clamp(16px, calc(5.725svh + 5.725svw), 72px) !important;
--baseline-unit-1: var(--font-baseline);
--baseline-unit-2: calc(var(--font-baseline) / var(--gr));
--baseline-unit-3: calc(var(--font-baseline) / pow(var(--gr), 1));
--baseline-unit-4: calc(var(--font-baseline) / pow(var(--gr), 2));
--baseline-unit-5: calc(var(--font-baseline) / pow(var(--gr), 3));
--baseline-unit-6: calc(var(--font-baseline) / pow(var(--gr), 4));
--baseline-unit-7: calc(var(--font-baseline) / pow(var(--gr), 5));
--baseline-unit-8: calc(var(--font-baseline) / pow(var(--gr), 6));
}
[1] https://news.ycombinator.com/item?id=40408418
That article about the golden ratio lost me with that horribly cropped image. It ignores all the things that actually matter when composing and cropping a shot, and gives some absurd advice that will actively lead people astray. The end result cuts off valuable content in favor of blurry background nonsense, leaving a random pencil end sticking up out of nowhere and a massively distracting board that is uncomfortably lined up with an outer edge. Learning some basic compositional techniques would be far more helpful both for the author and its readers.
Agree! I cleaned up my comment. Hopefully it's a bit clearer.
The newly standardized css `zoom` property might help with this.
AirBnB's designers have trouble understanding em and rem that have been part of CSS since at least 1999? I wonder what they do in their professional lives.
I honestly don't understand what the whole issue with web design is about (it's as far away as possible from my domain of expertise, so this is a statement of ignorance, not of arrogance).
A "motherfucking website" without any css nor js is perfectly readable and usable on all devices and browsers. Users can select their preferred font sizes, and even colors. It is just like an ebook, that is readable everywhere, and responsive with user-chosen display setups and settings. What is the problem, then? Some websites want to look "fancier", and then they specify styles in manner that is incompatible with some usage patterns? This is an entirely self-inflicted problem. The problem did not exist in the first place, they created it.
I have real trouble accepting that "web design" is not a bogus and fully useless human endeavour. I hope someone around here enlightens me to the contrary.
A "motherfucking website" without any css nor js is perfectly readable and usable on all devices and browsers. Users can select their preferred font sizes, and even colors. It is just like an ebook, that is readable everywhere, and responsive with user-chosen display setups and settings. What is the problem, then? Some websites want to look "fancier", and then they specify styles in manner that is incompatible with some usage patterns? This is an entirely self-inflicted problem. The problem did not exist in the first place, they created it.
I have real trouble accepting that "web design" is not a bogus and fully useless human endeavour. I hope someone around here enlightens me to the contrary.
Do you believe that you could implement the Airbnb interface without any CSS or Javascript?
Does the Airbnb interface need to be implemented at all?
Only if they intend for their business to continue existing.
An interface, sure; but the specific interface they are currently using, to which the previous comment was referring? Of course not.
I mean if I wanted, I could implement any of Airbnb, Twitter, Facebook, HN, Medium in e.g. GTK2 and people could use them with their favorite theme without any issue. Does that count as "without CSS or Javascript", in a non-pedantic sense?
> Do you believe that you could implement the Airbnb interface without any CSS or Javascript?
No, I don't. It has scrollable maps, for example. Those require a Javascript-operated canvas.
What I don't understand is why it needs CSS or Javascript for the rest of the interface. It's just text and photos. An empty css with static html would be enough for that, and convey exactly the same information.
No, I don't. It has scrollable maps, for example. Those require a Javascript-operated canvas.
What I don't understand is why it needs CSS or Javascript for the rest of the interface. It's just text and photos. An empty css with static html would be enough for that, and convey exactly the same information.
Do you believe the CSS serves absolutely no purpose other than just looking pretty?
I’m also a proponent of simple pages wherever they can be made but we’re not the only audience on the internet. Different people find different UIs effective.
For example: Airbnb (last I looked, anyway) has a little mini carousel in the thumbnail of a listing. I found it mildly useful. I imagine a company the size of Airbnb are tracking if people use that widget so it’s probably earned its place in the interface.
Standing outside the whole thing with no data and saying “none of this is necessary” strikes me as an unhelpful perspective. Neither you nor I actually know.
I’m also a proponent of simple pages wherever they can be made but we’re not the only audience on the internet. Different people find different UIs effective.
For example: Airbnb (last I looked, anyway) has a little mini carousel in the thumbnail of a listing. I found it mildly useful. I imagine a company the size of Airbnb are tracking if people use that widget so it’s probably earned its place in the interface.
Standing outside the whole thing with no data and saying “none of this is necessary” strikes me as an unhelpful perspective. Neither you nor I actually know.
I often feel the same, so I will try to give a serious answer:
Most web design today is driven by branding. Everyone seems to feel like they have to be express their uniqueness. This is awful and can widely be regarded as a bad move. I fully agree with you on that front.
On the other hand, the default browser styles are bad in their own way. Look at http://bettermotherfuckingwebsite.com/ for details. In practice, some degree of web design is necessary.
Also, you can create art and beauty on a computer. A well designed website can elevate the experience, just like a well designed book or chair.
Finally, HTML is limited in what it can do. JavaScript, CSS, and WAI-ARIA together form the low-level technologies to extend the web with new functionality. See https://extensiblewebmanifesto.org/ for details.
In summary, I would say that most web design is useless, but not all of it.
Most web design today is driven by branding. Everyone seems to feel like they have to be express their uniqueness. This is awful and can widely be regarded as a bad move. I fully agree with you on that front.
On the other hand, the default browser styles are bad in their own way. Look at http://bettermotherfuckingwebsite.com/ for details. In practice, some degree of web design is necessary.
Also, you can create art and beauty on a computer. A well designed website can elevate the experience, just like a well designed book or chair.
Finally, HTML is limited in what it can do. JavaScript, CSS, and WAI-ARIA together form the low-level technologies to extend the web with new functionality. See https://extensiblewebmanifesto.org/ for details.
In summary, I would say that most web design is useless, but not all of it.
I'd prefer standard controls with a set of universal downloadable themes (as a way to avoid writing it from scratch myself) to literally any modern "website design". It adds no value except for selling, but it's their goal, not mine.
Users can select their preferred font sizes
Browser vendors actively disrupted these features for decades, cause most of them became biggest sales/tracking platforms.
Users can select their preferred font sizes
Browser vendors actively disrupted these features for decades, cause most of them became biggest sales/tracking platforms.
I would recommend reading Josh Comeau's brilliant article[0] on this subject, I prefer his more intuitive approach for deciding when to choose `rem` or `px` for CSS values.
For example, from this Airbnb article:
> In the case of Airbnb, the team decided to prioritize the use of rem units specifically for font scaling, rather than scaling all elements proportionally.
This can lead to undesirable outcomes as sometimes spacing between elements can have a functional purpose, e.g. making it easier to vertically separate one paragraph from another. If you use `rem` solely for font-size and nothing else users with `32px` as their default font-size would not have the necessary amount of space to help discern one paragraph from another in this case.
PS It looks like they use Linaria, one can simplify the transition from `px` to `rem` by declaring this helper function and using inside their `css` rules:
```ts
export const px = (...spacing: number[]) => spacing.map(s => `${s * (1 / 16)}rem`).join(" ")
// Example usage
const styles = css`
p { // This inline padding is for aesthetic reasons, we don't want this to scale
```
[0] https://www.joshwcomeau.com/css/surprising-truth-about-pixel...
For example, from this Airbnb article:
> In the case of Airbnb, the team decided to prioritize the use of rem units specifically for font scaling, rather than scaling all elements proportionally.
This can lead to undesirable outcomes as sometimes spacing between elements can have a functional purpose, e.g. making it easier to vertically separate one paragraph from another. If you use `rem` solely for font-size and nothing else users with `32px` as their default font-size would not have the necessary amount of space to help discern one paragraph from another in this case.
PS It looks like they use Linaria, one can simplify the transition from `px` to `rem` by declaring this helper function and using inside their `css` rules:
```ts
export const px = (...spacing: number[]) => spacing.map(s => `${s * (1 / 16)}rem`).join(" ")
// Example usage
const styles = css`
p { // This inline padding is for aesthetic reasons, we don't want this to scale
// with users preferred font-size
padding-inline: 16px;
// This serves a functional purpose, it will become `0.5rem 1rem`
// which should match `8px 16px` if users are using the default 16px font-size
margin-block: ${px(8, 16)};```
[0] https://www.joshwcomeau.com/css/surprising-truth-about-pixel...
just use tailwind, and everything else just ask ai
On web, use `overflow-wrap: break-word` and make sure your header can shrink.