A collection of deep-deep dives on various topics would be a fun thing for someone who can build a nice website to do (You don't want to see my attempts at being a designer).
For example, "What every programmer should know about memory" covers memory but what about (as you say) screens.
No. Just simple heuristics that work for most users at the expense of people who admit, like OP's opening statement, "I’m a weirdo".
Building responsive client UI is hard. In my experience here, the falsehoods HNers believe about clients is that it's somehow not hard. Or just a silver bullet away from being easy (like replacing JS with $faveLang). Or that resources are infinite such that every defect is explained by incompetence (except for, presumably, that HNer who is intimately familiar with resource finitude in their own life).
It's 'hard' largely because the standards bodies and browser makers fail to provide simple and expedient means to do the most basic of operations, making every little thing a designer wants to do a giant hack.
For something so universal ... there should be a very clear and unambiguous function call and at least a rational way to move through the fragmentation molasses.
More like testing for an infinite number of resolutions is expensive so developers only test on the main ones and the ones used by hackers on Pop_OS Linux that rotate their screen 90 degrees are out of luck and default to one of the tested resolutions :)
One of the best features of my Lenovo Chromebook Duet (a 10" ChromeOS tablet) is that it reports itself as a laptop with 1920x1200 screen so you get actually usable webpages and not the mobile crap.
The proposed solution for developers doesn't work any better; DPI is correctly calculated on desktop, but nearly always wrong on phones. So fixing sites for vertical desktop monitors will break them in most phones.
I’d express it much more strongly than you have: doing what this article suggests is catastrophically wrong. For layout purposes you must not look at physical resolution. Physical resolution should only be used so that you can render on scaled displays at higher quality, e.g. by choosing a higher-resolution image, or by scaling your canvas by devicePixelRatio so you can draw more precise lines.
The proposed solution is not just no better, but far, far worse.
We use a web-based time tracking system that appears to assume that you're either on a device with a touch screen, or have an ultra wide display. You can't easily scroll side to side without touch, so the second best option is full screen on a ultra wide screen, so you don't need to scroll.
I long advocated that website started to use the more of the width of the screen on desktops, to avoid unnecessary scrolling. However, I just a frequently have two windows next to each other.
There's no real good way of satisfying all use cases, but it generally seems like desktops are being neglected when company design websites. Previously mobile seemed to be hacked on to an existing site, now everyone seems to go the route of: If it's good enough for mobile, it's good enough for desktop users.
It's a difficult one though - say I have left menu, and a sidebar on the right, and a central column with my copy. Very roughly, at about ~1350px (so neatly displayed on a generic 1440 laptop) I have about 250*2 (500px) for my sidebars, about 800px for my central column, which at a decent font size will give me a 'right-ish' about of words per line, and a few more pixels for gutters.
As you start to make that smaller - 1200, 1100, something has to change. We can maybe adjust the font size in the main column, maybe there's some flexibility to shrink the sidebars (but maybe there isn't, because we need an ad in there, and that can't be resized). So we have to adjust - lose a sidebar to a hamburger menu, or change our horizontal menu at the top to include the most clicked links (and not the ten links we have before). Maybe the search bar becomes an icon, because it's more important we push the "Buy Now" button than give people an option to search, etc etc.
It's an art - what do people need the most? What will make them convert? What can we remove first? What resolutions are most used, and how do we optimise for that?
I see your point, and I'm not complaining about that.
As you point out:
> Maybe the search bar becomes an icon (...)
I'd already be ecstatic about that.
I'm talking about features which are essential to a website that just disappear completely because the owner thinks "no one on a tablet will ever want to use this".
Haha, yes, it's definitely a balancing act! Thankfully analytics and heatmaps are a good start to figuring this out (even without applying common sense fundamentals)!
You can query for aspect ratio in CSS, yes. This can be useful for figuring out whether it's better to place something as, say, a sidebar vs a footer. The sites they are complaining about, however, are only looking at the horizontal dimension.
I think primarily that's for constraining a div's aspect-ratio. Like making sure you have a div that's always 16:9 to hold a video player. I'd be interested in hearing other use cases, though.
The aspect ratio media query just lets you apply certain CSS to the page depending on the viewport aspect ration. It does not set an aspect ratio on an element.
Maybe there’s something I’m missing, but I’m not sure how knowing the aspect ratio of the screen would help make an element 16:9. If my browser is narrower or wider, that doesn’t affect how I would style the element.
The first DPI detector site detects my 55" 4K monitor as 442 DPI (5120x2880 at 13.3") when entering my resolution and diagonal size in inches gives me 80 DPI. The other one detects it as 192x192 DPI which is a much larger number. Maybe the first number means it should be 80x80 DPI but either way 192x192 is much larger. Maybe I'm missing something.
At least these sites have a desktop oriented UI. Modern Gnome just assumes you're always on a phone (even though the phones capable of running Gnome are still extremely niche.)
Wait, so sniffing on screen resolution is the way web developers distinguish desktops from mobile? That's just crazy.
There should IMO be a preference sent, "I'm on a portable, touch-enabled device". I'm guessing it doesn't exist because it would add a bit to the fingerprint.
In this case, "portable, touch enabled device" wouldn't match what we're talking about. Someone with a large tablet should receive the version optimized for larger screens.
The website is saying "if your screen is at least this big, I'm going to show you the version for big screens". The OP has an unusual setup where their big screen is reporting as a smaller screen.
> Someone with a large tablet should receive the version optimized for larger screens.
Not necessarily, because the “smaller screen” layout tends to be linked to the touch one e.g. larger active targets, while the “large screen” layout is optimised for precise pointing devices (mice) and may be nigh impossible to interact with using fingers.
the way that web developers generally do responsive design is to use media queries checking the width of the screen they are on, as opposed to the device width.
This is the suggested way because if you check the device width you know that they are on a small device and thus probably mobile but your styling changes for small windows (less wide windows) do not get applied, so 'best practice' is to check the actual screen width. Hardly anyone checks the height because for web development height is generally not that important.
But this is often not useful because a lot of web solutions style things based on JavaScript and CSS and while the CSS will rerender automatically based on changing the screen size the JavaScript needs to detect you've changed the screen size and then rerender. So then there is a discussion as to how many people really resize the windows and do we need to catch this resize to do a rerender even though doing so is irritating and can be a resource hog (fixable by extra code but maybe better not to code at all!)
But there are lots of other ways to detect if you are on a mobile device, you can detect if touch screen events are enabled etc. but then what if you have one of those weird desktops that became possible a few years ago (I nearly wrote popular instead of possible) where your laptop's monitor also has touch screen events.
As a general rule it is best to do things based on the capacity of the system, and not by what type of system it is, but as the capabilities of our systems exist in infinite combinations it follows some things will just fall through no matter how exacting you try to be - maybe especially if you try to be too exacting.
> Wait, so sniffing on screen resolution is the way web developers distinguish desktops from mobile?
There’s really no other information since “physical” dimensions are completely fake: a CSS inch is 96 CSS pixels which are “one pixel at 96 dpi at an arm’s length”.
Screen resolution is, more or less the best approach.
Layouts need to fit a size, not a device, so that's why media queries based on the screen size are usually the best approach. If I resize my browser to make it smaller, I should get a layout to match that. If I'm using Safari on iPad, docked to the side of the screen, I should get a layout to match that. These are all about screen sizes, not "mobile vs desktop".
For testing interaction cabailities, there are the @media (pointer: coarse) and @media (hover: hover) media queries for testing touch vs mouse, and hover capabilities, but it's important to not rely on these for mobile vs desktop layouts otherwise tomorrow a MS Surface user will post "Just because I have a touch screen, doesn't mean I'm on a phone".
Best practice dictates "mobile-first responsive design" with "progressive enhancements." So designing first for mobile and touchscreens seems ideal, and then adding special features for larger resolutions, and, in a separate media query, for devices with (hover: hover).
The general idea with well built responsive design is to build a site that works at any width, reflowing as things would break. You can try it by just resizing the window of most popular sites to be progressively smaller.
It’s honestly been a significant improvement over dedicated mobile layouts and for the most part works pretty well.
Yes, they define a bunch of @media filters in css for different known screen widths. You usually get a surprising look when pointing out that it is crazy. “How else would you know that?”
Something as simple as “use-case: handheld | bellyheld | desktop” property? Css designers missed this opportunity completely.
You don’t, because you don’t know how far from that screen a user is. User can override default mode in a browser’s toolbar. That’s what OP wants but has instead to jump through dpi/font/scale hoops to achieve it. You may want to use desktop, tablet or mobile look that is not related to your device width.
It's a bad habit, but it's pretty common. Really, there's two distinct things to consider when building responsive design. One is viewport size (and really just width in most cases) and the other is touch vs mouse. Vertical monitors is one case, but so is touch-enabled monitors or mouse-enabled handhelds. Most of those are considered small enough edge cases, that it's not worth investing. Most websites look kinda crummy if you use a phone in landscape too.
I used to insist that designers never say "phone, tablet, desktop" and instead say "small, medium and large" but it never stuck.
> Wait, so sniffing on screen resolution is the way web developers distinguish desktops from mobile? That's just crazy.
No, it's not how it's done. And there is generally no logic trying to see if it's a mobile or not. One just have various designs for various sizes. When he has a 700px wide display, what else can the website do than collapse the content when it's not enough space for it?
Client hints (proposed successor) are the same thing but more selective. That is a site has to request extra information rather being given right away. Among them are platform and mobileness.
The real problem is that designing for different screen sizes, especially with responsive design, is very difficult.
For my personal projects, screen size is the factor used to determine layout. Mobile/tablet/laptop/desktop is irrelevant. My goal with smaller viewports is to make the layout as similar as possible, without the user having to scroll horizontally. Because I don't want to change the layout too much, I do not use hidden navigation menus.
Hamburger menus are terrible - I see them as a design copout.
I'm curious what your menu solution is. I agree hamburger menus besmirch the good name of the hamburger, but for longer menus they feel like at least an acceptable solution.
I like gear icons, sometimes they don't map to exactly the semantics of what is in a menu, but if there are no other possible menu elements than I know to go to the gear icon.
I've become used to the hamburger menu, but it still doesn't catch my eye (Chrome's now three dot option is even worse at this), gear looks noticeably different than the rest of the UI and so I can easily spot it for options.
> Hamburger menus are terrible - I see them as a design copout.
I am genuinely interested in why. The only reason I can think of, is that they may me unintuitive, but I think this is becoming less and less of a problem.
Hamburger menus are an accepted and pervasive design element. That does not means it’s good design, but it means that users are familiar with the concept. Familiarity goes a long way to ensuring good UX.
Just use the word "menu". The hamburger menu (and its cousin, the three vertical dots) have no analogy to the real world.
Sure, it has become more common, but for anyone not already familiar with it, it is utterly useless. You have to be willing to click random things to discover what it does.
From personal experience, I had to train both my wife and mother to look for them, neither of whom had the patience otherwise to figure out these cute designs. They may be common at the sites you look at, but that doesnt help people who have only used sites without them, or only used portions of sites accessible without clicking on them.
It’s not that hard to display a few paragraphs. It’s hard to display complex pieces of information while also making them look good to the client (which, we should remember, pays our bills)
A message board like HN is more difficult than you think to get right across a wide range of screen sizes, just because comments can nest many levels deep. HN arguably has problems of its own in that regard.
Almost all websites are pretty minimal in terms of their
features, but they're built as if they were an in-browser image
editor.
Reddit is barely more than HN with pictures and a LOT of bloat
inbetween. It could be as minimal as 4chan-style imageboards if
you add voting and a slightly different comment view.
Youtube is just a tiled list of thumbnails or an embedded video
player followed by a list of thumbnails. It could work 100%
without JS outside of the video controls. Instead it's a huge,
slow mess. It's also inconsistent; in my case it scales the
list of videos from subscriptions to about 50% of the browser
window's width, leaving a chunk of empty space on the sides. The
startpage with basically the same layout always uses the full
width.
100% agree. The kneejerk reaction of "well HN is so simple, of course it has a simple design" has the causation backwards. You only realize how simple HN is because they stick to a simple design!
99% of websites are (could be) just static text and images. Facebook, Reddit, CNN etc could look like HN. Amazon could look like craigs list. The amount of sites that actually need and are enhanced by JS bloat is very low.
Pinch zooming works on HN, which helps me hit the buttons. I might prefer slide-to-action like narwhal's Reddit interface, but I'm OK with HN not being quite that fancy.
Lolno. I have to make Firefox take only half the screen, otherwise HN will render wiiide lines with text. I cannot read lines with >200 characters, then I miss the mark when jumping to the next line when it's multiple lines in a paragraph. HN is also the only site I have zoomed in on desktop, as the font is unreadably small on high dpi devices.
And on mobile I find it impossible to hit the upvote arrow.
I can read long lines just fine, and I like that the full width of the viewport is used.
Because HN is designed so simply, you can trivially get the layout you want (half width lines) and I can also get the layout I want.
If HN instead tried to artificially limit the viewport in code (which is something lots of web developers do), they would break all sorts of other use cases for no reason. That's what I mean when I say websites tend to overcomplicate their design.
I read HN on mobile all the time, what is the problem with it? The only issue i've noticed is being a bit harder to tap the show/hide branch icon but it is a minor issue.
That's why i like to keep an 19" TFT screen as a third display on my desk, most websites render perfectly on it and i can always have a browser in the foreground.
I prefer that way, way more than going to, for example, Github and doing a code review and the website refusing to give me more columns to look at in side-by-side view, because they think that the number of lines they've enabled is perfect and want to have the sides of the screen be full of whitespace that you have to modify the layout of the website to get rid of.
Or random blog sites that become a narrow column of text and a *huge* amount of whitespace on either side.
Browsers should have more say. In a perfect world, the web developer should not even need to know the browser's width or height, whether it's a phone or computer, or what kind of input devices are available. The developer should simply provide some kind of semantically tagged content (text and images), a list of suggested colors and fonts, and let the browser make the final call, based on what's best for the particular platform and screen size.
Somehow we've gotten to this world where the web designer expects almost-pixel-perfect control over the layout of every little thing on the page, user's preference be damned. You're not laying out a magazine page in a desktop publishing application!
Sure. Now let's say you're shopping for a brand new rug for your living room. Are you going to buy it from a site the looks like HackerNews? If so, I'd venture to say you're in the minority. A used rug from Craigslist, perhaps, but a brand new rug costing hundreds, you're going to want a site that looks VERY professional.
So you’re saying “professional == follows modern design fads” as a proxy for how legitimate a site is. And maybe you’re right that is a somewhat useful (if unreliable) proxy for legitimateness, but it’s not an argument that it’s good design.
Actually I've bought rugs and computers from websites not much more complex than HN. Both sets of transactions went smoothly and quickly with no issues. I wish I could say the same for some very flashy websites I've used. On some I can't even get a delivery estimate until I've submitted credit card etc.
And yet quotes don't wrap to any specific size, so you end up with an awful horizontal scroll bar.
There is no way to format your text, even stuff that's available since MS Word 1.0, such as bold or italic. Even science papers have formatting so I don't buy the "overuse of styles" BS.
There is no way to have avatars or some other ways to distinguish users (or mods!) to make this place feel more like a community in real life. I've gotten used to it but it still sucks.
The contrast is super low.
HN is an MVP for a super minimalist forum that wouldn't fly for any other kind of community except for the intersection between hackers and wannabe entrepreneurs.
If you weren't aware https://news.ycombinator.com/formatdoc may be helpful. There are some basic options for text formatting on HN, including italics and bold.
Yes, I know people do things like that (mostly on Twitter, it seems), but I wouldn't recommend it; it'll interfere with searchability, copy/paste, etc., and generally make the text less interoperable. The mathematical alphabets in Unicode are intended for specific technical uses where the typeface is an inherent part of the symbol's identity, not for styling normal text.
Now try a screen reader (on a mac, Edit > Speech > Start Speaking will do nicely).
Spoiler: You mean mathematical sans-serif bold small l, mathematical sans-serif bold small i, mathematical sans-serif bold small k, mathematical sans-serif bold small e, mathematical sans-serif bold small t, mathematical sans-serif bold small h, mathematical sans-serif bold small i, mathematical sans-serif bold small s?
Why don’t people point out how terrible screen readers are then, instead of criticizing people posting online who cannot be reasonably expected to stay up to date with Unicode and screen reader functionality?
Yes, because avatars and signature blocks (which are useless, I agree), couldn't possibly be designed to be tasteful and fast to load. Especially avatars. A 30x30 image of any kind would be enough to convey more info about the speaker.
I’m much happier that it isn’t a “proper” community with avatars & such, fwiw. Much like I’m not fond of small talk, I’m also not fond of the obligations that come with social media.
I can't downvote (I think?) and I don't miss it. I use an android client (Materialistic) that doesn't even provide me with an option to do so, and I haven't looked for a way to do so. If I disagree with a post or comment and don't want to add a response, I just move on. If I'm in the browser, I'm probably not even signed in unless I want to upvote or save something.
HN is almost useless on mobile. Tiny UI elements that are hard to hit, people using code blocks for quotes that cut off after the first few characters, etc
At least it allows for pinch zooming, which is (IMO, of course) an acceptable compromise. Maintain readability for the text while still making it possible to hit the UI elements.
It does clamp text at some max width. If you have a couple 1440p monitors try stretching the browser window across screens.
Its actually one of those cases where the old news print model of multiple columns would work well, but that is much harder than it should be with CSS, so pretty much no one does newsprint style scrolling where you read all the columns and then scroll to the next set.
For my own ventures, I always use a fixed width layout. Saves an almost infinite amount of time, tricky bugs, and therefore
a lot of $. Designers produce designs and you just take the pixel dimensions it always looks good. Done.
OTOH, when clients tell me they want responsive design - no problem! It's job security, and I bill by the hour ;)
On iOS it just changes the UA. This means that regular CSS-only responsive sites don’t change at all, unlike what the other 2 comments are suggesting. Maybe on Android it’s different.
Portrait viewing for screens bigger than tablets are edge cases of edge cases.
The rabbit hole is websites are supposed to cater for every screen size by pixel is ridiculous. At some point the user should respectfully use normal orientated/ sized device.
I feel like this is a more complex problem to solve than it seems at face value or the author implies, especially considering tablets of varying dpi.
CSS dpi media queries are unsupported in Safari mobile and desktop, so that increases the complexity significantly.
Beyond that, the fact is most web layout is still done in px or other non-fraction-of-the-width units, so it’s often a matter of the wider layout simply being broken at smaller widths, rather than just refusing the display.
Yeah, I was trying to find a way to create a toolbar with buttons and make sure the buttons are not too small or not too big. DPI info is not present and different tricks to work around this will fail on different phone models.
I wish I could ask the browser "what are the dimensions you the browser use for your buttons" so I can use same dimensions too and the user could configure this in his browsers and everything would follow it.
In theory this is what css { font: caption } should do. There are other font shorthand’s for menu text, icon labels, dialog box text, etc. that should clue you in to how a particular system UI is scaled, if browsers are doing it right. (Of course they also might not because of fingerprinting risk)
Note that this is different from { font-family : system-ui } which doesn’t include size information.
Caniuse sadly doesn’t have much info on font: caption support.
There’s a good reason why there are no real DPI media queries: You should not decide how big things appear on the screen, that’s up to the user. The user has the ability to change resolution or to change the website’s zoom level, you should never access the real size and decide that a button must be exactly 1cm wide in real life on every screen for everyone.
Just design for the default and then people will zoom or change resolution if the default isn’t enough.
The UA doesn't tell you anything about the screen the person is viewing on or the size of their window. If I resize a window on my desktop to 450x1000, showing me the layout for narrow screens is likely the best option.
Because a single user agent and present websites at multiple sizes.
Consider an iPad which can display a website at three vastly different sizes. Full-width, half-width, and roughly 1/5th width docked to the site. They should have at least two different layouts.
What if the person is using an Android phone connected to a monitor? As someone said in another thread: you design a view for a screen size not a device.
Mobile has some unique characteristics that don't fully allow agnostic design, namely:
- viewport changes size due to soft keyboard
- address bar hides/unhides during scroll down/up
For certain types of apps, like games, it's important to know whether a device is actually "mobile" regardless of size/resolution. Sniffing user-agents might have to come back into vogue. Who knows where "mobile browsers" will end up - maybe some giant 60" kiosk app, or other places.
Barring that though the article brings up good points and searching the web for how to detect mobile usually brings up the error-prone portrait/landscape resolution detection that the article discusses.
The full solution requires the knowing the resolution and the dpi to get an estimate size of screen in inches. At least with that we can be safe until next article "Just because I'm a 100" kiosk app, doesn't mean I'm on a phone".
I've been using 3 vertical screens side-by-side for years. Like web pages, source code is also long and (usually) not too wide. Being able to see that complete method / function without scrolling is invaluable to me. Square screens would also suit me well, but they don't exist, sadly (apart from very expensive Eizo).My current resolution is 3x 1440 x 2560, so luckily I don't get mobile versions of web pages.
Wholeheartedly agree. And this apply not only to vertical.
I have a Samsung Tab A Tablet (Model SM-T510) that has better resolution than my notebook (A Lenovo T430). A page that displays very well in the Lenovo (1366x768) displays like crap in the tablet (1920x1200) even when using it in the landspace position.
Sites are not detecting a portrait screen and deciding that they're displaying on a phone. Someone who switches their monitor to portrait, or resizes a window to be taller than it is wide, is still going to get the desktop view.
In this case the author is scaling their resolution, and so their browser is presenting itself to sites as 720px wide. Sites see that and show a layout optimized for a screen of that width. Those sites are acting correctly.
The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
Agreed completely. One mistake that designers/developers do though is to completely give up under 1000px so we get this swaths of whitespace and a hamburger. That’s a waste of estate and a waste of my time.
Yeah, I still very often get "here is the desktop design, here is the mobile design". Depending on who is developing the designs depends how that's going to translate.
I have all the time in the world for developers that reflow the page and remove/adjust elements at different breakpoints (based on the design) between 'desktop' and 'mobile' so the experience is good for everyone. Sadly, most people don't bother.
Convincing a client to pay for time to spend checking the design and tweaking it in the space between the breakpoints can be more hassle than it's worth.
That said, sane breakpoints can usually avoid unexpected hamburgers on the desktop.
You convince them in the same way you convince a PM to give you time to write tests for your work: you don't give them an alternative. "You want this done? That'll be 20 billable hours." And your estimate includes the time needed to do work you're willing to sign your name to. When I hire a plumber or an architect, I tell them what needs doing, but I expect and trust that they'll put in the work (and bill me accordingly) to ensure that it gets done properly, even though I don't understand all of the specifics of what doing those jobs properly entails.
that's something I don't understand. the Dev tools in Chrome and Firefox make it really easy to test through every resolution without problems. every UI change I make I view in all possible resolutions and its quite obvious of something breaks and I adjust accordingly.
If it takes too much time, you are probably doing something wrong like having hardcoded layouts for different resolutions instead of using reflow as much as possible.
Even with all reflow it's hard. Should I reduce a width a little bit more so that it become 3 columns instead of 2 on iPad vertical at risk of having some line wrapped? Things like that.
I like to start on the desktop but build in a way I know the objects will flow. Then I set up a tester with a bunch of breakpoints and check as I go and make micro adjustments to each element that is "off". Then you can set the element inspector to the side and just keep shrinking the screen to make sure nothing is awry as the width gets less and less. I don't really have X sets of 'rules', just elements adjusting at the point it feels right to adjust them.
For my day job working on a UK e-commerce site that gets roughly 100,000 uniques a day, our split is 70/30 for mobile/desktop. Unfortunately within the company it’s closer to 1/99. So no matter how many times I repeat the phrase “mobile first”, the higher-ups just don’t get it. Luckily I can make rational decisions for them!
I believe true webdesigners are in decline. You have lots of people who do this as a side gig after reading a few tutorials. In a way that’s a nice compliment for the accessibility of the tech, but not accessibility for the end user.
Same with “We only tested this on Chrome.” of sites/apps, of which are there are many, as I can attest, as I never use Chrome.
It's just plain hard to keep up with front-end tech. Most people use front-end dev work as an entry point. They quickly realize there are more sane jobs available on the backend and migrate there.
I don't think apps are as relevant to current discussion. For apps (not public websites), there are different requirements depending on the target audience.
I wouldn't be mad at a B2B web app being desktop only, no mobile CSS.
But I agree that web apps should still be compliant with safari + FF + Chrome.
> I believe true webdesigners are in decline. You have lots of people who do this as a side gig after reading a few tutorials.
In decline from when? Picking it up after reading a few tutorials has always been a common way to get into web work, and if anything I feel like it's been getting more professionalized over the last twenty years.
Just the general gist over the last few years. I am not saying there are no really skilled professionals, I am just seeing a lot of lower par work from jobs I take over. Plus just by surfing the web and noting the quality.
I’ve been doing web development since 2007, and I’m struggling to think of an era that had more professionals doing front end than we have now. I’m not sure my experience agrees with you
I've emailed one of YC's huge successes multiple times over years about how it's frustrating to have horizontal scrolling on a browser that's half of a 1080p display wide (i.e., nearly 1000px).
Unfortunately, the horizontal scrolling UX with substantial wasted whitespace on the sides remains.
I've found sites using Material UI guidelines (heavy use of cards and navbar hamburger) especially culpable to this. Huge gap of greyish whitespace with a hamburger in the left.
Someone else mentioned bootstrap in the other thread too.
Maybe because these Frameworks are hugely popular, their defaults amplify the impact. Definitely these values are tweakable.
As it happens though, with the navigation design they chose, the entries wouldn't fit at that width.
They certainly could have added an extra breakpoint where the navigation becomes smaller before bailing to a hamburger, but of course that does add complexity.
I suppose, but "Deliver with Just Eat" is a pretty long, and an overall odd choice for a top menu item. Wasn't clear to me that it meant "drive for us". And that's what's eating the width.
This doesn't address the author's central argument, which is that websites need an effortless way of letting fonts become bigger without affecting the entire layout. I've wanted it too. I don't really care if some text gets cut off on headers and looks weird, I just want to read stuff from the comfort of my bed with my laptop a few feet away.
I love that Chrome on Android lets me zoom into any content on any site, regardless of how bad the devs borked the UX. (Yes, devs, if you don't allow me to zoom using the browser's built-in capabilities, you have borked the UX, and should be ashamed of yourselves.)
If you have a windows 10 laptop, pinching on the touchpad seems to give you the same zoom functionality now. vastly superior than the one built into the browser
I didn’t know this! And inability to do this is a huge pet peeve (as well as not being able to zoom OUT and get a desktop-like view on my phone). Does this work on any browser for iPhone?
This is one of the main reasons I prefer using a website on my phone as opposed to an app. Some apps allow me to zoom others don't. The browsers lets me do that regardless.
If you're using a mobile browser on Android that doesn't allow overriding websites that disable zoom (or using a website that defines font sizes in vw/vh), check your accessibility settings, there should be a shortcut for triple-tap to enable a zoom function. Some devices have other magnifying functions as well. My tablets and phone all have the basic magnifier function; my LineageOS (android 7 & 8) tablets additionally have a screen zoom/dpi setting to modify how large both pictures and text appear, and my samsung tablet (Android 10) has this and also a text zoom function. There's also a minimum view width setting in developer options since at least Android 8, to ensure interfaces aren't too small on mobile (this only goes one way though-- there's no maximum view width and no height controls).
It doesn't help with everything, but the triple-tap zoom is quite useful.
This was tried in the mid-late oughts was it not? It is nearly impossible to logically derive what should increase in sized and what should not.
Should the space given to sidebars increase? Should those sidebars disappear? What about headers and footers? How will the overfloat be treated? A single line, double lines? What about captions underneath images? How do you handle text that happens to be embedded within images themselves, or even on top of images?
"I don't care if headers look weird"
It goes beyond things looking weird, it really does break websites.
That's how zooming (ctrl+scroll) in the browser used to work: It increased font sizes. It has been abandoned because it just wreaks havoc on the layout and is impossible to handle properly.
It was so standard, it wasn't even called "zooming", because it wasn't. It was called "increase text size". It worked well for most reasonable sites, certainly a lot better than an actual zoom typically does.
> I just want to read stuff from the comfort of my bed with my laptop a few feet away.
That's not what laptops are for.
I think that's a typical snide HN/Stack Overflow-type answer, and I don't mean it rudely, but it does have some bearing on this conversation. What's the intended form factor of a laptop? What are the top 10 intended form factors? I'm not sure "reading from 'a few' [several] feet away, while I'm laying down in bed" is in that top 10 list.
Are there devices better suited to that form factor? I don't know.
> What's the intended form factor of a laptop? What are the top 10 intended form factors?
Isn't the real questions why we allow devices or their makers to decide the "intended use-cases" and accept that many other use-cases are often near impossible. The PC revolution was about a general purpose computers, and laptops should imho still be general purpose computers; not machines for which some overlord in Mountainview or Cupertino checks on every button pressed whether I am allowed to do what I intend to do.
Politics aside, I am the only one who has the impression that with every new release of macOS or Firefox features get removed, that enabled me to personalize and optimize my workflows before?
>What's the intended form factor of a laptop? What are the top 10 intended form factors? I'm not sure "reading from 'a few' [several] feet away, while I'm laying down in bed" is in that top 10 list.
I mean, I guess less so now that everyone has phones and maybe an e-reader, but... that's not such a weird use case. That's basically how I spent the later half of high school.
On mobile: all browsers have "force enable zoom" + test scaling in accessibility settings; Additionally Opera supports reflow on zoom (Settings > Text options > "Text wrap").
I don't really care if some text gets cut off on headers and looks weird, I just want to read stuff from the comfort of my bed with my laptop a few feet away.
How is a web site supposed to know if you're someone sitting in bed with the screen a few feet away, or someone sitting at a desk with a screen a few inches away?
That's on the user. Learn how to use your browser, device, and operating system's zoom features.
I just have bad eyes. I complained once about text size here and a lot of people just said, "use your browser zoom", completely ignoring how layouts not scale or reflow.
When people lay out desktop sites, 960px is the smallest common minimum design width. Many of these sites are statically laid out, and if rendered with the width of 949px would require horizontal scrolling.
Yes, if these sites were not statically laid out, and instead gracefully handled any size they happened to be rendered at, providing a viewport width of 949px would not be a problem.
Yes, and webdevs have been trying for over 10 years now to figure out how to get this right. Has no one just stopped to consider having a browser send a `prefersMobileView` or `viewport:phone` or anything like that? I can remember back a few years ago, an iPhone 6+, turned sideways could get a desktop view on some sites... simply because it met the requirements set by the author. Now, the author's assumptions were wrong of course, but all we have to go on, is literally guesswork. We're told constantly NOT to use user-agent strings, but honestly, it's like we really need something to key off of. I know the A List Apart folks would have us create content that can be viewed on ANY viewport, but I consider that a tad bit unrealistic. I've been out of Front-end dev for a few years though, so perhaps things have changed.
> Lay out content based on the viewport width, in CSS pixels.
This is wrong because the viewport width is not the same as the monitor width or the DPI: especially on big monitors running the browser fullscreen is very hard to use (my browser rarely exceeds more than ~50% width on a 2560x1440 monitor and even when i use a 1366x768 monitor - which btw is at 22", not some tiny laptop one - i very rarely use it maximized).
Most "mobile" usage is actually stationary, typically seated. If you really need to change layout based on motion you can use the accelerometer, but I can't see why you would?
The problem is that the horizontal space only tells you how many pixels are available, not how big whatever you use those pixels for ends up on the screen.
The precise vs coarse isn't helpful either for something like this because this isn't just about clicking vs tapping, it is about how the end result looks - and there are PCs with both very small monitors and very big monitors (and relatively large monitors with low DPI or small monitors with very high DPI). CSS pixels only help for setting sizes/positions, but not layout.
AFAIK the best that can be done nowadays is resolution media queries but that isn't available everywhere (at least according to caniuse).
Of course in practice i expect none of the above to be used and have my browser simply zoom out whenever i reach many sites just because i do not want to maximize my browser :-/
CSS pixels are good for layout, not just sizes and positions, because a pixel (in a browser) now represents an apparent size. That is, if the user has a large device far from their face, or a small device close to their face, a pixel represents a similar portion of their vision. If they want things larger, they can adjust the scaling so a pixel represents a larger apparent size, or the reverse.
This is never true in practice though and what you describe is just about sizes and position, you can't change the layout with CSS pixels - you need resolution media queries for that.
Isn't that still true in 2021? I haven't been particularly fond of the mobile view of most sites I come across. I force desktop-view on my phone fairly frequently just to get at features/pages I want.
It is still maybe a little bit true, where some sites will make some things only possible to do on desktop, but when the iPhone came out mobile sites were generally incredibly minimal. They needed to be, to handle existing devices and browsers, which were much less powerful than the iPhone.
Mobile websites pre 2008 tended to be WML over WAP. If they existed they were terrible, probably created by an intern once and not updated, because very few people used mobile phones for internet access (other than say linking their PDA or notebook to their phone via IRDA)
IMO the best solution is to just have natural breakpoints (i.e. when a part of the design of the given page would cease to work, add a breakpoint to change the format of that component, rather than at predefined points) and then for logged in users have an option to request the desktop design, which you can do by simply setting a viewport to 1000px width and leaving everything else unchanged
what would be really nice would be element-size-based media queries. you can use javascript to do it but that sucks
I think we really need to be able to more cleanly separate content from the design, and let the browsers, a.k.a. user-agents, decide/override more. Browsers have ceded too much control over layout and visual structure to web designers, who go on to make (often incorrect) assumptions about how the user wants to interact with their content.
the problem is that there is no distinction between a webapp and a document, the line is thoroughly blurred. For documents, you can probably just override a fair bit of schenanigans and things will still work, if look somewhat ugly, but for a spreadsheet app that's a rube goldberg machine of javascript and continuously regenerated html and css, it'll just turn it into a broken mess. the browser has become the de facto cross compatible application platform, which requires handing a lot of control to websites.
That sounds similar to a CSS proposal called container queries, which has been a much-requested feature for many years. Currently the only native way to do responsive design is to make styling changes based on attributes of the viewport (like width). But like you say, it would be nice to have dynamic layouts for every individual component of a website. Container queries do that.
yeah I heard of those, I was blanking on the name, thanks for pointing that out. Another thing I really want would be position:device-fixed; but that one doesn't even seem to really be on the table for the most part.
The A.V. Club took flak for turning all their lists into slide-shows on desktop. Their response was to tell people to adjust their browser width to force the mobile view. When you load a page, it preloads the assets for both views and switches based solely on window width. If you play an embedded youtube video and try and toggle full screen mode, the site reverts back to slide-show and breaks the video.
That's horrific. And the content is off center at full res so they can load their sidebar that well, isn't so much as off to the side as halfway into the center of the screen.
Personally, I'm not a fan of having a web site designer thousands of miles away from me just decide what font and text size I should be using to read their web site. Why not let the browser more easily control/override this? We already have PDF if your content truly needs pixel-perfect layout. Browsers have kind of dropped the ball. They're limiting user choice and slowly turning into desktop publishing platforms rather than being agents of the user.
Most browsers have a "minimum font size" setting, which would be applicable here.
In general, CSS already provides a bunch of generic font families and sizes. So a page could style something as e.g. "sans-serif" and "large" - and then the browser should figure out what this actually means according to user settings. The problem is that very few sites actually use these. But for those that do, the browsers do the right thing - and, again, most of them let you configure what the generic font families map to.
It could be easier in Firefox where it applies per language, with no "just set everything" option (at least Latin and Other are needed for english). I highly recommend using it, although it does break sites occasionally (seems like less often these days).
And it would have been avoided entirely if HN simply used relative font measures (em/rem) and allowed the user just set the damn base font size in the browser settings.
Do you also think every site should come with a built in screen reader? Accessibiliy should be about enabling everyone to use the website - using additional tools if needed - not to dumb it down to the lowest common denominator. If zoom / min font size breaks things complain about that, otherwise don't force giant fonts on everyone else.
Is that really an issue? Javascript is basically universally supported on the web.
Users with NoScript will just have to live without some functionality. I'm sure they are used to that already, since a large fraction of websites use JS for styling. (I use NoScript)
I would add to this that the specific sites in question have fairly unreasonable media-queries: The Guardian breaks to mobile at 980px, and Just Eat at 1024px. On my MacBook Pro with default scaling, these are both more than 50% the width of the monitor; i.e. if I size the window to half-screen, I'm in mobile mode on these sites. For reference, in sites I make I usually set the mobile breakpoint closer to 768px (note that this isn't a question of increasing pixel-density on phones; "CSS pixels" are virtualized to approximate the same physical size across devices, though they get affected by display-scaling too).
So IMO it just comes down to some sites doing a bad job of picking responsive breakpoints.
Edit: Out of curiosity I checked MDN, and their media query tutorial has you set the mobile breakpoint at 40em. Default font size at least on desktop is 16px (again, virtual pixels which scale with display-scaling and device size), which comes out to a breakpoint width of 640px: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
I just checked and the iPhone X has a height of 812px. It has a width of 375px. The regular iPad has a width of 768px, and the iPad Pro has a width of 1024px. So you could be right about them trying to capture all tablets, though a hamburger menu on the enormous iPad Pro sounds just as ridiculous as it does on a vertical monitor
The hamburger is more for "better" touch navigation though. I know these devices work fairly good with standard hover type states now, but the UX could be argued to be better when optimized for touch inputs.
Sizing is another matter entirely, in which I would agree, yea a tiny hamburger menu on an iPad Pro is likely bad. We all have engineering budgets though and in the grand scheme of things, iPads are likely a small fraction of the visitor base for these sites, so I get it.
This is more or less what we have at the moment, with DPI scaling ensuring that 16px in CSS roughly is the same amount of physical distance. On a phone with a 2x DPI scaling (like an iPhone), that’ll render as 32 physical pixels.
You absolutely do not want to scale the page to the same physical size on different screens because you also need to take into account distance between screen and your eyes. Text on phones can be smaller physically than text on a desktop monitor because you hold your phone closer. As an even more extreme example, think of browsing the web on a TV screen while sitting on the couch and how small the text would be if it is physically the same as it is on your phone.
w3c never wanted to implement physical units [1], saying OS are not reporting screen DPI reliably, etc.
I understand they had to start with something and 20 years ago no one expected thre will ever be monitors with DPI > 96 but I don't understand why the situation hasn't changed yet. Now that we have many physical screen sizes with vastly varying densities.
In my opinion, devices with a screen are like a sheet of paper. Imagine a tablet or Remarkable eink. You can print only that small font on such paper. If the font is too small, we can use a magnifying glass or, in case of electronic devices, clever scaling mode.
If that was implemented, buying a bigger monitor would actually mean we could fit more content, wider newspaper there.
The current situation is just a mess with designers just randomly guessing how it's gonna look on most current devices and using media queries to somehow automagically solve it all. But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height and there are empty unused paddings everywhere. I.e. if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily. Sometimes all you get is three columns of text instead of one. Sometimes. If media queries are set up reasonably well. But even then, on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally...
I think you're conflating "bigger monitior", "higher resolution", and "high-dpi".
> But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height
> if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily.
I don't think this is the case at all? The web and browsers handle DPI scaling incredibly well. I don't think I've ever ran into an issue with it. Remember that Apple has been shipping high-DPI monitors for the past 15 years, and I've never experienced these issues of a website of a website not handling this. More or less, the browser completely abstracts this away - you have to purposefully screw things up to render things at different sizes depending on DPI.
The current situation is not a mess; it works pretty well:
* Manufacturers configure their devices to ship with reasonable default settings, where is CSS pixel is roughly the same apparent size for everyone.
* Users who want content to be displayed larger or smaller can change their device scaling, which then makes their CSS pixels larger or smaller.
* Web developers can write for CSS pixels, knowing the content will display at a reasonable size for the user.
> if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecessarily
It sounds like you're probably sitting closer to the monitor then expected? Lower your device scaling and things will be a better size in all programs including the web browser.
> on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally
I think this is also running into user preferences and design. If I'm reading an article, and there is just one stream of text, I'm quite happy for it to take a 40em strip down the middle of my screen. If the text ran edge to edge it would be much harder to read, because it's hard to keep your place when jumping to the next line.
There's no more a "break to mobile at 980px" than a "break to mobile at 1140px", it's just the one you have a problem with. A responsive site scaling at multiple breakpoints isn't like switching to a mobile site just because it changes its "More" menu to a hamburger. The problem seems to be your choice of hardware coupled with your split-screen window size plus your want of three rows over two at a specific site; remove one and the problem goes away. To me The Guardian is scaling perfectly well and trying to paint it as switching to mobile is disingenuous. I'm amazed reading stuff like this at HN (well maybe not as most "hackers" can't design if their life counted on it). The Guardian is a good example of a perfectly well working responsive website.
I have many dissatisfaction for YouTube Music. One of my problem is that the Web hides some buttons/elements like +1 button when the window < 1280px (IIRC) even though there are empty spaces.
I prefer to browse with portrait-mode windows, and often find that sites give me the mobile layout unless I stretch the browser out wider than I'd prefer. It is annoying.
You're missing the forest for the trees here. Sites are using pixels as a proxy for physical device size. Which obviously breaks. I doubt people actually intend to display mobile view on a 720px, 12" wide device.
They're only working correctly if you ignore the intent and only look at the technical implementation. The technical implementation is flawed and doesn't accomplish the intent.
But the OP is using pixels as a proxy for screen size as well, they're deliberately presenting their screen as 720x1080 to make the fonts bigger because they are too far from the screen.
The stupidest thing to do at that stage would be to say "ah I see you're running a low resolution on a huge screen, let me make all the text tiny".
Without accusing you of any -isms, OP merely said that, given how far they sit from the screen, the font is too small.
You conflated that with sitting too far away. There are a lot of reasons why that might not be correct, including presbyopia. I think it's unlikely OP is sitting at that distance by accident, since it's pretty easy to move a monitor closer, so one of those reasons is more likely to apply than is your assumption.
Since tone carries very badly let me say up front that I'm mostly just confused by this entire discussion.
For now I stand by my assumption that OP wanted the fonts to be bigger because they were too far from the screen to read them at their current size. Though I fear I can't see why their reason for wanting fonts to be bigger would matter. I could have omitted OP's reason for wanting the fonts to be bigger but I thought a brief description would help keep the discussion related to the article.
The main thing I was advocating was that software should allow fonts to be bigger regardless of physical size, but clearly I've somehow allowed my argument to be horribly misconstrued.
I think their point was that if you want fonts to be bigger, there are settings to do that. (or should be even if the world isn't perfect yet) Same to a lesser extent for other ui features.
In reality, as of today, so far, neither desktops nor apps are that good where you can have the display set at it's correct native resolution, while having buttons, menus, icons, text, window controls etc all scale to preference.
But saying that that's what should happen rather than lie to the software about the hardware, is not agist or ableist.
I think the point was simply that fundamentally, lying to the software about the hardware is always inherently doomed to produce some form of incorrect result, and when it does, it's not the tech's fault for failing to second-guess, work-around, and essentially thwart your actively dishonest misconfiguration.
You're not disagreeing with the argument or conclusion of that post, though: it would be bad for sites to look at dpi and determine the native screen width without factoring in zoom level, because doing so would make text unreadable for you.
More to the point he is using multiple edge cases at the same time and dislikes the result he’s getting. He then suggests other people accommodate him.
Sorry, as long as the site still works it’s simply not worth it.
> The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
Agree. I sometimes browse the web on my TV - and I sit about 2 metres (or 6 feet) away from it. So the TV screen occupies a similar portion of my field of view that a phone would, and I usually browse at 150-200% zoom.
DPI might help you figure out the size of the screen, but it doesn't tell you how much of a person's field of view that screen occupies, which is what really matters.
Yes, field of view is what really matters, but scaling at the OS level (like TFA's author is doing) is a good way to correct for unusual fields of view. Got a higher-than-typical DPI and/or ridiculously far away screen and/or vision impairments? Scale the OS up. Got a screen with lower-than-typical DPI and/or touching your nose and/or amazing vision? Scale the OS down. You need the entire OS scaled, not just web pages.
"CSS pixels" are kind of a roundabout way to conceptualize it, but they solve the problem of proper readability once the OS scale is correct for the user. The combination acts as a proxy for field of view.
Then there's detection of course/fine pointing devices, as already discussed, to further augment the layout for proper target area.
I don't believe anything else will matter if the above is accounted for.
> The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
The author's problem is not things becoming bigger.
Larger was the goal after all of settings that scaling.
The author's problem is things optimize for mobile interaction.
Like making thing touch controlled,
Or making buttons disproportionately large to make easy to click with thumb.
> Sites are not detecting a portrait screen and deciding that they're displaying on a phone.
You wish!
A few years ago one website of a huge electronics component supplier did exactly that. I notified the webmaster, to which they responded that I represent a corner case in their new mobile-first strategy and it's a wontfix. However after politely inquiring how many of their customers source industrial supplies from their cellphones it was eventually reversed.
I think many developers/designers ignore device and dpi detection now. It has become too complicated, and the benefits are too few.
@media rules with min-width or max-width is really all you need; just make sure the breakpoints aren't so ridiculous that you serve the "mobile" version of your site to desktop users.
That still doesn't work very well. I have Firefox on one half of my 1440p monitor and vertical tabs down the left side. Web pages I see are tall and narrow, and many fall back to mobile style controls.
I'm kind of confused about this - I'm sure the author experiences real problems, but I wonder if there's something else at play here?
I've never actually seen screen aspect ratio media queries used in practice, nor have I really seen them advocated for. When I load www.theguardian.com on my portrait monitor (1441 x 2561) I get the desktop layout https://imgur.com/a/ZpUI95Z
Absolutely yes design your breakpoints around screen width. Using aspect ratio seems like a poor choice.
Even then - when I set my resolution to the same 1080 × 1920 the author states, The Guardian still renders the "desktop" layout. The more compact layout from the doesn't kick in until 739px.
Maybe it's their font-scaling settings are getting in the way and changing the viewport resolution?
Ironically, the author of dpi.lv (https://lea.verou.me/) doesn't even bother to have a "desktop-friendly" site. On desktop everything (font, header, images, buttons) is huge and ~50% of the vertical space is wasted. Not the best calling card for someone living "at the bleeding edge of web standards". Or maybe it looks Ok if you view it on a Mac?
Cool, that's the theme WordPress recommended to use as default in 2020? Maybe I should ask them to buy me a Hi-DPI monitor... that would display a bit more content, but actually I'm afraid the lonely column of text in the middle of the screen would look even worse.
It looks fine on mobile to me, scrolling is free, and filling 100% of the screen with information has nothing to do with if a person is "at the bleeding edge of web standards".
That's my point, it looks (probably?) great on mobile, but on desktop it's a mess. Maybe that's what they mean by "bleeding edge" - only that it's the eyes of some of the users doing the bleeding...
As with every engineering project, there's always a point where you have to look at how few people are within a certain use case and decide it's not worth the effort to cater for them
As a vertical PC user, you're in the vast minority, and you can't really be surprised that people don't want to spend the extra time (and money) developing to support your edge case
On work, I know a couple of people who use vertical screens (including me). At home I have a large 43" 4K monitor (no scaling). A lot of websites think it would be something like a 23" 4K monitor and everything on the website is super large.
As rule of thumb, as more fancz the website is, the more is the website broken if you don't use just a 08/15 monitor.
In the past I'd respond: just because I have javascript disabled doesn’t mean I’m on a phone. But unfortunately developers have dropped supporting HTML completely for even older cell phones. There's no more mobile.twitter.com that serves HTML for example.
398 comments
[ 3.0 ms ] story [ 321 ms ] threadFor example, "What every programmer should know about memory" covers memory but what about (as you say) screens.
Building responsive client UI is hard. In my experience here, the falsehoods HNers believe about clients is that it's somehow not hard. Or just a silver bullet away from being easy (like replacing JS with $faveLang). Or that resources are infinite such that every defect is explained by incompetence (except for, presumably, that HNer who is intimately familiar with resource finitude in their own life).
For something so universal ... there should be a very clear and unambiguous function call and at least a rational way to move through the fragmentation molasses.
The proposed solution is not just no better, but far, far worse.
It's amazing how many websites are incredibly unusable when displayed 2-up on my 27" monitor.
There's so much screen estate, but I often literally have to resize the window to fullscreen to find a search or login field.
I long advocated that website started to use the more of the width of the screen on desktops, to avoid unnecessary scrolling. However, I just a frequently have two windows next to each other.
There's no real good way of satisfying all use cases, but it generally seems like desktops are being neglected when company design websites. Previously mobile seemed to be hacked on to an existing site, now everyone seems to go the route of: If it's good enough for mobile, it's good enough for desktop users.
1920x1080 in half.
It’s a regular problem I run in to.
As you start to make that smaller - 1200, 1100, something has to change. We can maybe adjust the font size in the main column, maybe there's some flexibility to shrink the sidebars (but maybe there isn't, because we need an ad in there, and that can't be resized). So we have to adjust - lose a sidebar to a hamburger menu, or change our horizontal menu at the top to include the most clicked links (and not the ten links we have before). Maybe the search bar becomes an icon, because it's more important we push the "Buy Now" button than give people an option to search, etc etc.
It's an art - what do people need the most? What will make them convert? What can we remove first? What resolutions are most used, and how do we optimise for that?
As you point out:
> Maybe the search bar becomes an icon (...)
I'd already be ecstatic about that.
I'm talking about features which are essential to a website that just disappear completely because the owner thinks "no one on a tablet will ever want to use this".
Maybe there’s something I’m missing, but I’m not sure how knowing the aspect ratio of the screen would help make an element 16:9. If my browser is narrower or wider, that doesn’t affect how I would style the element.
// The viewport is in a landscape orientation, i.e., the width is greater than the height.
@media (orientation: landscape)
// The viewport is in a portrait orientation, i.e., the height is greater than or equal to the width.
@media (orientation: portrait)
But then I read to “720×1280”, and… well of course, what did you expect?
There should IMO be a preference sent, "I'm on a portable, touch-enabled device". I'm guessing it doesn't exist because it would add a bit to the fingerprint.
The website is saying "if your screen is at least this big, I'm going to show you the version for big screens". The OP has an unusual setup where their big screen is reporting as a smaller screen.
Not necessarily, because the “smaller screen” layout tends to be linked to the touch one e.g. larger active targets, while the “large screen” layout is optimised for precise pointing devices (mice) and may be nigh impossible to interact with using fingers.
This is the suggested way because if you check the device width you know that they are on a small device and thus probably mobile but your styling changes for small windows (less wide windows) do not get applied, so 'best practice' is to check the actual screen width. Hardly anyone checks the height because for web development height is generally not that important.
But this is often not useful because a lot of web solutions style things based on JavaScript and CSS and while the CSS will rerender automatically based on changing the screen size the JavaScript needs to detect you've changed the screen size and then rerender. So then there is a discussion as to how many people really resize the windows and do we need to catch this resize to do a rerender even though doing so is irritating and can be a resource hog (fixable by extra code but maybe better not to code at all!)
But there are lots of other ways to detect if you are on a mobile device, you can detect if touch screen events are enabled etc. but then what if you have one of those weird desktops that became possible a few years ago (I nearly wrote popular instead of possible) where your laptop's monitor also has touch screen events.
As a general rule it is best to do things based on the capacity of the system, and not by what type of system it is, but as the capabilities of our systems exist in infinite combinations it follows some things will just fall through no matter how exacting you try to be - maybe especially if you try to be too exacting.
There’s really no other information since “physical” dimensions are completely fake: a CSS inch is 96 CSS pixels which are “one pixel at 96 dpi at an arm’s length”.
Layouts need to fit a size, not a device, so that's why media queries based on the screen size are usually the best approach. If I resize my browser to make it smaller, I should get a layout to match that. If I'm using Safari on iPad, docked to the side of the screen, I should get a layout to match that. These are all about screen sizes, not "mobile vs desktop".
For testing interaction cabailities, there are the @media (pointer: coarse) and @media (hover: hover) media queries for testing touch vs mouse, and hover capabilities, but it's important to not rely on these for mobile vs desktop layouts otherwise tomorrow a MS Surface user will post "Just because I have a touch screen, doesn't mean I'm on a phone".
It’s honestly been a significant improvement over dedicated mobile layouts and for the most part works pretty well.
Something as simple as “use-case: handheld | bellyheld | desktop” property? Css designers missed this opportunity completely.
I used to insist that designers never say "phone, tablet, desktop" and instead say "small, medium and large" but it never stuck.
No, it's not how it's done. And there is generally no logic trying to see if it's a mobile or not. One just have various designs for various sizes. When he has a 700px wide display, what else can the website do than collapse the content when it's not enough space for it?
That's what the user-agent is[0]. And all major browser engines have/had a Mobile token on relevant devices.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_de...
[0] https://www.zdnet.com/article/google-to-phase-out-user-agent...
For my personal projects, screen size is the factor used to determine layout. Mobile/tablet/laptop/desktop is irrelevant. My goal with smaller viewports is to make the layout as similar as possible, without the user having to scroll horizontally. Because I don't want to change the layout too much, I do not use hidden navigation menus.
Hamburger menus are terrible - I see them as a design copout.
I've become used to the hamburger menu, but it still doesn't catch my eye (Chrome's now three dot option is even worse at this), gear looks noticeably different than the rest of the UI and so I can easily spot it for options.
I am genuinely interested in why. The only reason I can think of, is that they may me unintuitive, but I think this is becoming less and less of a problem.
Hamburger menus are an accepted and pervasive design element. That does not means it’s good design, but it means that users are familiar with the concept. Familiarity goes a long way to ensuring good UX.
Sure, it has become more common, but for anyone not already familiar with it, it is utterly useless. You have to be willing to click random things to discover what it does.
From personal experience, I had to train both my wife and mother to look for them, neither of whom had the patience otherwise to figure out these cute designs. They may be common at the sites you look at, but that doesnt help people who have only used sites without them, or only used portions of sites accessible without clicking on them.
I consider that to be an utter failure.
HN works beautifully on any window / screen size.
Reddit is barely more than HN with pictures and a LOT of bloat inbetween. It could be as minimal as 4chan-style imageboards if you add voting and a slightly different comment view.
Youtube is just a tiled list of thumbnails or an embedded video player followed by a list of thumbnails. It could work 100% without JS outside of the video controls. Instead it's a huge, slow mess. It's also inconsistent; in my case it scales the list of videos from subscriptions to about 50% of the browser window's width, leaving a chunk of empty space on the sides. The startpage with basically the same layout always uses the full width.
99% of websites are (could be) just static text and images. Facebook, Reddit, CNN etc could look like HN. Amazon could look like craigs list. The amount of sites that actually need and are enhanced by JS bloat is very low.
I think many people, my parents included, would have trouble navigating HN on a phone. Especially upvote/downvote.
And on mobile I find it impossible to hit the upvote arrow.
Because HN is designed so simply, you can trivially get the layout you want (half width lines) and I can also get the layout I want.
If HN instead tried to artificially limit the viewport in code (which is something lots of web developers do), they would break all sorts of other use cases for no reason. That's what I mean when I say websites tend to overcomplicate their design.
Except you're ignoring mobile devices.
Or random blog sites that become a narrow column of text and a *huge* amount of whitespace on either side.
Somehow we've gotten to this world where the web designer expects almost-pixel-perfect control over the layout of every little thing on the page, user's preference be damned. You're not laying out a magazine page in a desktop publishing application!
So an accessible site that follows modern design fads is probably the best thing to have (if that sells rugs).
There is no way to format your text, even stuff that's available since MS Word 1.0, such as bold or italic. Even science papers have formatting so I don't buy the "overuse of styles" BS.
There is no way to have avatars or some other ways to distinguish users (or mods!) to make this place feel more like a community in real life. I've gotten used to it but it still sucks.
The contrast is super low.
HN is an MVP for a super minimalist forum that wouldn't fly for any other kind of community except for the intersection between hackers and wannabe entrepreneurs.
Are you entirely sure about that?
Spoiler: You mean mathematical sans-serif bold small l, mathematical sans-serif bold small i, mathematical sans-serif bold small k, mathematical sans-serif bold small e, mathematical sans-serif bold small t, mathematical sans-serif bold small h, mathematical sans-serif bold small i, mathematical sans-serif bold small s?
HN doesn't have a "quotes" feature. Some users here have the unfortunate habit of abusing the code formatting feature for quotes.
>There is no way to have avatars or some other ways to distinguish users
Thank god. There's a lot I miss about forums, but avatars and huge signature blocks are better left in the trashbin of history.
That isn't an acceptable compromise, you end up doing a lot of horizontal scaling to read block quotes and zooming to touch UI elements.
It's not the worst, but it is trivial to do better.
what block quotes?
Its actually one of those cases where the old news print model of multiple columns would work well, but that is much harder than it should be with CSS, so pretty much no one does newsprint style scrolling where you read all the columns and then scroll to the next set.
OTOH, when clients tell me they want responsive design - no problem! It's job security, and I bill by the hour ;)
The rabbit hole is websites are supposed to cater for every screen size by pixel is ridiculous. At some point the user should respectfully use normal orientated/ sized device.
CSS dpi media queries are unsupported in Safari mobile and desktop, so that increases the complexity significantly.
Beyond that, the fact is most web layout is still done in px or other non-fraction-of-the-width units, so it’s often a matter of the wider layout simply being broken at smaller widths, rather than just refusing the display.
I wish I could ask the browser "what are the dimensions you the browser use for your buttons" so I can use same dimensions too and the user could configure this in his browsers and everything would follow it.
Note that this is different from { font-family : system-ui } which doesn’t include size information.
Caniuse sadly doesn’t have much info on font: caption support.
Just design for the default and then people will zoom or change resolution if the default isn’t enough.
We used to do this before responsive design took over.
Consider an iPad which can display a website at three vastly different sizes. Full-width, half-width, and roughly 1/5th width docked to the site. They should have at least two different layouts.
- viewport changes size due to soft keyboard - address bar hides/unhides during scroll down/up
For certain types of apps, like games, it's important to know whether a device is actually "mobile" regardless of size/resolution. Sniffing user-agents might have to come back into vogue. Who knows where "mobile browsers" will end up - maybe some giant 60" kiosk app, or other places.
Barring that though the article brings up good points and searching the web for how to detect mobile usually brings up the error-prone portrait/landscape resolution detection that the article discusses.
The full solution requires the knowing the resolution and the dpi to get an estimate size of screen in inches. At least with that we can be safe until next article "Just because I'm a 100" kiosk app, doesn't mean I'm on a phone".
Is there a good npm lib that does the above?
I have a Samsung Tab A Tablet (Model SM-T510) that has better resolution than my notebook (A Lenovo T430). A page that displays very well in the Lenovo (1366x768) displays like crap in the tablet (1920x1200) even when using it in the landspace position.
In this case the author is scaling their resolution, and so their browser is presenting itself to sites as 720px wide. Sites see that and show a layout optimized for a screen of that width. Those sites are acting correctly.
The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
I have all the time in the world for developers that reflow the page and remove/adjust elements at different breakpoints (based on the design) between 'desktop' and 'mobile' so the experience is good for everyone. Sadly, most people don't bother.
That said, sane breakpoints can usually avoid unexpected hamburgers on the desktop.
I learned this lesson the hard way. The client was on desktop. The users were 40% phones. Everything was great for months and months.
Then one day the owner of the company that owned the company tried to look at the web site on her grandkid's iPad. Fan met shit that day.
Same with “We only tested this on Chrome.” of sites/apps, of which are there are many, as I can attest, as I never use Chrome.
I don't think apps are as relevant to current discussion. For apps (not public websites), there are different requirements depending on the target audience.
I wouldn't be mad at a B2B web app being desktop only, no mobile CSS.
But I agree that web apps should still be compliant with safari + FF + Chrome.
In decline from when? Picking it up after reading a few tutorials has always been a common way to get into web work, and if anything I feel like it's been getting more professionalized over the last twenty years.
Unfortunately, the horizontal scrolling UX with substantial wasted whitespace on the sides remains.
Someone else mentioned bootstrap in the other thread too.
Maybe because these Frameworks are hugely popular, their defaults amplify the impact. Definitely these values are tweakable.
“The small breakpoint is 768px wide? I guess below it it’s a phone, I hope you like burgers”
They certainly could have added an extra breakpoint where the navigation becomes smaller before bailing to a hamburger, but of course that does add complexity.
I agree though, let me zoom on a blog post. The diagrams are often unreadable on mobile.
It doesn't help with everything, but the triple-tap zoom is quite useful.
Should the space given to sidebars increase? Should those sidebars disappear? What about headers and footers? How will the overfloat be treated? A single line, double lines? What about captions underneath images? How do you handle text that happens to be embedded within images themselves, or even on top of images?
"I don't care if headers look weird"
It goes beyond things looking weird, it really does break websites.
Given that we're increasing the text 2x or 3x, it's an important question whether or not we're also increasing the width of the scrollbar 2x or 3x.
That's not what laptops are for.
I think that's a typical snide HN/Stack Overflow-type answer, and I don't mean it rudely, but it does have some bearing on this conversation. What's the intended form factor of a laptop? What are the top 10 intended form factors? I'm not sure "reading from 'a few' [several] feet away, while I'm laying down in bed" is in that top 10 list.
Are there devices better suited to that form factor? I don't know.
Isn't the real questions why we allow devices or their makers to decide the "intended use-cases" and accept that many other use-cases are often near impossible. The PC revolution was about a general purpose computers, and laptops should imho still be general purpose computers; not machines for which some overlord in Mountainview or Cupertino checks on every button pressed whether I am allowed to do what I intend to do.
Politics aside, I am the only one who has the impression that with every new release of macOS or Firefox features get removed, that enabled me to personalize and optimize my workflows before?
I mean, I guess less so now that everyone has phones and maybe an e-reader, but... that's not such a weird use case. That's basically how I spent the later half of high school.
How is a web site supposed to know if you're someone sitting in bed with the screen a few feet away, or someone sitting at a desk with a screen a few inches away?
That's on the user. Learn how to use your browser, device, and operating system's zoom features.
My experience has been the exact opposite of what you're saying.
And the result is, 90% of the time, a site that goes from usable to unusable.
On many sites, this trigger the appearance of the dreaded hamburger menu.
Which they shouldn't be.
* Lay out content based on the viewport width, in CSS pixels.
* Use larger tap targets for coarse pointers (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...).
This is wrong because the viewport width is not the same as the monitor width or the DPI: especially on big monitors running the browser fullscreen is very hard to use (my browser rarely exceeds more than ~50% width on a 2560x1440 monitor and even when i use a 1366x768 monitor - which btw is at 22", not some tiny laptop one - i very rarely use it maximized).
As for why it is wrong, it is because you can't rely on it to make a Mobile vs Desktop distinction - i already provided an example why.
It's still not clear to me where you think this approach gives bad results?
Usage while walking/moving vs. sitting/standing at a desk.
Most "mobile" usage is actually stationary, typically seated. If you really need to change layout based on motion you can use the accelerometer, but I can't see why you would?
The precise vs coarse isn't helpful either for something like this because this isn't just about clicking vs tapping, it is about how the end result looks - and there are PCs with both very small monitors and very big monitors (and relatively large monitors with low DPI or small monitors with very high DPI). CSS pixels only help for setting sizes/positions, but not layout.
AFAIK the best that can be done nowadays is resolution media queries but that isn't available everywhere (at least according to caniuse).
Of course in practice i expect none of the above to be used and have my browser simply zoom out whenever i reach many sites just because i do not want to maximize my browser :-/
what would be really nice would be element-size-based media queries. you can use javascript to do it but that sucks
example: https://tv.avclub.com/the-hunt-is-on-with-clarice-the-equali...
Specifically, they have:
If I turn off all the site's font-size overrides, I no longer need to zoom in.In general, CSS already provides a bunch of generic font families and sizes. So a page could style something as e.g. "sans-serif" and "large" - and then the browser should figure out what this actually means according to user settings. The problem is that very few sites actually use these. But for those that do, the browsers do the right thing - and, again, most of them let you configure what the generic font families map to.
When I read that, I read, "we're ableist and here's a few crumbs so we can feel better about ourselves".
This is untenable as well. You'll end up with microscopic websites on high DPI phone screens.
Users with NoScript will just have to live without some functionality. I'm sure they are used to that already, since a large fraction of websites use JS for styling. (I use NoScript)
Setting aside the debate about separation of concerns. Yes, it has notable performance and UX implications.
> Users with NoScript will just have to live without some functionality.
Why should we prioritize OP's use case over that of NoScript users?
@media (min-aspect-ratio: 1/1) /* wide */
@media (max-aspect-ratio: 1/1) /* tall */
@media (aspect-ratio: 1/1) /* square */
Here, play with your window width to see: https://hypertele.fi/0000000000000000
So IMO it just comes down to some sites doing a bad job of picking responsive breakpoints.
Edit: Out of curiosity I checked MDN, and their media query tutorial has you set the mobile breakpoint at 40em. Default font size at least on desktop is 16px (again, virtual pixels which scale with display-scaling and device size), which comes out to a breakpoint width of 640px: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
Sizing is another matter entirely, in which I would agree, yea a tiny hamburger menu on an iPad Pro is likely bad. We all have engineering budgets though and in the grand scheme of things, iPads are likely a small fraction of the visitor base for these sites, so I get it.
¯\_(ツ)_/¯
What's wrong with using something like: @media (min-width: 8in)
To determine if someone is using a larger screen (or window)?
Edit:
https://hacks.mozilla.org/2013/09/css-length-explained/
Seems like 8in is just short-hand for 8*96px. Thanks for nothing, web standards.
I understand they had to start with something and 20 years ago no one expected thre will ever be monitors with DPI > 96 but I don't understand why the situation hasn't changed yet. Now that we have many physical screen sizes with vastly varying densities.
In my opinion, devices with a screen are like a sheet of paper. Imagine a tablet or Remarkable eink. You can print only that small font on such paper. If the font is too small, we can use a magnifying glass or, in case of electronic devices, clever scaling mode.
If that was implemented, buying a bigger monitor would actually mean we could fit more content, wider newspaper there.
The current situation is just a mess with designers just randomly guessing how it's gonna look on most current devices and using media queries to somehow automagically solve it all. But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height and there are empty unused paddings everywhere. I.e. if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily. Sometimes all you get is three columns of text instead of one. Sometimes. If media queries are set up reasonably well. But even then, on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally...
[1] https://github.com/w3c/csswg-drafts/issues/614
> But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height > if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily.
I don't think this is the case at all? The web and browsers handle DPI scaling incredibly well. I don't think I've ever ran into an issue with it. Remember that Apple has been shipping high-DPI monitors for the past 15 years, and I've never experienced these issues of a website of a website not handling this. More or less, the browser completely abstracts this away - you have to purposefully screw things up to render things at different sizes depending on DPI.
* Manufacturers configure their devices to ship with reasonable default settings, where is CSS pixel is roughly the same apparent size for everyone.
* Users who want content to be displayed larger or smaller can change their device scaling, which then makes their CSS pixels larger or smaller.
* Web developers can write for CSS pixels, knowing the content will display at a reasonable size for the user.
> if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecessarily
It sounds like you're probably sitting closer to the monitor then expected? Lower your device scaling and things will be a better size in all programs including the web browser.
> on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally
I think this is also running into user preferences and design. If I'm reading an article, and there is just one stream of text, I'm quite happy for it to take a 40em strip down the middle of my screen. If the text ran edge to edge it would be much harder to read, because it's hard to keep your place when jumping to the next line.
They're only working correctly if you ignore the intent and only look at the technical implementation. The technical implementation is flawed and doesn't accomplish the intent.
The stupidest thing to do at that stage would be to say "ah I see you're running a low resolution on a huge screen, let me make all the text tiny".
As I read this I:
1. am wearing my computer reading glasses +1.5
2. have my browser set to zoom HN by 125%
3. am reading distance from the screen
I know programming and tech in general is a young man's game, but let's at least try not to be ignorantly ageist & ableist.
> But I find the fonts slightly too small at that resolution – given how far I sit from the screen.
You conflated that with sitting too far away. There are a lot of reasons why that might not be correct, including presbyopia. I think it's unlikely OP is sitting at that distance by accident, since it's pretty easy to move a monitor closer, so one of those reasons is more likely to apply than is your assumption.
For now I stand by my assumption that OP wanted the fonts to be bigger because they were too far from the screen to read them at their current size. Though I fear I can't see why their reason for wanting fonts to be bigger would matter. I could have omitted OP's reason for wanting the fonts to be bigger but I thought a brief description would help keep the discussion related to the article.
The main thing I was advocating was that software should allow fonts to be bigger regardless of physical size, but clearly I've somehow allowed my argument to be horribly misconstrued.
In reality, as of today, so far, neither desktops nor apps are that good where you can have the display set at it's correct native resolution, while having buttons, menus, icons, text, window controls etc all scale to preference.
But saying that that's what should happen rather than lie to the software about the hardware, is not agist or ableist.
I think the point was simply that fundamentally, lying to the software about the hardware is always inherently doomed to produce some form of incorrect result, and when it does, it's not the tech's fault for failing to second-guess, work-around, and essentially thwart your actively dishonest misconfiguration.
Sorry, as long as the site still works it’s simply not worth it.
Agree. I sometimes browse the web on my TV - and I sit about 2 metres (or 6 feet) away from it. So the TV screen occupies a similar portion of my field of view that a phone would, and I usually browse at 150-200% zoom.
DPI might help you figure out the size of the screen, but it doesn't tell you how much of a person's field of view that screen occupies, which is what really matters.
"CSS pixels" are kind of a roundabout way to conceptualize it, but they solve the problem of proper readability once the OS scale is correct for the user. The combination acts as a proxy for field of view.
Then there's detection of course/fine pointing devices, as already discussed, to further augment the layout for proper target area.
I don't believe anything else will matter if the above is accounted for.
The author's problem is not things becoming bigger. Larger was the goal after all of settings that scaling. The author's problem is things optimize for mobile interaction. Like making thing touch controlled, Or making buttons disproportionately large to make easy to click with thumb.
You wish!
A few years ago one website of a huge electronics component supplier did exactly that. I notified the webmaster, to which they responded that I represent a corner case in their new mobile-first strategy and it's a wontfix. However after politely inquiring how many of their customers source industrial supplies from their cellphones it was eventually reversed.
https://twitter.com/varjag/status/1050370136585187328/photo/...
Shrinking the viewport so it is toothpick shows me the phone screen view. I don't think they are selecting on aspect ratio alone.
@media rules with min-width or max-width is really all you need; just make sure the breakpoints aren't so ridiculous that you serve the "mobile" version of your site to desktop users.
I've never actually seen screen aspect ratio media queries used in practice, nor have I really seen them advocated for. When I load www.theguardian.com on my portrait monitor (1441 x 2561) I get the desktop layout https://imgur.com/a/ZpUI95Z
Absolutely yes design your breakpoints around screen width. Using aspect ratio seems like a poor choice.
Maybe it's their font-scaling settings are getting in the way and changing the viewport resolution?
As a vertical PC user, you're in the vast minority, and you can't really be surprised that people don't want to spend the extra time (and money) developing to support your edge case