From the other side of the fence, it has been a lot more efficient to use a responsive design on all clients, so that small screens automatically get what used to be the mobile site. The benefit for us was we don't need to maintain separate code paths which turned out to be quite a bit of code/markup and caused a lot of problems over time.
Agreed, but unfortunately not how a lot of sites work (especially Google's properties) - they'll sniff a Mobile Safari user agent and say "Here's the gimpy phone edition with half the options missing!"
13" iPad Pro? Gimped version. 12" MacBook with a smaller screen and worse CPU/GPU performance? Full version!
I would've thought that it'd be simpler to have one codebase and make some UI modifications so that it works on touch devices. But it's been years and they didn't. Maybe cost savings by giving phone users low resolution streams and no way to change it?
I don't use Google Docs, but I gather being able to use the real web version on an iPad now beats out their official iOS apps.
Unfortunately if your site is interactive, you still need to know if dealing with touch versus keyboard.
For touch, extra spacing is needed around click targets (allow for fat fingers).
For some touch data entry, you need to allow for different input methods, because accessing symbols and numbers is different from a real keyboard versus a virtual keyboard. Also a virtual keyboard: covers some of the page, causes scroll, causes resize, can cause zoom, loses fixed headers. Avoiding the effects of those issues often requires some compromises.
For touch, you must register onclick events on a div near to an input that can be tapped. Otherwise the browser resizes the touch zone to be bigger than the actual input, and you can't tap the div.
There are many many subtleties to how browsers treat touch events and virtual keyboards
> Unfortunately if your site is interactive, you still need to know if dealing with touch versus keyboard.
Detecting a mobile browser vs regular won't handle this well for laptop touchscreen users... especially for anyone using a laptop in a tablet mode. I suspect the larger targets would also help some regular keyboard + mouse users with poor fine motor control.
Similarly, we try to support tablet users (iOS/Android) with external keyboards or mice. I totally agree with your point (I purchased a laptop with a touchscreen for testing).
For tablets we optimise for touch, but I also make sure keyboard and mouse work (e.g. I am extremely careful to support click events, not just touch events). I can do this because we have our own framework (when I developed our product, other frameworks simply did not work well with corner cases). Writing our own framework means I am very familiar with the various quirks and workarounds.
However, browsers force us to make compromises, because we simply can't detect or fix certain problems that affect the UI.
Come on, we both know the answer... They’re serving shitty versions for iPad users to force them to download their app which has much more invasive tracking abilities.
