Trying to impart this way of thinking was one of my biggest failures managing a product engineering team. I’m curious if others have successfully gotten teams of designers and engineers to stop worrying about mobile/tablet/desktop first and instead think in terms of an infinite number of viewport configurations?
To be more specific about my problems: in my experience with designers is that they want fixed viewport sizes so they can come up with “pixel perfect” designs. The tools they used tended to have fixed canvas sizes and dimensions. For “responsive first” designs, you need something that’s constantly changing the viewport size.
Engineers struggled because they wanted specs to implement against that were also pixel perfect. From a tooling perspective, I noticed most use Chrome and NOT the responsive view. I don’t know how anybody can build a responsive web application without being exclusively in responsive view and constantly resizing the viewport.
If I had to generalize the struggle between design & engineering, they felt they couldn’t meet the requirements given to them in a reasonable amount of time unless “mobile” and “desktop” were scoped separately.
This is pretty much the "original sin" of the web. Every anti-accessible inflexible technology we've had to struggle with for 20+ years has been driven by this. Flash sites. Text "baked" into images. User-agent bans.
If I had to guess, they think the amount of people who would actually use something that falls outside of the standard desktop/mobile/tablet presets is very low and not worth the amount of extra effort it would take to implement.
In other words, this is one of those things the boss says they want but realistically it's way down the list of real world priorities and if nobody does it, nobody gets in trouble for not doing it, so it wasn't actually important in the first place. Whereas if something's wrong on the desktop or mobile designs, they'll hear about it and hear about it quickly, so they know that IS important.
The reason it was "way down the list of real world priorities" is because it was perceived as an impossible requirement to meet in terms of effort. My hopes is that it would be met as an innocuous side effect of making the thing work in a mobile and desktop viewport, but for the reasons I speculated above, it wasn't, and hence got dropped down on the list to the point where it wasn't worth the battle needed to ship a truly responsive design.
I can't just blame individuals though -- its easy to say, "oh, well they just weren't smart or motivated enough", but that's not the case. In the end I'm left thinking that the tooling, documentation, and ecosystem surrounding it simply didn't support making this "an easy requirement".
Sadly, no, despite my best efforts across multiple teams I've led in the last few years.
If someone manages to crack this, I'll hail them as a hero.
Your story isnt important enough to deal with God awful UX.
javascript:let i, elements = document.querySelectorAll('body *'); for (i = 0; i < elements.length; i++) { if(getComputedStyle(elements[i]).position === 'fixed' || getComputedStyle(elements[i]).position === 'sticky'){ elements[i].parentNode.removeChild(elements[i]); } }
That zaps fixed and sticky elements, so I can actually see the content. (I like the Vivaldi browser because I can assign keys to many things.)
Resolution can be targeted with other media queries, which should be useful for other high-resolution devices. And separate from this you should target touchscreens with a `pointer: coarse` query.
This is exactly why you should not think in terms of mobile, tablet, desktop, but instead in terms of features of the output media.
Lots of “gotcha” questions being asked that are symptoms of less-than-thorough responsive and multi-device development, I have to say…
I've tried using tailwind and semantic ui very briefly, but wasn't aware they provided any responsive-oriented classes.
eg. you can give an element a class of "sm:p-2 lg:p-4 xl:p-8" to give different padding sizes.
the docs are here: https://tailwindcss.com/docs/responsive-design