[HN Gopher] The ideal viewport doesn't exist
___________________________________________________________________
The ideal viewport doesn't exist
Author : Kye
Score : 223 points
Date : 2023-08-21 11:49 UTC (11 hours ago)
(HTM) web link (viewports.fyi)
(TXT) w3m dump (viewports.fyi)
| Solvency wrote:
| Many parts of this article are unviewable on mobile. Irony?
| esdott wrote:
| For those who think that you can simply build something "fluid"
| or "flexible," it's a lot harder than it seems. A lot of the
| industry jargon comes from print and the printing process;
| margins, padding, kerning, spacing, etc. There is no such thing
| as a fluid layout on a printing press (as far as I know :-). So
| we are stuck with a language to describe design based on a
| different era. Additionally, in the design phase you HAVE to
| select a layout/viewport for proofs and examples. Which in turn
| the client will expect to look exactly right on every surface.
| There is obviously room for client education and pushback but
| fluid designs seem like an afterthought in html/css where we are
| adding new features on top of html/css that are best used in a
| fixed width based system.
| eternityforest wrote:
| If you learn non fluid design first it seems hard. In absolute
| terms, it's really just a matter of using flexbox and percents,
| and being willing to just scrap your design idea and do
| something else if it doesn't map nicely to something fluid.
|
| Client education is a challenge and all, they often have ideas
| in mind that are very specific (For some reason clients
| invariably like the simplest thing that's the least general and
| most direct of a translation from a basic analog system...).
| But on the technical side... once you stop making designs that
| rely on being able to control exactly where everything goes it
| gets a lot easier.
| beeslol wrote:
| > If you're on a desktop device reading this, how many windows
| are filling the entire screen? How much screen space does the
| browser you're reading from take up?
|
| > It's safest to presume that users on desktop or laptop devices
| are not filling their entire screen with a browser.
|
| Is this true? If you're reading this casually (and you are
| reading this casually) is your browser not at full size? I almost
| exclusively use my desktop and laptop with windows maximized
| unless I'm doing some work which requires me to split up my
| screen (for example writing while looking at docs or program
| output). Am I the outlier here?
| aendruk wrote:
| I almost exclusively use my laptop split-screen unless I'm
| doing some work that requires maximization.
|
| Over the last few years increasingly many websites when
| allocated half the laptop screen have needlessly contorted into
| less functional layouts appropriate for a phone, but stretched
| huge.
| pdabbadabba wrote:
| For me, it varies by OS. I'm currently reading this on a Mac,
| and the window is not filling my entire screen. If I were using
| my Windows PC, however, I would be much more likely to have the
| window maximized. I find that Windows makes is easier to track
| all the windows I have open even when one is maximized.
| kosasbest wrote:
| Responsive sites have to be like elastic 'jelly' and accommodate
| every view-port resolution. The only exception being non-mobile-
| friendly web apps, in which case some sort of manifest should be
| read by the browser and presented to the user clearly stating
| mobile isn't supported and they should use a desktop browser
| instead.
|
| Then there's the progressive web app (PWA) debacle, where users
| don't even know what a PWA is and don't know that they can pin
| sites to their home-screen, simulating an app.
| calderwoodra wrote:
| Our product is the exception here (desktop only web app).
|
| We basically just account for 800-1300px width range and call
| it a day. On the low-side, we show a "desktop only" overlay. On
| the high side, we block the content from expanding.
| depressedpanda wrote:
| > Then there's the progressive web app (PWA) debacle, where
| users don't even know what a PWA is and don't know that they
| can pin sites to their home-screen, simulating an app.
|
| Users don't need to know what a PWA is. Thereason users don't
| know that they can be 'installed' is because they're on iOS,
| where Apple has been effectively hamstringing them in favor of
| the Apple App Store. There is a way to install PWAs on iOS, but
| it's quite hidden.
| mattigames wrote:
| The user may tap with their finger and later on they may use a
| mouse, many devices support both inputs so don't optmize for
| either (even after using one because the user may like to use
| both), the user may have spilled coffee on his device and is not
| able to see one part of the site, may sure to not put any element
| that needs to visible, the user may have a broken screen, its
| pretty common after a falling accident, so they cannot tap there,
| so don't add any elements that need to be tapped/clicked, overall
| the best its to have a blank page that doesn't show or do
| anything by design, this way nothing can be broken with the wrong
| viewport/device.
| mouzogu wrote:
| > "The main point we're trying to get across is that you simply
| do not know how users are going to visit your website or web app.
| Instead of making design decisions on strict, limited
| breakpoints, keep in mind the sheer amount of fragmentation there
| is in viewports."
|
| I don't know how useful this is.
|
| setting breakpoints allows some sanity in the build and testing
| process otherwise you have an infinite scope for issues which of
| course would be pretty lucrative for a boutique agency.
|
| > "This goes all the way back to planning your projects too. When
| mapping out page content, ask yourself how it will be for the
| weird viewport sizes that don't fit the typical mould? Always try
| to simplify and condense content to make it useful for everyone."
|
| it's really not that complicated. keep the amount of crap (stuff
| that can go wrong) like animations, weird font sizes and font
| faces, javascript to a minimum. and dont do stuff like hijacking
| the scroll, zoom or other common behaviours. just dont do
| anything unless you absolutely have to.
|
| but thats why the web is such a hostile platform. difficult to
| manage high user/client expectations with pragmatism.
| depressedpanda wrote:
| > setting breakpoints allows some sanity in the build and
| testing process otherwise you have an infinite scope for issues
| which of course would be pretty lucrative for a boutique
| agency.
|
| Honestly, now that container queries are available, I see very
| little use for breakpoints. Container queries allow for easy
| reuse of components, and a truly fluid and responsive design.
| tshaddox wrote:
| IMO the promise of container queries isn't that breakpoints
| will go away, but rather that breakpoints can emerge from the
| bottom-up composition of components rather than top-down from
| your CSS framework or Tailwind config or whatever.
|
| You're still probably going to want the left sidebar of your
| multi-column layout to collapse behind a menu on narrow
| viewports and abruptly appear when the viewport width gets to
| >= _n_ [0]. But it 's conceivable that the value of _n_
| emerges from some constraints you specify (such as the
| minimum desired width of the sidebar and the main content
| column), instead of being chosen upfront from a small list of
| predertmined breakpoints.
|
| [0] E.g. https://tailwindui.com/components/application-
| ui/application...
| depressedpanda wrote:
| While I suppose breakpoints might still have some use
| cases, I believe an overwhelming amount of the stuff we
| currently use them for can be better and more fluidly
| accomplished with container queries.
|
| The example you give of a sidebar collapse with a menu
| button replacement can easily be accomplished with a
| container query on the wrapping box, no?
|
| I'm honestly curious about a use case that a media query
| breakpoint can handle, but which a container query can't.
| brailsafe wrote:
| I wouldn't say it's a hostile platform, I'd say that it's a
| volatile design medium. Regarding breakpoints, I've always
| agreed with Jeremy Keith's opinion on the subject, which in
| some sense is to design for the content and fix it when it
| breaks, but to assume that it will and test it as best as you
| can. Breakpoints are just a way of demarcating broken/not-
| broken layout. I also use them for generalizing design if I'm
| doing it before writing the layout in code, which you can do if
| you start with no assumptions as to how it will be viewed, and
| just choose some arbitrary constraints to move things around
| within, then refine when you actually have something in the
| browser.
| danielvaughn wrote:
| The problem is that at a real company, this is very difficult
| because you have to argue with your product/design team and
| explain why you don't want to implement [x] feature because
| it's "too complex". Inevitably they'll point to some competitor
| website that has the same feature, which makes you look like
| you're just lazy. It's possible to succeed in those arguments,
| but it's hard.
|
| It's one thing to convince them not to do some weird
| scrolljacking, but even something like a dropdown or a popover
| adds a ton of complexity for responsive sites.
| withinboredom wrote:
| If your company cares one iota about accessibility, you can
| usually get those features off the table instantly just by
| arguing that point. "Yeah, well it's pretty clear that
| competitor doesn't care about blind people" is a pretty easy
| argument.
|
| I invite you to learn to use a screen reader and try using
| your app (whatever it happens to be). It's seriously pretty
| terrible for some of these websites with all the fancy crap.
| hagg3n wrote:
| I envy you cause the teams and companies that I've worked
| with basically say fuck em to that argument.
|
| I have lost jobs and annoyed people trying to argue for
| greater care with accessibility. It's somewhat depressing.
| avmich wrote:
| I think there are some laws which require a certain
| degree of accessibility for at least government websites.
| And if your big company deals with government, they'd
| better think about that.
| esdott wrote:
| This is exactly what happens. Especially if your voice is
| in the minority Or you're the only one. You're seen as a
| trouble maker. We all know what happens to trouble makers
| when margins are on the line.
| withinboredom wrote:
| I just stab them in the eyes and then say "now you'll
| care about blind people," then calmly walk away. Works
| every time. /s
|
| In all seriousness, I ask something similar to the above:
| "Would you feel the same way if you got in an accident
| that left you blind for the rest of your life?" Sometimes
| this moves a few people to your side. I don't want to be
| the only one, but I do care about accessibility. I care a
| lot, for personal reasons. But like you said, you don't
| want to be the minority trying to support minorities.
| [deleted]
| smarkov wrote:
| > I don't know how useful this is.
|
| I think very. I've never designed anything based on arbitrary
| breakpoints (md, lg, xl and whatever numbers they might
| translate to) because that forces me to make design choices
| around those constraints.
|
| The only way to sanely add breakpoints in my opinion is to
| gradually reduce the width of your page and search for things
| that start looking off. Are your paragraphs starting to look a
| little cramped? Add a breakpoint at that width, maybe remove
| the sidebar, maybe lower paddings and margins to allow it to
| stay a little longer, maybe manually reduce font size or switch
| your column layout to rows if applicable. Keep doing that until
| you get to ~350px width and everything looks fine. You decide
| what needs to change when it makes sense rather than being told
| that something needs to change at some specific breakpoint.
| traceroute66 wrote:
| > I don't know how useful this is.
|
| The website that is the subject of this discussion comes from
| Andy Bell.
|
| I would encourage you to see his other work, e.g. Every
| Layout[1], and the website[2] linked to a recent talk he
| gave[3].
|
| In particular the answer to your question can be found at
| 14:38[4] in the talk, perhaps more precisely the slide he shows
| at 14:59.
|
| [1]https://every-layout.dev [2]https://buildexcellentwebsit.es
| [3]https://www.youtube.com/watch?v=5uhIiI9Ld5M
| [4]https://youtu.be/5uhIiI9Ld5M?t=878
| eternityforest wrote:
| There's one thing I absolutely will disable and that is the
| MFing pull to refresh. I hate that feature more than pretty
| much anything else about the Internet.
|
| Users can't, for some hideous reasons that should be illegal
| due to accessibility concerns, disable it, and it is an
| excellent way to accidentally throw away your work several
| times a month if you don't have very steady hands, depending on
| if the back button decides to not restore.
| mmcnl wrote:
| I agreed with you until you went overboard with your last
| sentence. A "hostile" platform? What in the world? You
| literally just mentioned how easy it can be to avoid all this
| crap. There is nothing "hostile" about the web. I really don't
| like these overly strong statements.
| dsr_ wrote:
| Fundamental dilemma:
|
| * The web is a great way to publish information and access a
| few services.
|
| * The web is the cross-platform operating system for
| applications.
|
| Everything stems from the difference in those two approaches.
| Both are correct.
| ArtWomb wrote:
| If you need to get weird now, webgpu has arrived, what we
| really require is a dedicated demoscene on the live web ;)
|
| Your first WebGPU app (Conway's Game of Life)
|
| https://codelabs.developers.google.com/your-first-webgpu-app
| hammock wrote:
| Using the data provided, I calculated the minimum window size
| in order to have full viewability among a percentile subset of
| the audience. Here are the answers: Mobile:
| 50% of viewports: Width 375, Height 635 80%: Width 375,
| Height 635 90%: Width 360, Height 560 95%: Width
| 360, Height 550 99%: Width 320, Height 500
| Desktop: 50% of viewports: Width 1440, Height 900
| 80%: Width 1024, Height 600 90%: Width 1024, Height 600
| 95%: Width 1024, Height 600 99%: Width 800, Height 300
| [deleted]
| Sohcahtoa82 wrote:
| > and dont do stuff like hijacking the scroll, zoom or other
| common behaviours.
|
| The hijacking of scrolling pisses me off so god damn much that
| I've considered building Firefox from source and modifying the
| code to completely eliminate a website's ability to set the
| scroll position.[0]
|
| Front end devs, I implore you. _Stop acting like you think you
| know what the user wants in regards to scrolling behavior_.
| Smooth scrolling already exists natively in every browser.
| _There 's no need to try to re-implement it in JavaScript_.
| Your implementation will not work in every browser, and will
| only cause strange stuttering, bouncing, or even end up somehow
| completely disabling scrolling altogether. Do not try to get
| fancy and implement "momentum" into scrolling. You're changing
| a well-understood behavior into something that is unexpected
| and jarring, and likely it won't work anyways.
|
| Do not change the scrolling amount. My wheel sensitivity and
| browser setting are configured so that 1-click ~= 2.5 lines of
| scrolling. Do not impose _your_ preference of 1 click ~= 1 line
| on me. You do not know better than me.
|
| And disabling zooming? _WHO EVEN DECIDED THAT WEBSITES SHOULD
| BE ALLOWED TO DO THIS?!_ It _destroys_ accessibility! Sometimes
| there 's text or an image that's just a little too small to
| recognize. I'd pinch to zoom in...but some moron front-end dev
| has adopted the beyond-bone-headed mentality of "removing
| features is a feature!" and makes their site tell the browser
| to not allow zooming because...why? Someone please, tell me
| why.
|
| [0] I'm sure it's possible to write an extension that could do
| this, but any time you're manually setting the scroll position
| in code, you're bound to fuck it up. Rather just completely
| eliminate the ability to set the scroll position entirely.
| kyleyeats wrote:
| You're mad at the wrong people here. I've never met a
| frontend dev who doesn't hate moving stuff vertically or
| scrolljacking. It's the marketing people that want it.
| ncallaway wrote:
| The one that hurt me the most was making a page that
| started at the bottom and scrolled up. I left a comment
| somewhere in the JavaScript apologizing for it.
| depressedpanda wrote:
| > I'd pinch to zoom in...but some moron front-end dev has
| adopted the beyond-bone-headed mentality of "removing
| features is a feature!" and makes their site tell the browser
| to not allow zooming because...why? Someone please, tell me
| why.
|
| For sites that have no business disabling zoom: no idea, and
| it annoys me too. I just chalk it up to dev, designer and/or
| managment incompetence, close the tab and never return again.
|
| /Moron frontend dev
| drewrbaker wrote:
| As the poor sap who's had to build lots of these types of
| sites, I'll tell you that it's not the devs that want this.
| It's the damn client that keeps complaining about the
| "gravity" or the "momentum" or the "scroll speed" of the
| site. Locomotive.JS being the main thing clients want us to
| use... no amount of explanation of all your valid points will
| persuade them if "this one cool site we like had it".
|
| I will say this... the scroll speed being different between
| Chrome, Safari and Firefox doesn't help our cause... wish
| these were normalized at the very least so we can avoid "it
| feels better in X, but we use Y browser" notes.
|
| Allowing an easing function API for scroll would be a middle
| ground I could live with. It's better than what we have now
| (a bunch of award winning sites emulating scroll with
| translates).
| zimpenfish wrote:
| > And disabling zooming?
|
| I had a weird experience with Google Groups recently - I
| zoomed in because the text was too small and ... the page
| resized the viewport to its original pixel size even though
| the font was scaling. Ended up with about 10 characters in an
| unscrollable viewport. HILARIOUS.
| aidenn0 wrote:
| I had the opposite problem with a web page the other day.
| When I zoomed in, the text resized itself to still fit the
| same amount of text in the viewport, but since other
| elements would zoom correctly, the more I zoomed in, the
| _smaller_ the text got.
| paulddraper wrote:
| > And disabling zooming? WHO EVEN DECIDED THAT WEBSITES
| SHOULD BE ALLOWED TO DO THIS?!
|
| Applications such as maps, image editors, presentations, and
| flowcharts benefit from having control over zoom. (And you'll
| notice that almost every one of them does.)
|
| This of course is only one difference of many between
| "documents" and "applications" and the web is being used for
| both.
| gnarbarian wrote:
| yes you're right. we have a map with a toolbar at the top
| of the screen. when zoom was enabled people were constantly
| zooming in preventing them from being able to see some or
| all of the buttons hindering their ability to use the app.
| and causing confusion because they didn't realize they were
| zoomed in. as soon as we disabled zoom the complaints and
| questions stopped.
| throwaway14356 wrote:
| setting just the toolbar to not zoomable should have been
| the obvious solution.
|
| (In stead I have to disable zooming in on images to
| preserve the next/previous/close buttons and implement
| zoom from scratch. wtf?)
| debugnik wrote:
| No, they benefit from overriding the pinch gesture or the
| scroll wheel. Browser zoom shouldn't need to be a casualty
| for those features to work, it ought to stay available in
| some form.
| _jal wrote:
| Maps drive me fucking nuts, taking over zoom. As do nearly
| every other app that does it. They think they know what's
| good for me, and they don't, and it leads to me using them
| less. Yes, paper maps just work better for me a lot of the
| time.
|
| The only thing maps.app or Google maps are good for are
| finding places to spend money or driving to places to spend
| money. If you have any other spatial interests, they're
| almost pointless.
|
| I would happily run a build that removes this capability.
| paulddraper wrote:
| I would love to see your maps app that doesn't touch
| zoom.
| throwaway14356 wrote:
| No offense, I had to try that..
|
| https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE
| _el...
|
| Look how fast and responsive it is!
| aendruk wrote:
| With spatial range requests this could actually be a
| reasonable replacement for a slippy map.
| shadowgovt wrote:
| > The hijacking of scrolling pisses me off so god damn much
| that I've considered building Firefox from source and
| modifying the code to completely eliminate a website's
| ability to set the scroll position.[0]
|
| That'll break just about every cloud logging UI I'm aware of,
| but what you do to your own UA is your business.
| johnnyworker wrote:
| For me it really just involves squishing the browser window in
| all sorts of ways and see what happens, and if I get any ideas
| on what I would want to change. I don't see what the big deal
| is.
|
| > crap (stuff that can go wrong) like animations, weird font
| sizes and font faces, javascript
|
| None of these per se are the issue, and you can still have the
| issue with zero animations, fonts or JavaScript.
| [deleted]
| bryanrasmussen wrote:
| >I don't know how useful this is.
|
| >setting breakpoints allows some sanity in the build and
| testing process
|
| clamp allows for sane responsiveness
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/clamp
|
| and if needed you can add some minimal breakpoints.
|
| The fact is that most front end devs don't know about it, and
| there is no framework that I know of which is based around its
| use (and everything nowadays seems to be about the frameworks),
| thus you end up with inefficient multiple breakpoints which may
| seem sane until you get too close to one of the breakpoints and
| your design looks like crap until that point is hit and you can
| switch to the new values set for the breakpoint.
|
| breakpoints are a great solution if you happen to be living and
| working in the web of 3 years ago. But the clamp, min, and max
| functions have been available in every major browser since 2020
| - even Opera.
|
| People keep telling me 3 years is an eternity in internet time,
| so why are there still all these damn breakpoints?
| throwaway14356 wrote:
| it seems much cleaner to give each size its own css?
| adithyassekhar wrote:
| I was hoping to read some kind of solution at the end of all this
| huge text. Some radical way to do layouts without using
| viewports. Instead I got a link to buy a book from some author.
|
| Why is this even here? This is a long ad with useless data
| points.
| return_to_monke wrote:
| There is, it's called flexbox and the CSS grid.
|
| I've found that on simple websites a lot of problems are solved
| with just a few lines of flexbox config (flex-wrap, etc)
| adventured wrote:
| There's a way to do it entirely without viewports, although
| it's extremely unpopular with designers.
|
| Present a .css file for mobile or for desktop, based on the
| presence of "mobile" in the agent string. Chrome continues to
| report that agent data and it's very accurate for this use case
| (where your primary aim is to detect mobile equivalent, else
| present for desktop).
|
| You can drop the viewport html tag. All major phones, including
| iOS and Android operating systems going back at least a decade,
| will automatically scale your site for mobile without viewport.
| You customize the mobile version of your .css file for just
| mobile. And it's very easy these days to cross check to make
| sure the look and compatibility is correct (for Chrome and
| Safari mobile in particular). You present different site UI/UX
| based on the "mobile" detection; if mobile, present mobile
| layout, else present desktop layout.
|
| Google will punish you (SEO) slightly for the lack of a
| viewport tag however.
|
| This is a far easier way to design for mobile & desktop vs
| trying to deal with many different viewports (which is a
| ridiculous, backwards problem that represents an industry
| failure).
| depressedpanda wrote:
| For any aspiring frontend devs that might not know better:
| they're talking about user agent string parsing.
|
| Please don't do this. There's a reason it's an unpopular
| approach.
| madeofpalk wrote:
| Cannot tell if this is sarcasm or not...
| adventured wrote:
| Nope, it works very well. I have been testing it routinely
| for a decade now.
|
| The core to it is simply getting the "mobile" keyword out
| of the user agent string. That takes care of nearly
| everything, from there all you have to do is a simple css
| split for either desktop or mobile.
|
| It very effectively covers all the major browsers, all the
| major platforms, going back at least a decade.
| temac wrote:
| I'm not even sure what mobile means in this context. What
| happens when you plug your phone on a screen? What happens
| when you use a tablet?
| adventured wrote:
| That's very straightforward. Obviously the user agent is
| reported by the browser/device as mobile or not (it either
| includes that keyword or not). In nearly all cases mobile
| means smartphone or tablet, whether Android or iOS, Chrome
| or Safari. iPad commonly includes the mobile keyword in its
| user agent string, unless desktop is enabled by default and
| then they'll just get the desktop version (you could
| trivially detect for the iPad keyword and force mobile;
| given the userbase size of iPad it would probably be worth
| it, it'd take seconds to do). This approach covers such a
| comprehensive percentage of users that it's only going to
| be an issue if you absolutely need to cover every single
| possible variation, and then you have to do it another way
| to go from 99% to 100%.
|
| Your desktop browser doesn't include the keyword "mobile"
| in the agent string. Your Safari browser on iOS does, ditto
| for Chrome on Android.
|
| So here's the iPhone 13 Max user agent string:
|
| "Mozilla/5.0 (iPhone14,3; U; CPU iPhone OS 15_0 like Mac OS
| X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0
| Mobile/19A346 Safari/602.1"
|
| The "mobile" keyword gets you what you want.
|
| Here's iPhone 8:
|
| "Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X)
| AppleWebKit/604.1.34 (KHTML, like Gecko) Version/11.0
| Mobile/15A5341f Safari/604.1"
|
| The "mobile" keyword gets you what you want.
|
| ChromeOS desktop (Chrome browser), Mac desktop (Safari),
| Windows desktop (eg Chrome or Firefox). They don't include
| the "mobile" keyword.
|
| It's not flawless, getting to 100% requires a lot more
| effort. This approach is far beyond good enough however,
| particularly for an average site. If you're building a
| giant enterprise app and want to appeal to every possible
| user and you have a team, maybe you'll throw a lot more
| resources at getting the small number of problematic edge
| cases.
|
| And if you're using Nginx, which I commonly do, you can map
| the agent key in your http segment, eg:
|
| map $http_user_agent $mobilekey {"~*Mobile" mobile; default
| desktop;} (or vise versa)
|
| and then you can utilize that for caching related tasks
| (attach it to your proxy_cache_key to differentiate a
| mobile vs desktop cache).
|
| And as I've noted, this is widely despised by the HN crowd
| despite the fact that it works so well and so easily.
| ghusto wrote:
| > It's safest to presume that users on desktop or laptop devices
| are not filling their entire screen with a browser.
|
| Not on literally any laptop I've ever seen. I've never seen a
| screen where the browser _isn't_ filling all space available to
| them, sometimes even the entire screen (in fullscreen mode on
| MacOS).
| MrJohz wrote:
| For general browsing, that's often the case, but for solving
| tasks, I often see people using the "snap to side" feature in
| Windows. It means you can view two windows side-by-side without
| faffing around dragging window sides around, and it's really
| useful if you're trying to cross-reference data on a smaller
| screen.
|
| Although I think that sentence would probably be better written
| "It's safest not to presume [...]", as in, don't make
| assumptions about screen sizes here.
| kube-system wrote:
| I presume you're talking about maximized windows, but that
| still does not equal "filling the entire screen", because
| browsers have their own user interface around the viewport.
|
| Go maximize your browser and enter this into your dev tools:
| console.log(`${window.innerWidth}x${window.innerHeight}`)
|
| Does that equal your screen resolution?
| madeofpalk wrote:
| I like this because opening the dev tools has a high chance
| of changing innerHeight :)
| kube-system wrote:
| And even if you open dev tools in another window, many
| people run browsers that are configured to display other
| controls... like tabs, or an address bar.
| amiga-workbench wrote:
| Its a Mac user thing, they have a collage of overlapping
| randomly shaped windows splayed everywhere. Windows users tend
| to just maximise their programs or snap them when needing to
| multitask.
|
| Gnome pushes users to fullscreen programs too, with a quick
| mouse twitch to get the overview open to switch programs.
| chc wrote:
| A lot of Linux users tile their windows too.
| sebzim4500 wrote:
| I think most people have a task bar at the bottom, at least on
| Windows and Linux.
| PMunch wrote:
| You never side by side your browser and another application
| like a terminal or text editor? And even barring that the
| taskbar of your OS along with window decorations means that
| your browser is seldom 100% of the screen. This is also talking
| about the viewport, so even though they clumsily refer to it as
| the "browser" the website won't be given 100% of your
| resolution even if your browser did have 100% simply because of
| things like the tabs bar and other navigation. Can you full-
| screen a website? Sure. But that's not the common way to
| browse.
| jerf wrote:
| I believe the intention of that statement is to not _assume_
| that it 's filling the entire screen, that is, not to count on
| it in some manner.
|
| A lot of people still make this mistake one way or another. In
| about the last year I finally gave up; my tiling window manager
| used to have the browser at 2/3rds the screen with the
| remaining 1/3 a terminal, but more and more I've been
| encountering websites that are very unhappy with that width;
| not small enough to kick in mobile mode or they detect that I'm
| on a desktop browser and don't adjust, but not large enough for
| the design they serve me, creating overlapping regions, or
| horizontal scrolling, etc. So my browser is full screen a lot
| more often now. On the one hand I'm annoyed, but on the other,
| an implication of the article is that you essentially can't
| test at "all" viewport sizes anymore and it's just so easy to
| accidentally write a website that is unhappy at _exactly_ pixel
| widths 892-945 when used with my exact font setup and /or zoom
| setting that I can't really stay mad at some of these sites.
| Some of the sites I have trouble with are clearly trying, and
| are competent in many other ways. You can hardly expect your
| designers to visit every page on your site and test every
| single width from 200 to 2000 one pixel at at time, let alone
| ask them to do it again with a variety of zoom settings.
|
| Heck, I can't even tell you my own website can do that. I've
| checked it on a phone and in my desktop browser at a couple of
| sizes, but I can't do it anymore than anyone else can nowadays.
| Kerrick wrote:
| I've noticed similar annoyances lately browsing sites on my
| 4K displays set to 200% scaling and positioned vertically.
| Sites tend not to work or look their best at 1080px wide
| anymore.
|
| It almost makes me nostalgic for 960px being the defacto
| standard width for desktop sites.
| marginalia_nu wrote:
| You've never seen a 17"+ laptop I guess?
| bandergirl wrote:
| [flagged]
| ryandrake wrote:
| I have a 27" display and browse with the browser window
| maximized. I paid for this display, and I expect to use
| every pixel. Web designers, however, seem to hate me for it
| and choose to constrain the width of their content to a
| tiny, 6cm column down the middle of my display, leaving 80%
| of the width as whitespace.
| bandergirl wrote:
| Clear case of _you're using it wrong_
|
| I don't know how you expect a designer to fill 27" with
| an article. Surely they could add several columns just
| for you, though, a great investment of team hours.
|
| There are very few types of websites that benefit from
| all that space and it's usually video and photos.
| mcv wrote:
| I recently bought a 4K screen specifically to be able to
| have an IDE and a browser next to each other. Every once in
| a while there's an app that thinks that all of that screen
| real estate is really all just for them. It's not.
| bandergirl wrote:
| Placing windows side by side is the correct usage of the
| available space, I hold no qualms against you.
| DylanSp wrote:
| My guess is that filling the entire entire screen is _common_ ,
| especially on laptops that aren't hooked up to a monitor, but
| not common enough to assume that'll always be the case.
| bee_rider wrote:
| It just seems like confusing wording. I think you are right
| that most people use their programs full-screen on laptops (As
| an aside, it is funny that thin-and-light-ism has managed to
| progress to the point where the average person finally gets the
| 2008 experience).
|
| But I think what they meant is: it is safest not to presume
| that desktop or laptop users are filling their entire screen
| with a browser.
|
| The way they wrote it suggest that the assumption of the
| negative is safest, while the way I wrote it says it is safest
| not to make the assumption. This has a general smell of the
| inverse fallacy, although it isn't like they are trying to make
| some bulletproof logical deduction anyway.
| catapart wrote:
| I'm kind of surprised here, myself, and am very interested in
| seeing real numbers because, just from the replies to this
| comment I'm seeing a lot of difference of opinion.
|
| Personally, I always use a browser full screen and most
| everything else is 'windowed'. My browser usually ends up
| being the "background" of my monitor, only traded out when
| I'm writing code, in which case my IDE is the "background"
| (full screen). Everything else except games runs in a smaller
| window. Dragging and dropping still works, like that. It's
| just really convenient.
|
| From mostly working with other devs, this is usually what I
| see. This is how I see MOST people use their desktops. Full
| screen browser, always. Then we get to this article and this
| comment section and people are talking like it's a given that
| MOST people use their browsers in windowed mode. Personally,
| the only time I can even remember someone doing that is when
| they snap it to an area and then snap something else beside
| it.
|
| My suspicion is this is a Windows/Linux vs Mac thing?
| Everything in Mac defaults to "floating" app windows, instead
| of defaulting to a single app window, maximized, with sub-
| panel windows inside the app renderer. So people just kind of
| mentally map it that way, depending on the OS? But then,
| that's just a guess!
|
| Obviously, I don't mean to imply that one way is better or
| worse. I'm just kind of intrigued by how blindsided I - and
| apparently others - are about this.
|
| Anyway, you're right about the article's hand-waving. It's
| not as compelling to me, because I've had users file tickets
| when our "anything past 1060px gets centered on the screen,
| instead of expanding to fill" method was displayed on a 4K
| screen. They claimed it was "unusable", even though it was
| entirely the same, it just didn't expand as much as they
| would have like (yes, even on a TV; other users were using it
| just fine). So I don't think anything past 800 is less worth
| consideration. At the very least, I'd say that number is more
| like 960 or 1400. The upper end of standard desktop sizes
| instead of the lower. At 800px width, even default browser
| font sizes look big. Scaling down to a 10 or 11px font size
| is fine for complex utilities, but when you're trying to size
| it for big, finger-sized buttons, 800px gets cramped, fast.
|
| But yeah, the overall advice holds.
| flohofwoe wrote:
| That's the definition of 'anectodal evidence' though. The nice
| thing of desktop environments is that people (still) have
| enough freedom to organize windows the way they want without a
| platform owner telling them what's "best for them".
| RugnirViking wrote:
| Nice web design but this jumped out at me:
|
| (they have 120000 viewpoints):
|
| "Wembley stadium has a capacity of 90,000, so our datapoints
| could fill Wembley once and still fill another third of the
| available capacity."
|
| the way this is written adds to confusion rather than enlightens.
| "another third of the available capacity" makes it sound like
| there is space left over in wembley i.e. you haven't fully filled
| it.
|
| I think people know how big 120.000 is, but if you must, just say
| its more than wembley
| shortrounddev2 wrote:
| Also, working in an industry with a lot of data, 120k isn't a
| lot
| afavour wrote:
| Come on, that's a silly statement. There's no point comparing
| completely context free "amounts of data".
|
| If the post was "the incredible difficulty of inserting 120k
| rows in database" you'd have a point. But it isn't.
| paxys wrote:
| Such meaningless comparisons also often have the opposite of
| the desired effect. I read it and went "there are >8 billion
| people all over the planet, and you can fit all the possible
| viewports into a single football stadium. Neat!"
| pdabbadabba wrote:
| > I think people know how big 120.000 is, but if you must, just
| say its more than wembley
|
| Agreed. And if you _must_ compare to a stadium, why not just
| pick a bigger stadium? You can pack at least 115,000 into
| Michigan Stadium.
|
| (What's that you say? You've never been to Michigan Stadium?
| That's probably another reason not to rely on this kind of
| comparison! I, for example have never been to Wembley.)
| swayvil wrote:
| Could an AI write a JIT custom window manager? Or would that be
| too unreliable?
| chiefalchemist wrote:
| With flexbox and grid, and dynamic text size, how necessary are
| breakpoints at this point?
| quickthrower2 wrote:
| Scroll hijack makes this unusable
| ovao wrote:
| I didn't experience any issues on my first read through, but on
| the second visit it now randomly scrolls back to the top of the
| viewport.
| paxys wrote:
| Pretty ironic that a post about accessible web design is
| unreadable because of scroll hijacking that makes it constantly
| jump to the top (at least on mobile).
| rmilejczz wrote:
| ya this gave me quite a hearty chuckle. I'm sure the content of
| the article is excellent but it's impossible to read on my
| viewport
| PMunch wrote:
| I wish more pages took the pointer and resolution media queries
| into account. So many times I open windows side-by-side on my
| desktop and end up with the menu collapsing into a hamburger menu
| which fills the entire screen when clicked. Many phones today
| have very high DPI and very low precision in touch, so it makes
| sense to have massive visual elements and buttons, but my desktop
| with the same size in pixels as my phone but a much lower DPI and
| much higher input precision doesn't really need them.
| TT-392 wrote:
| When I visit my bank, with my browser taking up half my 1080p
| desktop display, it tells me to use the app instead.
| aimor wrote:
| I know the official line is that "media types have proven
| insufficient as a way of discriminating between devices with
| different styling needs." But as far as I can tell most people
| really do just want to know if the visitor is viewing on a
| monitor or a phone. Trying to back that out through media
| features like viewport resolution and pointer types has been a
| big mess. I don't think the plan to replace media types with
| media features is wrong, but so far we haven't been given the
| right features to do what we want.
| crazygringo wrote:
| I'm actually not entirely sure what you're talking about.
|
| I'm very familiar with websites switching to mobile layout with
| hamburger menu instead of a navigation bar, when you reduce the
| width of the browser window on your desktop. BUT I don't think
| I've ever come across a _resolution change_ where the website
| elements (either hamburger menu or content) get massively
| larger.
|
| Can you provide an example of one or two mainstream sites that
| change resolution like that?
|
| The reason I'm confused is because in CSS everything is based
| on logical pixels, not actual device pixels. E.g. a "1 px"
| width will be 2 or 3 hardware pixels wide on an iPhone.
| Similarly "1 em" will be 16 hardware pixels on a standard
| resolution display, but 32 or 48 hardware pixels on a 2x or 3x
| display. So web designers don't have to do anything special to
| accomodate hi-DPI screens in the first place.
| withinboredom wrote:
| The resolution doesn't change, but a 64x64px icon button
| doesn't need to be that big on a desktop.
| crazygringo wrote:
| But this is my point, I haven't been seeing any 64x64 px
| (logical pixels) hamburger menu icons out in the wild. That
| would be too big for mobile as well.
|
| The hamburger menu buttons all seem normally sized to me
| when I make a browser window narrow on my desktop.
| withinboredom wrote:
| Yes, if you are on a touch screen, you need 'normally
| sized' hamburger menus. When using a mouse, a 16x16px
| hamburger is plenty big enough.
| crazygringo wrote:
| I think you may have misunderstood my comment. I'm saying
| I _am_ seeing normally sized hamburger menus on desktop.
| You 're using an example of 64x64, I'm saying I don't see
| that.
|
| Although 16x16 is a little on the small side even for
| desktop. The point isn't just to click it, but to have it
| be prominent enough to _see_ and notice as a primary
| action. It 's about visibility, not touch area.
|
| For example, on the SquareSpace homepage (an example
| someone else brought up) it's 30x18. That seems like a
| nice size to me. It's two pixels taller than the 16 you
| suggest, but the extra width helps make it a little more
| prominent. Especially since the width isn't taking away
| from anything else.
| withinboredom wrote:
| It is 44x44 on my computer. Absolutely massive.
|
| https://imgur.com/a/dL1Se2v
| rendaw wrote:
| The folder on your desktop is roughly the same size.
| crazygringo wrote:
| It can't be 44x44, it's not even square.
|
| I can't tell what units you're measuring in, are you
| measuring hardware pixels on a hi-DPI screen? We're
| talking about _logical_ pixels which is the only thing
| that makes sense to measure in and compare.
|
| But comparing it with e.g. the refresh button on your
| browser, it's merely 17% taller than that, in your
| screenshot. So I literally don't know what "absolutely
| massive" you're talking about.
|
| It seems perfectly fine to me. Maybe I'd make it a little
| narrower, but they probably wanted to balance the logo in
| the top left corner in terms of visual weight, so it
| makes sense.
| omegabravo wrote:
| The button is 44x44. The SVG is 30x18
| crazygringo wrote:
| If that's the clickable area, is someone complaining
| _that 's_ too large?
|
| You've been able to select radio buttons by clicking on
| their text for decades now. On desktop. Often literally
| hundred of pixels wide.
|
| Generous margins for clickable elements seems like a
| feature, not a problem. As long as they don't interfere
| with anything else (which they don't, here).
| withinboredom wrote:
| > Often literally hundred of pixels wide.
|
| And 16 pixels tall...
| carlosjobim wrote:
| It doesn't work like that. Web browsers do not count actual
| pixels when rendering. They adjust high density pixels to the
| equivalent real life size of low density pixels.
| afavour wrote:
| The OP is talking about things like media queries that only
| look at screen width and imply other things like input method
| from that.
|
| IIRC SquareSpace does exactly what they're saying: on desktop
| sites will have a horizontal list of links but on mobile it's
| a hamburger icon that takes over the entire viewport when
| clicked. Functionality exists to target pointer type and
| things like that in media queries, it's just very rarely
| used.
| johnnyworker wrote:
| Ohhh, I had no idea! Thank you.
|
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/poin... coarse -
| The primary input mechanism includes a pointing device of
| limited accuracy such as a finger on a touchscreen.
| fine - The primary input mechanism includes an accurate
| pointing device, such as a mouse.
|
| This solves everything! What I _really_ want is having more
| padding on mobile, that 's it. I prefer things to be
| compact otherwise, and it seemed hard to square that
| circle... with the pointer media query it's so trivial.
|
| Gotta love how every time you don't watch CSS like a hawk,
| it spawns 500 new features. Thanks again.
| withinboredom wrote:
| I'm actually surprised this isn't a selector in tailwind
| css.
| pests wrote:
| That is one of the issues trying to re-implement every
| css property:value pair with a class name inherent in
| Tailwind.
| crazygringo wrote:
| But that's what you _want_ , no? I just visited SquareSpace
| and their homepage seems to work as I'd want. When my
| viewport is narrow enough that there isn't space for the
| horizontal navbar at the top, it switches to hamburger
| menu.
|
| Surely this is better than cutting off the navbar and half
| the page content in the middle vertically, and requiring
| the user to scroll horizontally?
| afavour wrote:
| The hamburger menu could just be a vertical drop down
| stack rather than something that takes over the entire
| screen.
|
| The point is that the viewport-covering menu is huge
| because it's designed to accommodate touch (i.e.
| imprecise) interaction. It could be much smaller when the
| user is using a mouse. But you rarely see such
| accommodation being made. The assumption is low width =
| mobile = touch.
| crazygringo wrote:
| I still don't get it.
|
| The _actual menu items_ you select are 20 px font size in
| the hamburger menu, and 18 px font size from the navbar
| menu. That 's just 11% larger. Nothing about that is
| "huge".
|
| The hamburger menu taking over the whole (narrow) screen
| doesn't bother me at all. If I'm using the menu, it's not
| like I need to be looking at the rest of the screen.
|
| And it just feels silly to create a _third_ design. We
| already have navbar for widescreen and hamburger menu for
| narrow screen. Now you want a third version -- a
| hamburger menu that is pop-up rather than fullscreen --
| for narrow desktop usage? I sure wouldn 't want to do all
| that extra work.
| tacker2000 wrote:
| This. Unfortunately today, the desktop is an afterthought and
| everything is designed for "mobile first". I even see this in
| SaaS apps that should actually never be used on a phone. Or
| desktop OSes like windows and mac are increasingly using mobile
| paradigms on the desktop.
|
| There is so much whitespace, huge fonts, huge buttons,
| hamburger popup menu everywhere (aaaargh!!)
|
| Basically it boils down to the "information density" which is
| dumbed down to the lowest possible denominator.
|
| There should be a measure for this and websites/apps should be
| rates based on that.
| mmis1000 wrote:
| It sounds like you are talking about gmail web at md2 era.
| The giant sidebar item that can only literally show 6 item on
| a 1080 screen. The giant mail row that display only 10 or
| maybe 15 mail on whole screen. And new mail button on right
| bottom that requires you move your mouse across the whole
| screen to write a new mail.
|
| It really makes me wonder 'wtf? Who designed that, did he
| actually try to use it by himself?'.
|
| At least it seems they steps back a bit now. Also they moved
| the new mail button back to top left.
| Technotroll wrote:
| This is an interesting observation. Do you have some examples
| of this?
| aendruk wrote:
| Screenshots: https://cloudflare-
| ipfs.com/ipfs/QmUL69cYwCs2sWV7eHqtt14BEcn...
| bandergirl wrote:
| > Do you have some examples of this?
|
| Sorry if it sounds rude, but have you used the web on the
| desktop in the past 10 years? Anything under 1000px-wide
| windows and sometimes 1200px-wide ones gets you the "mobile
| menu" on most websites. It's a consequence of Bootstrap and
| other fixed-breakpoint frameworks. Overflow menus like what
| you see on GitHub repositories are the minority.
| throwaway290 wrote:
| react.dev
|
| And for an example that does it better, legacy.reactjs.org :)
|
| When I saw it I wondered how they managed to drop the ball so
| hard and how much they paid for it. All they needed is to
| expand and slightly restructure the docs, but apparently
| someone sold them a complete redesign that just made the
| whole docs way less usable (a11y aside, can't speak for
| that).
| cthor wrote:
| That masonry layout diagram is horribly deceptive. The boxes
| aren't to scale at all.
| mcv wrote:
| I see it often, and I hate it. It standardises on width, so
| everything that's wide (landscape oriented photos, or in this
| case desktop windows) gets shrunk dramatically.
|
| In this particular case, it makes the largest viewports look
| the smallest, and makes the smallest ones look largest. It's
| indeed very deceptive.
| aidenn0 wrote:
| Android app authors ought to read this too. I recently had an
| android app where the button on one screen was past the bottom of
| my screen _and it wasn 't scrollable_. I went to report the bug
| and someone else had already reported it.
|
| Given that the workaround was to set the system font-size small
| enough that the button would appear back on the screen, this
| would also be an accessibility problem for those who have their
| font-size set larger, even if their screen would be normally
| large enough to display it.
| karmakaze wrote:
| Landscape on mobile is the least well supported configuration I
| know. Static headers/footers commonly take 50% or more vertical
| space with no way to dismiss or shrink them.
| coldpie wrote:
| I'm going to change your life: https://github.com/t-mart/kill-
| sticky
|
| It's a bookmarklet that gets rid of sticky elements. It nukes
| those stupid fucking headers and footers and kills most cookie
| banners and "give me your email" type pop-ups. Works in every
| browser (I use it in Safari on iOS and Firefox on desktop). I
| almost reflexively go hit this bookmarklet on every website
| now. It makes the web so much better.
| tantalor wrote:
| > no way to dismiss or shrink them
|
| You can shrink them by rotating your phone back to the correct,
| portrait orientation.
| karmakaze wrote:
| Or shrink everything to unreadable sizes with "Desktop site".
| layer8 wrote:
| It also happens on tablets and notebooks, in particular with
| larger font sizes or zoom factor configured.
| ciwolsey wrote:
| I refuse to read anything even remotely related to accessibility
| written by someone dumb enough to put white text on a yellow
| background.
| teekert wrote:
| ? I don't see that anywhere?
| adventured wrote:
| I'm on desktop so maybe it's different on mobile, however I
| don't see a single example on their site of white text on
| yellow background, only black text on yellow background.
| locusofself wrote:
| "The population of our home town, Cheltenham, is around 116,000
| so our datapoints could almost populate the entire town!"
|
| 120,000 > 116,000, so their 120k data points could _more_ than
| populate the town...
| terracottalite wrote:
| LOL. Line 1268 of that CSV file [0] has a negative height. And it
| actually is in the visualization [1]. Wonder what kind of device
| reports a -2000 height :D
|
| [0]:https://viewports.fyi/data.csv [1]:https://viewports.fyi/all/
| lucideer wrote:
| There's an elephant in the room here, and it's Adobe.
|
| The author's put forward a lot of valid criticisms of the
| breakpoint-based approach & also provided a really good guide to
| doing proper web design, but what's skipped over is that their
| guide only works for developer-designers, & won't fit the
| workflow of a large proportion (majority?) of people doing visual
| design for web. Those designers are have backgrounds in
| multimedia or have academic backgrounds in design-forward
| colleges with extremely poor html-css modules. And their tool is
| Creative Suite - largely because Adobe has a stranglehold on
| design education.
|
| The likes of Sketch have shaken things up somewhat so we at least
| have XD, and slightly fewer people are designing entire websites
| in Photoshop & Illustrator alone, but even so - the ability of
| tools like XD/Figma to allow the designer to model their work
| fluidly in a way that matches web viewports is not mature, not
| least because Adobe have been historically hostile to the idea
| (XD being a very reluctant response to new competitors after
| already killing off Fireworks).
| agos wrote:
| I've started doing frontend work back in 2008, and I
| immediately noticed the friction with designers coming from
| Adobe tools and their equivalents. It's disheartening to see
| that 15 years later the problem is still there
| madeofpalk wrote:
| > and slightly fewer people are designing entire websites in
| Photoshop & Illustrator alone
|
| Across the wide industry, sure, but I haven't worked with a
| designer who uses Photoshop in 10 years...
|
| Granted, I'm in my own bubble, but over a varity of gigs it's
| been Sketch, and now universally figma.
| lucideer wrote:
| All designers I currently work with are 100% figma, but I
| work for bigcorp where things are a bit more formalised &
| designer friends working in the startup world are much more
| on the multitool/Adobe wagon.
|
| Even so though, Figma, while an improvement, is still not
| where tools should be in this regard. It's a compromise
| between what's expected by Adobe-educated users and how
| things actually work on the web.
| larrik wrote:
| > Even on one iOS device, there's a minimum of 3 environments a
| website could find itself in, based on operating system states.
|
| Besides the fact that I'm not convinced the 3d touch one is a
| real viewport, how can he miss the fact that there is landscape
| mode on these devices, which have completely different
| dimensions?
| avmich wrote:
| The visualization, I think, could be improved. Make a graph of
| points, where X and Y coordinates correspond to width and height
| of the viewport, this is like imagining all those viewports
| having the same left top corner and recording bottom right
| corner. Those points on the graph which correspond to more
| frequently occurring viewports should be brighter (if not bigger
| circles). Many points for large number of small viewports will be
| clustered in left top corner, to make points more evenly spaced,
| the coordinates could be logarithmic.
| +--------------------+ | . . | |
| *. .*. | | .**. .. | |
| ..*. | | . . | |
| . | +--------------------+
| Jabrov wrote:
| Literally can't read through this on Chrome iPhone 13 because it
| keeps jumping back to the top :(
| csydas wrote:
| I was seeing something similar with desktop Safari (15.6.1) on
| MacOS. Resizing the browser window, and looks like (but not
| sure) that it just switches to another breakpoint (their words)
| for a new viewport, and they didn't design a way to pass the
| page scroll position to the new view port so it just resets the
| page position.
|
| Their "all viewports" page also isn't visible on my browser if
| the window is too small as the titles on each viewport aren't
| visible.
| smilespray wrote:
| Same on my iPad Air 4.
| tacker2000 wrote:
| Same on iphone 12 pro, ios 16
| cal85 wrote:
| Same on iOS Safari. Jumps back to the top seemingly at random.
| Sometimes I can get a few scrolls down the page but then it
| jumps back.
| _gabe_ wrote:
| This article was great! I think the overall premise is probably
| more useful for graphic designers than programmers, because I
| believe many programmers kind of implicitly know this advice.
| However I've worked with graphic designers in the past that were
| obsessed with having their Figma design translate to the web page
| in a pixel perfect manner, and they would always be confused when
| things didn't align correctly. This inevitably leads to
| breakpoint Hell, where they design pixel perfect designs for tons
| of breakpoints and ask you to implement them.
|
| While this is laudable, I think it's important to remember that a
| design should focus more on how the layout flows when resizing
| the viewport and focusing on a couple target breakpoints. I think
| that's what this article is trying to emphasize.
| nickdothutton wrote:
| I'm not, and never was, a "front-end guy". I've noticed more and
| more quirks (bugs?) in UIs where something is off screen, or
| unclickable, or suffers extremely unhelpful placement that
| prevents or significantly impedes my use of a web site/app.
| Rotate phone/tablet, change font size, hide URL bar, mental note
| to try it on a desktop or laptop "later". This feels like the
| front-end version of "it works in dev".
| bobthepanda wrote:
| If you've worked in front-end dev for a while you can be aware
| of all the issues.
|
| The problem, generally, is that frontend dev is taught poorly
| if it's taught at all, and the barrier to entry is so low that
| there's an Eternal September problem.
| calderwoodra wrote:
| I'd think that eventually we'd have a large enough cohort of
| folks that know web dev well since the barrier is so low, but
| I think most people try to get out of frontend development
| asap.
| jonny_eh wrote:
| I dunno, I love it, quirks and all. The ability to make and
| deploy new UIs quickly is unmatched elsewhere. I also may
| be weird in that JS/TS is my favourite programming
| language.
| zlg_codes wrote:
| I'm trying to learn some JS in my spare time, if only to
| show in interviews that I _can_ do it, but I understand why
| one wouldn 't want to. I'm just doing bare JS for now, but
| even with a framework, there is so much to manage in the
| DOM to make consistent interfaces, and CSS3 is so much more
| complex (but also convenient, in some ways!), putting
| together good interfaces is legitimately hard.
| Responsiveness is the big hurdle in creating a well-
| behaving app, from my perspective.
|
| I think I could've learned a GUI toolkit and had something
| working in the time it's taken me to pick up building two
| JS apps. The barrier to entry may be low, but that's only
| because the feedback loop for webdev is _super_ tight.
| Great for prototyping, experimentation, and getting more
| newbies in the field. But it 's crazy that anything
| productive gets built on JS and DOM.
|
| The backend, with databases and storage and caches, service
| management and sysadmin, that's where the fun is!
| bobthepanda wrote:
| JS and DOM are popular mostly because they exist
| everywhere, and there's a large ecosystem of support. In
| practice, given (until recently) difficulty in hiring,
| places found it easier to have one JS team than to have
| one native team for every possible platform (Windows,
| Mac, iOS, Android, maybe even Linux). And it also does
| not help that each native platform can have wildly
| divergent frameworks and practices.
| bityard wrote:
| I have this shaky hypothesis where the majority of UX devs
| today (not just web devs) grew up consuming content on smart
| phones, ipads, and small laptop screens. Their default way of
| interacting with technology is one app or web page at a time,
| all in maximized windows taking up the whole screen, and
| switching between between full-screen apps to multi-task.
| Perhaps this pattern carries over into their adult work, where
| they design sites and apps that look great when taking up the
| whole screen of a typical PC or tablet, but outright fail when
| exposed to a typical "windowed" browser width.
|
| My normal browser width is about 1300 pixels and I see so many
| web sites and apps these days that can't tolerate what I
| consider a very reasonable browser width that this is the only
| explanation I can come up with.
| zlg_codes wrote:
| Good points! The unfortunate side effect of having 4k and 8k
| screens is that 1080p is still common. I could understand why
| they'd assume nobody leaves a browser window covering only a
| quarter of their screen, but at the same time, both major
| browsers have a Responsive Mode where you can test screen
| resolutions, orientations, and tap events.
|
| There are devices with resolutions under 800x600 still
| accessing the Web. Every developer has to place where their
| own minimum threshold of consideration is. I personally aim
| for those old-school resolutions as the minimum, and may move
| upwards to something like 720p if it's a bit more complex. My
| screen itself is 1080p, so if it looks good at full screen,
| it will probably look decent on 4k as well as long as I'm
| using scaling units.
| carlosjobim wrote:
| Your visitors and paying customers access your site on
| mobile. Mobile is the majority. If you don't design for
| mobile you lose business. It has nothing to do with the UX
| devs. If I notice 80% of my customers come from Japan, you
| better believe I will make everything available in Japanese.
| The same with mobile. Most people do not use computers. Most
| people who use computers only use them for work in specific
| applications. Most people who have a computer at home haven't
| been able to use it in years, because every time they try to
| boot it, Windows Update takes up all the system resources and
| bandwidth.
| prizzom wrote:
| Things I like about this article:
|
| + A focus on viewport size instead of screen size.
|
| Few people browse websites in full screen in fact "Full Screen"
| browsing is used almost entirely for people using a web browser
| for presentations or physical kiosks. A completely different use-
| case than regular desktop browseing.
|
| I _loathe_ the fact that when I tile my windows to half my screen
| size the website "helpfully" switches into a tablet/mobile
| layout. Incidentally WCAG (which I consider a well-meaning but
| ultimately largely useless set of guidelines) can be blamed for a
| lot of this nonsense.
|
| Things that I _hate_ about this article:
|
| - Like many "analysis" articles they start with a misleading
| validation of their sample size. 120,000 datapoints is not
| terribly big.
|
| - Implying that these screensizes can't be grouped together.
| Resolutions #3 and #4 are practically identical 393x660 vs
| 390x664 is essentially a rounding error.
|
| - Implying that any sane person should be considering how their
| desktop/mobile website should be displaying on a smart watch.
| This is totally different use case and (admittedly having never
| built anything for a smartwatch) I assume (hope?) that unless
| you've somehow identified your design as being smart watch
| compatible the browser is very liberally going to strip most of
| your layout and styling anyway to just text and headings.
|
| - Implying that anyone should _care_ about the minor differences
| in screen sizes. As a veterean of the Flip-phone days when the
| scourge of "form over function" phones (think Beyonce clamshell
| phone) was at its previous highest. There is no solving this
| problem. Apple swooped in an took a strong-armed approach to
| screen sizes that made developing on iOS EXPONENTIALLY EASIER
| than supporting MIDP or Android.
|
| - A useless masonry visualization of viewports in a garish
| orange/purple contrast that is impossible to read. Thanks for
| nothing.
| [deleted]
| Am4TIfIsER0ppos wrote:
| http://motherfuckingwebsite.com/ unironically
| seydor wrote:
| i wish the fad of responsiveness went away. i m fine with zooming
| in and out in pages, and i like thinking of a document as a 2d
| map.
| orliesaurus wrote:
| Not sure if the author will read this but, I think there's a typo
| on that page towards the end:
|
| "it's a much difference picture." should be "it's a much
| differeNT picture."
| Devasta wrote:
| The fix is simple: Lobby congress to ban everything except 1024 x
| 768 resolution screens.
___________________________________________________________________
(page generated 2023-08-21 23:00 UTC)