joined:Nov 9, 2004
I'm generally happy sitting back watching seo stuff, since mostly it has no impact of importance on us, but lately I've been examining the monstrosity of 'responsive mobile first design' (equal in my opinion in vileness to the old flash based websites as fads go), with a major update of a client's site in mind.
Unless I'm missing something, css based pixel view screen tests have now grown totally and utterly useless because of the very high pixel densities of mobile screens.
I'm concluding that responsive design (sic) is terrible design for desktop user, who in my opinion are serious users, but for people who surf now and then on mobile, it makes good sense to serve a fully crippled version of our site to them.
To my eyes, again, unless I'm missing something really fundamental with css and resolution based tests, resolution based tests are unfortunately now almost totally useless, when what actually matters is only physical screen inches, nothing else, and I believe that data is not available to css.
My personal conclusion is that we are now firmly back in the world of server side browser detection, and that's the direction I'm planning. There is no desktop in my opinion that benefits in any positive way from responsive design, basic usability tells us that there is a max width the human brain responds to, over that max, and it overloads, so all layouts need max widths no matter what, and since no desktop has less than 1024 pixel width, I can see absolutely no reason why I would use responsive css for desktops as a rule.
However, I am seeing a good argument for responsive on mobile (possibly excluding tablets, which are really just smaller laptops with good screens). This is why google is pointing to mobile meaning phones with screens below a certain physical dimension, but, again, because pixel resolutions are getting incredibly high, all the css tests are frankly largely useless, which is why 'responsive' layouts tend towards being absurdly information poor, super inefficient in terms of good use of screen real estate.
This was brought to my pained attention when my long time favorite site (sports related) switched recently to responsive layouts, which now on the desktop have cut down the information presented by about 10x I would estimate per screen / scroll. I know that when I look at my surfing on that site, because it's now a royal PIA to access all the day's news, my average session has dropped from 5 to 10 articles per visit to 1, max 2, per visit. Because it's almost impossible to access information because each item is now > 10x larger than it used to be, that is, exclusivly to cater to the crippled touch interfaces of mobile screens. That to me is suicide for catering to desktop users, so we're certainly not going to lose our desktop base which is most of our users to placate google via some overarching responsive single file type css 'solution'.
I find the entire thing sort of pathetic, a terrible usaer experience being pushed by google, who have the audacity to tell us via their mobile information to 'build for mobile first', which means, totally scr@w your desktop serious users. I view this as yet another idiotic internet fad, almost in my opinion equivalent to the old fad of all flash driven sites, done for the same bad reasons, so the question is, how do we deal with google and also support mobile users, who we want, even if they are minority.
I'm not asking how to deal with it, it's more a rhetorical comment, but I'm starting to suspect to be honest that google is NOT limiting this algo to only mobile, I'm beginning, based on some changes we've seen this week, that they are in fact already penalizing sites that fail to follow google's absurd and frankly juvenile ideas about how to present data to end users. I'm seeing site after site ruining their desktop user experience totally, by those idiotic big clunky things that work for crippled mobile touch interfaces, but which are a massive waste of screen real estate for any non crippled web access system, like a desktop with a keyboard and mouse.
Because of my suspicion that google is in fact already applying some of this algorithm, we have to deal with this soon, but I'm wondering what google internally is looking for in terms of signals on page, for example, there's no way I'm going to ruin a really good website that is desktop focused by trying to cater to largely useless mobile traffic, not fully useless since I'm sure some of our users will access it while commuting to check some data we offer, that's totally something we should support, but only in my opinion via browser detection delivering core layout css depending on device type, but I suspect that google, being juvenile idiots, will be trying to enforce the retarded all responsive all the time nonsense that is an insult to our user's intelligence.
To be technically clear, because barring super basic pixel width based tests, like <> 800 pixels (ie, the width of an upright iphone or similar size screen), really pixel based css triggers are not going to solve any problems, basically you have to go with percent based containers, which is easy technically, but only works on mobile, plus on/off switches for various site features that don't work on mobile, in other words, dekstop first, then tweak for mobiles via server side browser detection only, which means, only serve phones the custom percent width based css, otherwise serve desktop widths, possibly also some tablet modifications, but detecting tablets is a serious PIA because of phablets etc, and cheap small screen tablets, etc, again, because of increasing pixel densities (soon to be, if not already, at 600 pixels per inch, about the limit i believe of human vision more or less), but since you have no real way of knowing the screen resolution of a mobile device, basically you default to the super dumbed down one size fits all type 'solution', which basically means usable on the smallest screen, clunky on the biggest phone screen. This is what I see sites doing more and more, so I assume that's the only way to actually try to realistically deal with primary container sizing.
[edited by: lizardx at 9:48 pm (utc) on Mar 20, 2015]