December 30th, 2013
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 do you prioritize design considerations?
- Are semantic ID classes useful?
- Are there performance issues with lazy-loading?
- When can we stop supporting older browsers?
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 firstname.lastname@example.org. Forgive us for the acronyms. Again, that’s email@example.com.
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.
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.
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.
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.
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.
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.
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.
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.
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…