Aaron Gustafson – Designing Across Devices with Progressive Enhancement

Podcasts – UIE Brain Sparks

[ Transcript Available ]

Responsive web design seems to come up in every other discussion or article about UX these days. And rightfully so as it’s an elegant way to make sure your design adapts to the multitude of devices on the market. But with the Internet of Things looming, it’s becoming more than just the visuals of your site that are of major concern. How your content displays on a car dashboard, “can a watch handle this page weight?”, or “is this refrigerator JavaScript enabled?” are not unrealistic issues moving forward.

Aaron Gustafson believes that progressive enhancement can go a long way to addressing these questions. In his virtual seminar, Designing Across Devices with Progressive Enhancement, Aaron discusses strategies for layering the experience. By thinking of the interface as a continuum, it can not only adapt to devices, but can become more robust with browser capabilities.

The audience had a lot of questions for Aaron during the live seminar and he joins Adam Churchill to address some of those in this podcast.

• How can you approach pages where JavaScript is required to complete a task?
• How do you prioritize design considerations?
• Are semantic ID classes useful?
• Are there performance issues with lazy-loading?
• When can we stop supporting older browsers?

Recorded: December, 2013
[ Subscribe to our podcast via ?This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

---

Adam: Welcome to another edition of the SpoolCast. Earlier this fall, Aaron Gustafson presented his virtual seminar, “Designing Across Devices with Progressive Enhancement.”

The recording of this seminar has been added to our library of over 115 seminars on all things user experience design. A library soon to be unveiled as UIE’s “All You Can Learn.” If you’re interested in early access, you can email us [e-mail]. Forgive us for the acronyms. Again, that’s [e-mail].

In Aaron’s seminar, he addressed the sea of considerations designers need to take into account, such as browsers, accessibility, device compatibility and responsive or adaptive design. With new techniques and devices coming out daily it’s easy to feel overwhelmed. But in the seminar, Aaron showed how to wrangle all these elements using progressive enhancement.

Today, Aaron joins us to discuss the concept some more and answer a few of the questions that remain from the seminar. Hello, sir. Welcome back.

Aaron: Thanks for having me.

Adam: Aaron, for those that weren’t with us that day, can you summarize your presentation?

Aaron: Sure, I’ll do my best. I started off discussing sort of where we are in terms of dealing with devices nowadays. I mean, we’re all fairly well schooled in the worlds of laptops and desktops and tablets and stuff like that, and certainly smartphones. But we often don’t think about things like gaming systems, televisions, e-readers, crappy netbooks that you can buy at CVS or Walgreens or something like that.

Then kind of the breadth of all of these different feature phones. Low quality smartphones that I would kind of lump into that feature phone category that may be running an operating system like the latest version of Android. But it’s on, really, less than stellar hardware.

This is kind of where we are right now. The future is really kind of questionable as to where things are going, at least with commodity hardware. Obviously, the development world is kind of interested in what’s going on with things like Google Glass. But we also have a lot of heads up units in cars that are starting to become web enabled, refrigerators that are starting to have this sort of stuff. We’ve got watches starting to hit the markets that have some connectivity to the Internet.

How do we develop a sane strategy for reaching all of these different devices with all of these variable screen sizes? That’s sort of what responsive web design is all about and what it’s meant to achieve. It does that from the standpoint of looking at fluid grids, flexible media and media queries as a means of dealing with the visual representation of a web page and across a variety of screen sizes.

But once you get kind of beyond that relatively, not to trivialize it, certainly, but relatively simple visual rearrangement. You end up with the really difficult things like content strategy, dealing with page weight, thinking about JavaScript support.

Not just a binary, is JavaScript on or is it off, but what are the capabilities on the given device. What capabilities are there in the browser? Do we have access to some of the alternate interaction methods or sensors within the device? Is the device powerful enough to be able to actually execute our JavaScript or is that going to be problematic?

We have different interaction methods like touch. We have, obviously, gestures like swipe, pinch, zoom, etc. We have the traditional keyboard for interacting with pages. We have now motion detection things like the connect on Xbox, but also leap motion. Then we kind of have the traditional scroll wheels and stuff like that that we had in early BlackBerries and Trios and various other rockers and things like that that we need to use to navigate pages.

We have to deal with network latency and performance issues when we’re dealing with mobile networks. I mentioned hardware performance as an issue. Then of course, screen resolution, when we’re talking about kind of a normal resolution screen versus a high resolution screen. We start getting into retina displays that are two, sometimes even three times as dense, pixel wise, as kind of traditional desktop screens have been.

All of this stuff is kind of the more complicated things that are swirling around the concerns of responsive web design.

In the seminar, I walk through the concept of progressive enhancement and that philosophy and that approach to web design. How, if we focus on our content very much in the same way that the mobile first philosophy asks us to focus on our content as the primary driver, the main reason that we build websites to begin with.

If we focus on those core tasks, if we focus on the pros and then we build up the experience from there, based on capabilities that we can actually reach more devices for less. That means both less cost wise, less overall effort, less headaches, less gray hair.

The way that we get there is by beginning to think about interface as a continuum. You may have one way of experiencing a given page or a particular component on a page, and that component may adapt based on the capabilities.

Whether it’s screen resolution, whether it’s input method, JavaScript availability, whatever, it will adapt to become a tailor made component for any user that comes to that page. Two users may not have the same exact experience of that content. But as long as the experience is a positive one, then we’re golden. That’s what Progressive Enhancement strives for.

That’s what I talked about in the seminar. I went through the different ways that we built up an experience using HTML, CSS, JavaScript, and that sort of thing, then gave them some solid strategies and some techniques that I had found useful for organizing our thoughts around this continuum of experience.

To create maps that help us to be a little bit more cognizant or have a little bit more forethought about what the different experiences or what the different ways of experiencing our content should be put together. As opposed to leaving it in the hands of just development team, actually having designers and content authors, project managers, et cetera all involved in them.

Adam: Very cool. Let’s get to some of the questions that were left over. The folks at Anthology Marketing Group, they asked about what’s a Progressive Enhancement philosophy on pages where JavaScript is required for accomplishing a task.

The examples would be calculations or maybe a presentation of content-based choices, and say a bit more about JavaScript. Doesn’t everybody have that?

Aaron: It’s not so much a question of, “Do users have or not have JavaScript,” so much anymore. There certainly are a number of users who do not have JavaScript. I think that the numbers that I saw recently from gov.uk, from their traffic was putting it somewhere around one percent of their users, which depending on your volume of users could be a significant amount of your traffic.

Beyond that, the over reliance on JavaScript…First of all, I love JavaScript, and I program in it all the time. I enjoy it as a language. I think it’s a great tool, but I think it’s also important to recognize what the tool is good for and where its failings are.

One of the problems with relying on JavaScript is that when we’re, let’s say programming a back-end for a website, and we’re building that in some language like PHP or Ruby or Python or even JavaScript, if we’re using Node.

We have control over the server stack. We have control over the environment within which that application code is being executed. We know where the problems are. We can address those, and we can fix those right away.

With JavaScript that we’re writing to be used in the browser by clients, we have no control over their environment within which they’re executing that JavaScript. For that reason, when we put all our eggs in that JavaScript basket. If they don’t have the appropriate environment for that code to be executed, none of that code will be executed.

In fact, depending on the issues with the environment, other JavaScript that it may encountering in that environment or what have you, our code may not execute at all. In fact, no JavaScript code may execute, so the user may have the ability to execute JavaScript, but something they’ve precluded from happening.

When we build interfaces that are wholly reliant on JavaScript for the user to be able to experience anything, there’s a risk there that the user may not have, not just a good experience, but they may have no experience at all.

The classic example that I’ve used for a number of years is when Gawker Media launched their new Web platform. Every piece of content was being delivered by JavaScript. They were using this same platform to run all of the different blogs that they run, like Lifehacker and Gawker, et cetera.

There was an accidental error in the JavaScript code that was produced by the team that made it out into production. What happened is that it was severe enough to cause JavaScript to stop executing altogether, and no content was being loaded into those pages.

That was a really bad experience for all of their customers, not just on one site, but on every site that was using that same platform. To think about, what is the experience that we want users to have? We always want them to have a good experience with our brands and our products.

We want to have a site that’s going to work for them regardless. We want to build something that’s robust. I think there are opportunities to use JavaScript to great effect, but we need to have a fallback.

When people say, “Oh, I need to be able to have a calculator on this page,” or “I need to be able to have this, that, or the other,” you can have that. You can certainly have that, but if you think about what we used to do back in the early days of the Web. For those of us who’ve been on the Web for a really long time. Before we had JavaScript, we used to do round trips to the server, to run calculations or to load new content or what have you. That works whether you’re on a text-based browser or an awesome Chrome 30 running on a really fast machine.

That same old code that runs using HTTP requests and just reloads the page based on values that you supplied in a form is going to continue to work now and into the future. There’s no reason we couldn’t have that and then have a JavaScript that comes in and says, “Hey, here’s the calculator. Here are all of the fields. I don’t have to do a round trip to the server because I can run this calculation just in JavaScript.” There’s not a big problem with that, so you can create a better experience for people who do have JavaScript.

Some of the larger applications on the Web — say your Twitters, your Airbnbs — had jumped very whole-hog into this world of JavaScript and having JavaScript render every Web page that you went to. They’ve actually both pulled back from that, because they found that the speed of delivery of content and the time to actual display of the page was much faster if they actually loaded a normal HTML page from the server, with actual static assets and such. Then once the page was loaded, took the page over with JavaScript and started doing all of the enhancement stuff that they wanted to do to make a richer experience for their users.

It’s just about finding a good balance between wanting to give users a great experience, but still wanting to have a core experience that’s always going to continue functioning even if something really bad happens.

Adam: Aaron, early on in the presentation, you were talking about those factors that we talked about at the beginning of this podcast, all those design considerations, and you had a graphic where they were stacked on top of each other. Mike asks this question. Do you have a process that you use for prioritizing all of them? How do you then turn around and communicate the reason for those priorities to your clients?

Aaron: For us, the priority is always the key task, whatever that is. We need to make sure that a user can sign up for an account or a user has access to the content that they need in order to be able to submit their taxes, for lack of a better example. That is the core, and everything on top of that is gravy to us.

The core tasks are always the priority, and then we start to think about how can we make the experience better for people who have a greater capability. Sometimes there’s trade-offs. We were working on a project recently, and our client wanted to compress the print version of a calendar listing to be making better use of space.

Because the calendar events themselves, when they’re in a linear list, when you’re printing that out, you’re going to use a lot of paper, potentially. In this case, they actually did have a lot of people who did want to print the calendars from the Web page, and they didn’t want to lay it out in a typical, boxed, calendar format because that didn’t give them enough leeway to put in a lot of information in some of the days, so a list was the most appropriate display of that content.

When we started to look at options in print, the first thing that we thought about is, well, CSS3 has columns, and we should be able to use CSS3 columns to essentially make different aggregate groupings of dates, wrap around a couple of columns on the print version, and then it would be the next aggregate group with its own columns, et cetera, et cetera, continuing down the page.

We wouldn’t have to make any determinations about how tall a page is and what size paper somebody’s printing something on, that sort of stuff, which is fairly similar to trying to figure out where the, quote/unquote, “fold” is on a desktop screen. It’s not a fun task to try and figure that out. It’s pretty much a fool’s errand.

We were trying to make something flexible. The problem that we ran into was that there are a lot of browsers that support CSS3 multi-col right now, but some of them — most of the ones that are based on WebKit — don’t actually implement that in print. Whereas, Firefox and Internet Explorer were having pretty good luck doing multi-column in print.

We had to try and figure out, what are the different experiences that we’re going to be providing in those instances? Do we give just the one linear view to users of Chrome and Safari and then do the multi-column for the browsers that can support it, or do we do single-column for both and try and float things to try and take up less space?

We always try to keep in mind what is the best thing for the user, not necessarily what’s easy for us. Where we ended up with that is trying, to the best of our ability, to determine, does this browser support multi-column layout? If so, is it a WebKit browser? Because, as we know, currently WebKit doesn’t support this.

Then we had JavaScript actually add a class to the HTML element that told us which mode they were in, in terms of having multi-column support for print or not. Then we adjusted what the styles were that were applied for the print medium in order to provide the best possible viewing experience for the user when they printed it out.

Adam: There’s some debate over the usefulness of semantic class ID names. What are your thoughts there?

Aaron: In a sense, classes and IDs, they don’t have much use, beyond for us to communicate with each other as designers and developers, by themselves. IDs were intended to be used for identification purposes, for identifying a specific element on the page, in order to be able to anchor to it, in order to be able to find it via the Document Object Model or what have you.

Classes were originally intended for classification of similar elements, as a way of us being able to extend the semantics of HTML beyond what the actual built-in lexicon was at various stages in the development of HTML. On the surface, they don’t really have much meaning beyond that. It’s good to have class names that make sense from a semantic point of view, because it’s easier, as a team, to know which class to apply. If you’re just applying class EF or EF3 or something like that, you don’t know what that is, whereas if you’re using a class of article or carousel or something like that, that makes human sense, right?

There are some systems out there that do apply these non-semantic class names. When they’re generating HTML, for instance, a lot of CMSes do this. A lot of back-end systems that are just churning out markup will create these, I don’t know, non-readable or nonsensical class names and IDs and such, and I don’t find them all that helpful because it’s hard for me to figure out what’s going on, even though it may be smaller in terms of file size that’s being delivered to the actual browser client.

The added importance of the semantic stuff, to me, is, if we’re using semantic class names and we’re looking at each other’s code, we start to gravitate towards similar constructs. This is how the micro-formats community continued beyond the Xhtml Friends Network. This is how we got kind of the h-card spec, the h-calendar micro format, etc. And, by using these class names consistently, from site to site, that content could then be repurposed. We could extract event information.

We could extract people’s cards, addresses, stuff like that and add them directly to our address book. So that was a really cool thing.

But also, our decision to use specific classes and ids, came back to help influence the html spec as it moved forward. A lot of the new html 5 elements were based on class names that we were using. Things like ‘article’ and ‘section’, these were all concepts that we were creating – “header”, “footer”, “main” – and these have worked their way back into the spec and become kind of codified as actual tags. So, in some ways, the semantics that we choose to use in our class names and IDs, really do help to influence the future of the language that we all use. So, from that standpoint, I think that they’re a good thing as well.

Adam: Aaron, in the seminar you gave some examples of lazy loading, could you speak a bit more about what that is and are there performance issues associated with it?

Aaron: Sure. So, lazy loading is the idea of having a core set of content that’s loaded into the browser that’s sent from the server that comprises your, sort of, minimum viable product, sort of speak. It is absolutely what users need to have access to, no more, no less. And then, lazy loading is a way that we then bring in additional content to the page either when we feel it’s a good time to do so.

Maybe after the page is initially loaded, we then load in the contents of the comments section of that blog post. Or maybe we load in images as a user scrolls down the page and they get to within 300px or so of the image, we then load the image in.

And, the effect that this has is we’re kind of streamlining what the initial package is, so to speak. We’re giving somebody kind of a minimum download to begin whatever it is that they’re trying to do on a given page. And then, we’re bringing in assets as they’re needed or as they are requested by the user. And, as I said, these could be triggered by user actions like scrolling, or maybe clicking a button or something like that. Then maybe we make a request for an additional piece of content.

Sometimes we want to do that in a little bit more of an anticipatory fashion. So, in some cases, let’s say, clicking a button is going to reveal more content, but you don’t have that content on the page to begin with because it’s sort of ancillary to the primary purpose of the page. What you could do is you could track when the mouse gets within 400px, circle around the element and then when it gets within 400px, you make a request to the server to obtain that additional information and load it into the page to have it at the ready if the user clicks the button.

What this allows us to do is kind of deliver experience in a little bit more of an a la carte fashion. Which is much more bandwidth friendly and much better for users who just want to get access to the content right away. And don’t want to have to wait to download two megs of JavaScript or something like that in order to be able to have the page assemble and then be able to potentially do everything when they only want to do one thing on the page.

Adam: Aaron, when can we stop supporting older browsers?

Aaron: That’s always the big question, right? So, obviously, paying attention to your stats is an important thing, looking at your analytics data. But, I think it’s important to look at your analytics data with a little bit of a different perspective in that, if you look at your analytics data and you see, “Oh we don’t have any ie6 users or we don’t have any Blackberry four users”, it’s important to kind of ask a follow up question to yourself of, “What is that experience in that browser or on that device”?

If your answer to yourself is, “Well, it’s a crappy experience”, that may be kind of the reason right there. It may be a self-fulfilling prophesy, or at least self-deterministic, that you’re not having any users have x, y, or z browser. So, I think that that’s an important thing but I also think that, as we begin to think more about building sites from a progressive enhancement standpoint. The “problem browsers,” like IE6 become less of a problem because you’re thinking about a continuum of experience instead of trying to achieve exactly the same experience in every browser.

So, for most of the projects that we’re building these days, we still support IE6 and Internet explorer 7, but we don’t optimize for them. We serve them a very basic experience. We give them the mobile first experience without all the bells and whistles. So, for many of those users, they’ll have a single column layout of the text but it will still be usable to them. They’ll be able to find the information they need. They’ll be able to submit the forms they need to.

They won’t have all of the awesome bells and whistles that somebody on the latest version of pro will but, they’ll still have a good experience and they can still accomplish what they need to which is really what we should be striving to do anyway. To be able to reach our users wherever they are and give them a good experience.

Adam: Does IE support media queries?

Aaron: No, not until IE9. So, I don’t remember. I believe that it was, Stephanie Reiger, who… It was either Stephanie or Brian. I can’t remember for sure. Stephanie or Brian Reiger mentioned that, in fact, lack of support for media queries is like the first media query. Because if you use a media query to link a stylesheet. You won’t get that stylesheet loaded in a browser that doesn’t understand media queries. So, it’s a good way to create kind of a base stylesheet that you load for everybody that has your basic typography.

Your margins and stuff like that for elements relationship to one another, but then load a second stylesheet that uses a media query to assign a medium to it. That gets delivered to any browser that understands media queries. And that one contains kind of your additional layouts, your multi-column layouts, and stuff like that.

Those are more aimed at a more advanced browser that has more real estate. And that way the user of a browser like IE6, or even IE8, isn’t penalized by having to download all of these styles that they’re not ever going to use.

Adam: Aaron, in the seminar, you shared a light box example towards the end of the presentation and there was an inquiry. Wouldn’t a link to the larger image still be useful for somebody who maybe is on a device so they can still pinch and zoom?

Aaron: It’s something that certainly could be done and there wouldn’t be really any harm in that, I don’t think. But, in that particular example, my feeling was that the image that we were showing in the light box was really not going to be that much bigger and it wasn’t going to give a great experience to somebody who is on one of those phones or just in a browser that has a smaller screen resolution. So, that was kind of a judgment call, on that particular example.

You could certainly have a link to the image and then still do the light box as a progressive enhancement for browsers that do support it. But I would still probably do a check to determine whether it makes sense to actually show the content in the light box or not because, I don’t know about you. But I’ve had way too many experiences where something has come up in a light box or some sort of overlay.

I have to chase it around the page pinching or zooming, to try to get the content focused. And so, we don’t want to give frustrating experiences to our users. We want to take the friction out of their lives. So, for that reason, I think that we need to be really thoughtful about how we apply JavaScript effects like a light box and such.

Adam: All right. Cool. Aaron, thanks for joining us again to talk more about progressive enhancement.

Aaron: Yes, thank you very much, Adam.

Adam: To our audience, thanks for listening and thanks for your support of the UIE virtual seminar program. Good bye, for now…