Aaron Gustafson – Adapting Your Designs with Progressive Enhancement
Podcast: Play in new window | Download (Duration: 37:16 — 18.8MB)
Subscribe: iTunes | Android | RSS
It’s difficult to predict how users will access your designs and your content. More and more, people are connecting to the internet through some sort of mobile device. Using the latest advances in HTML and CSS can leave aspects of your site incompatible with some browsers. How do you ensure that you’re providing a good experience to your users over a broad spectrum of scenarios?
Aaron Gustafson, author of Adaptive Web Design, believes that progressive enhancement can help. He says that progressive enhancement is a great way to get designers to think about the user first. As he states in the podcast, “the best browser is the one you have with you… so why are you making it impossible for me to do something super simple?”
Approaching your designs in this way, you avoid putting technical restrictions on your users. You end up delivering a rich experience appropriate to them in their context. You can employ CSS3 and JavaScript to create a robust experience for those who have capable browsers. But you can also remain accessible and able to perform on older browsers or less capable devices.
In this podcast, Aaron and Jared Spool discuss adaptive web design in more depth. You can also check out Aaron’s daylong workshop from User Interface 17, now in our All You Can Learn Library.
As always, we love to hear what you’re thinking. Share your thoughts in our comments section.
Recorded: June, 2012
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Jared Spool: Hello everyone. Welcome to another episode of SpoolCast. I’ve got to tell you, this is going to be a fun session because I’ve got Aaron Gustafson here and he is really one of the smartest dudes I know.
He wrote a fabulous book called “Adaptive Web Design.” He’s going to be speaking at the User Interface 17 Conference this November, November 5th-7th. Today, we’re going to talk about this adaptive web design thing and what it’s all about. Aaron, how you doing?
Aaron Gustafson: Not to bad Jared, how are you doing?
Jared: I’m doing really awesome. “Adaptive Web Design” covers just a whole range of areas. The subtitle to your book is, as you probably know, I’m thinking, is “Crafting Rich Experiences with Progressive Enhancement.” I want to hone in really quick to start with on mobile. Because, mobile seems to be freaking people out.
A lot of folks are getting overwhelmed with, “how do I take this?” I think for some of them they just got the hang of desk top stuff and now mobile’s got all these different constraints. Have you seen that? Are you seeing people getting overwhelmed by this and what do you think is causing that?
Aaron: Well, there’s a lot going on. It’s definitely something that I’m often overwhelmed by mobile. Just when you start to become aware of all the different factors that are involved in mobile experience. You’ve got the obvious, the form factors. You have varying sized devices. You’ve got everything from small feature phones all the way up to iPad sized devices like a 10″ tablet in general.
But then you start to look at these devices. If you dive any deeper than that, say an Android 7″ tablet, you’ve got five potential font sizes that could be rendered on the device. Three different distance settings, which are basically near, medium, and far. Then, two different orientations, obviously, for the device.
That with one device alone is 30 potential viewing states, which is overwhelming when you start to think about, “How am I laying this out? How do I make a website that’s going to work across just this one device and all of its potential ways of accessing the content?”
Then, of course, there’s the speed factor. “How do I optimize my sites to make sure that they’re going to be delivered quickly over a 3G, or worse, an EDGE network, or something like that, since not everybody has 4G? How do I deal with limitations in terms of processing power on the device, and just the wide range of capabilities across all of these different devices, some of which can make a phone call, some of which can’t make a phone call, some of which have location information, some of which don’t?”
There’s all of this variability, and once you start to scratch the surface and get a little bit further down into the mobile space, it can get super overwhelming, just because there are all of these variables that are affecting the user experience for somebody. Obviously, if you’re thinking enough about mobile to actually be making it something that’s a priority for you, you don’t want to half-ass the experience for them.
You want to make sure that you’re delivering a good experience across the board, and you just don’t want to take those sorts of shortcuts so you start to go down that rabbit hole, and then it’s really easy to get overwhelmed quickly. Yeah, it’s something that I see very frequently out in the business world. It’s certainly something I suffer from every now and then as well. There’s a lot to deal with. There are a lot of variables.
Jared: In the book, you sort of focus on progressive enhancement, and you talk about progressive enhancement as it applies to markup, as it applies to CSS, what you can do with JavaScript, what you do for accessibility. Progressive enhancement has been something that people have been talking about now, I want to say, for…well, years. For years and years.
But, lately, people have been talking also about responsive design. I’ve got to say, I’m a little confused about what the difference is between responsive design and progressive enhancement and adaptive web design. Can you help me get this clear?
Aaron: Yeah. So as Ethan defined it, since he was the one who coined the term “responsive web design”…
Jared: Ethan Marcotte, yeah.
Aaron: Yes. Ethan Marcotte. Responsive web design is about fluid grids, flexible media, and media queries. So responsive web design in that context is really about the design end of things.
When I decided to use the phrase “adaptive web design” for the name of my book, I was doing it to differentiate it from the one other title out there which is “Designing with Progressive Enhancement” by the Filament Group, which is a fantastic book. But I was looking for a term or a phrase that sort of captured what progressive enhancement was about, but didn’t sound as clinical.
Because “progressive enhancement” is a bit of a mouthful. It sounds like this very clinical term or this very technical term. And I wanted it to be something that could resonate a little bit more easily with people. So “adaptive web design,” as I use it, is really a synonym for “progressive enhancement,” which is really about the whole experience. It’s a more holistic view of how it is that we create experiences for people on the web.
So it goes all the way back down to the way that we offer content-essentially making sure that what we write is clear, and easily understandable by everyone and is going to be usable by anyone, no matter what their device or their platform or what have you. And then, building up that experience layer by layer, with the understanding that at certain points you may have devices that don’t understand something that you’re doing.
That’s OK, as long as the core experience is there and available for the users, it shouldn’t matter. The technology should not get in the way of the experience, in other words. So, progressive enhancement is really about creating a rich experience for users that’s appropriate to them, without placing any technological restrictions upon them.
And as such, responsive web design fits very neatly into that as a great progressive enhancement technique, especially mobile first responsive web design.
Because what you’re doing is you’re building up this experience from the most baseline experience, which, in terms of browser capabilities, some of the older mobile devices really are kind of the low man on the totem pole in terms of what they can understand and how they process things, especially if you look at maybe a BlackBerry OS5 and such, older Nokia devices and the like, and some of the cheap non-Android phones that are out there.
They all have varying capabilities. They tend towards the lower end of the spectrum, the lowest common denominator. We use that as our baseline experience.
We build up the experience from there, layering on micro-formats, or HTML5 elements and additional semantics there, which help the browsers that do understand that, and help the assistive technologies that look for that and the plugins that look for that. Then build on top of that layers of style that then adapt the layout to the device.
Bryan Rieger of Yiibu has this great quote where he said media queries…which are what makes it possible for us to adapt layouts based on device dimensions, color density, that kind of stuff. He said, in essence, the lack of media query support is in fact the first media query.
When we start off and build our baseline design around the single-column, very streamlined approach, and then build it up from there using media queries, it works really well for those old devices. It also works for modern browsers because it allows us to take advantage of the media query support, adapting the layout to accommodate larger screen resolutions.
In the JavaScript end of things…We can use detection of features and other available components within JavaScript to determine whether we should load particular JavaScript libraries. And whether we can do things like query their browser to find out what the location of the user is, in order to provide them with instant directions or find them the nearest office, or something like that.
The accessibility piece is woven throughout. We’ve been thinking about accessibility for a long time. Hopefully, most of us have been thinking about accessibility for a long time. A lot of it is woven into the content that we write. That’s a baseline accessibility thing.
The semantic markup that we use, the styles that we apply in terms of color contrast, text sizing, that stuff is all about accessibility. In the JavaScript world, we want to make sure that the user is capable of actually accomplishing whatever the core tasks are for the page, regardless of whether they have JavaScript support or not.
There’s this new spec that’s come out from the W3C called WAI-ARIA, which stands for the Web Accessibility Initiative’s Accessible Rich Internet Applications spec. That allows us to do things like declare a section or a division of the content on the page as being the main content of the page. Or this content over here, this is acting as the banner for the entire website.
We can provide greater context, giving assistive technology, essentially, landmarks throughout the page. That can allow a user to immediately jump from point to point, to jump immediately to the navigation, to jump immediately to a search form without having to hunt throughout the page for it.
ARIA goes even further to define roles and states that are being used by rich interactivity or rich interactive widgets and such, such as progressive disclosures or tabbed interfaces–the things that we’ve come to expect in this rich Internet applications world.
ARIA helps to define those better for assistive technology so that users can know what’s going on, and know how to interact with a particular technology. It maps a lot of those paradigms from the desktop environment to the web. It gives a consistent end-to-end experience for people who are using assistive technologies.
Jared: When you say holistic, what we’re really talking about here is…This is taking the full gamut of everything you’re designing for that user experience, and looking at that. Not just focusing on how does this fluidly display when you move from one width to another, one height to another for a window. You’re looking at the input side of things. You’re looking at the interactivity side of things. If you can support JavaScript or you can’t support JavaScript, it just happens to keep working no matter what you’re doing. Do I got that right?
Aaron: Yeah. It’s about creating a really robust experience. The classic example that I like to highlight most recently is when Gawker media re-launched their web platform. They had moved their entire platform over to JavaScript as a 100 percent requirement for accessing their content. They’re a content site. All their sites are content sites. Their blogs, I’m sure, want to be “Huffington Post” or a “New York Times,” eventually, but they’re a content site.
And what they were doing, they were actually requiring that JavaScript be available in order to load in content to a page. When they launched the new platform, there was a bug in the JavaScript that caused JavaScript execution to halt. When that happened, nothing was loaded into the page. There was a nice little loading icon. I don’t remember if it was spinning or if it was static. I’m fairly certain it was spinning. So it would just spin forever because the JavaScript had stopped executing.
But the markup that was there to begin with, which included that little rotating loading sign, was there, and was able to be rendered by browser, so they ended up in this really weird situation.
Obviously, it was a big problem for them, but if you think about it, when you’re relying on one particular technology to that extent for something as simple as a content site, you’re really creating this very fragile environment. There are lots of people out there who say, “Oh, everyone’s got JavaScript now so that’s not a problem,” but this is an example of people who did have JavaScript support not being able to access the content because there was a bug in the JavaScript.
Sure, you might say, “Oh, my JavaScript is impeccable. It’s never going to have an issue in it,” but stuff happens. Buggy code makes it into production. Heck, there have been lots of versions of Chrome that have made it into production that have had regression bugs, and stuff like that. If you rely on any third party JavaScript, whether it’s hosted jQuery, or advertising code, or anything of that nature, that can halt execution of JavaScript as well, which can in turn break your site.
So, you want to create an experience that’s going to be able to work independent of JavaScript’s availability. You can create a more interactive, a more fun, a more exciting experience for users who do have JavaScript, but you need to make sure just for the simple sake of having a site that works, you need to make sure that it’s going to work without that. So, yeah, it’s kind of funny.
Jared: Does this mean the designers themselves have to design multiple versions of each thing? That they have to do a non-JavaScript version, and a non-CSS3 rounded border, margin padding thing, because it’s not supported in whatever browser? So they have to have different versions of each thing, or is there a way to prevent us from having to do five versions of everything?
Aaron: Well, I think it really depends on your process. In terms of the way that we run things in our projects, we deal with a lot of this at the planning stage, so this is all part of our IA documentation, our wireframes, our user flows, and the like. We outline what it is that interaction is going to be with and without JavaScript.
When we’ve got existing systems in place, let’s say for a tabbed interface, for example, if we built something in the past that has worked for us, and we’ve got that as a module in terms of the HTML that we need, and the JavaScript, and the CSS, a lot of times we’ll essentially drop that component into the wireframe, so we keep kind of a library of what the fallbacks are.
A lot of that thinking needs to happen at the planning stage in terms of what the interaction’s going to be, and then that in turn helps the designer to determine which things they need to design, or whether they design the Hi-Fi experience and then make some notes, or some annotations, on that design in terms of, “This is what the fallback is.”
If it’s a carousel, does the carousel break down into being four stacked article promotions, or does the carousel just remain a single image with a description, or something like that, and it’s not a carousel, it’s just the image with the caption?
Those determinations can be made during the planning phase and then help to define that for the designer, and the designer can decide how far they want to take it. It may just be a couple of conversations with the programmer, or just some thinking about it if they’re the designer and the programmer as well, in terms of what that experience looks like.
Obviously, it depends on the particular project as well, as far as what you want to have for particular requirements. If you’re building your own Basecamp, for example, I think you have a little bit more control in terms of what you’re going to say you support for browsers, and you can make some specific requirements in terms of level of CSS support, and level of JavaScript support, and the like.
Obviously, it helps in terms of JavaScript to build it more robustly such that it doesn’t need JavaScript in order to run. But at the CSS end of things, you can put particular requirements on it because it’s an application that people are having to agree the terms of service in order to use, and it’s not just a public website. They actually have to have an account, and they have to log in, and so on and so forth. I feel very much the same way about Gmail.
However, The New York Times, or The Boston Globe, or something of that nature, you’re a public website, I don’t think that it’s a good idea to make those stipulations in terms of what somebody has to be using in order to access your content. That’s what we were doing back in the browser wars days of Netscape versus IE.
You had all of these sites that had actually put up barricades to say, “You can’t access this site because you’re not running X, Y, or Z browser,” and those sites still exist out there, and for some reason they tend to be a lot in the banking industry. If you go to do online banking, and I’ve had this, I’ll be on Chrome 17, or Chrome 19, or whatever, and it’ll say, “Oh, you need to be running Firefox 2.”
Jared: Oh, my latest experience is, I was using a banking site and trying to transfer a payment. It’s a three step process, and on step two it would consistently log me out, and I’d just get the login screen. I’d have to login again, and of course when I logged in again I’d have to start over, and it wouldn’t let me go.
I finally called customer support and I said, “The website’s not working. It won’t let me transfer money.” The first thing she said is, “You’re running Safari, aren’t you?” I’m like, “You’re serious?” Sure enough, I bring up Firefox, works fine.
Aaron: Yeah.
Jared: It’s crazy.
Aaron: It is, and it’s frustrating as a user. You know this better than anybody. You don’t want to be frustrating your users. You want them to be able to accomplish whatever their task is that they’ve come there to do, and you want them to be able to do that quickly and easily, no matter what device or platform or browser they happen to use.
It’s like the quote about cameras. “The best camera’s the one you have with you.” Well, the best browser is the one you have with you. I’m sorry, I may be in an environment that I can’t download another browser, so why are you making it impossible for me to do something super simple?
Jared: Oh, anyone who stays in hotels knows that the hotel business center has the worst possible browser configuration one could come up with. I don’t know why, but they all…I think there’s a version of IE4 that was made especially for hotel business centers. IE4 running on an Atari 2600, or something. Yeah, there’s nothing worse than an airline site that you’re trying to get your boarding pass for that won’t work on the hotel browser.
Aaron: Yeah, absolutely. Speaking of Atari 2600, it’d be like purchasing E.T. for the 2600, and then going home and actually trying to play it. It’s a very frustrating experience. [laughs]
Jared: Exactly.
Aaron: The five of your listeners that are Atari fans just laughed their butts off, but everybody else is scratching their heads.
Jared: Yes, that’s right. [laughs] My Atari fan base has been diminishing over time. It sounds to me like adaptive web design, it’s not something that you put on, like frosting of a cake, at the end of the process. You’re thinking about this all the way through the design process. When you first start doing your, “Who are we building this for?” Part of it is, “Well, what do those people have, and how are we making sure that we can accommodate all their needs?”
Aaron: Yeah, absolutely. It’s a philosophy that goes throughout the entire process. You can have all the statistics in the world in terms of what users are coming to your site and stuff like that, and you might say, “0.1 percent,” or, “0.01 percent are actually coming to my website on BlackBerry OS 5, so I really don’t care. I’m not going to put in the effort for that,” but you don’t know if that 0.01 percent is somebody who’s got a million bucks to spend on whatever your product is that you’re selling.
We don’t know anything about our users, really, when they come to our site. We can make some educated guesses, but that’s all that they are, and the more that we can create an experience that is going to work for them regardless, I think that a better position we are in business-wise. It’s not all that complicated to do. It’s just a different way of approaching the web development process and the web design process.
Once you get that mindset, it all starts to fall into place. You see how these different technologies come together and play off of one another in order to build up that experience, and you start to figure out where are the places where I can play with this a little bit and make something that’s even better for somebody with the latest and greatest browser, while still serving somebody who may be on something that’s super old or they might be on IE4 in the hotel lobby.
It takes that little mental shift, and then all of a sudden, once you get it, you just become ravenous about it, and you just want to make every experience like that. I’ve been really excited because a lot of the people I’ve talked to about the book, they’ve come to me, and they’re like this is exactly what I needed. This helped me put so much stuff into context.
I even met a guy the other day who is working his way through it a second time because he enjoyed it so much the first time. It seems to be resonating with a lot of people, even though the philosophy, it’s been around since…2003 was when Steve Champion coined the term and really tried to move us away from the idea of graceful degradation.
We’ve had a couple of slips since then as progressive enhancement became fairly popular and standard operating procedure throughout the beginning of the ’00s, and then, Ajax came along, and everybody started freaking out and thought Ajax was the best thing since sliced bread, and so they started putting all their eggs into the Ajax basket, as the Gawker media people did.
And then, Jeremy Keith actually brought us back to reality with the concept of hijacks, and actually being able to have a baseline, straightforward, HTML, HTTP, baseline experience with standard links and normal forms, but actually posted to a page, and then using Ajax to hijack that form or that link in order to do something different with it.
So we came back to progressive enhancement again, and then Apple dropped their HTML5 showcase on us, and everybody started freaking out again. Once they wiped the drool off their keyboards, they were saying, “Oh, progressive enhancement is dead.” I want to do all this nifty, cool stuff, and they were getting caught up in the technology, and getting caught up in what was possible with the browsers, which is great. It’s important to be enthusiastic about what we do.
But there was no tempering of that with what is the reality out there in the world and how can I have my cake and eat it, too, basically. How can I do these awesome things that I want to do without screwing over this poor guy who is stuck on the IE4 in the lobby of the hotel, or whose boss may not be willing to buy him a new phone, and so he’s rocking a phone from 2004 or 2005.
Progressive enhancement isn’t trying to hold us back. In fact, it’s trying to just get us to think about the user first and think about how to build up that experience, so that we can create a great experience for anybody, regardless of what their device or platform or special needs are. To instead, just focus on that experience and build it up and making sure that everybody has a good experience, even if it’s not the same experience.
Jared: Yeah. And that’s a really interesting idea, this idea that not everybody has to have the same experience. I think that we get really stuck on the idea that somehow other people will complain if they find out that someone else has had a different, richer, interactive experience, where they could drag and move things, versus select and click a menu option.
Yet, the reality is that they’re not going to notice, and they’re not going to know. And what they’re really going to notice is if they just can’t do what they need to do because their browser doesn’t support it or there’s a bug in the code or something.
Aaron: Exactly. I think it’s really about avoiding frustrating your users and making sure they have a positive experience because, I mean, we don’t want people to associate our products, our websites, our services, with bad experience because that’s not going to get us new clients. We want to make sure that they have a good experience.
Even if Sally doesn’t have the same experience as Tom, we just want to make sure that they both have a positive experience.
Jared: It seems to me that this is…I read through your book, and I’ve got to say, I’m not much of a coder, but I found it really easy to follow along and figure out exactly what you were doing. It just made perfect sense to me. This is not a really hard concept. This is not, “ditch everything you know, flush it down, and go off and learn this whole new thing.” It’s really just bringing stuff we already know into perspective and saying you know, there’s a way to get this done that it actually works for everybody.
Aaron: Exactly. It’s a philosophical mind shift. And, to me, I tried to make the book to be more like a philosophy book, punctuated with bits of code to illustrate points, but to me, the technologies, they shift so much, our best practices shift so much, that no tech book really stands the test of time for very long. It may get a six month shelf life if it’s lucky. In some cases, we come out with a book with a new technique in it, and it’s outdated within three months or a month.
To me, I wanted to create something that was a little bit more philosophical and illustrated some of the concepts, but didn’t put so much emphasis on technique and particular approaches, so much as just trying to get your mind going in terms of what’s possible, and here are some examples of how this philosophy is born out with regard to topic X.
I also wanted to keep it a short book, so I didn’t want to go into exhaustive detail about things, so if there’s a whole compendium of things that you should read into that’s listed in the end, not so much a bibliography, but a further reading. If you’re particularly interested in content, these are the go-to books and articles that you should check out in order to see how all this progressive enhancement stuff relates to content or this is how it relates to design, and so on and so forth.
So, really, it was like let’s give people the cliff’s notes, help them understand the philosophy, and get them excited about what the possibilities are, and then send them out into the world to get the further knowledge that they need and to bone up on what the particular techniques are that are useful to them now, and let that be handled by somebody else.
Because that’s the stuff that’s going to change more frequently. That’s the stuff that’s going to require following blogs and staying on top of .NET magazine and A List Apart, and other publications, Smashing Mag, and such. That’s where we want to go for that stuff. You’re not going to pick up a book to look at a technique. But you may refer back to a book to see about philosophical approach to a particular design challenge.
Jared: This is all really interesting. I’ve got a question for you, though. Is it really easy to tell if I’m doing a good job or I’m screwing it up, or is this one of those things where I just have to wait until users start complaining before I’ll know whether I got it right or not?
Aaron: There’s a bunch of different ways to potentially test this stuff. The first and easiest way is to fire up a text-based browser like Lynx.
Jared: Seriously?
Aaron: Yeah, if you can…
Jared: I don’t even know where I get one of those.
Aaron: You should probably have it installed already on your computer.
Jared: Seriously? I didn’t even know that. [laughs]
Aaron: But if you can use a website in a text-based browser, you’re golden. Being able to use the site with JavaScript turned off, that’s one way to do it. Using Firefox, you can turn off JavaScript. You can turn off styles. Turning off styles and turning off JavaScript will pretty much get you to that text experience, except you’ve got the baseline and browser style sheet applied.
But those things will help a lot with being able to see how robust and how tiered your experience is. And that’s the initial starting place. Testing accessibility, a great way to do that is just…A way is to just turn off your monitor and use a screen reader and see if you can actually use the site. Obviously, you’re not going to be as fast as somebody who uses a screen reader every day.
Jared: Oh, wow. Yeah, this weekend I was with some blind folks, and they were using a screen reader. And, man, they can just burn through those screens. They actually had to slow it down to demo it to me.
Aaron: Yeah, I was at an accessibility conference in Stockholm, and they were doing some live demos of a guy going through. They were going through a bunch or rich interactivity modules and components and stuff like that and showing where they were done well and where they were done poorly.
Yeah, they had to slow down the speed of the screen reader reading because most people who use them every day have them reading quite fast. I do the same for all of my demos. Well, I do it when I’m actually using a screen reading, because I can’t listen that quickly.
But when I’m doing a ScreenCast, for instance, of a particular interface, I’ll make sure it’s really slow and then the other thing that I’ve started doing, which was actually…I don’t know why I didn’t think of it, but when I was doing ScreenCasts of a screen reader actually reading out the content, I didn’t think to caption it. So I went back and I captioned pretty much all the videos that I do screen readers with so that you can actually read it as well as listen to it depending on what you’re able to do.
It’s crazy. I couldn’t even imagine trying to actually do captioning against an actual screen reader being used by somebody who uses it every day. It would be…I don’t know. It’d be like trying to caption somebody from New Jersey, just really, really difficult.
Jared: So this is an unrelated question, but we’re talking about this, and it occurs to me that if I’m building a website that works great when I’ve got JavaScript and styling off, that means I’m building a website that the search engine crawlers now can really get to see what’s going on, and therefore, there’s a really good chance that my SEO is going improve out of this.
Aaron: Absolutely. The semantics that we use in terms of markup helps to key the search engine spiders into what the content means, because the semantics is all about providing deeper meaning about the actual prose that’s on the page.
A lot of people…We talk about the PageRank algorithm that Google uses. First of all, most people don’t realize that it’s actually named after Larry Page. It’s not because it’s indexing pages.
Jared: I didn’t know that.
Aaron: Yeah.
Jared: [laughs] That’s hysterical. I didn’t know that.
Aaron: Yep. The original algorithm was wholly based on link text and specifically what the text was that was being linked to another page. And then, based on how many people are linking to a given page with that term that boosted that targeted page’s rank for that particular term. So this is how we ended up with Google bombing, which we had the famous example of miserable failure.
Santorum is a more recent example that’s not safe for work, although I think they’ve probably corrected that one by now, once he got a little bit more up in the polls.
So that was the entire idea. But that was really the first time that a search engine was starting to pay attention to semantics, because it was saying here is the phrase that’s being linked from one page to another. This must have some bearing on what the content is that I’ll find on that page. When we start talking about content, and we start talking about content strategy and stuff, we refer to this as contextual linking.
But that was really the start of search engine spiders paying attention to the semantics of a document. And it’s spread from there. They pay attention to heading levels that are in use. They pay attention to emphasis, strong. They obviously pay attention to what’s further up in the document before stuff that’s at the end of the document, which is why a lot of us have moved to a content first approach, where the content is the immediate thing you have after the banner, the site identifier at the top.
Jump immediately into the article content or whatever the main content is of the page, and then move the navigation and the tangential information to the bottom of the page because navigation will always indexed by the search engine spiders, but we want to make sure that content’s indexed fully. Most search engine spiders only index a certain amount of data per page basis. So we want to make sure our content is as far up on the page as possible.
But some search engines even actually pay attention to things like microformats in a page. It’s through the use of the XFN, XHTML Friends Network, which was the first microformat, that we ended up with the Google social graph, which allows you to dig up all sorts of information about a particular person based on a single URL that they controlled, because…the way XFN works is it uses a rel attribute, which most people who write HTML are probably familiar with. It’s what we use to say that this linked style sheet is actually a style sheet.
But you can use it on normal links as well, so I can, let’s say, point to my wife’s website, or a page, like her page on Flickr or something like that. I can say rel equals spouse, muse, sweetheart, whatever, and it established the relationship of my page to her page, or from me to her.
But there’s a special version of that called rel equals me, which you use to point to other sites that you own or other profile pages of you on the web. So the search engine spider for Google has actually indexed all of this content and determined all of these relationships and has been able to build this massive web of all this information.
So there’s a JavaScript engine called Ident that you can use that will actually query that. You can have somebody. Let’s say they’re signing up for a service on your website. They can enter a URL that they own, say their Flickr profile or their Twitter profile, and it will go through and pull all of the data from all the various other profiles they have that are linked to that profile and build a whole profile of that user, bring in their photo automatically, their bio.
Let’s say pull part of it in from LinkedIn, part of it in from their Flickr profile, part of it from Twitter, and so on and so forth and try and build the most accurate description of that person that the social graph can do, which is kind of creepy.
But I think if you set the expectation, like hey, you’re signing up for this new service. If you’d like, we can build a profile from you, from your other social networks that you’ve already put a profile on publicly. If you’d like to do that, go ahead and put a URL to one of your profiles and we’ll build it for you. And you can edit it from there, rather than having somebody having to type the whole thing again.
Jared: I think I’ve seen that in some blog comment features, like Discus and stuff, where they somehow magically get my picture and know who I am without having me having to have explicitly told them.
Aaron: Yeah, some of that comes through authorization through third party things like Twitter, and some of it comes from simply the email address being tied to a Gravatar. That’s how a lot of blogs do it. But the Ident stuff is creepy but cool at the same time and definitely goes a bit deeper than that, because if you do have a LinkedIn profile, if you do have a Flickr page, and that sort of stuff, it can pull all kinds of information about you, all of which is public, of course.
It’s not stuff that you’re keeping private. It doesn’t have access to that. But it’s still interesting to see the power of something like microformats and see how search engines are starting to use that content. Another example of that is we were working on…my friend Craig Cook and I, this was back in 2006.
We started working on a product microformat, and shortly after we started working on that, somebody at Best Buy picked up on it and started working on it a bit more. But when that started to get rolled out, we were actually seeing that some sites were being indexed higher for using the product microformat, even though it was still in the draft phase.
But what we were seeing, that search engines were actually paying attention to the microformatted content and giving that a higher ranking because they were able to tell what the semantics are, what the meaning was behind the actual prose of the content you had in the page. So, yeah, lots of Google juice and Yahoo juice and such for that stuff.
Jared: This is all really interesting. I’m really excited about your workshop coming up and learning a lot more about how to do this on our sites, and I think it’s going to be really a tremendous amount of fun and really let me and everybody else who’s there, get a whole new perspective on how to create great websites that can be used everywhere.
So thanks for taking the time to help us understand what adaptive web design is and to hear a bit about just how powerful it can be.
Aaron: Awesome. Thank you very much. I’m looking forward to the workshop as well.
Jared: So for those of you who want to learn a bit more about Aaron here, it’s really easy to do. You just go to the Google, you type in, “adaptive web design,” and you will get to his book, “Adaptive Web Design: Creating Rich Experiences with Progressive Enhancement,” which you can get on his site, easyreaders.net, or at Amazon.
You can hear Aaron when he comes and speaks at UI17 on creating adaptive responsive web designs. It’ll be a fabulous conference. You should not miss that. That’ll be November 5th through 7th in Boston, Massachusetts, and we hope to see you there. Aaron, thank you again for taking the time to talk to us today.
Aaron: Yeah, absolutely. Thank you so much for having me.
Jared: I want to thank our audience for once again listening and encouraging our behavior. We will talk to you again soon. Thank you very much.