This adds a new z-axis to the work of the information architect. Instead of designing for the full-size desktop display and then creating a separate mobile site, the IA has to think about how each template, page, and application interface will change as the resolution decreases.
This may sound complicated, and of course to an extent it is (I do this for a living, so why would I say otherwise?). But for those of us who remember the frustrating years of the “browser wars” it is a lot better than trying to design for multiple browsers on multiple platforms that differed in terms of which HTML coding standards they supported.
I am accustomed to use the phrase “web and mobile” when I describe my projects, with web signifying the “desktop” experience and mobile referring to handheld devices. But since tablets have now completely bridged the web and mobile gap, the user experience is becoming seamless. And so the phrase “web and mobile” will soon become unnecessary when describing site design and development.
Regular readers of my blog will notice that I’ve changed to a new WordPress theme. Both the old and new themes employed responsive HTML5 design, but I’ve been customizing this new theme in order to accommodate a more sophisticated set of features (including my project portfolio), so I’ve had a chance to tweak the guts of the system a bit. This also meant testing on 4 different screen resolutions and on multiple devices, so I thought I’d share some thoughts about responsive design.
With today’s generally DOM-compliant browsers (meaning your web property should display and work pretty much the same on all browsers), developers and interface designers can focus primarily on screen size and resolution when making design decisions. (Note that resolution, measured in pixels, is different from screen size, measured in centimeters or inches; I have a pretty high-res smartphone, which is great for watching Netflix but awful for sites designed strictly for 960 pixel widths.)
Of course, as I have previously written, the user experience designer should also think about which tasks users are most likely interested in performing when sitting at home vs. when mobile. But the distinctions between these “likely use case scenarios” are blurring as all computing devices have essentially become mobile. (Does anyone besides a hardcore gamer buy dedicated desktop computers anymore?)
I’ve also written that what web users do at their desks and what they do in a store (or on the road) may be quite different, and so you have to design the mobile interface around the mobile experience, which might include knowing where the user is located. That is still true, to an extent, but with Bluetooth keyboards for mobile, GPS technology for laptops, and ubiquitous 4GL broadband, I find myself swapping pretty dexterously between phone, tablet, and laptop.
Not long ago I spoke to a marketing exec at a major corporation who said that their entire web site should run on mobile. But all too many execs are expecting that the pinch-and-zoom capability of a smartphone browser will suffice to handle the heavy UI payload of an interface designed for a high-resolution desktop. That’s like using a jeweler’s loupe on the Compact Edition of the Oxford English Dictionary. It means a lot of scrolling, squinting, and broken, off-target tapping. Yuck.
The responsive design of HTML5 means that a web developer can design for a reasonable number of screen resolutions, say 3 to 5 cases. The largest resolution can do everything, while each smaller or “degraded” resolution can handle a subset of user interface elements. In some cases, images will shrink along with margins. Three columns will become two, and then one, with some columns stacking or vanishing entirely, perhaps given over to more space-efficient drawers and sliders. Banners and superfluous graphic design elements might vanish. Navigation might change from horizontal menus to a simple dropdown widget, and content might change to summaries, with links to the full content. Relative font sizes may actually grow, to accommodate smaller screen sizes.
The job of the information architect is to plan how the interface elements will shift and degrade on smaller screens, while still enabling the user to do almost anything they could do in the large screen version. Thanks to HTML5, the rules for what appears, shifts, or changes in an interface can be stored in the CSS (cascading style sheet), so developers can code these rules in a manageable, maintainable, and consistent way.
So I hope that you have a good user experience reading this blog, no matter what device you are using. At least you got this far.
Nice article and yes, I checked it out on both PC and iPhone 5 and it looks great on both with the RHS navigation gone on the iPhone.
In addition to HTML5, I think it’s important to note that iOS and Android apps are the other approach to making the mobile user experience work well. I often find myself choosing between the app and the website for a given provider depending on the functionality I’m looking for at a particular moment. The interesting thing to me is that the mobile app is not at all just a degraded version of the website – it often contains additional features that are not available on the website as a result of access to mobile device specific features such as GPS, accelerometer, camera, compass, bluetooth, and the like. So, the app will just have different features, not a strict subset.
I may NOT want the website to be de-featured, gracefully or otherwise, when accessed via mobile as it is possibly to get to information or features not available in the corresponding app. I think there should always be an option to get to the full website, even if you have to use the jewelers loupe on it!