


Easy peasy, and IE8 gets the mobile layout (a baseline level of support that is not likely to cause you any testing headaches). Īny browsers that don’t understand media queries will ignore the second CSS file entirely and receive only the linear, mobile view. 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. 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. 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. 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. 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. 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. Heck, we can even take over the entire page and convert it into a single page app.īut we should never sacrifice the functional core. We’ll hijack forms and links to lazy load additional content or otherwise avoid full-page refreshes. We’ll use JavaScript to give real-time feedback to our users. We should start from the narrowest screen size we can imagine and let the content guide our breakpoint decisions. 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. Then we can look for opportunities to enhance the experience, all while keeping that functional core at the center of the experience. This is our minimum viable product and it will work anywhere. Typically we’re talking text, some basic HTML, actual links to other pages, and forms that submit to a back-end of some sort.

What is the simplest way to realize that purpose?.What is the purpose of this page, this form, this interface?.We need to ask ourselves two simple questions: 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. Wha?! We can have our cake and eat it too? Yes. 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. 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. Testing can be tedious, time consuming, and costly. We need to thoroughly test because we can’t make any assumptions about the browsers and devices being used to access our content. And don’t even think of trying to test on that many devices.Īnd yet, here we are designing websites that can (and will) go anywhere. You can’t design for 200 different screens, let alone 1,000. That last stat blows my mind every time I read it. By 2014, however, they were seeing 1,000 unique screen resolutions each and every quarter (with over 200 of those recording 10+ visits per quarter). In 2008, they detected 71 different screen resolutions, which is already a lot to consider.In 2014, that number had skyrocketed to 14.4%. In 2008, visits from “mobile” devices accounted for only about 0.1% of their traffic.Firefox narrowly beat out IE with a 20% share of users. By 2014, that percentage had fallen to 19.7%, with Chrome bringing in the lion’s share of the traffic (37%). In 2008, Internet Explorer dominated as the browser for 93.5% of their visitors.In two days!Īs further evidence, consider the enlightening details of this post from Jason Samuels of the National Council on Family relations, a non-profit organization: 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. It seems like every other day the public is granted some new means of accessing the web.
