At last year's Voices That Matter Web Design Conference in Nashville, Peachpit's Nancy Ruenzel sat down with Steve Krug, Jeremy Keith and myself for a roundtable discussion.
Below is the video and transcript of the conversation called "Web Kaffee Klatsch".
Nancy Ruenzel: I am here today with four of our authors at the Voices that Matter conference in Nashville.
To my far right is Christopher Schmitt, who is author of the book Adapting to Web Standards: CSS and Ajax then to my near right, Steve Krug, author of Don't Make Me Think, and then to my closest right, Jeremy Keith, who is the author of Bulletproof Ajax.
We are just going to talk a little bit about some of the themes we have been hearing at the conference today, and boy, I have been getting some interesting insights, but also hearing a little controversy, some pot-stirring going on, not just among the speakers, but also the audience, and the audience is asking some pretty good questions.
I do not know if you guys agree, but the things I am hearing are things like are standards eroding because of proprietary software? The things I am hearing are, is usability becoming so simple that we do not need usability consultants any more? Are there web trends that are going in no directions, directionless web trends?
Let us start with you, Christopher. In your session, somebody asked you how far one could go in sacrificing code for innovation.
Christopher Schmitt: That was an interesting question because he was getting around to the point of, if I just have semantic markup, but how far should I or should I not go to add additional markup, like an additional span and divs or other elements in order to pull off an effective design.
My belief is that if you just need a little bit to get you over the edge, that is fine, but just do not have 10 classes or 10 divs or 10 spans or 100 spans or whatever to pull it off. As long as the base of your markup and content is semantic, great.
If you can pull it off without adding any additional divs or spans, more power to you, but we are not there yet with CSS and HTML.
Jeremy Keith: The thing with the attitude that your markup should be perfectly pristine and you should be able to accomplish everything just using the standards, I think that attitude would be totally justified if we had CSS3 and if we had perfect browser support for all this stuff, because then there would not be any excuse for adding in extra markups. But we are not there, right? We do not have that situation, so it is perfect--
NR: But Jeremy, you are on the web standards project.
JK: Yeah, yeah.
NR: You have been involved. So what is taking you guys so long?
JK: Well, you know, we push, but the mission of the [inaudible] has changed. It is not really about pushing for implementation and browsers so much, because we have a pretty good baseline. It is more about educating the developers to use this stuff. There is a bit of a lag there.
It used to be about hammering at the gates of Netscape and Microsoft and trying to get them to support this stuff, but they are actually all on board with supporting it. It is taking longer than we would like, but they are committed to it at least.
So, there is no point pointing fingers at them when they are actually okay with the idea of Web standards ,at least.
CS: I think now we are at the level of trying to finalize the next level of standards, and you just cannot go harassing browser vendors for those standards when they are not responsible for making them. And also, making standards is a long process. The term that is tossed about in online circles is "glacial."
CS: It is going to take some time, but we are still in this practical sense that we do what we need to do to get the effects that we need to have.
JK: So that means adding the occasional superfluous divs, superfluous span, and it does not mean just because we have to add some extra markup means that there is no point in writing semantic markup and we should all use tables for layout and font type.
It is a pragmatic thing. It is like, "Oh, I wish I did not have to, but I have to put in this extra bit of markup."
NR: Well, should we be using Ajax at all, for example? I mean, it's--
JK: Not a standard as such. I mean, not as a proprietary technology that came from Microsoft, but I guess, that idea of de facto standard when something gets used enough becomes standard.
I think, Ajax is now going to be a W3C standard. It's a--
JK: And [inaudible] and Dean Jackson... Essentially, documenting was already there. Looking at the existing behavior, turning it into the spec. But, yeah, it's one of those cases where a proprietary technology becomes the standard, because it's that useful.
NR: For people listening who may not know what Ajax is, in a nutshell, how do you describe it to your beginners.
JK: My nutshell explanation of Ajax is, communicating with the server without refreshing the whole page. If you agree with that definition, then, Flash is Ajax and framsets are Ajax, and Java applets... anything could [inaudible], which obviously kind of tongue-in-cheek. But, it is interesting; a lot of the same set of design and usability challenges that cropped up with Flash and with frames and frameset are returning with Ajax.
It's kind of a jokie thing to say, "Oh, frames are kind of Ajax," but they actually bring up a lot of the same issues like bookmarking and the back button, and that sort of things.
NR: That's interesting.
JK: It's not that new. I mean, in a way it is. It's a really revolutionary way of making Web sites in one sense. In another sense, well we've been using this kind of stuff for kind of a long time.
NR: So this is in some way is a reinvention, in other way is an evolution.
CS: Yeah, it's a new tool that we have at our disposable. It's not suddenly a whole new Web just because we got this new tool in our toolbox. You can't throw away the old rule book just because you got some new technology. But the implications of Ajax are kind of exciting.
NR: So, you did a precon workshop on that yesterday...
JK: Yeah, that was good.
NR: And you had a lot of really good questions. What were some of the other questions you had?
And one of the other things that I took out initially was accessibility for specifically screen readers and stuff. You know what? I won't cover that today. Which is a great parable for how accessibility gets treated in most projects anyway. Time's oppressing. I think we should just take out the accessibility concerns.
But it came up help anyway, because somebody asked a question, and I was talking about providing feedback, visual feedback, and he said, "Well, what about a screen reader. How do they get the feedback?" I was like ah OK. We're going to go there. And I started talking about screen readers and it actually, it's a fairly depressing discussion because we're not... it really is a tricky situation where the current state of things is not great. There are some great hacks out there to kind of fudge your way around and Jazz Langland and Steve Faulkner have been doing great work and researching in finding these things, but the disparity between where browsers are at and where screen readers are at is still pretty broad.
In the future, you know, we've got our jet packs and our flying cars, it won't be a problem because there are things like REL, which is W3C standard specifically for making rich applications on the web and everything will be wonderful and we'll all be tripping through the meadows.
NR: Right, right.
JK: For today if you want to use Ajax to work well with screen readers it's tricky. It's really quite tricky. So it's just interesting that I wasn't planning to actually cover it because I thought I'll leave it out, and it ended up actually being a big topic of discussion.
NR: So you can't really ignore it. It's there. It's kind of like the elephant and the--
JK: Because I was talking about design challenges, and you got to talk about the challenges of Ajax. That's got to be one of the biggest challenges there is. Now I couldn't really take it out. It had to be covered.
CS: Well, that's good that accessibility is still an issue. You know someone brought it up and... Is that part of the accessibility issues with flash or is it... Is flash better towards accessibility?
JK: Flash now is better. Flash now is better. It's funny, because I had my perception of Flash frozen at Flash 5. That's when I used to use it. And I had mine, "Oh, yeah, it's got all these things you can't do it in Flash, and the problems it has."
And it wasn't until I sat down with my friend, Aral Balkan, who's really good Flash programmer, and talked to him that I realized that Flash has gotten really good.
NR: Interesting, interesting.
JK: ... familiar so he was....
I'm so glad I used a screen readers at this point, because Flash is that bit closer to the operating system level, they're able to build in a lot more hooks.
You have to know where to look--add the accessibility support; that could make it easier for authors to do it straight out of the box, but what you can do with Flash generally is better than what you can do with Ajax.
NR: Yeah, yeah, well that's another reason why we all have to keep up. We were talking about this at the lunch table today. There were a couple of designers who had traveled from Washington, DC, working for the government, and they wanted to know, gosh, do we have to do everything in Flash? Or could we stay in PHP and MySQL, etc? Because it takes so long for us to convert the pages and that's a lot of hard work, and where is Flash really going?
A lot of people are at this point, where they're trying to figure out - where should we put our energies?
JK: Which is, I guess, where Microsoft and Adobe are hoping to...
NR: Yeah, yeah.
JK: ... capitalize on that with things like Silverlight and AIR and say, "Here is the solution to all your problems."
NR: Exactly, yeah.
JK: "Here's the magic pill you've been looking for."
CS: [sarcastically] Never heard that before.
CS: Yes, we have no memory of anyone ever promising that kind of thing.
NR: No, no! Right, right.
JK: [sarcastically] Oh, wait. No, we did and it really panned out well, didn't it?
JK: We're all here just glowing.
NR: Right, exactly.
JK: I think the people who have been around the block a few times are a bit wary of all the hype.
NR: Yes, indeed. And for those of you listening who don't know what AIR and Silverlight are, AIR is... I guess you'd call it a technology around...
CS: Miracle technology.
NR: ... Miracle technology [laughs] around the Adobe integrated runtime. And I am not a technical expert so I can't tell you what that means specifically, but I can tell you what the programs that are out there on Adobe's sites will show you. If you go to adobelives.com, you can find sites that will give you applications where you can run them on your desktop, and bring information to your desktop, as if you were on the Internet.
So basically, it's removing that fine line between the desktop and the Internet.
CS: Actually, I had a product where Adobe AIR just came in perfect for it. We had to break through the browser wall. A browser can't... you just can't make a browser go search your hard drive - you can only pick out one file, and then that file will get uploaded or whatever you want to do with it.
We had a project where we had to, for quality assurance, we had to burn a lot of DVDs for a project, and we had a lot of human error creep in to the mix, because our workers weren't applying file names, or full names, appropriately. We had a spec written out, and you could check for it, but it was kind of hard to read and hard to retain, and people just didn't want to do it.
So what we did was we built an Adobe AIR application. We only had about ten workers working on it, and we had the web knowledge, so we would be able to quickly build an Adobe AIR application, hand it out to distribute it. Quality went up...
NR: That's great!
CS: ... And workflow went faster, because people didn't have to spend more time fixing their mistakes.
NR: Ah, OK, that makes sense.
CS: So in that way, I love Adobe AIR just for being small internal applications, for large companies and software. I think it has a great niche for that.
NR: Yeah, the first thing that came to my mind when I saw it was widgets - I don't know why. I was just thinking widgets; thinking of what my iPhone does with weather, and calendar, and movies, etc. It just makes applications so much easier to use.
JK: Yeah, but I think our widget ideas were a more little abused than most, where you have the website and you can go to the website if you want, but there's an alternative, which is that you download the AIR version that sits on your desktop and is nicer and smoother and whatever.
But I don't see anyone building solely Adobe AIR applications where there is no HTML website version. I see it as complimentary.
A lot of the demos that Adobe are showing are things like 'well, here's an example of an eBay widget' that would sit on your desk, or an example of, I don't know, a Flickr widget or something like that, or people are building Twitter clients.
They're all these alternatives to using the website version, but I don't see anyone building a purely, 'You've got to use AIR or you can't use our product at all,' situation. I don't really see that happening.
NR: Exactly, yeah. That could be limiting. Any comments about Silverlight and what you see them doing so far? Anybody have any word...
JK: We're not allowed to compare it to Flash, because it's nothing like Flash!
NR: And with that, Steve, you had some good questions in your session today. Of course, one of the things I was reading between the lines so I don't want to put words in your mouth but, was 'If this is so easy and it's do-it-yourself, in that you can get so much information from even interviewing, or observing, just a few people, do we need usability consultants in our lives?'
NR: What does this mean for all those professionals out there who make a living doing usability consulting?
SK: Get run out of down on a rail!
SK: Yeah. One of the things that I worked on in the book, and one of the things speced out, was I have to have a page that's a whole page that's blank except it says, "If you can afford to hire a usability consultant, by all means, hire one."
NR: Just as your disclaimer, right.
SK: Exactly. Which I believe. The fact is there are umpteen bazillion Web sites out there, and there are, at max, 10,000 usability consultants. Basically, any web presence can use some usability testing. So I think there's plenty of work to go around. I don't think it's taking work out of anybody's mouth.
NR: But the nugget that I took away, and what we were just talking about a little earlier, is you really don't need to have this statistically sound, or quantitative analysis. You can garner insights from observing just a few people, and take those anecdotal insights and really make important changes in what you're doing, right?
SK: Yeah, I mean, I am going out on a limb on some of this. But I do believe it from what I've seen.
JK: But, isn't it true then that the role of the consultant, usability consultant, what you need them for is to interpret and analyze those results?
SK: Uh, no.
SK: In the sense that, if I'm encouraging people to do their own usability testing, what I'm encouraging them to do, is to do something they haven't done before, which is to watch some people use the stuff.
What I'm saying is what will come out of that is some huge problems that are so obvious, and so impossible to get by, will emerge immediately. It's like shooting ducks in a barrel.
That's why I do live user tests. If I'm doing a presentation that's long enough I will do a live user test at it, because I know it's going to work. I can take anybody, it's like a parlor trick or something.
Give me a URL, give me a volunteer. I'll make up a task based on looking at the URL for a minute and we'll do a user test. We'll have a person try and do that test.
When I do them in my workshops it's like the person whose site it is, is sitting there the whole 15 minutes, they're sitting there feverishly writing stuff down. Inevitably they want me to give them the Camtasia file of the test.
Because unless your site is clean and is in really great shape there are major usability issues. On the other hand, once you've gotten it clean then that's where the usability person who has the experience--
JK: Fine tuning it, yeah.
SK: Yeah. And if you can afford it, the usability person can come in and without even running tests... Basically if you're a usability consultant and you're doing a round of user tests, before you do the user tests you're basically doing an expert review because you've got to use the site yourself.
NR: Right, right.
SK: You can, if it's not going to make you look bad, you can basically tell them a bunch of things that are wrong. The great thing would be to fix them before you actually do the user tests.
JK: Best bang for your buck there.
SK: Yeah, exactly. Then you're learning more from the participants. I think the usability professional should be... as I said this morning, Jakob Nielsen said this four years ago at the Usability Professionals Conference, that the usability professionals shouldn't be doing the user tests.
It's like having the neurosurgeon winding bandages. It's silly because almost anybody can do it. It doesn't take that kind of skill. The usability professional should be tackling tricky issues and helping people figure out how to do innovative interfaces, and teaching people how to do their own testing, and thinking deep thoughts.
NR: Right. But not necessarily in the trenches asking those questions. I think it'll come to that. Yeah, so that is the UPA, yeah.
SK: But on the other hand, nobody wants to see somebody else doing part of your job, most of the time.
NR: No, no.
SK: Especially because the testing is a fun part.
JK: Everyone should... It's also a wonderfully humbling experience as a designer to watch somebody touch your site. Every designer should go through it. It should be mandatory.
NR: Wonderfully or terribly?
JK: It's heaven and hell.
SK: That's one of the reasons why I really want people... I want people to do it themselves, and I want everyone involved in the project, including stakeholders and check-signers and whoever, to come and watch--because you've never seen this before. It's so eye opening, so educational and so team building.
JK: Yes, completely.
SK: It's a great experience. The fact is that if you can do this without spending a lot of money on it, it's one of the most valuable things you can do.
JK: Yeah, it's funny, we do a lot of usability testing at Clearleft, we're a user-centric design company. I'm amazed every time.
JK: I should be used to this by now. Why am always so surprised. But every time we do small, I mean really small, cheap, quick and dirty, user testing, the benefits you get from that are so humbling and so slap-your-forehead obvious.
SK: Exactly. I always say the insight to cost ratio is huge.
JK: Yeah, it's amazing! But every time! You'd think you'd get used to that.
SK: It's true. It's kind of foolproof, in a way. The stuff is always surprising. That's what you're looking for, you're in it for surprises.
NR: The 'aha!' moment.
SK: There are always surprises, like nobody noticed that?
JK: So can I put in a blatant plug at this stage?
JK: So we like to do a lot of user testing. It's like what I was saying about the accessibility thing, right? When it comes to the budget, sometimes one of the first things to go, they'll say 'well we'll have to cut user testing because it's too expensive.' Because sometimes it just costs so much to do it.
So we wanted to do quick and cheap user testing. Looked at the tools that were out there, didn't really see anything that great, so we ended up making our own.
We all use Macs, and we realized--this was Andy Budd's idea, thought it was really great--pretty much every Mac these days has a built-in iSight camera, like the iMac and the MacBook.
You can do screen capturing; there's lots of applications for that. You can capture the video from your iSight camera.
SK: And there's a microphone built-in.
JK: Yeah, and there's a microphone built-in. Let's just put the two together.
There's an application that just does one really simple thing, which is you start recording, you have someone using the web site, and meanwhile you're recording their face and their audio as they're using it. You can be asking them questions as they're doing it.
At the end, you export that as a merged video file. The idea is that it will be cheap. It will be less than $50. Called Silverback, silverbackapp.com, I have to plug the URL. It will be out very soon.
The idea is that, as I say, it is going to probably make some people obsolete, or some software or jobs obsolete, maybe. Because I think all you would need is a copy of Silverback and a copy of Steve's new book.
NR: There you go.
JK: And the medic...
NR: And the medic. Yeah, yeah, yeah.
SK: And the medic, OK. True. There is that.
SK: Wait, wait, wait.
SK: I don't think that's going to make anybody obsolete. I don't think anybody who is currently able to afford to pay a usability consultant to do user testing for them is going to buy a copy of anything and start doing their own user testing. They've got money for all that.
JK: That's true. We hope the people who have never done...
SK: People are doing it.
JK: Yeah. The people who have never done this stuff before will now start doing it.
CS: I have a question about computing error in your conversation this morning. It was a little bit like how many people should do user testing or something like. Should you do a hundred or more to get a lot of great data...
SK: Statistical significance.
CS: Or should you, you mentioned in your talk that you're in there for the insights. So is one better than the other, or when should you use one, when should use one or what--
SK: Well, there are times when the kind of question you're trying to answer requires statistical significance, or some larger sample of people if you're trying to benchmark. We have this version of our application and people use it all day long and we want to figure out whether this new version of it is going to enable people to process 100 more claims a day than the original version. Then you've got to do quantitative testing. You've got to measure time on task for each person and you've got to balance all the variables so the data is consistent between the two trials and all that stuff.
But that's a big deal and it's expensive. And that's what they usually refer to summative research. What I'm talking about is a whole new branch, which is formative research, which is when you're in the design process and you're basically just trying to get insights into what's not working in your design. You don't need any proof. The kind of problems usually is the interesting thing when you do it. It's the kinds of problems. People say, well how can you tell what's a serious problem or not. Everybody watching the test says, "Egh!"
, it's a serious problem. It's not hard to figure out.
The other thing that I was saying this morning is I recommend that people do three or four people once a month, they spend one morning a month and do three or four people. Because you do get diminishing returns after you've watched four people do the same tasks. And more than that, if you do three or four people, you're going to turn up enough serious problems that you should fix that it's going to keep you busy for a while. You don't have to grind out a lot of problems, because it takes a lot more time to fix these problems than it does to find them.
NR: Well, I think the latest development list we had, the Pierson Technology Group was at least 200, and...
SK: Well, see, I don't give people the big list any more. I won't give them the punch list, because it's a distraction. And people can go ahead and they can check off 75 of the really easy to fix things on their punch list, and ignore the two that are really hard that nobody wants to look at because they know they're problematic. Whereas those two are probably the ones that's it's really most important to fix.
NR: So how do you prioritize?
SK: I get away with a lot of crap.
SK: I stopped doing written reports a couple of years ago, or what I call the big honking report. I will do it, but I tell the client up front I'm going to charge you twice as much if I have to write a report. Instead, I do it in conference calls, which I think, I hope it will catch on. Because it's much more effective than a report, and reports take a long time to do. The other thing is... what did you just say?
CS: What does the client take away from this?
SK: Well, they get this conference where I tell them what I think where the most serious problems. And I say that I'm not going to tell them more than the most serious problems. And then when they can prove to me that they've fixed those, I'll give them more. I don't really do that, but I tell them I'm going to do that.
NR: You're forcing them to prioritize the big ones, right?
SK: Yes. I'm prioritizing for them. But that's only because when I'm doing that I'm doing expert reviews so I'm not doing any user tests. I'm just going in and using myself. But if you do the user test, I think as a group, I say do three or four people in the morning, buy pizza, everybody debriefs over lunch, by the time lunch is over you're done for the month. I don't think, in my experience so far, there's not a whole lot of argument about what were the most serious problems that people saw. They are kind of obvious.
And you have to iterate it. You have to do it every month and then you plan as you're going to fix stuff and you're going to do it again the next month, or you're going to do it two weeks depending on what kind of cycle you're working on. The iteration is important and that's why you don't have to worry about, you're not trying to catch all the problems in one round of testing. That's why you can get away with three or four people because you know you're going to do it again. So the problems will keep...
NR: So why do so many companies not do this if it is so easy to work it into a regular schedule?
CS: I think most people know what the problem is....
NR: They think they know.
CS: Or they don't think there is a problem. They need to go back to the humbling experience it is if you use user testing.
When I talk to designers or screen designers, one of the things I tell them and I don't do it in a very nice way because it really hurts them to hear this is that, designers get wrapped up in the ego of, like, I made this, this is beautiful, this is great. And it's kind of hard when they should do a bit of testing and see whether people like it--
SK: That's why you have to bring them and have them watch.
JK: It's also much nicer to have a complete stranger say to you there's a problem here, or point out a problem, then someone at work because then politics comes into it. It does become an ego issue like, I think I'm right, you think you're right and one of us must be wrong. Having a complete stranger, a complete third party coming in and pointing out this is really obviously a problem.
CS: And they also pain, I spend 20 bucks before...
SK: You said something earlier, and it made me think that all the web designers and developers - are they now actually getting older and things are going to change? It's no longer every Web developer and designer is 24 years old.
It's now they're 34 years old. It's like a big stack of 34 year olds. Is that going to change people's take on all this stuff?
JK: They probably won't go snowboarding as much.
CS: I'm not sure. We'll see. That's the beautiful thing about this industry. The barrier to entry is just so low that we should be surprised by the young talents coming out that they're going to take over and do something that we never would have thought of. Today's generation, like the whole concept of privacy online is totally flipped from the older generation. Where we say, no you can't have any of my private information except for when I allow it, whereas the younger generation comes out and says, everything is private except what I did...
SK: I actually checked because I went to talk with a school in London, and these kids used a lot of social media and stuff and I tested that. I asked which one of these two approaches would you agree with and it was very much, data is public unless you specifically want to keep it private and just don't publish anywhere. But by default everything is public.
And I actually find myself agreeing more with that point of view, but most people I know my age very much not like the ideas. No, no, there is this private sphere and you don't want to publish that much or you ought to publish it in a very closed kind of way.
I find myself agreeing more with the younger generation.
NR: Young at heart. Always.
SK: Young at heart, yeah.
NR: Well, you know, and that also goes along with the phrase that you coined last night, can we say that you coined this? The voices that matter, "ambient intimacy."
JK: Oh, I didn't coin that.
NR: Who coined that?
SK: Oh, that was Lisa Reichelt. Lisa Reichelt coined that.
NR: OK. Let's give her her props, then. All right.
JK: Yeah, I guess that the value a lot of people get from this social stuff - because when you try to describe it, and I'll take the classic example is Twitter. You try to describe Twitter to someone who's never used it and they say, "Well, where's the value?" Well, none, there, I mean, there is no value, as such, if you're looking for that."
JK: How does that benefit you? It won't, it won't in any concrete, tangible way. But, in the way it keeps you sort of very loosely in touch with people, just know, "Oh, Fred had a sandwich last night. That's good to know."
NR: This is really, you could call it private information or you could call it public. And kids, you know, my daughter...
SK: It's the banal information, but that's really important. All this banal, sort of flea-picking kind of stuff is really important to societies. And, if you take that away, where people have no interaction, even if it's very basic and banal stuff, then it's... Society really doesn't work that well.
So, having those loose, very loose connections, actually brings a lot of benefit. It's just not the obvious sorts of benefit we're used to thinking about.
CS: It's one, like, it's not really a major benefit of Twitter. When Twitter first made its big boom, I guess it was SXSW a couple of years ago, I had to go do some work and so I had to take off--so I went to a restaurant and I just Twittered, "Hey, I'm at this restaurant and doing some work." And I didn't actually end up doing any work because a lot of my friends saw me on Twitter and went to the restaurant and then I had to like eat for another hour.
SK: So Twitter is great for surfacing in serendipity like that. Just surfacing serendipity is exactly what the Doppler guys go for. That's their stated mission is that you say you're going to visit somewhere and someone else says, "Hey, I'm going to be in town." Doppler tells you this.
But, Twitter's actually really good for that in a very unplanned kind of way. And the amount of times, yeah, things have happened...
NR: So, you're calling that surfacing serendipity?
JK: I guess so.
NR: I'm just loving coining all these terms.
JK: That would have been Matt Jones.
NR: Matt Jones. OK.
JK: Matt Jones had the best description of serendipity. He was quoting from someone else, he didn't come up with this but it was, "Serendipity is looking for a needle in a haystack and finding a farmer's daughter."
JK: That was a great definition.
NR: Good one. So, we didn't coin these terms here, but we're using them and we're enjoying them.
And we are running out of time, so does anyone have any final thoughts or final plugs they want to share other than I would like to plug all of your books. If folks haven't read them, please do go out and get them. If you've already read them, then I encourage you to subscribe to Safari Books Online, which is Safari.Peachpit.com, where you can search across all of their books and all of the books that we publish. And all of O'Reilly books and Lynda.com videos and our videos and for a whole library fee, a monthly annual subscription fee, you've got instant solutions from the top experts.
And I want to thank you all for being here.
CS: My pleasure.
JK: Mine too.
NR: Looking forward to yet another.