I 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!
As further evidence, consider the enlightening details of this post from Jason Samuels of the National Council on Family relations, a non-profit organization:
That 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.
And 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.
Testing 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.
We 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.
Wha?! We can have our cake and eat it too? Yes. Yes we can.
When 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:
Then 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.
Then we can look for opportunities to enhance the experience, all while keeping that functional core at the center of the experience.
We 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.
Weâ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.
But we should never sacrifice the functional core.
This 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.
What 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.
In 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.
Some 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.
<linkrel=âstylesheetâhref=âdefault.cssâmedia=âallâ>
<linkrel=â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).
You 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:
if(âquerySelectorâin document ){
// We can use querySelector!
}
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.
<!â[ifgtIE8]><!â>
<scriptsrc=âmain.jsâ></script>
<!â<![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.
Progressive 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.
In 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.
I 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:
Itâ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.
For 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.
If 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.
Once 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.
If 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.
If 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.
If 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.
If 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.
Virtualization 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.
Regardless 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 oddballor two to see if your interfaces hold up.
Itâ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.
If 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.
Breaking 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.
Gathering 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.
With 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.
Thankfully, 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.
This 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.
Everybody wins.
]]>The 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).
Now 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.
If you only earned US$295 a month, a US$799 smartphone would likely be out of the question.
As 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.
Of 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.
]]>For 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.
Applications 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.
webOS 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.
Sadly, 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).
In 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.
Iâ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.
]]>