3 ms·

> 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 u

> 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.

bradgessler 4y ago
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".