The more I build for the web, the more the term ‘device-agnostic’ endears itself to me.

I used to think it merely dealt with basing responsive breakpoints on content rather than particular devices, but there’s more to devices than the size of their screens. A device-agnostic approach also takes into account infinite combinations of screen resolution, input method, browser capability, and connection speed.

With such a wide range of possibilities, the sensible thing to do is to zero in on the harshest conditions (or toughest things to deliver) and build from there. Like cars designed to perform in extreme heat or on icy roads, websites should be built to face the reality of the web’s inherent variability. In my mind this approach addresses the following from the beginning:

  • Hostile browsers
  • Tiny screens
  • Slow connection speeds
  • Touch inputs

Let me break these down.

Hostile Browsers

Trying to make websites look the same in every browser can be expensive and unrealistic. People often use outdated browsers, and some prefer those that place data savings above visual perfection (e.g., Opera Mini). Though we might consider certain browsers hostile towards both design and modern web technologies, we must acknowledge that they are often a user’s deliberate choice. In many ways, this hostility extends beyond browsers to the web itself—like JavaScript timing out while an Amtrak rider with less than 2% battery waves his or her phone in the air in search of one extra bar (or dot) of reception before the next tunnel hits.

It’s the nature of the web as a continuum for support and capability to be in a constant state of flux. Embracing this variability means that we, as web designers, must prioritize content delivery to all browsers (usually via HTML and mobile-first structured CSS), and progressively enhance from there.

Tiny Screens

With mobile and tablet sales exceeding desktop, small screens ought to be considered from the beginning of the web design process, especially from a content strategy perspective.

90% [of users] use multiple screens sequentially to accomplish a task over time.—Google, The New Multi-screen World

Users want consistent experiences, features, and content across devices. No one likes having to revisit a website on a desktop to view the full site, finish checking out, or to reset a password. Karen McGrane for A List Apart:

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

Inconsistent experiences typically manifest themselves as incomplete mobile versions of websites. Sites planned and designed for a desktop-amount of space almost inevitably lead to the painful process of hacking content for smaller screens. If a piece of content doesn’t fit into a mobile experience, what qualifies it for the desktop? A “mobile first” approach to content strategy serves as a solid foundation for content parity, and in turn, happier users.

Slow Connection Speeds

Slow pages lose users. Designing in an office with 30-100mbps connections can skew our perceptions of how most people access the web—impatiently. Consider John Maeda’s Laws of Simplicity:

No one likes to suffer the frustration of waiting. Thus all of us, consumers and companies alike, often try to find ways to beat the ticking hand of time. We go out of our way to find the quickest option or any other means to reduce our frustration. When any interaction with products or service providers happens quickly, we attribute this efficiency to the perceived simplicity of experience.

Since 2010, the average webpage has almost doubled in size. I agree with Paul Irish’s sentiment that standards and expectations for acceptable performance have become way too lax. Every content and design decision affects performance and speed. I like how Tim Kadlec sees it:

With anything added to a page, you need to be able to answer the question of “What value does this provide?” and in turn be able to determine if the value outweighs the pain.

I believe the “pain” Tim talks about is the same as the “frustration of waiting” John describes. We can all do better. Thinking of (and testing with) slow connection speeds is the best place to start, carefully considering whether or not each enhancement is worth the weight.

Touch Inputs

There is no correlation between screen size and input method. It’s easy to think that touch screens are limited to phones and tablets, but that’s not true. We live in a world where people go around swiping and poking any screen they can get their hands on: ATMs, airport terminals, television sets, and most recently for me, 30” Windows 8 desktop screens. We need to adopt a “fat finger-first” approach to web design. Tappable links often take up more space than clickable ones. Because the need for a touch interface can deeply impact a site’s design (especially when hover states are used for key interactions), it’s easier to make affordances for fat fingers initially rather than retrospectively, especially when detecting touch is near impossible.


Device-agnostic sites should address each of these four scenarios by default. Responsive design could be a feature you sprinkle over a website, but RWD is at its best when it is built upon device-agnostic philosophy. What’s the difference, you may ask? Unsurprisingly, Ethan says it best:

Responsive design is not about “designing for mobile.” But it’s not about “designing for the desktop,” either. Rather, it’s about adopting a more flexible, device-agnostic approach to designing for the web.

A responsive site may have flexible grids, fluid images, and media queries, but if it also scroll-hijacks desktop monitors while stutter-scrolling on touch devices, auto-loads heavy videos that break data plans, or asks users to rotate their screens 90° for the full immersive experience, I’d argue it’s not device-agnostic. Many sites, responsive or not, are built only with ideal scenarios and a small set of devices in mind.

