[HN Gopher] Rethinking Text Resizing on Web
___________________________________________________________________
Rethinking Text Resizing on Web
Author : GavCo
Score : 131 points
Date : 2024-05-20 18:36 UTC (4 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| acl777 wrote:
| https://archive.ph/vYY8I
| warpech wrote:
| 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
| onion2k wrote:
| 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.
| warpech wrote:
| 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.
| whoopdedo wrote:
| 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.
| diego_sandoval wrote:
| 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.
| mperham wrote:
| Using the default 12px text size is a pretty good indicator that
| a website's entire engineering team is under 40.
| lagniappe wrote:
| 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.
| voiceblue wrote:
| 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.
| rjsw wrote:
| I have been short sighted since my teens but my eyesight is
| improving as I age, don't bother wearing glasses now to use
| a computer.
| trallnag wrote:
| You sure it is improving and not just getting worse the
| other way
| deathanatos wrote:
| ... 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.
| kevincox wrote:
| 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-...
| Kerrick wrote:
| Once you customize something, it's no longer the default.
| kevincox wrote:
| > the defaults can vary on different devices.
|
| Also there are different levels of default. The user can
| customize the default size of the document element, but
| this can then be overridden by the web developer.
| naitgacem wrote:
| I currently have HN set to 150% on my laptop. It is
| unreadable at the default zoom level.
| slater wrote:
| 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%.
| wonger_ wrote:
| 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?
| fwip wrote:
| 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.
| SuperNinKenDo wrote:
| 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.
| ec109685 wrote:
| 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.
| jwells89 wrote:
| 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...
| kibwen wrote:
| 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.
| sanjit wrote:
| 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.
| poisonborz wrote:
| 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.
| dexwiz wrote:
| 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.
| naitgacem wrote:
| 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 ...
| rezonant wrote:
| I'm hoping for the hand terminals from the Expanse: Project
| images into the space around you.
| MrJohz wrote:
| 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.
| lxgr wrote:
| 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.
| zozbot234 wrote:
| > 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
| wonger_ wrote:
| 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?
| skydhash wrote:
| > _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...
| wonger_ wrote:
| 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.
| skydhash wrote:
| 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.
| ludamn wrote:
| 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 // 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...
| whoopdedo wrote:
| 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?
| kevincox wrote:
| 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.
| daemonologist wrote:
| 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...
| tda wrote:
| 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
| alex_young wrote:
| 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.
| david422 wrote:
| I'd be interested to see what his sample graphic looks like
| after his "font scaling" solution. It is 1/4 the total space.
| mminer237 wrote:
| 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.
| lerpgame wrote:
| just use tailwind, and everything else just ask ai
| tlogan wrote:
| 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...
| naitgacem wrote:
| 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.
| sorahn wrote:
| 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.
| naitgacem wrote:
| ctrl+scroll on Windows generally scales the text only. Even
| the built-in magnifier is _extremly_ clunky and zooms only
| to 200%, 300% ...
| Vegenoid wrote:
| 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/
| drewtato wrote:
| This is also important for being able to show normal size text on
| smaller phones. I've got a 5.8" screen and basically every app is
| visually broken, with about 10% functionally broken as well.
| Every web or app designer should get an iPhone Mini or similar,
| crank the font size accessibility setting, and make sure
| everything works. In particular, any text that is truncated needs
| to have a line-wrapped version available somewhere, every page
| with content needs to be scrollable, and the input box needs to
| be functional (e.g. it must show at least one line) when the
| keyboard is out.
|
| On web, use `overflow-wrap: break-word` and make sure your header
| can shrink.
| Civitello wrote:
| As someone who has worked in compliance testing for tightly
| controlled software platforms, things like this piss me off.
| These problems have known solutions.
| kevin_thibedeau wrote:
| Works on my <1yr old iPhone phablet. Ship it.
| naitgacem wrote:
| 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
| hinkley wrote:
| The new Reddit login modal is a disaster even on an iPad mini
| in landscape mode. Does nobody test anything anymore?
| nicce wrote:
| 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.
| calvinmorrison wrote:
| I was so sad when they droppped the old /.compact interface
| which was heavenly
| dagmx wrote:
| 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.
| wruza wrote:
| 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/deg 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.
| madeofpalk wrote:
| > 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.
| zamadatix wrote:
| 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)? deg doesn't make sense until you pick a
| viewing distance, at which point you're really back to some
| scaled value of cm/in.
| wruza wrote:
| _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.
| zamadatix wrote:
| 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.
| wizzwizz4 wrote:
| 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.
| zamadatix wrote:
| 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.
| wizzwizz4 wrote:
| 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.
| zamadatix wrote:
| 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.
| wizzwizz4 wrote:
| 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.
| zamadatix wrote:
| 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.
| skydhash wrote:
| > 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.
| dvdkon wrote:
| 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?
| ffsm8 wrote:
| 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.
| refulgentis wrote:
| 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 branded as 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
| enriquto wrote:
| 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.
| wcrichton wrote:
| Do you believe that you could implement the Airbnb interface
| without any CSS or Javascript?
| marssaxman wrote:
| Does the Airbnb interface _need_ to be implemented at all?
| enriquto wrote:
| > 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.
| afavour wrote:
| 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.
| xtalx wrote:
| The web would pretty bland and less usable without CSS.
| White background and full page width Times New Roman
| paragraphs, inline images.
| wruza wrote:
| 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?
| wruza wrote:
| 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.
| mjw1007 wrote:
| 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.
| DrewADesign wrote:
| 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.
| skydhash wrote:
| 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.
| tambourine_man wrote:
| 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.
| jacobp100 wrote:
| The output is actual an CSS file - so it's not quite the same
| as other CSS in JS libs
| hypertexthero wrote:
| 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.
| lxgr wrote:
| > so that I can pinch-and-zoom
|
| Without requiring horizontal scrolling?
| hypertexthero wrote:
| 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.
| rrr_oh_man wrote:
| 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: :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)); }
|
| (Initially there was no `clamp()`, but I had to concede that
| point for a better UX on really large and really small screens.)
|
| [1] https://news.ycombinator.com/item?id=40408418
| dwallin wrote:
| 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.
| rrr_oh_man wrote:
| Agree! I cleaned up my comment. Hopefully it's a bit clearer.
| dizhn wrote:
| I guess nobody bothers to mention the text size issues on this
| very site anymore knowing it won't be fixed.
| skydhash wrote:
| 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.
| aimor wrote:
| If they want a better mobile site at 200% they should get rid of
| the padding around everything. That's one of the first things I
| change for "mobile" layouts (not that CSS wants you knowing when
| someone's using a phone) and it's an easy win. I know the article
| is parallel to this point, but I tried their website with 200%
| font and it's still unusable for me.
| GalaxyNova wrote:
| The newly standardized css `zoom` property might help with this.
___________________________________________________________________
(page generated 2024-05-20 23:00 UTC)