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.
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.
> 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.
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…
I would love to see your maps app that doesn't touch zoom.
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…
> 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.
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.
> 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).
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.
> "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…
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.
> 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 scrol…
> 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.
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.
> 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?
> "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…
> "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…
> 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 scrol…
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.
> 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 scrol…
> 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.
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.