A place to cache linked articles (think custom and personal wayback machine)
選択できるのは25トピックまでです。 トピックは、先頭が英数字で、英数字とダッシュ('-')を使用した35文字以内のものにしてください。

index.md 9.5KB

123456789101112131415161718192021222324252627282930313233343536373839
  1. title: Device-Agnostic
  2. url: http://trentwalton.com/2014/03/10/device-agnostic/
  3. hash_url: bee263ecc2b22dbc31411b34535f4f44
  4. <h3>The more I build for the web, the more the term ‘device-agnostic’ endears itself to me.</h3>
  5. <p>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.</p>
  6. <p>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:</p>
  7. <ul>
  8. <li>Hostile browsers</li>
  9. <li>Tiny screens</li>
  10. <li>Slow connection speeds</li>
  11. <li>Touch inputs</li>
  12. </ul>
  13. <p>Let me break these down.</p>
  14. <h3>Hostile Browsers</h3>
  15. <p><a href="http://dowebsitesneedtolookexactlythesameineverybrowser.com">Trying to make websites look the same in every browser</a> 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.</p>
  16. <p>It’s the <a href="http://adactio.com/journal/6692/">nature of the web</a> as a <a href="https://twitter.com/adactio/status/438436027288797184">continuum</a> 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 <a href="http://en.wikipedia.org/wiki/Progressive_enhancement">progressively enhance</a> from there. </p>
  17. <h3>Tiny Screens</h3>
  18. <p>With <a href="http://infogr.am/Apple-device-sales?src=web">mobile</a> and <a href="http://www.computerworld.com/s/article/9242344/Tablet_shipments_will_surpass_desktops_and_laptops_in_Q4">tablet</a> sales exceeding desktop, small screens ought to be considered from the beginning of the web design process, especially from a content strategy perspective.</p>
  19. <blockquote><p>90% [of users] use multiple screens sequentially to accomplish a task over time.—<a href="http://www.thinkwithgoogle.com/research-studies/the-new-multi-screen-world-study.html">Google, The New Multi-screen World</a></p></blockquote>
  20. <p>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. <a href="http://alistapart.com/article/your-content-now-mobile">Karen McGrane for A List Apart</a>:</p>
  21. <blockquote><p>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.</p></blockquote>
  22. <p>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 “<a href="http://www.lukew.com/ff/entry.asp?933">mobile first</a>” approach to content strategy serves as a solid foundation for <a href="http://bradfrostweb.com/blog/mobile/content-parity/">content parity</a>, and in turn, happier users.</p>
  23. <h3>Slow Connection Speeds</h3>
  24. <p><a href="http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html">Slow pages lose users</a>. Designing in an office with 30-100mbps connections can skew our perceptions of how most people access the web—impatiently. Consider John Maeda’s <a href="http://lawsofsimplicity.com/2006/07/23/law-3-time/">Laws of Simplicity</a>:</p>
  25. <blockquote><p>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.</p></blockquote>
  26. <p>Since 2010, <a href="http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-2013/">the average webpage has almost doubled in size</a>. I agree with <a href="http://timkadlec.com/2014/01/fast-enough/#comment-1200946500">Paul Irish’s sentiment</a> that standards and expectations for acceptable performance have become way too lax. Every content and design decision affects performance and speed. I like <a href="http://timkadlec.com/2014/01/fast-enough/">how Tim Kadlec sees it</a>:</p>
  27. <blockquote><p>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.</p></blockquote>
  28. <p>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 <em>weight</em>.</p>
  29. <h3>Touch Inputs</h3>
  30. <p>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 (<a href="http://trentwalton.com/2010/07/05/non-hover/">especially when hover states are used for key interactions</a>), it’s easier to make affordances for fat fingers initially rather than retrospectively, especially when <a href="https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/">detecting touch is near impossible</a>.</p>
  31. <hr/>
  32. <p>Device-agnostic sites should address each of these four scenarios by default. Responsive design <em>could</em> 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, <a href="http://unstoppablerobotninja.com/entry/toffee-nosed/">Ethan says it best</a>:</p>
  33. <blockquote><p>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.</p></blockquote>
  34. <p>A responsive site may have flexible grids, fluid images, and media queries, but if it also <a href="http://trentwalton.com/2013/10/23/scroll-hijacking/">scroll-hijacks</a> 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.</p>
  35. <p>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. <a href="http://veen.com/jeff/archives/000503.html">In 2004, Jeff Veen explained</a>:</p>
  36. <blockquote><p>…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 <em>everyone</em> … everyone … using the Web today. And try to argue with the business value of that.</p></blockquote>
  37. <p>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 <a href="http://www.internetworldstats.com/stats.htm">over 2.4 billion people in the world online</a>, <a href="http://www.boston.com/business/technology/articles/2010/02/23/poor_but_networked_un_says_cell_phone_use_surging/">including many in developing countries</a>, I see it as something that can help make everyone else’s lives better, too.</p>
  38. <p class="footnotes">Thanks to <a href="http://twitter.com/davatron5000">Dave</a>, <a href="http://twitter.com/raygunray">Reagan</a>, <a href="http://twitter.com/bonniewalton">Bonnie</a>, and <a href="http://twitter.com/beep">Ethan</a> for feedback on this post.</p>