Mobile is just the beginning

The ‘trouble’ with Ice Cream Sandwich

I really feel I must write a follow-up to yesterday’s post given that i’ve just spent the morning playing with the Galaxy Nexus, Ice Cream Sandwich, and the new Chrome mobile browser.

Honestly, if you had any illusions of micro-managing the web experience on devices, this new OS and browser will make you cry. Here are some initial highlights of the new browser settings:

  1. Request Desktop Site is a lovely (prominent) little option that lets users request the desktop version of a site they are looking at. I presume Google simply switches to a known site (elegant how we name these isn’t it?). As you can imagine, if the site is responsive this option does absolutely nothing. Logical when you know what’s going on underneath, yet pretty confusing for users. Your responsive site will appear broken…even though it’s technically not. Not sure how to handle that one…
  2. Then come the Accessibility features! These are really quite awesome (for users…maybe not so much for designers and developers…can you feel a trend here)? These consist of all sorts of well thought out and (so far) well implemented settings. My favourite so far is Force enable zoom which enables users to “override a website’s request to control zoom behaviour”. I haven’t tried it yet but I presume this means overriding any custom viewport meta tag settings which prevent sites from auto-zooming at landscape mode. End result…you should now presume some users will see the width they want to see, not the one you’ve optimised/designed for.
  3. The old Zoom Level settings (the ones I mentioned in yesterday’s article) are still there, but they are now in the Advanced settings panel.
  4. To augment the zoom levels, we now have a cornucopia of alternate settings such as Text Scaling, a lovely slider with a default of 100% and a range of 50-200%. Then there is the Zoom on double-tap slider, enabling users to control how much the content will zoom (i.e. it no longer appears to simply fit to screen on tap…it can zoom at different increments, which can result in content pushed horizontally off-screen, even on a mobile site).
  5. Not to be outdone we also have a Minimum font size setting (OMG!!) ranging from 1pt to a whopping 24pt. I’m not sure what the default even was (10 or 12 maybe?) as i’ve already adjusted it and there is no implicit default for these types of things…you just go with what ‘feels’ right (especially as they’ve labelled it points, not pixels, ems or percentages).
  6. There is also a Save for offline reading option (was this there already?) that does exactly what it says, and in the process disables most real-time behaviours such as those triggered by JavaScript, hyperlinks, and even in-page anchor elements. The document becomes so static, it may as well now be a PDF…until that is, you hit the magic Go live option which brings it back to life with a subtle page refresh (you almost expect to see those animated stars that Tinkerbell used to summon up in old Disney cartoons).
  7. There is also the usual handy Load images setting (now quite prominent as one of the few things in the Bandwidth management section).
  8. And finally, to make the brand managers quiver there is a Contrast setting (which currently seems to be disabled)…just in case you really need to see those brand colours in super high or low contrast.

When all is said and done, users have totally won this time around. They can now adjust and control just about everything related to the display of content on their device.  And why shouldn’t they? The challenge now for the industry is to find that ‘happy place’ where we learn to control far less while still offering much more.

7 Responses to “The ‘trouble’ with Ice Cream Sandwich”

  1. Joerg

    Do you really think that users will profit by getting these features? I can imagine lots of really confused (non-power-) users in the future. Some (like the accessibility options) are useful and necessary, of course. But all in all I think that it will be impossible to foresee what a website will look like on a particular device. I’d rather see designers and developers do what’s necessary to create a compelling user experience than Google offering lots of different options (which will lead to placing the burden on the users to find the right settings for a certain site).
    I think it might end up like this: “let’s do it someway, we can’t what it’ll look like on the users device anyway. They will just have to go and adjust their settings to make it work somehow.”

    • steph

      I do know what your saying but think there needs to be a middle ground. Lots of (mobile optimised) sites are already broken right now, it’s just people don’t realise it as they only test on a few devices. Few people also test their desktop site on mobile, despite the fact that their mobile traffic keeps rising. Ironically, some of the things we now do to control the experience actually makes it worse…like setting element widths in pixels (lots of people still do this even on responsive sites), setting font sizes in pixels (which forces people to zoom), disabling pinch/zoom altogether, or setting a specific viewport width using the meta tag.

      It’s things like this that make users actually use these settings to begin with (…because the font is too small, or the content is off-screen, but pinch/zoom is disabled, so the only option is to increase the text size to read anything at all).

      So I don’t know. I don’t for one minute think that ‘more features are always better’ but I also suspect that if Google introduced none of this, an awful lot of people would continue using it as an excuse to only develop for a handful of ‘popular’ fixed screen sizes.

  2. Davide

    “Request Desktop Site” will probably change the User Agent string to the one of a desktop browser (Google Chrome?). Opera Mobile has this feature too. It’s extremely useful for websites which detect mobile user agents and redirect them to a pay mobile edition (while the desktop edition is free). If your website is responsive, it does nothing, just like it does nothing if you don’t have a mobile website (because the site is always the same). In order to make it “compatible” with responsive designs, it should also fake its replies to media queries, fake some js properties etc. but what would you use as fake value? Width 1366px? 1920px? It should be configurable, but I think that it’s not something that Average John could manage. So, there’s probably no better way to implement it.

  3. Colonel Sponsz

    As a passionate front end developer I find things like this, the Android variations you’ve outlined and your Letting Go talk actually inspire me. My reaction to this is to fall back onto solid fundamentals:

    * Well thought out information architecture
    * Focused and relevant content
    * Valid, semantic and accessible markup
    * Clear and robust visual design
    * Genuine progressive enhancement of CSS and JavaScript – not just a bit of graceful degradation tacked on at the end
    * Low page weight, minimised requests and other Page Speed/ YSlow goodness

    We have always known that these things mattered but now they have become vital. If you get these fundamentals right then handing control over to the user shouldn’t be that bad as you’ve done your utmost to to give them, and their internet viewer of choice, something solid to work with.

    I built my first website in 1994 and the browsers I was using regularly were Mosaic and Lynx – the lessons I learnt then have never been more valuable than they are today when building device agnostic sites.

    • steph

      I haven’t yet been able to find docs related to this specific feature. Would be nice if they provided some clarity regarding what they’re actually doing and if there are any ways to circumvent it (for the good of the user in cases where Google simply swapping a header won’t have the desired effect).


Leave a Reply

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS