> Now, I think we can all agree that, on our desktop computers, we prefer viewing the full-width layout of most web pages.
This assumption is not reflective of current accessibility research. For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer. This is disproportionally impactful for older seniors, who might struggle with instructions like "remember to put an m. in front of the url".
> For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer.
I am one of those people; I have ~150% zoom on most sites, often higher. It's 240% on HN right now, which is my "default" for HN. This is not because I'm visually impaired by the way – I don't even use (or need) glasses – I just like it. I've been doing this since I was in my mid-20s and I just find it more comfterable.
I find these kind of reflows frequently make the page worse, not better. Even with a high zoom level the full desktop site usually works better than the "mobile optimized" site.
It's not uncommon that zooming will make the text smaller. You're at 140% and want to go a tad higher, so you go to 150% and bam: you're over the limit, the text becomes smaller, and now you need to zoom to ludicrous amounts to actually get the desired 150%.
The overall layout also often becomes worse. A common issue is that it makes the box in which the text is displayed too narrow, wasting a lot of space.
This is basically what's going on in this story: it's not that the website shouldn't work well on all different zoom levels or that it shouldn't have any kind of reflow at all, it's that it shouldn't give me a "mobile" site when the desktop version is actually still just fine. I think you've misunderstood this post a little bit.
In my own websites/webapps I generally take a gradual approach. If the screen becomes too narrow to display a certain UI element then tweak that element a bit, and do this individually for every UI element. This is quite a different approach than the "IF smaller_than(1200px) THEN serve_mobile_site". IMHO that's just lazy and bad design.
I usually avoid device detection, but do use it for a few things (e.g. <input type="date"> is ugly on the desktop, so it always serves a JS version for that).
A related note: forcing mobile UX patterns on desktop in general is usually not a good idea. Today I wanted to copy some text from the Dutch parliament website, and I couldn't as the UI element was one of those "swipe left/right" things, so actually trying to select text would swipe the thing to the left/right. I had to resort to the inspector mode to actually be able to select/copy the text.
>It's not uncommon that zooming will make the text smaller
At least in Firefox you can enforce the minimum font size through settings without using any third-party plugins or custom themes (look in about:preferences → "minimum font size"). I have it set to something like 16 or 18.
This doesn't fix the actual problem, but I gave up on trying to change the world a long time ago.
The problem with minimum font size is that sometimes you want the text to be smaller, especially in cases where it's used as UX labels or the like. I used to set it fairy high in Opera (long time ago, Opera Presto) and even back then it would break stuff.
I have a few custom userstyles to deal with the worst of it; topnavs that grow to 20% of the page height and stuff like that.
> It's not uncommon that zooming will make the text smaller. You're at 140% and want to go a tad higher, so you go to 150% and bam: you're over the limit, the text becomes smaller, and now you need to zoom to ludicrous amounts to actually get the desired 150%.
In fact, the video in his link that shows "correct" responsive design does exactly this, the text becomes larger or smaller in a seemingly random fashion as he zooms in. But to be fair to the BBC, I went to bbc.com and it doesn't seem to do that currently.
Yes, but how showing (shoving) everything under a hamburger menu on desktop helps accessibility? Usually if you back from such a full-page menu, you'll completely leave the website, because it's implemented as some <div> overlay with no one bothering to at least push an entry into history, so it looks like navigation but isn't and is in general very confusing.
On mobile people may be using back button less, but on desktop it's always easily visible and accessible in multiple ways, incl. the keyboard, and at least for me it's almost a reflex to use it. Just ctrl+[ away.
Yes, navigation links that don't behave like normal links are also an accessibility problem[1]. That's a separate issue, though; I don't think it is a reasonable argument against supporting reflow based on perceived window size.
Mixing links and dropdowns is a 'well-known' antipattern, in the sense that lots of people don't know not to do it, so everyone is familiar with it once you bring up the subject, but most people don't think about it until someone mentions it.
This is why you see icons in the menu bar indicating that clicking here doesn't navigate you away from the page, but clicking over here instead might send you away from whatever it is you're doing here.
We have desktop users with anywhere from 1400 to 3200pixel screen widths, so the concept of having a 'desktop site' without any kind of flow logic at all just doesn't make sense to me.
You end up with sites like daringfireball that is always 512 pixels of content centered in however wide your window is. On a 16:9 display this is extremely awkward. On a 1.85:1 or 2.39:1 display this looks dumb as hell.
The way I see it, if I wanted my text constrained in a narrow column, I'd resize my browser window. Why specifically take the choice away from users by declaring in the code "512 pixels is the one and only way"? Browsers have given way too much design control over to web developers, taken from end user's choice.
1) Sites with multi-column or table design that can show more information when the browser window is wide. I tend to widen the browser window to get the most out of these pages.
2) Sites like Daring Fireball that have a fixed width, so I can still read the content just fine whether or not the window is wide.
3) Sites that expand the line length to wrap at whatever width the browser is at. I find these impossible to read unless I narrow the browser window because I lose track of which line of text I’m reading.
Types (1) and (2) are compatible and make up the large majority of sites I visit. Type (3) isn’t compatible for me, so I find it inconvenient. It’s not the end of the world, but it slightly inhibits my desire to visit such pages. I’d rather not maintain a multi-level navigation hierarchy with multiple windows and multiple tabs in a window.
Daring Fireball, PG's blog, Hacker News and anything that is primarily text...I just click the little Reader View icon and it looks the way I want it to look.
Ecommerce sites are a minefield.
Saas and anything table-y or app-y, you're also out of luck for the most part.
This is my default for mobile - Reader view for ALL content by default - need to whitelist a few (mainly CMS-style) sites, but no ads, just text and an occasional pic.
Something barely related that drives me nuts, is that if reflow is something so important (it is), then why is Opera the only Android browser which implements text reflow? !
It should be a top concern for browser and page devs IMO.
I replied a wall of text in a sibling (cousin?) post, but here's a video of what the feature I meant. I'm not sure what the most accurate name for it would be, I've always seen it called text reflow.
https://www.youtube.com/watch?v=yAWTd9h1lbI
Not the OP, but I think I know what they mean. If you zoom in so that you see a div full of text that would get wider than the screen, Opera will reflow the text to fit the width of the screen even if the underlying page layout is wider. This allows you to read pages at high zoom level without having to pan the page side to side for each line of text.
> Opera will reflow the text to fit the width of the screen even if the underlying page layout is wider.
That is not something I would want in many cases where I'm zooming in on mobile, if I understand you. A lot of time I'm doing that so I can accurately click a link that was too small. I want the text to stay positioned so I can zoom to a specific part of it without it changing underneath me. That's what a zoomed in view means, IMO, especially when considering the origin of the meaning.
You'd be surprised how well this feature works. I don't recall ever having had an issue like the one you describe. The browser isn't changing the entire page layout, mind you. It only re-layouts the text when all you're seeing on screen is pretty much a single div. I guess you have to experience it to understand.
When looking at a desktop sized web page such as old Reddit, most likely an entry's title won't fit horizontally on the screen. What some browsers do (and I really dislike) is that they somehow guess what's important on the page, and bump those elements' font size in ridiculous ways, while leaving others as they are. I believe this is called font inflation, or text size adjustment. This makes it so the title of a Reddit post becomes huge, while the 'see comments' button below it stays ridiculously tiny and unclickable.
Other browsers just don't care, leave the text in desktop-like proportions, and when you zoom in you end up needing to scroll sideways back and forth to read a sentence, quite cumbersome.
The most reasonable solution is Opera's where if you're on a desktop like site and you zoom to a block of text, it allows the letters to increase in size naturally according to your pinching, but when you let go it reflows the text block and makes it wrap once a line (at its new zoom level) reaches your phone's screen width. This way if you see a long paragraph (or Reddit title, for example), you can zoom until the text is readable, and then only need to scroll up and down, instead of sideways as well, without compromising the original site's design by wonking up the font sizes at (apparently) random.
I'm not sure I did the best job at explaining it, but basically the goal is to be able to zoom into small text on desktop-like pages until I'm comfortable with the size, and then make it wrap to the screen's width so you don't need to scroll sideways to read the text.
Easiest demo is to download Opera on Android, go to old.reddit.com and zoom around. Once you get used to it, every other browser becomes annoying.
Edit: lol, after typing all that I thought of looking up a video and here it is. Looks like some phone's default browsers already do it well too. https://www.youtube.com/watch?v=yAWTd9h1lbI
Yes, we found our customers like to shrink our webapp down to half the screen, multitask, etc. Assuming full width even if their screen dimensions were large was a bad idea.
I often scale my browser window to 30% of the screen's width(it's a large screen).
Webapps and responsive webpages often like to either switch to a layout made for smartphones which looks really weird and makes some links and options inaccessible, or it just breaks in some ugly way. I've seen websites literally becoming unscrollable when the browser window got too narrow, websites where writing in a text field would gradually shift the site out of the visible area, forums that would hide away the "reply" button in narrow windows, instead showing the "report" button in the same location(facepalm).
Web developers should stop assuming their website is the center of my world and attention.
> Web developers should stop assuming their website is the center of my world and attention.
They really should just focus on the content, and not obsess so much about how each and every pixel might look on my various browsers, and stop trying to make assumptions and guess about how I might prefer things to look based on silly things like browser width and user-agent string.
Yes, I almost never have my browser fullscreen (only when the page layout forces me to), and instead use a roughly 1:1 aspect ratio in the middle of the screen, so that text lines aren’t too wide and text starts not too far on the left. That’s with a 27" 16:10 screen.
While the wording isn't particularly clear, the later remarks contrasting full-width with full-screen makes it clear that full-width in this instance does not refer to the full-width of the screen, but only that the "widest" responsible layout is used.
I don't think the article is using unclear wording; I think it is clearly arguing the exact opposite of what you're describing. I think the clearest demonstration of this is the concluding section, where the author specifically talks about using "is desktop/laptop" as a preferred alternative to breakpoints that are based on window size.
Not only do I zoom in all the time, I also, you know, use my operating system's capabilities to put the page into a non full screen window, sometimes even a small (especially narrow) one.
Each of the suggested device categories (Desktop/laptop, Tablet, Phone) has many different screen sizes/resolutions. And all of them might have screens in landscape or portrait mode. All of these devices might support multi-tasking with varying split screen sizes. All of those devices support custom accessibility configurations for font-sizes, zooming or both. By detecting the UA and trying to shoehorn it into a certain category, you only increase the number of issues for the users.
One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible.
This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.
Yeah, the advent of CSS frameworks introduced the concept of a relatively small number of global breakpoints. The consequence of this was that at certain widths, typically some figure meant to represent a change on form factor (mobile, tablet, laptop, desktop), there'd be dramatic layout shifts.
For a long time I resisted this, opting instead for more surgical introduction of a breakpoint, literally at the _point_ where some part of a page's design _breaks_ (not really the etymology of the word, but it's fun to think of it this way). But it's felt like a decade-long battle against the momentum of the industry, and sometimes I just want to build things rather than fight.
I agree with you in principle. But having many different breakpoints that are accurately defined at exact widths leads to one huge practical downside: the number of possible combinations of website element versions skyrockets. I have found this to quickly lead to a situation where it is no longer practical to test all combinations.
A small number of global breakpoints can be a better trade-off when it means the website works better (for most people).
I think you're definitely right. It's possible that container queries may open up new possibilities that resolve the tension between the two approaches.
Looks that approach it would be a hell to maintain. In special if it's a big web app.
I prefer having a few fixed well defined breakpoints that having a combination explosion of places to fix and widths that I have to control when I do a changed on a component.
Yeah, that was confusing to me, too. I saw the article's first example and thought, "Well, that's not really responsive design, that's switching between two entirely different views!"
On my personal site I do indeed have a media query to make some tweaks when the viewport is phone-in-portrait-orientation narrow, but I try to keep them pretty minimal. I find sites that reorganize themselves at different widths ("if your browser window is 2000px across, this is a three-column display instead of two!") to be…not necessarily bad, but at best, unnecessarily clever.
I guess that's bootstrap's legacy: they implemented a grid in precisely that annoying way. Not that you have to use it like that, but the temptation seems to be considerable.
> This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.
I agree this is confusing, but I think we still need a term for distinct types of views. The point of the article is that, once a user has started using one particular view, it shouldn't suddenly change to a completely different view with a different layout just because the user's browser window got resized by a few pixels.
I don't think it's possible for an app to auto-detect which view the user wants to use, particularly not if the auto-detection logic allows changing views on the fly in the middle of a user session based on resizing the browser window. I think the only real solution is to have different views that each have their own distinct URL, so the user can choose which view to use. Each view can then be "responsive" within the general constraints of the layout it adopts.
> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
While the web still lacks in certain areas to accomplish this with CSS, there are many new techniques with grid and flex that allow very little use of media queries to reflow the content.
When using break points, or media queries, I don't think you should abide to a constant set. While relative units might solve certain situations, it's not a complete solution.
Using constant set of breakpoint sizes is what causes these bizarre jumps from a "wow this is a very stretched out mobile site." By using grid and flex and things like auto-fit, minmax(), etc will get you part of the way today. After you still need to use breakpoints to handle edge cases. These should always be set only at the point they are actually needed, not a fixed "this how wide phones kind of are." This way when the page is resized you have a fluid adjustment of content that only reflows automatically (with grid and flex) and at strategic breakpoints for edge cases. So regardless of the device it will flow more smoothly according to your site's content, rather than just 5 different screens (breakpoints).
> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
Not sure what you mean. What does "no more space left" mean in practice, and how do you detect it with CSS?
Assume you have a number of cards organized in rows and columns. You could define how many columns to show between each breakpoint using several media queries. However, a better approach would be to use a flex container with `flex-wrap:wrap`. Specify `flex-basis` for its children and the browser will automatically wrap them accordingly. No break points needed.
That makes sense, thanks; although I am still not sure it's applicable to the case described in the article, where the author was complaining of the layout grid that changed a three-column layout to a single-column layout. Assuming that we use CSS grids for layouts, and grid's cells don't wrap, I can't imagine how one can manage without a media query that will change the number of the grid's columns. Which will cause an abrupt change in the layout, which is, if I understand the author correctly, something he doesn't like.
But instead of just using CSS units, you can use hard breakpoints, but not for the whole site.
Each UI elements needs to be tailored based on width and height of a browser, you cannot bucket everything.
The best way to accomplish this is container queries, which are just starting to show up in browsers. Essentially, you define breakouts based on the dimensions of individual elements, not the full browser window. https://css-tricks.com/say-hello-to-css-container-queries/
Sounds like they just dropped in Chrome Canary, so this is very, very early. That typically means it'll take years for it to be supported in all browsers or 99% of browser versions in use. Is there a polyfill solution for this in the meantime?
Container queries have been suggested for a while now, it is not a new idea. But it has gained a lot of momentum recently, for example [1]. So maybe it will not be years until all modern browsers might support it. Until then, you might want to try [2] (not a polyfill, but a workaround with JavaScript).
> The most striking example is when a horizontal menu bar is converted to a vertical menu bar: all the user's spatial memory of the menu bar's links flies out the window! That option that you thought were there? It's actually here!
What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.
Furthermore, vertical menus are far more common on mobile phones (not just on websites — apps too). Finding a way to shoehorn a horizontal navigation layout into a tiny screen is more likely to mess with a user’s spatial memory rather than respect it.
Exactly this. You can either having pages that scroll horizontally or content that reflows. There is really no other option available when dealing with a layout that can be arbitrarily resized (edited to add: there are a couple other options such as scaling down all individual UI elements, or simply removing some elements but those aren't really viable solutions in most contexts).
Since we have collectively decided that horizontal scrolling is unacceptable in almost all web contexts, that leaves reflowing content when the window gets smaller.
I understand the complaint and I sometimes have a similar frustrations. But, what other options are there that don't introduce horizontal scrolling?
Not all reflowing is created equal. Say you knew for certainty your users were only on desktop. In that case you may still want responsive design but it will likely be a different responsiveness than what we get with the cliff dive to "the mobile site". Reflowing can be done gently and granularly at the exact maximum points needed with minimum changes - rather than the stark nuking to a completely different site at 700px.
I think the issue is that many sites use screen size (e.g. max-width, max-height) as a proxy for things like "is this a touchscreen device", instead of using the media queries designed for that, e.g. (pointer: course) and (hover: none).
I understand _why_ things are done that way; it's far easier to design and test for three or four different screen sizes than it is to design for dozens of different combinations of screen size, pointer types, and screen orientations. Still, I get why some people might be frustrated about UI density _decreasing_ to accommodate a touchscreen when they reduce the size of their browser window on desktop.
> What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.
Before the author went off on a questionable advisement about javascript device detection he made a very good point: People should be using relative sizing for layouts so they scale.
Agreed, but I think the answer is still more nuanced than that. For example, even though touchscreen devices tend to have smaller screens, they need larger click targets; your finger is much less precise than a mouse cursor.
Ideally, both users get their way. The web developer should be able to just say "button" and have the browser decide how big it should be, based on the user's preference and what is appropriate for the platform.
Well, the context of the question, I think, is what you do when the "content" in question is navigation elements. I expect the page not to move things, either, but I also don't expect to have to scroll to access basic navigation -- and if you just let those elements wrap on a small display, well, we're back to the page moving things.
In general I'm (ahem) on the same page with you, but there are times when you have to decide on the least worst option.
> If you have a site that needs navigation elements then you don't have a site. You have an app. You should build an app instead.
I have a web site that has multiple sections in it, and some of those sections have articles or stories in them, and some of those stories have chapters. I have breadcrumb navigation for it. That is a navigation element. I am not building an app. There are also web sites that have menus in them, because they have different sections and they choose to let you navigate between those sections using tabs or buttons or left-hand navigation columns or whatever. Those web sites are, nonetheless, still web sites.
> When I scroll on a site I expect all of the site to move. That includes and headers or footers or sidebars.
And when I view a site on my phone, I would prefer not to have to scroll left and right to access navigational elements. Because there will probably be navigation elements. Because web sites have those. :)
> I have a web site that has multiple sections in it
Cool. Scroll up to change sections.
> and some of those sections have articles or stories in them
That's pretty spiffy.
> and some of those stories have chapters. I have breadcrumb navigation for it.
When I read an ebook, I scroll down. When I scroll down I expect the navigation elements to move with (and disappear from) the screen.
If you want to repeat your navigation elements at the bottom of the page, that'd be a nice compromise. But please do not keep navigation elements on screen.
> There are also web sites that have menus in them
Menus are not discoverable in websites. Most websites implementations of menus is god-awful. It's absolutely _not_ intuitive, ever, that hovering a mouse should open a menu. And if you click a menu, should that navigate to a new page like clicking on anything else? Or should clicking suddenly _not_ navigate to a new page but instead do something different? How do you tell the difference?
Answer: you don't. The site shouldn't use menus. Use hyperlinks.
> because they have different sections and they choose to let you navigate between those sections using tabs or buttons or left-hand navigation columns or whatever. Those web sites are, nonetheless, still web sites.
And they're trashy websites that should be apps instead.
I mean, okay. I never said "keep navigation elements on screen"; I said web sites need navigation elements. As for "menus aren't discoverable in web sites," well, again: I mean, okay. They've been around in web sites for about two decades and maybe they've made you mad for about two decades, but I am going to go out on a limb and say that a lot of folks, when confronted with a list of items across the top of a web site that read like Categories of Things much the same as the menus that they have been using in GUIs in many many many other places, can intuit what's going on.
Maybe we're talking past each other. It feels to me like you're imagining the way these things that can be designed that you find absolutely the most annoying and deciding that's what I'm describing, and that you also have super strong opinions.
Also, thanks for suggesting the documentation web sites that I work on that have left-hand navigation columns are "trashy web sites" because I need to include tables of contents that are always visible, but I respectfully decline your demand to turn them into apps, because that's stupid.
> You aren't. Why should you assume that a mobile browser window is any different than a desktop window?
Because it quite obviously is. It would be absolutely bananas if the default view for the New York Times’ homepage was a super zoomed-out full width desktop site like it was in the original iPhone demo.
"A layout optimized for different viewports results in the layout changing when the viewport changes."
How ridiculous to complain about a phenomenon that is basically tautological. The solution? Apparently it's user agent detection of phones vs. tablets vs. desktops. Because (of course) all phones are the same size, all tablets are the same size, and all desktop browser windows are the same size. Oh, and phones and tables are apparently also square.
The complaint seems to be about bad implementations of responsive design, as illustrated in the gif. In other news, bad design is bad.
> on non-responsive pages, it is very clear if the window needs to be resized to fit the whole page, but on responsive pages, there isn't anything signaling to the user that hey! the whole page doesn't fit with your current window size
So instead of appreciating that someone tried their best (which, sure, sometimes isn’t good enough) to fit their site to your window, they should have deliberately made it worse just to signal to you that you should make your window fit their site? Like, if the site looks cramped to you, resize the window. If it doesn’t, what’s the problem? This is a super-weird and niche request that would be better solved with a browser extension.
The title is so click baity and the whole premise seems flawed.
Spacial reasoning wouldn't work on mac if the users were constantly resizing their monitor. If you always want your website to look and feel the same, keep your browser the same size.
If you don't want a site optimized for small screens, don't make your screen small.
Additionally, this is all complaints with no solution.
It's not an anti pattern if it's the only way to solve a real problem.
> maybe it would be better if we went back to some form of user agent detection
God no. Just because I have a desktop PC with a big monitor, doesn't mean that I'll always have one fullscreen browser window occupying all of it. For all the troubles of responsive design, it's really nice to be able to tuck a website into a very narrow viewport at the edge of the screen to do something else while keeping an eye on it.
The mobile-first approach that web developers have adopted reflects the desire to maintain one codebase regardless of device. What the author of the article proposes is what we used to have before responsive websites: separate mobile and desktop websites.
You can design responsive websites today using CSS Grid without needing media queries, and the resulting sites can offer a better experience than using media queries. Unfortunately, not many developers are taking such an approach. Why not? It may be they are:
- using a CSS framework (that does not use CSS Grid)
- using a CSS-in-JavaScript-style framework
- need to support older browsers
- simply aren't aware of modern CSS features available
CSS is still horrible and will never be anything less than that, but...modern CSS (for modern browsers) lets you leave behind all the horrible CSS hacks from the past.
I recommend watching this excerpt from an excellent video by Jen Simmonds (Developer Advocate at Mozilla) on CSS Grid from 2018:
> web designers need to think long and hard about how they implement responsive design.
No, web designers need to do their best to balance cost/value of changes. While this might be a hot button topic here, I doubt the general public knows or cares much. Silly and self centered to DEMAND everyone needs to change to fit a niche group of users
Good responsive design is _hard_. I think people tend to pave over this by just recommending "mobile first" and then giving a list of breakpoints named suggestively after device classes ("iphone", "tablet", "notebook" and so on).
There's sadly no easy, widely supported, reliable way to identify what designers try to deduct from these breakpoints. Even if you correctly identify my 4K screen as a notebook, that doesn't mean you'll take into account that it has a touchscreen. And even if you detect the touchscreen, I may prefer using the trackpad instead.
Microsoft had the right idea with the prominent touch/mouse toggle on their Office desktop apps, even if the solution feels a bit clunky and awkward. In the end you'll probably just need to take an educated guess and allow the user to override.
But sadly this means instead of a simple linear progression from lowres/touch to hires/mouse, we end up with a multi-dimensional matrix of touch/mouse, lowres to hires and so on, doubling or multiplying the variations with each new variable (e.g. dark mode).
Responsive design is great, lots of people do it badly. C'est la vie. Most are making practical decisions regarding time and cost. I can look at my analytics and see very few people actually looking at the site between "standard" mobile and "standard" desktop sizes. Then I can look at conversion rates and figure out what's worth spending time and money on.
As for the author and his predicament, why doesn't he just zoom out? I'm pretty sure every desktop browser can do that. He can make his window smaller and have the full desktop experience. Sure the text will be a bit smaller, but you can't have your cake and eat it.
>As for the author and his predicament, why doesn't he just zoom out? I'm pretty sure every desktop browser can do that.
Oh wow, I can't believe I never thought of doing that. (Not sarcasm.) I guess I'm just accustomed to responsive design being so poor that any client side change borks eveyrthing.
I just tried that on Facebook, and it actually doesn't break the site, but moves it a little more toward the usability of the old design. Thanks!
Edit: With that said, "just zoom out" doesn't work on mobile: once you get to a threshold, at least iOS interprets further zoomout as "I want to see all my tabs". Bleh.
On mobile (Chrome/Android at least) you can tick the "Use Desktop" box and it'll display the full desktop site. You obviously have to pinch zoom in to actually read stuff (for the most part).
Suggesting a zoom out with smaller text is doing response design "badly".
Looking at your analytics buy matrix only tells you what is working now not what you should spent money on. If you fixed your desktop version your analytics looks a lot different next month.
I didn't suggest that was "good responsive design" and literally started my comment with "lots of people do it badly". The zoom out was a suggestion to fix the authors particular problem with sites that aren't doing responsive as well as he'd like.
As for analytics, yes, of course. But if my CVR is currently 4% on desktop, and 4% on mobile, and 2% on tablets, maybe I want to spend some money on my tablet design. But maybe tablet traffic is SO small in the bigger picture, that the money spent getting optimised for (and maintaining) tablet sizes is better spent elsewhere.
I'm not arguing for shitty design. I'm just saying it happens, and I can understand (in some cases) why.
> I can look at my analytics and see very few people actually looking at the site between "standard" mobile and "standard" desktop sizes.
You can look at your analytics and completely misinterpret what they mean.
I have a 2560x1600 screen. I almost never have a window fully maximized.
I have two screens at that resolution. I almost never have a window fully maximized.
I also have several 1920x1080 screens attached. I almost never have a window full maximized.
I have many windows open. Some are thin -- tens of pixels. Others are wide. Some are tall, others short. Mostly though, I get really annoyed when software decides that I can't have a window that size.
Your analytics aren't a useful metric for determining what a user wants to do or see.
> Those metrics come at the cost of spying on your users.
You can do analytics without doing Google Analytics. More people need to understand this. There is nothing wrong with analytics (other than code/network bloat from overuse). Every website you connect to already has your IP address, browser info, referrer site, etc.
> Just ask your users what they want.
Jesus no. Do you even understand why we do analytics in the first place? We do analytics because you can't trust users to actually say what they want. The analytics tells you exactly what users are doing.
And yes, analytics tells you that some weirdo is browsing your site at 20px wide. No one is spending money and time designing anything for the outliers.
You're getting off track here. If you ask the users what they want (and you have reliable sampling) you're going to get the same result - very few of them will be running 550px wide browser windows.
> If you ask the users what they want (and you have reliable sampling) you're going to get the same result - very few of them will be running 550px wide browser windows.
That's a very huge assumption. I know many people who would have 550px browser windows if those browser windows weren't cluttered with all sorts of garbage that won't go away when the window is resized.
> It's not a huge assumption at all. Lots of us already have access to this data from our analytics.
So you're saying that a lot of people have access to privacy-violating analytics. And that the analytics don't tell you what people want. And so you make decisions based on inferred information.
So again you're off track. We're here to talk about responsive design, not privacy issues. Analytics don't tell you what people want, but what they do. And what they do is browse the web in mostly large or maximised windows (when on desktop).
It's crazy to me that a bunch of people that I don't know and who don't know me nevertheless separately and repeatedly duplicate attempts to pick the correct font, size, weight, line length and line height for me, and the browser client running on my machine let's them do this with only the most minimal and transient fig leaf support for personalization.
The tools we use to access and share information are broken.
Bingo. Browsers have given away so much power and control to web designers that should be in the user's hands. I know what size text I like. I know what font and colors I prefer. Why make it so difficult to configure my browser to use them, and so easy for web developers to override my preference? The John Gruber site frequently comes up here as the poster boy for this problem: I have an enormous 27" beautiful monitor, but he just -decides- for me that I should be reading text in a tiny narrow horizontal sliver of that screen. Who the hell are you to tell me how I should be reading text on my screen? And the browsers are complicit.
> I personally like to my browser windows to be reasonably narrow […]
> What can the user do?
Just use a 1000+ pixel window width like everyone else.
The vast majority of desktop browsers are used with a 1000+ pixel with, often much larger. You are just the edgiest of edge cases.
I understand you’d like the whole world to cater to your weird preference for narrower windows, but making decent experiences for all sorts of operating systems, screen sizes, browsers, interaction models and so on is already hard enough. Asking for it to be made harder for your convenience is not a reasonable request.
The problem in that page is sidebarism -- there are two meaningless sidebars, a dark pattern, disinformation that we're accustomed to ignore, on the page.
Of course the real content should be privileged, but the #1 problem of the commercial web is the stuffing with trackers, distractions, time wasters, etc. and put responsive layout into that and it it is death.
I am working now on an HTML template to publish a photograph and some notes about it online and it revolves entirely around "taking over the viewpoint" so that I can put in a video-game style navigation bar (choose 1, 2, 3, 4 or 5 even if you don't know what it is it loads so fast you will) that always stays on the side but the other panel can have or not have a scrollbar, the photo automatically fits if you turn it, you can zoom in, etc.
It is possible with CSS and a polyfill, but it also takes a commitment to quality: I don't cookie you, I don't have to harass you with a cookie popup, etc.
Yup. This is super annoying. Web forums that I used to be able to use well on a Blackberry are now auto-flowed to a mobile setup even on a modern iPhone. And here’s the thing: the web forum actually HAS a separate mobile mode!
It is worth noting that responsive design is required for accessibility. The list of devices offered in the article omits, for example, ‘visually impaired users with zoom set to 400%’.
Web design isn't the answer. Web design is the problem.
I'm increasingly convinced that styling should be taken entirely out of the hands of the site / page designer, and into the hands of the user (or at least their device).
Offer a class of page styles (homepage, index, article, gallery, discussion, etc.). Offer a standard set of styles for these. Offer a set of minimal "identity" modifications for the site.
(The Microformats concept approaches this to a high degree.
As does Gemini, from another direction.)
And let the user agent (with an override for those few power users who know and care) choose which of those styles to apply. (Again, elites could modify/adapt the styles if desired.)
Yes, this means you're not going to be able to design "for X browser". Yes this means that appearance will be highly distinct across devices.
But at least those of us accessing content can read the motherlovin' thing.
(Accessibility, screenreaders, machine processing, etc., will also benefit.)
When I'm using my tablet, I'd rather get the desktop layout. Because my tablet's screen is higher resolution than that of many laptops, and, even if the screen itself is physically smaller, I also hold it closer to my face, and, most of all, because layouts designed for phones just look bad on it.
I kind of wish my browser could just set a flag that CSS can see, so that I can decide for myself how much I like hamburger buttons and four words per line of text.
> One of the fundamental concepts that informed the design of the Macintosh, the first true consumer-oriented graphical user interface, was the idea that humans could interact with computers spatially.
Does anyone know a source to confirm this? I remember reading an anecdote years ago that users got so used to the folders being the same as the window that held their contents that they had difficulties when that metaphor broke down. That story had some good insights on user-friendliness in design.
For instance, this article [0] talks about implementing the Finder, and how it "was the first to begin to take advantage of the idea of spatial organization". But really, all of e.g., Jef Raskin's work on UIs revolved around spatial metaphors.
I think debating where the breakpoints should be is fair. My rule of thumb is that a site should not go to “tablet” mode until it’s below half the width of a laptop monitor: ie anyone on a laptop should be able to put two windows size by size and still see the “full-width” version.
However, this is impossible to actually implement, because we don’t get media queries in “what percentage of the screen is visible,” we just get how many pixels (or virtual pixels) we have to work with.
One variation on the authors idea: suppose that browser vendors implemented media queries differently so they provided “screen=small|medium|large|xlarge”. Then the widths which trigger these layouts could be configured in the browser (with sane defaults), and the user could “lock” their browser to whichever query they preferred regardless of the window size.
But, that would actually be really hard to deal with on the implementation and testing side. Do you - should you? - care if a user has their browser locked to “xlarge” but then the layout breaks when the window is shrunk down to 500px wide?
At the end of the day there’s no perfect solution here.
For anyone building a React site that wants a solid responsive UI framework that makes it easy to adapt to multiple screensizes, I highly recommend Chakra UI: https://chakra-ui.com/
It allows you to set width and height units (as well as any other CSS style) for each component using an array or object to describe how the component should render for each screen width (as defined by you). Also has built-in React hooks for responsive variables.
I've never had a better experience building responsive sites.
I think most of what the author is complaining about is bad responsive design. Media queries, by themselves, are a powerful primitive, but they get harder to work with and balance the more complex your site gets. Better tooling helps!
Maybe this can be solved on the browser side of things. I can imagine that a browser could communicate the width of the screen as the width of the window to the webpage, even though the width of the window in reality might be made smaller by the user.
Imagine having a "lock layout" button on your toolbar. Once locked, the browser would continue reporting the window width as being what it was when the layout was locked - regardless of window resizing. I think this is a great idea!
I find it kinda ironic that the article is horrible to read on a phone, desktop style side paddings meet minuscule text ...
Given that i am using some hn reader app with integrated browser frame, it might be also safe to assume that the proposed imperative solution to "responsive design" would break on my edge case (it's not the reason for the current articles appearance though, it's just as badly optimised in the regular browser)
Would sure be nice if the website actually had a way of telling if its being displayed on a mobile device (in a way that would correctly detect a landscape mode ipad for instance), as well as a way of telling you are on a metered connection, or even slow connection. There are no reliable ways to do any of that in the browser.
Responsive web design caters both businesses (cheaper than having a separate mobile website) and users (single URL for everything). I guess the article author is out of the main demographics as most users don't notice this because they browse with maximized windows, and that's what the design trends are reflecting.
This article points to one poorly designed website which uses CSS media queries incorrectly (poorly chosen breakpoints) to try to justify that media queries are bad and it fails to mention the millions of websites which are doing it right.
> Cross-site inconsistency
The whole section doesn't present a single logical argument. The author later tries to argue that designing a completely different interface for each device type will somehow lead to a more consistent design across devices... That is completely contradictory. Also, maintaining all these different interfaces will involve a lot more maintenance work and will lead to inconsistent functionality between devices. I hate native mobile apps in part because the interface is often completely different from the website.
The whole point of media queries is to provide the most consistent experience possible between devices by sharing as much of the HTML layout and CSS as possible between all the devices. If the breakpoints are chosen carefully, it does an amazing job at this.
Responsive design is amazing. Just like any powerful tool, there will always be people who misuse it. It doesn't make sense to call something bad because it's flexible enough that it allows people to make mistakes.
People should stop blaming tools and start blaming people. Not all developers are the same. Many software developers these days are completely irrational and incapable of critical thinking... They should be working in a different industry. That's the real problem.
We try so hard to avoid hurting people's feelings that we end up blaming everything except the people. That's why so many people are completely incapable these days; most of them never received any criticism, never had any incentive to improve themselves.
How do you go from (paraphrasing) "this guy is wrong; responsive design is a powerful tool that can do an amazing job" to "kids these days suck because they never got enough criticism"? That's way out of left field. Who knows why the guy is wrong, or can you magically determine from that blog post that he's just an incapable schlub who was never subjected to enough shaming?
there are some useful ideas in responsive design, but for the most part it has become a cargo cult where checking the box of responsive design matters more than a thoughtful design for any of the sizes in question.
There are a variety of screen sizes that should work. I once got a very small screen android phone and pretty much no apps worked correctly on it. But the responsive design approach where elements resize and reflow, etc., is at best only a partial solution. Perhaps the UX on a tiny screen should be fundamentally different.
Responsive design presupposes various layout oriented invariants that may not actually be the most sensible way to reorganize information. This combined with the cargo cult of DRY results in some pretty bad design.
To me it looks like adaptive design, not responsive design. Responsive design scales seamlessly and doesn't even need breakpoints when designers don't insist on pixel perfect mockup recreations and let the browser do it's thing.
I really miss the defunct `media="handheld"` attribute.
That said, available layout area and the kind of user interaction available to an interface are separate concerns. So can we have `media="touch-only"`, please?
That forced three column layout with only content in the middle column is worse. Two thirds of my screen is empty white but I have to scroll vertically to read things like sample code.
A probably more realistic 'fix' for this would be a browser extension that could strip media queries out of all websites' css, below a certain threshold (eg, 600px)
The consensus that I believe has been reached in the front-end community is to design the CSS with mobile versions as the default — no media queries — and then adjust the design with cascading media queries to manage specific needs of the various sizes that grow from the default. With grid and flex offering truly responsive layouts without excessive or restrictive media queries, adjusting for tablet and desktop screens consists largely of filling in any layout rendering/browser quirks or handling design quibbles.
The reasoning for this is fairly simple: a majority of users visit the site on mobile devices. Sites are being developed with a single code base for the largest group of visitors, with tablet and desktop users being added on afterward almost as alternative views. Using this process doesn't always produce the best results for any browser size because it requires a design plan that considers the requirements of this method.
There's nothing to see here other than the Dunning-Kruger effect. Current responsive design practices are not perfect, but the author's conclusion (to target platforms with user agent strings) is downright regressive. There are a multitude of well documented reasons that we moved away from this, and it's offensive that the author didn't bother to educate themselves properly before penning this.
One thing that would help responsive design are breakpoints on elements, rather than the page itself. If my article preview component knows its own width, it can "break" accordingly into a better layout. While this is currently possible with JS, CSS support would greatly improve things (and enable the concept for non-js browsing experiences).
Echoing the idea, or restating it, I would say that a lot of responsive design is a failure to design in the first place. If a layout has to change radically between devices, browsers, etc., it most likely needs to be rethought from the ground up.
> Now, I think we can all agree that, on our desktop computers, we prefer viewing the full-width layout of most web pages.
This assumption is not reflective of current accessibility research. For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer. This is disproportionally impactful for older seniors, who might struggle with instructions like "remember to put an m. in front of the url".
WCAG 2.1 success criterion 1.4.10: Reflow is a good starting point for learning about this: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html