I can attest to not thinking about either mobile or desktop much in isolation since utility div classes in frameworks have become muscle memory. The other beneficial change has been to just look for visually weak browser width ranges, within content sections or components, and adjust them, regardless of whether “mobile” or “tablet” would be looking at them. It sounds like more work, but it’s better than trying to work to an arbitrary spec and usually results in more thoroughly refined work than conceived by designers.
Same! I can also attest to most people not thinking about the problem this way and it being a huge pain to get most engineers and designers to think in terms of “responsive first”, as opposed to “mobile first”.
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.
> in my experience with designers is that they want fixed viewport sizes so they can come up with “pixel perfect” designs.
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 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.
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.
There's a lot of truth behind this, but it's a bit of a chicken and egg problem.
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".
Good thoughts. It can be hard to “scale” this kind of conscientiousness. You might try to get them to use an app that shows multiple widths at once. A regression test suite to catch obvious problems in certain ranges can also help and some engineers would enjoy writing them.
> 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
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.
Not to mention lower height when in landscape mode. Websites that don't disable sticky headers (or other elements) are useless because those fixed elements now take up most of the screen.
But that seems to be most sites these days. I have this bookmarklet invokable with a keyboard shortcut:
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.)
It’s lower width (and height) because the screen is smaller. Remember that in CSS, px is not a physical screen pixel. It’s actually defined in the spec as an angular size[1]. In practice users might adjust their display preferences to suit their eyes. I would not recommend trying to compensate for physical display size, and instead let the user and the browser handle that.
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.
Just do your user research to see if it’s worth detecting non-touch input and resize elements. If you do this, you’ll be doing it for all larger widths, not just your guess at tablet. You don’t want to do it based on device detection because so many tablet users prefer keyboard and trackpad input (but again, try to find that out for your app/site’s user base.)
Lots of “gotcha” questions being asked that are symptoms of less-than-thorough responsive and multi-device development, I have to say…
True. We usually do raster content 2x at all widths, and size everything in pixel-independent units. But you are right that thinking in that abstraction doesn't cover all the work.
Bootstrap or tailwind, plus a handful copied from project to project. Just the usual fractions of width, width and aspect ratio constraints, padding, and so on.
