![\"A](\"https://www.aaron-gustafson.com/i/posts/2014-11-06/05-lg.jpg\")
Device testing is time consuming, but you can make it easier on yourself.
\n","url":"http://www.sitepoint.com/bringing-sanity-order-device-testing/","tags":["devices","web development"],"date_published":"2015-06-16T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/bringing-sanity-and-order-to-device-testing/","title":"✍🏻 Bringing Sanity and Order to Device Testing","summary":"It seems like every other day the public is granted some new means of accessing the web. Some days it’s a new browser. Others it’s a new smartphone. Or a tablet. Or an e-reader. Or a video game console. Or a smartwatch. Or a TV. Or a heads-up display. Or a car. Or a refrigerator.
","content_html":"It seems like every other day the public is granted some new means of accessing the web. Some days it’s a new browser. Others it’s a new smartphone. Or a tablet. Or an e-reader. Or a video game console. Or a smartwatch. Or a TV. Or a heads-up display. Or a car. Or a refrigerator.
\nI worked on one project where the client provided me with a spreadsheet detailing 1,400 different user agents that accessed the login screen for the m-dot site. In two days!
\nAs further evidence, consider the enlightening details of this post from Jason Samuels of the National Council on Family relations, a non-profit organization:
\nThat last stat blows my mind every time I read it. You can’t design for 200 different screens, let alone 1,000. It’s a fools errand. And don’t even think of trying to test on that many devices.
\nAnd yet, here we are designing websites that can (and will) go anywhere. We need to thoroughly test because we can’t make any assumptions about the browsers and devices being used to access our content.
\nTesting can be tedious, time consuming, and costly. Surely there’s a way to make it easier. There sure is: Instead of getting hung up on creating one experience that needs to be nearly identical on every browser, we can be smarter about how we build things and treat experience as a continuum.
\nWe can build websites that are both nimble enough to work on low powered devices over slow networks and smart enough to take advantage of advanced features and sensors when opportunity knocks.
\nWha?! We can have our cake and eat it too? Yes. Yes we can.
\nWhen dealing with the insane proliferation of web-enabled devices and the great unknown of where our websites will go, it pays to take a step back and focus on what’s important. We need to ask ourselves two simple questions:
\nThen we need to build that first. Typically we’re talking text, some basic HTML, actual links to other pages, and forms that submit to a back-end of some sort. This is our minimum viable product and it will work anywhere.
\nThen we can look for opportunities to enhance the experience, all while keeping that functional core at the center of the experience.
\nWe can use CSS to add visual hierarchy to the page, provide some visual interest, and adjust the layout to create a good reading experience on a wide range of screen sizes. We should start from the narrowest screen size we can imagine and let the content guide our breakpoint decisions.
\nWe’ll use JavaScript to give real-time feedback to our users. We’ll hijack forms and links to lazy load additional content or otherwise avoid full-page refreshes. Heck, we can even take over the entire page and convert it into a single page app.
\nBut we should never sacrifice the functional core.
\nThis approach to designing for the web is called progressive enhancement and it’s the number one tool for dealing with the one-two punch of older browsers and device proliferation.
\nWhat makes progressive enhancement so helpful when it comes to dealing with this swirling mass of devices and browsers is that the core experience will always be available. There is nothing precluding our users from accessing it, even on a crappy WAP browser or a text-based browser like Lynx or even some no so far-future talking computer that only “sees” the web as text.
\nIn order to ensure we don’t accidentally deliver advanced features to less capable browsers like these, we just need to be smart about how we load stuff like CSS and JavaScript.
\nSome basic CSS—think typography, color, etc.—will be usable by just about anyone, so we can put all that stuff in one CSS file (e.g., basic.css) and include it with a standard link. Then we can tuck all of our layout rules and other advanced CSS into a separate CSS file (e.g., advanced.css) that we link to with an associated media query.
<link rel=\"stylesheet\" href=\"default.css\" media=\"all\" />\n<link rel=\"stylesheet\" href=\"advanced.css\" media=\"only screen\" />Any browsers that don’t understand media queries will ignore the second CSS file entirely and receive only the linear, mobile view. Easy peasy, and IE8 gets the mobile layout (a baseline level of support that is not likely to cause you any testing headaches).
\nYou can even take things a step further and use the @supports block within advanced.css to limit certain rule sets to only the browsers that support specific CSS features.
Of course, CSS support issues are nothing compared to JavaScript, so sometimes it’s best not to deliver certain bits of JavaScript-based functionality to browsers that can’t handle it. This is where feature (and object) detection becomes incredibly useful:
\nif (\"querySelector\" in document) {\n // We can use querySelector!\n}You can also use inverted conditional comments to prohibit older versions of IE from getting JavaScript in the first place (which means you don’t even need to worry about debugging JavaScript there). Here’s an example that hides main.js from IE8 and below, but makes it available to IE9 on up and to every other non-IE browser.
<!--[if gt IE 8]><!-->\n<script src=\"main.js\"></script>\n<!--<![endif]-->By being conservative in what we deliver to browsers we ensure the greatest level of support, but can still optimize for more advanced ones. This makes testing so much easier because we know older browsers will be okay with the basics and we aren’t trying to use JavaScript features unless we know they’re available.
\nProgressive enhancement helps us avoid a lot of rendering and scripting issues before we even get to the testing phase of a project, but eventually we do need to sit down and run our projects through their paces.
\nIn order to keep testing manageable during development, it’s best to test in one browser we know to have good web standards support. It will provide a basic gut-check for our work. Once we are pretty confident things are working as they should be, we can begin more thorough testing on a variety of browsers and devices.
\nI personally keep several versions of each major browser on my laptop at any given time. I work on a Mac, so I typically have a few versions of Chrome, Firefox, and Opera lying around. You can get older versions of these browsers here:
\n\nIt’s near-impossible to get older versions of Safari running on modern versions of OS X, so I typically just have the latest version locally.
\nFor testing on Windows versions of said browsers, I typically have anywhere from 3-5 virtual machines running various Windows versions with their associated browser version and (typically) a copy of Chrome, Firefox, and Opera for good measure. The MS Edge Dev site offers free Windows VMs for download. If you’re just looking to get a gut-check in the latest and greatest from Microsoft, there’s also the Remote.IE service, which allows you to connect to a virtualized version of the browser.
\nIf you develop on Windows or Linux, you’ll need access to a Mac or you’ll have to rely on virtualization to test on that platform. I’ll discuss virtualization in a moment.
\nOnce you’ve thoroughly tested in the various desktop browsers, it’s time to take the deep dive into the world of devices. If you’re unsure where to begin, take a look at your analytics, but take them with a grain of salt. Analytics can lead you to make false assumptions. For example, if you see a low percentage of Blackberry users, could that be because your site just doesn’t work well in Blackberry so they don’t stick around (or come back)? Beware the self-fulfilling prophecy.
\nIf you have the budget, by all means pick up some devices to have on hand for testing. You can use tools like Adobe’s Edge Inspect, Vanamco’s Ghostlab, or Viljami Salminen’s Remote Preview (or a combination of all of the above) to synchronize browsing on a handful of devices. Some of these tools also allow for remote inspection of the device to debug CSS and JavaScript. Weinre (which Adobe Edge Inspect uses) and Vorlon.js also provide remote inspection functionality.
\nIf you are lucky enough to have one nearby, you should stop by your local open device lab (ODL) to run your tests. ODLs are free community resources, typically offered by a web design studio or an individual who happens to be sitting on a ton of devices. Someone at the ODL should be able to help you pick out devices to test on and introduce you to the testing tools they have available in the lab.
\nIf you don’t have an ODL nearby, you can also do some guerrilla-style testing in your local mobile phone or electronics store. Just make sure they have real devices… you won’t get far on the fake plastic ones.
\nIf none of these are options for you, there’s always virtualization. You can download and install emulators for a variety of mobile browsers and devices. Additionally, services like Browserstack and CrossBrowserTesting offer access to hundreds of virtual desktops and devices for a nominal fee.
\nVirtualization will never give you the same experience as holding a real device in your hand. The performance is rarely the same and you don’t get any sort of feel for how the device responds to your input. I once stumbled on an Android 2.3 bug wherein generated content was being re-generated and re-inserted every time the device was rotated. I doubt I would have discovered that using an emulator. That said, emulators can help you get a rough idea of whether your interface works or not.
\nRegardless of the means by which you procure your testing devices, try to cover a good cross-section. Pick some low-end ones, a couple older high-end devices, and handful of the latest flagships, and a wide variety of screen sizes and resolutions. Make sure you have good coverage in terms of operating systems too—the latest iOS and Android versions are a given, but make sure you have a Windows device or two, a few Blackberry options, and some older Android and iOS versions in the mix. Then throw in an oddball or two to see if your interfaces hold up.
\nIt’s important to bear in mind that we will never be able to give each user on each device exactly the same experience. We need to be okay with that—experience is a continuum. As long as our users can accomplish what they need to on our sites, they will be well-served.
\nIf we really want to make things easy on ourselves (and our team), we should consider building a pattern library before we build a single page of our website.
\nBreaking our interfaces down into discrete, repeatable patterns (e.g., a label and form control, a tabbed interface, etc.) lets us look at each in isolation and test it that way too. Testing in isolation is far easier than trying to debug a page with a lot of moving parts.
\nGathering our patterns into a live, web-based pattern library allows anyone on our team to collect the patterns they need to build a given interface as easily as they’d assemble a plate at a smörgåsbord. And if we really want to streamline the building and testing process, we can even make the patterns importable into the live site so everything stays in sync.
\nWith the constant onslaught of new devices, form factors, and considerations, it’s tempting to throw up our hands and find another line of work. The pace of advancement is so brisk, it’s just hard to keep up, let alone feel like we’re on top of where things are headed.
\nThankfully, however, all is not lost. By taking a step back and focusing on what matters, embracing experience as a continuum, and being deliberate in how (and when) we deliver certain features and functionality to browsers, we’ll head most issues off at the pass.
\nThis relieves some of the pressure (and frustration) from the testing process and frees us up to test on a wider variety of devices and browsers, which means we’ll be able to provide a solid experience for more users, no matter what marvel of technological wizardry they happen to be using at the time.
\nEverybody wins.
\n","url":"https://www.aaron-gustafson.com/notebook/bringing-sanity-and-order-to-device-testing/","tags":["web design","mobile","devices","progressive enhancement","web development"],"date_published":"2015-06-05T13:56:03Z"},{"id":"https://www.aaron-gustafson.com/notebook/an-onslaught-of-low-cost-smartphones/","title":"✍🏻 An Onslaught of Low-cost Smartphones","summary":"It seems every week we are seeing more and more low-cost devices being launched in an effort to connect the unconnected. For instance, this past week saw the announcement of two new entries in the Microsoft Lumia line, the 435 and the 532, and the announcement of Samsung’s first Tizen phone, the Z1.
","content_html":"It seems every week we are seeing more and more low-cost devices being launched in an effort to connect the unconnected. For instance, this past week saw the announcement of two new entries in the Microsoft Lumia line, the 435 and the 532, and the announcement of Samsung’s first Tizen phone, the Z1.
\nThe two Lumia devices are the cheapest Windows Phone offerings to date: The Lumia 435 is €69 (about US$80) and the Lumia 532 is just slightly more expensive at €79 (about US$94). By comparison, the Lumia 535 was the previous low-cost Windows Phone winner at US$135. And Samsung’s Z1, which is aimed at the Indian market, runs a mere Rs 5,700 (roughly US$92).
\nNow if you’ve read this far, you are probably wondering why this matters. Well, spec-wise, many of these lower-end devices are far from what we are used to. All of these devices are running a resolution of 800×480. And their processing speeds are slower than the device you likely have in your pocket. But they are all far cheaper too. And remember that people in China and India have far less disposible income than we do.
\n
If you only earned US$295 a month, a US$799 smartphone would likely be out of the question.
\nAs Web designers and developers, we need to expose ourselves to the Web as others see it. This is why we need to view our sites and applications on lower-end devices and over lower-speed—2G, 3G, etc.—connections. Only by testing our wares can we truly ensure our content and services are available and accessible by anyone, anywhere, on any device. You know, the vision for the Web.
\nOf course you probably don’t have the budget to purchase a bunch of devices, no matter how cheap they are. So how do you test on them? Visit a local Open Device Lab like the one we have here in Chattanooga. Or if you don’t have one near you, consider getting together with some colleagues and starting an ODL in your area.
\n","url":"https://www.aaron-gustafson.com/notebook/an-onslaught-of-low-cost-smartphones/","tags":["mobile","web design","devices"],"date_published":"2015-01-15T16:58:11Z"},{"id":"https://www.aaron-gustafson.com/notebook/webos-is-back/","title":"✍🏻 webOS is Back","summary":"You may not remember it, but Palm’s groundbreaking—yes, I said groundbreaking—operating system, webOS, has been resuscitated yet again. This time by LG.
","content_html":"You may not remember it, but Palm’s groundbreaking—yes, I said groundbreaking—operating system, webOS, has been resuscitated yet again. This time by LG.
\nFor those of you who may have missed out on webOS in the past, here’s a primer: webOS was developed by Palm and debuted on the Palm Pre in 2009. It was the first “HTML5-based” operating system. Yes you read that right: the OS was built on HTML, CSS, and JavaScript. In 2009. Six. Years. Ago.
\nApplications for webOS were written using the front-end Web stack, with the JavaScript application logic tied into the device via the Mojo—and later Enyo—JavaScript application framework. Though novel at the time, this concept has since taken off in the intervening years. Windows, Firefox OS, and countless “unified” app development platforms have embraced the front-end Web stack as a means of building software.
\nwebOS also supported multitasking, which was not common back then. And to make it easy to manage, webOS introduced the brilliant card metaphor for viewing and switching between running applications. Apple, of course, ripped that idea off for iOS 7. If you dig that feature on your iPhone you have Palm to thank.
\nSadly, Palm usage was on the decline when webOS debuted so operating system never really took off. Eventually Palm was engulfed by HP, which launched the ill-fated HP TouchPad. It too failed to gather any steam and we thought webOS was dead (despite many proclamations to the contrary from well-meaning folks at HP).
\nIn 2013 HP announced it was selling parts of webOS to LG for use in smart TVs. It was a glimmer of hope for the beleaguered OS. And now, not only do we have webOS based smart TVs, but LG’s new smart watches are sporting the OS as well. And LG has not ruled out bringing it back for a phone either.
\nI’m happy to see webOS sticking around. It may have been the laughing stock in the app development community back in the day, but I’ve always had a soft spot in my heart for it.
\n","url":"https://www.aaron-gustafson.com/notebook/webos-is-back/","tags":["mobile","devices","web design"],"date_published":"2015-01-08T15:17:09Z"}]}