[HN Gopher] The anti-pattern of responsive design
___________________________________________________________________
The anti-pattern of responsive design
Author : mrzool
Score : 150 points
Date : 2021-04-22 09:50 UTC (13 hours ago)
(HTM) web link (john.ankarstrom.se)
(TXT) w3m dump (john.ankarstrom.se)
| politician wrote:
| 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.
| ryandrake wrote:
| 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.
| iamben wrote:
| 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.
| inetknght wrote:
| > _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.
| iamben wrote:
| "Your analytics aren't a useful metric for determining what a
| user wants to do or see."
|
| They're a pretty good starting point.
| inetknght wrote:
| Not really. Those metrics come at the cost of spying on
| your users.
|
| Just ask your users what they want. Or give them the option
| to change it themselves.
| deckard1 wrote:
| > 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.
| inetknght wrote:
| > _Jesus no. Do you even understand why we do analytics
| in the first place?_
|
| Yes.
|
| > _We do analytics because you can 't trust users to
| actually say what they want._
|
| False.
|
| > _The analytics tells you exactly what users are doing._
|
| At the cost of their privacy you get to learn what people
| are doing. That still doesn't tell you what they want.
| mdoms wrote:
| 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.
| inetknght wrote:
| > _You 're getting off track here._
|
| No I'm not.
|
| > _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.
| mdoms wrote:
| It's not a huge assumption at all. Lots of us already
| have access to this data from our analytics.
| inetknght wrote:
| > _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.
|
| No wonder the web is a dumpster fire today.
| mdoms wrote:
| 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).
| SilasX wrote:
| >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.
| iamben wrote:
| Haha, no worries! :-)
|
| 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).
| SilasX wrote:
| Yeah I move to desktop on a lot of sites, but then n some
| it doesn't make a difference because of the ugly mobile
| first.
|
| What's worse, there was some iOS update that made double
| tap to zoom very rarely work.
| eurasiantiger wrote:
| Pinch zoom doesn't work for that, but you can actually set
| the page zoom in the aA menu on the left of the address bar.
| ipaddr wrote:
| 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.
| iamben wrote:
| 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.
| mobjack wrote:
| Based on analytics of the website for my company, only 5% of
| users have a medium browser width.
|
| Instead of designing for three screen sizes, it is easier to
| design for two and give tablets the mobile experience.
|
| It is also the most challenging size to design for as you are
| restricted with horizontal space compared to the much more common
| desktop size.
| mumblemumble wrote:
| 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.
| themoose8 wrote:
| 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)
| [deleted]
| DHPersonal wrote:
| 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.
| jfengel wrote:
| Even if a majority of users aren't on mobile, there will be
| at least some. And mobile renders better on a desktop than
| desktop renders on a mobile.
|
| Desktop-only sizes and features are great add-ons if you have
| time. But being able to get MVP to 100% of users is the top
| priority.
| lolinder wrote:
| Does this solve the problem OP mentioned of many sites hiding
| the desktop version behind the query?
| themoose8 wrote:
| Alas, I mentally skipped over that part of the article and
| reacted to this being somehow on the onus of the web
| designer.
|
| It seems it may not be quite as simple as I described, but
| you could probably spoof the device width being sent to the
| web page
| terrortrain wrote:
| 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.
| DocTomoe wrote:
| > The crux is that it is not uncommon for web designers to lock
| the full-width design behind a media query and serve the mobile
| version by default.
|
| This of course is in part thanks to Google's "mobile first"
| doctrine:
| https://developers.google.com/search/blog/2020/03/announcing...
| open-source-ux wrote:
| 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:
|
| _CSS Grid: Assuming You Need Breakpoints_ :
| https://youtu.be/0Gr1XSyxZy0?t=189
| dreen wrote:
| 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.
| madeofpalk wrote:
| What's a "mobile device"? Is an iPad in landscape a mobile
| device? What about if that iPad has a 13" screen, the same size
| as laptops?
| deltron3030 wrote:
| 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.
| masswerk wrote:
| 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?
| FrontAid wrote:
| I agree with the general sentiment.
|
| > What can the web designer do?
|
| Completely disagree with this section.
|
| 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.
| simonlc wrote:
| > 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).
| azangru wrote:
| > 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?
| FrontAid wrote:
| 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.
| azangru wrote:
| 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.
| eurasiantiger wrote:
| Use a float grid which may flow ugly, or native CSS Grid
| which allows child elements to dictate their own min- and
| max-sizes.
| [deleted]
| yohannparis wrote:
| I agree with your sentiment.
|
| 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.
| jakelazaroff wrote:
| 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/
| chrisco255 wrote:
| 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?
| FrontAid wrote:
| 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).
|
| [1] https://github.com/w3c/csswg-drafts/issues/5796
|
| [2] https://philipwalton.com/articles/responsive-
| components-a-so...
| Izkata wrote:
| > 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.
| pdonis wrote:
| _> 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.
| [deleted]
| chipotle_coyote wrote:
| 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.
| resonantjacket5 wrote:
| It's not strictly defined but usually I've heard serving
| distinct mobile web pages (or layouts) as adaptive design
| andrewingram wrote:
| 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.
| molf wrote:
| 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).
| andrewingram wrote:
| 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.
| eurasiantiger wrote:
| Or, you know, use CSS Grid.
| tgv wrote:
| 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.
| thinkloop wrote:
| Not to mention watches and TVs
| pantulis wrote:
| 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.
| fanf2 wrote:
| I am amused that this article was unreadable on my default
| browser window because the text is too wide
| jamestenglish wrote:
| > 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
| Fauntleroy wrote:
| 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).
| scooble wrote:
| 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%'.
| matt_morgan wrote:
| 12 years later, Mobile-first design still solves this.
| lamontcg wrote:
| The thing I hate the most is click on some link in HN or reddit
| and getting the mobile site. Just make that go away, please.
| mdoms wrote:
| I don't think we should re-architect entire websites just because
| a handful of people like to browse in unusually narrow windows.
| burlesona wrote:
| 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.
| majewsky wrote:
| > 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.
| jakelazaroff wrote:
| _> 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.
| ncallaway wrote:
| 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?
| thinkloop wrote:
| 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.
| ncallaway wrote:
| Sure, but even if 100% of your users will be on a desktop
| site, you still need to deal with a browser window that has
| resized down to 300px.
|
| At _some_ point, you will have to have a significant
| transition if you have an website that is mostly optimized
| for a desktop, full window experience.
|
| I agree that _many_ sites overdo the transition, but there
| are some things that really do warrant a phase-change at
| some point.
| Scarblac wrote:
| > Sure, but even if 100% of your users will be on a
| desktop site, you still need to deal with a browser
| window that has resized down to 300px.
|
| In that case I would prefer the scroll bar over
| implementing a whole separate layout just for the 0.1%
| who resized their window to 300px for a moment.
| datagram wrote:
| > But, what other options are there that don't introduce
| horizontal scrolling?
|
| - Wrapping the menu to a second line
|
| - Moving menu items that don't fit to an overflow menu
|
| Both of these would preserve spatial memory for all of the
| earlier menu items.
| Ajedi32 wrote:
| 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.
| inetknght wrote:
| > _What do you expect to happen when there's simply no room for
| all the content to fit horizontally? Something has to give._
|
| First and foremost I absolutely expect the page to not move
| things!
|
| If I resized my window and things don't fit any more... then a
| scrollbar is _exactly_ what I want.
| deergomoo wrote:
| I feel like this should be a browser option more than a
| design consideration.
|
| How am I meant to tell if you are using a fullscreen mobile
| browser vs a resized desktop window?
| inetknght wrote:
| > _How am I meant to tell if you are using a fullscreen
| mobile browser vs a resized desktop window?_
|
| You aren't. Why should you assume that a mobile browser
| window is any different than a desktop window?
|
| I have an Android tablet with a 13" 4K screen and a stylus.
| A full screen window on there is _huge_ and you don 't need
| a huge button.
|
| I don't want huge buttons on my tiny iPod screen either.
| deergomoo wrote:
| > 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.
| chipotle_coyote wrote:
| 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.
| inetknght wrote:
| 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.
|
| When I scroll on a site I expect all of the site to move.
| That includes and headers or footers or sidebars.
| chipotle_coyote wrote:
| > 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. :)
| inetknght wrote:
| > _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.
| chipotle_coyote wrote:
| 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.
| [deleted]
| maxk42 wrote:
| > 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.
| jakelazaroff wrote:
| 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.
| inetknght wrote:
| That's what zoom is for.
| ska wrote:
| This isn't really an answer, you are basically throwing
| out usability for an appreciable fractions of users &
| devices.
| jakelazaroff wrote:
| I don't _want_ to zoom just to hit a tiny button. The
| design should accommodate my client. Zooming is an escape
| hatch in case it doesn 't.
| inetknght wrote:
| I don't _want_ to have giant buttons just because some
| people don 't want to zoom. Zooming is a feature to allow
| me to use my device the way I want.
| ryandrake wrote:
| 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.
| [deleted]
| Robotbeat wrote:
| 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!
| [deleted]
| rhn_mk1 wrote:
| > 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.
| lou1306 wrote:
| 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.
|
| [0]:
| https://www.folklore.org/StoryView.py?project=Macintosh&stor...
| hnbad wrote:
| 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).
| terrortrain wrote:
| Just assume everything is touch and mouse...
|
| My laptop is touch, and I use touch and the mouse frequently.
| Most apps work fine with either.
|
| If you do and context menu or whatever for right click, make
| sure you also implement them for long touch.
|
| All clickable things should be 40px or greater.
|
| Is there something I am missing? Some great mouse functionality
| that I never learned?
| coldtea wrote:
| > _I 'm sure I'm not alone in frequently experiencing this
| phenomenon. I personally like to my browser windows to be
| reasonably narrow_
|
| If you "like [your] browser windows to be reasonably narrow" then
| you're probably mostly "alone in frequently experiencing this
| phenomenon".
|
| Most people I've seen maximize (or close to maximize) their
| browser.
| mitchdoogle wrote:
| Why not just use browser zoom and font size to your liking?
| exac wrote:
| It would be interesting to find out what percentage of the
| population knows that their browser can zoom in, or pinch-to-
| zoom on mobile.
| jfengel wrote:
| It would be interesting to know what percentage of web sites
| have disabled zooming.
| idownvoted wrote:
| > _when I reduce the width of the browser window by a couple of
| pixels._
|
| > _I 'm sure I'm not alone in ... I personally like to my browser
| windows to be reasonably narrow_
|
| I do share his annoyance but I'm always hesitant to deduce UX
| needs of the masses from the needs of specialists. Especially if
| said specialists specialize in UX.
|
| Most users don't resize their browser windows all the time and of
| those that do, most non-techies don't care if the layout jumps.
| This GIF is a problem that only exists in UX people's heads. He's
| not alone as I've seen countless teams optimizing these jumps,
| animating them.
|
| > _I can 't believe that I'm saying it, but maybe it would be
| better if we went back to some form of user agent detection:_
|
| I think here he touches on the root cause: Why don't devices send
| a media-type like "print", "screen" etc?
| zebraflask wrote:
| 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.
| resters wrote:
| 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.
| dbjorge wrote:
| This article starts with a pretty big assumption:
|
| > 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
| megous wrote:
| 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.
| Semaphor wrote:
| I commonly use it on mobile, it's on the right side at the
| bottom, a very easy position to reach for my thumb
| dbjorge wrote:
| 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.
|
| [1] https://www.w3.org/WAI/WCAG21/Techniques/failures/F42
| hinkley wrote:
| 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.
| phreack wrote:
| 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.
| thinkloop wrote:
| Could you explain what you mean with an example?
| gmueckl wrote:
| 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.
| kbenson wrote:
| > 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.
| gmueckl wrote:
| 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.
| amelius wrote:
| Reflow can mean a bunch of different things. Do you mean that
| Android browser implements text flowing from one
| div/tablecell to another?
| gedy wrote:
| 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.
| layer8 wrote:
| 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.
| alpaca128 wrote:
| 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.
| ryandrake wrote:
| > 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.
| lostmyoldone wrote:
| 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.
| dbjorge wrote:
| 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.
| hinkley wrote:
| 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.
| deckard1 wrote:
| > 512 pixels of content centered in however wide your window
| is
|
| I'll still take it over Paul Graham's blog with all the text
| way over there on the left edge.
| ryandrake wrote:
| 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.
| fshbbdssbbgdd wrote:
| As a user, I encounter three kinds of sites:
|
| 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.
| jspash wrote:
| 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.
| solarkraft wrote:
| 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.
| arp242 wrote:
| > 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.
| fpig wrote:
| > 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.
| scaladev wrote:
| I'm doing this also, and for the same reason.
|
| >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.
| arp242 wrote:
| 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.
| PaulHoule wrote:
| 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.
| cryptica wrote:
| 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.
| ska wrote:
| > Responsive design is amazing. Just like any powerful tool,
| there will always be people who misuse it.
|
| This makes it sounds like most responsive site work really
| well, but there are some cases where people have done a bad
| job.
|
| That really doesn't match my experience.
| mrtranscendence wrote:
| 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?
| dredmorbius wrote:
| 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.)
| mikl wrote:
| > 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.
| tobr wrote:
| 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.
| chrisco255 wrote:
| 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!
| croes wrote:
| 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.
| psychometry wrote:
| "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.
| 8note wrote:
| Why does the website or browser have to choose this on behalf
| of the user? Why not let the user choose what they want as a
| setting?
| this-pony wrote:
| 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.
| taylodl wrote:
| 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!
| this-pony wrote:
| Indeed!, that is exactly what I had in mind.
___________________________________________________________________
(page generated 2021-04-22 23:02 UTC)