I use the term device-agnostic, now synonymous (to me) with good web design, to distinguish those sites that embrace the inherent variability of the web—which, in itself, is nothing new. In 2004, Jeff Veen explained:

…I end up delivering solutions to my clients that are far less complex to implement, are much easier to maintain, cost exponentially less to serve, work on multiple browsers and devices, do way better in the search engine lottery, and — of course — are accessible to everyone … everyone … using the Web today. And try to argue with the business value of that.

As web designers, it is our role to consider (and plan for) maximum reach and access, even when final results might seem underwhelming or less immersive. I used to think of device-agnostic responsive design as something that would simply make my life as a site builder easier. Now, with over 2.4 billion people in the world online, including many in developing countries, I see it as something that can help make everyone else’s lives better, too.

Thanks to Dave, Reagan, Bonnie, and Ethan for feedback on this post.

Ads by Fusion

30 Responses

Leave a comment or contact me via Twitter @TrentWalton

  • Mihai

    I think Jeff Veen was talking about small websites but if you think about web apps the story is different. And most of the of websites are actually ‘apps’. You just can’t make it work both on desktop and mobile unless you offer a modest UX on the both platforms. Now the question on mobile is if you also need a native app.

  • Trent

    @Mihai:

    You just can’t make it work both on desktop and mobile unless you offer a modest UX on the both platforms

    I don’t believe that’s entirely true. It might be more challenging to provide complete experiences across devices, but I think it’s worth it. I also like what Jeremy Keith has to say about ‘web apps’ vs ‘websites’.

  • Ryan Boone

    Sounds like we need tools that cripple our dev environment. Make the screen small, simulate a failing mobile connection. Throw glare on to the screen.

    My only question is, how far down the rabbit hole does one go? I suppose that’s where site stats come in handy.

    Good article, Trent. My fat fingers appreciated it.

  • David Maxey

    I really loved reading this, the points were made generally available for commenting (hence the side social comment button next to each paragraph) and spoke straight to the key points “Browsers, Bandwidth, Screen Size, and Mobilization”.

    This is all necessary to understand that we’re going into a very big change with the Internet and what we decide it will look like tomorrow.

    I really enjoy watching the WWW develop like a never-ending blooming flower. Consistency is good for success, as long as your dynamics are just as consistent!

  • Mike Torosian

    I think it would be great if overall we could see more company’s case studies on how they tackled certain aspects of device-agnostic design, even on seemingly less complicated sites. Maybe I am overthinking it, but I tend to get a bit overwhelmed with just how much is out there to supposedly help streamline responsive sites and improve load time, it always seems that I find something that has gained some popularity and then something new pops up in its place. I know images, backgrounds (i.e. textures), type sizing are big ones for me.

    Speaking of which, I’d love to see a post on how Paravel tackles body font-size increases, how and why :)

  • Josh

    @Ryan Boone: There are some neat tools currently out and about. If you want to test smaller screens I would have to suggest Chrome Dev Tools Device Emulation. For testing slow and spotty network connections I’ll suggest Clumsy (Windows only I think)

  • Jim Nielsen

    Love this post!

    A few months ago, I attended An Event Apart where I listened to Ethan give a talk on similar points. He talked about how defining what is “beautiful” on the web is more than just aesthetics. The definition of “beauty” should be informed by the essence and mission of the medium. So if your web site can be quickly accessed by anyone in the world, on any device, and empower that person, well then that is truly beautiful because that is the mission of the medium, the mission of the web.

    I wrote more about this to Ethan in an email, which I believe is quite relevant to your post Trent. You can find it on my blog:

    http://jim-nielsen.com/blog/posts/defining-beauty-on-the-web/

  • Theo

    Another thoughtful lesson - start designing for web! I find it very intersting that RWD is embraced as the new trendy thing and not as the possibility to create a better internet.

  • Trent

    @Mike Torosian:

    Speaking of which, I’d love to see a post on how Paravel tackles body font-size increases, how and why :)

    Good idea!

    @Jim Nielsen: Great stuff!

    Even if they are not that aesthetically appealing, if they are accessible, usable, and empowering than that is beautiful. How can we not see that? We should begin changing our definitions of “beautiful” on the web to be so.

  • Scott

    Really enjoyed this Trent, great work.

    @Josh: For those on OSX, if you have an Apple developer account (or know someone who does), you can use a tool called “Network Link Conditioner” to test slow or spotty connections. I wrote about it getting it setup last week.

  • Mike

    It’s moronic to spend time writing an article if you can’t be bothered to use correct English. Did you even bother to check the definition of agnostic? You know, if you want to use religious metaphors, the term poly-theism is a much more apt metaphor than agnosticism is for the multi-platform design strategy evangelized here.

    I have a hard time taking this sort of writing seriously when it does nothing more than redefine core software and hardware engineering concepts that have already been around for several decades ( and that the author has clearly never bothered to learn ). It really is important to get these details right if you want anyone to take you seriously behind your back.

  • Trent

    @Mike: Hi, Mike! You sound angry. Let me try to explain my usage of the term.

    I first saw it in chapter 4 of Ethan’s book. Since then, one or two posts have been written on the topic.

    Did you even bother to check the definition of agnostic?

    Yep! Keep in mind I didn’t coin the term. As you know words can have multiple definitions. I gravitate towards “asserting the uncertainty of all claims to knowledge” or the Greek origin “ágnōst(os)” or “not (or incapable of being) known.”

    To me, the term simply means that we can’t be sure of the devices (including their capabilities and contexts) users are coming from.

    I have a hard time taking this sort of writing seriously when it does nothing more than redefine core software and hardware engineering concepts that have already been around for several decades

    You may be right. I’m doing my best.

  • Patrick H. Lauke

    Hey Mike...the term “agnostic” is commonly used in exactly this way in a large number of articles on this particular subject. Terms such as “platform agnostic” or “hardware agnostic” are commonplace nowadays. Of course, you could argue that in effect saying that a site is, say, “input agnostic” results (by adding mouse, keyboard, touch, etc handlers) in a “input poly-theism”. However, “agnostic” as signifying “has no strong opinions / is open to all” is the shorter, catchier, and indeed most prevalent way of expressing this. As for the article simply “redefining” core software/hardware engineering concepts...you’d be surprised to find that a large number of developers haven’t seemed to care about them (see sites that assume “small screen” invariably means “a phone with touch”), so they’re definitely worth repeating/rephrasing.

  • Jon

    @Mike: Agnostic (from Ancient Greek ἀ- (a-), meaning “without”, and γνῶσις (gnōsis), meaning “knowledge”) .

  • Trent

    @Patrick H. Lauke and Jon: Well-stated.

  • David Landriault

    Great points Trent. I think education for clients on the need for “proper RWD” is key to raising the bar for website design and device support. It’s hard to implement an ideal solution unless you can convince the client of the need for it. Overall a great piece.

  • Michael Strutt

    Great piece, and I really like the term.

    Actually went as far as to name our team “Device-Agnostic” when doing an app design group project for my HCI module at University last year. I think it really hammers home the idea of designing without a specific device in mind.

  • Nils Rasmusson

    I too am really taking a liking to the all-encompassing meaning implied by the term device-agnostic. It’s more than responsive and is, of course, more difficult to achieve. I dare say there are relatively few sites out there that would qualify as device-agnostic right now. Articles like these are helpful as a reminder of the direction we ought to be heading.

  • Paul Davidson

    Completely agree with your sentiment. It’s about setting a new bar/standard. We went it all, and we want it now. So how does that translate? I was surprised when a site I just launched loaded in 1.3s vs the usual 3 or 4s. The big difference between that and the others? No slider. (finally)

    Mr. Irish’s challenge/ for a speed index of <1000 throws down the gauntlet on many levels. I’m gonna give it a go.

    Thanks for sharing.

  • Mike

    @Trent. Thank you for the favour of a reply.

    These remarks are generalized and should not be regarded as applied to any participant here.

    I work with a lot of front end “developers” who apparently can’t be bothered to educate themselves on even the most basic tenets of computer science. This intellectual laziness is quite surprising given the number of front end “developers” who fervently believe that nomenclature alone is evidence that they operate on the cutting edge, even though the way they talk reveals how little they know about important things like algorithms and memory allocation.

    In my previous comment I said “take you seriously behind your back”. What I meant here is that classically trained programmers don’t take front end “developers” seriously when they’re not around. We’d love to take you seriously but we’re far too busy thinking up ways to write high performance C++ that does damage control for all your bad Javascript and paints over poor memory allocation and bad design in order to make sure the user never experiences the full force of poor front end decisions. To this point, it’s tiresome to watch the front end crowd revel in the uniqueness of their nomenclature whilst being completely unaware the choice of framework is a actually decision to allocate memory.

    It might seem nitpicky to insist on correct terminology, but you have to understand how it looks: an inability to use the correct nomenclature is often regarded by back end developers as a symbol of the fundamental ignorance with which front end “developers” have toward the practice of computer science in general. Device agnostic is not the right term for the technical issues being discussed here. A classically trained programmer would refer to the desired nature of the relationship between a web site and user agent and device as being loosely coupled or abstract, but instead we have meaningless jargon such as “device agnostic” and “atomic design” and “responsive”.

    Is it too much to ask that some attempt be made to use the correct nomenclature? In classical computer science these concepts are already very well-settled.

  • Chris

    Mike,

    I’m sorry that you’re so upset with your co-workers. But there are plenty of front-end developers that have experience with algorithms, memory allocation, and even C++ (gasp!).

    Can you share the concepts in “classical” computer science that are more appropriate than device-agnostic? What *is* the correct nomenclature?

  • Jeremy Mansfield

    Thanks for the article, Trent. We need more like these. I recently took the same approach to rebuilding my own biz site. If it’s not device agnostic, we’re doing it wrong. It takes some sweat and elbow grease to keep it meaningful, memorable and clear, but it’s what is best for the users to have a great experience and keep coming back.

  • Mike

    In my last post I suggested loosely coupled and abstract as appropriate terms to describe various aspects of the relationship between a web application and the user agent or hardware. I’d add device independent as well.

    http://en.wikipedia.org/wiki/Device_independence
    http://www.w3.org/2001/di/

    The thing is, even if agnostic were the right term ( and it certainly isn’t ), it implies that you don’t care about the user agent or device. But, if I am to believe the basic content of this article, ( which above briefly sets forth a strategy of designing for mobile first ) then front end developers certainly do care about the user agent and device. Rather than saying that you don’t care, it’s much better to say that you want or need some degree of device independence.

    In general, it would be helpful if more front end developers actually had good working knowledge of things like memory management and object oriented programming because that would help front end developers see that things like framework choices actually constitute a decision to allocate memory. To this point, memory allocation decisions are among the most important factors in determining what degree of device independence is possible in the first place.

    Make sense?

  • Mike

    @Mike Thanks for taking the time to waste our time with your holier-than-thou diatribe.

  • Alex

    @Mike@Mike: I would argue that “mobile first” is a bad term, not “device agnostic” in this article. The message that Trent is conveying is that you should build keeping in mind the less capable client and building from there. In my experience the less capable client is more often than not an older desktop client and not a mobile client. Anyway, you have to understand that front end development is starting to become a business with a lot of speakers and a lot of books. Unfortunately this implies that speakers and writers speak and write for the “less capable clients” and I’m not meaning less inteligent people but beginners. Before complaining here maybe you should check out the Laravel crowd.

    As a front end developer I’m equally appalled that backend developers think we should do the front-end like it’s the ‘90s, tables and all. I bet you think, being a ‘real programmer’ you know better and all of this is just some basic html and css with no real importance. I’m a computer science graduate with a diploma in system and computer engineering and I think this is very important. I’m also very excited to see “change”. Everyday something new comes along, sometimes better, sometimes not, but I’m excited that things progress. I’m sorry if you are at the age where you feel overwhelmed by new things. If that’s the case maybe you should think about becoming a project manager or something. I’m not trying to be rude here. In our industry things progress very quickly and that’s a good thing, even with tabloid inspired catchy frazes. Sorry for my english.

  • Patrick H. Lauke

    Oh Mike...I admire your quixotic fight, cluing up these “developers” (I bet you do air -quotes in real life too) about “proper“development, one blog comment at a time.

  • Barry A. Martin

    Hi Trent,
    I hope this comment doesn’t come too late to hit your radar.

    In the post, you cite every argument I’ve ever made in proposal and meetings, in front of boards, managers and VPs and Eds. Plus a few I haven’t (but will!). In fact, I spend so much time trying to give the people who need us enough insight to make more informed decisions that I sometimes wonder if I’m speaking to the wrong crowd.

    Your readership are practitioners in our field. Do you find you need to spend half your time educating? Or do you (at this point in your career) have clients who ‘get it’?

  • Tony Mosley

    for simulating slow connections down I use a little application in OSX called Slowy (www.slowyapp.com).

    maybe someone will find it useful.

  • Matt

    This really just depends on who your target audience is - You need to take analytics into account, see who your actual visitors are, and work on the major browsers/devices that visit your website. I’m sure you can spend lots of time and money to build for every device and internet speed, but at the end of the day is that really your target audience?

  • Barry

    This is a really interesting way of framing the problem thanks for writing this Trent.

    @Mike: You are an example of somebody with the absolute worst traits that can ever be exhibited in a developer. I’d bet good money that your team hates working with you.

Leave a Reply