These days we have a number of devices that need to be taken into account when designing a website and a smart bunch began questioning whether we’re going at it the right way or if there’s a better approach.
The main issue is how do we cater to an ever increasing number of devices, each with its own feature set, browser and screen size?
Well, in short, there isn’t a perfect solution for now (gladly because it’d just be boring) but there is one approach which I believe has enough arguments to be widely considered.
Get your reading glasses.
Let me start by explaining some of the ways that people are currently tackling development for a wider range of devices.
In recent years, the Web has expanded beyond the desktop and jumped into several devices that pack not only different screen sizes but also different features.
Going back in time, the way the industry reacted to the surge in mobile usage was to create mobile versions of their full-featured websites, ie. the “m.” sites. This caused complex websites to create separate mobile teams which had to mirror the desktop site while being friendlier to the mobile bunch.
This strategy worked fine until one device came on stage to ruin the fun, the iPad. The industry had to face a middle ground between the mobile version and the desktop version and this time there wasn’t an approach that everybody embraced, some kept their desktop version, others redirected to the “m.” version and elsewhere some detected the iPad and served an hybrid version. And then other tablets flourished, each with its own screen size and feature set. Oh boy.
So it begged the question, should there be a tablet team and tablet version? Let me expand on a solution that surged from this very question: Responsive Web Design.
Some very clever folks came up with a different way of tackling diversity in screen sizes and not having dedicated versions for each new hip device. In a nutshell, through widely available technology you adapt your content to different screen sizes so you have a single website rearranging itself to various screen sizes. It’s an abstraction that very well works in most cases.
Improving on that concept and sticking to the content is king philosophy, you shouldn’t even adapt your design to specific screen sizes, rather you should rearrange your design whenever the content demands you to do it. This can easily be visualized by resizing the browser and naturally you’ll know when the content is either getting crammed or spaced out, whatever that width might be. I could go on and explain it further but it’s not my point here and there are a ton of articles about it.
Is this enough though? Does this really maximise a website to all the different devices? Not really, one can argue that you use a website differently when you’re on your iPhone and on your Mac and adapting the contents doesn’t really cut it.
Now that I’ve set the premise, let me introduce you to what I think is a solution for this, agnosticism (do not think Agnostic Web Design. No more fancy terms or buzzwords, it’s all web design. k thx bye).
My proposition is that everything be interpreted as a feature — may it be screen size, geolocation, touch input, camera, etc — and respond to features instead of widths.
This relies on an argument that user behaviour is determined by the feature set that is available in a device. So I can argue that, for example, the fact that an iPhone user is a consumer rather than a creator of information is determined by the features he is given, which are the small screen and touch input. This is not entirely the case of an Android tablet user, which has a bigger screen and touch input.
Your design should focus on the best user experience according to the combination of features that are available, which in turn determine common user behaviour.
So, for example, you can maximize both a user who is accessing your website with Chrome on a Macbook Pro and one on a Galaxy Nexus. Both of them have geolocation, so they both benefit from it but the Nexus user can’t really write a post as long as the one you’re reading, so why display writing functionalities as prominently as for the Mac guy?
Ok, so now you’re wondering how can this be achieved? There are libraries that help you with feature detection, like the widely used Modernizr, or you can even write your own tests. From there you can adapt your website’s layout and capabilities either on a per feature basis or by creating feature combinations and adapting to those. There’s space here for some more thought.
These are my first few considerations on this approach so I might write further on this in a while, after I give it more thought.
2 Comments
Wow, well put Pete.
Not going against what you just wrote, cause it’s true, let me just ask you: isn’t this what we (should) have been doing all along with progressive enhancement?
Build your stuff from a baseline, a common denominator if you will… and wherever possible, take advantage of more advanced features. That ensures a much more future friendly approach to building stuff on the web.
Now… you touched on two very important aspects of responsive layouts.
First: forget devices, think about your content. Absolutely, man. I’ve grown to forsake calling “mobile layout, tablet layout, etc.” and gone with generic sizes. This can also be reflected in media-queries using EMs for sizing instead of pixels. It gets interconnected with your content, by definition.
Second: you mentioned blogging on mobiles. Did you hear our friend Pedro CS the other day mentioning he wrote a really long article on the way home from work, on his iphone? That’s the danger in assuming what people want. I’ve find it far more effective and feasible with the least amount of effort to just progressively disclose stuff.
It works wonders. I never *hide* stuff. I just put them one step further away from the user. It’s still there, if he or she so needs.
So… thanks for writing this. These are definitely steady steps in the direction of universal access. That’s how I see responsive web design. Another evolutionary step towards that, after we learned to built stuff with progressive enhancement and after we build them to be bulletproof… now we adapt to any environment. We just have to figure out the kinks and never ever forget accessibility.
Kudos!
Definitely should’ve mentioned this is all based on the general idea of progressive enhancement, thanks for pointing that out!
You’re spot on not forgetting accessibility, it bothers me that even though most top developers and influencers push developers to care about accessibility, it’s still somewhat disregarded by most.
On hiding stuff on mobile, I’m not rooting for hiding stuff but rather prioritising with features in mind, so my mobile example was to expect that most users will not be writing a long post, even though they can and some will, and the UI for doing it should remain accessible nonetheless. When making your prioritised list of actions for your website or defining user flows, the features available should also play a part in the process and decision making.
Thank you for your comment, glad you got to read this post.