Mimsy Were the Borogoves

Mimsy Were the Technocrats: As long as we keep talking about it, it’s technology.

Google’s responsive design deadline

Jerry Stratton, April 21, 2015

Mimsy iPhone overview: The initial view of Mimsy Were the Borogoves on the iPhone 4S in iOS 8.; iPhone; Mimsy Were the Borogoves

The initial view of this blog in the iPhone 4S.

Today is Google’s deadline for responsive design. If you view this site in both your desktop and your phone or other mobile device you will notice—unless your browser chooses otherwise—that it continues to look the same in both places. I haven’t changed it. Google and I have a different idea of what it means to be mobile friendly.

Google systems have tested 569 pages from your site and found that 100% of them have critical mobile usability errors. The errors on these 569 pages severely affect how mobile users are able to experience your website. These pages will not be seen as mobile-friendly by Google Search, and will therefore be displayed and ranked appropriately for smartphone users.

I agree that it’s incredibly egotistic for me to think I’m right and they’re not. I’m also aware that others may disagree with me. But “critical” errors? “severely affect”? I don’t know about that.

I do know that whenever, on my iPhone, I visit a site that they think is mobile friendly I’m tempted to pull down the URL bar and Request Desktop Site. I almost always prefer, even on poorly-designed sites, the desktop version.1

Often, the site refuses to give me the desktop version—Wikipedia is very annoying in that regard, because I by far preferred the old full version of Wikipedia to the mobile friendly version that helpfully hides most of the useful information.

Even if responsive web design worked “right”, though, I still prefer to see the overview and then decide for myself which section I want to read first.

I was originally enthused by responsive design and the possibilities for customizing the experience to the device. That possibility remains, but, like the possibilities JavaScript provides to enhance an already good experience, as often as not they are used to replace an already good experience. Over time, I realized that even on mobile, I prefer the full page. In my experience, which I recognize is my experience, the best mobile design is one that makes it easy to view the full web site on a mobile device. That was part of what was amazing to me when the iPhone was first introduced: it could display real web pages and it had the tools to make them readable. It recognized the sections of a web page and made it easy to focus on whichever section I wanted to read. Everyone else quickly followed suit.

On my site, my only concession to Google’s deadline was to adjust the minimum width of the blogs to allow mobile devices more freedom in choosing how to display the page. While testing out various changes, I realized that I had been wrong to force a minimum width that large. The more I browse the web, the more I realize that the best way to display well on the web is more freedom for the browser. That, however, doesn’t register on Google’s compliance page.

Mimsy iPhone content focus: Focusing on the content section of blog on iOS 8 on iPhone 4S.; iPhone; Mimsy Were the Borogoves

A simple double-tap brings the content into focus.

I have tried to design this site so that the information is well-structured, and your browser can decide what it needs to do to display it to you. Because I’m going to lose traffic from Google for this decision, I did consider, and try some methods of, creating a responsive design that met Google’s requirements, but I couldn’t get one that I would want to read.

I considered adding a meta/viewport tag to get rid of half of the errors Google shows, but I’m pretty sure that there is no neutral version of that tag that just says “do what you want”. Even a neutral-sounding viewport value of “width=device-width” appears2 to be telling the browser not to set the width of the page to the device’s width. It appears to tell the browser to not set the width of the page to the device’s width. This is not how the iPhone reacts to it, but it is how Google’s simulation reacts to it, showing only the top-left corner of the page. The best explanation of this I’ve seen is that the width is not the width of the page, but the width of the device. That is, width=device-width tells the browser to set the width of the device to the width of the device, and, therefore, do not do any zooming.

There is no initial-scale of auto. Nor, in setting the device width, is there any option other than pixels. In theory, responsive web design would seem to have its uses, but in practice it appears to be a further attempt by web designers to fully control all aspects of viewing their pages down to the pixel. Its purpose appears to be a variation of “this site best viewed in” that used to appear on the web, but, instead of listing only one browser/device combination, responsive web design seems to be used merely to add more browsers and devices to the list of “best viewed in”.

Is your device only 320 pixels wide? Well, screw you, you don’t get my navigation. Is your device smaller than I’m ready to deal with? Screw you, I’m going to hide most of the useful information behind tap-downs.

Now, in some cases, hiding information may truthfully be a useful compromise. But it is a compromise. Google is trying to pretend that it isn’t.

Note that I’ve reduced the image quality (from 640x960 to 320x480) to more closely approximate their readability on the actual iPhone. It’s not perfect, though, because while clicking those images will bring up an image approximating the size of a smartphone screen, it will not be as crisp as a smartphone screen.

  1. If a site has a poorly-designed desktop version, it almost always has a poorly-designed mobile version—to paraphrase Google, critically poorly-designed, critically because it simply throws out information necessary to navigating the site.

  2. I write appears because the viewport value for the meta tag does not appear to be well-documented, and the width parameter is even more poorly-documented.

  1. <- Death of TV
  2. Chocolate factory ->