The jQuery Summit

Do you like jQuery? Environments for Humans is running a one-day, online conference focusing on jQuery, which I will be emceeing. 

The conference will be on November 19th and will feature a number of prominent members of the jQuery community, including members of the jQuery team.

The following talks are slated for the jQuery Summit:

  • The State of jQuery — John Resig
  • Web Interface Essentials — Marc Grabanski
  • RIAs: Building for the Desktop with the Web — Jonathan Snook
  • Rich Interactivity, Simplified, with jQuery UI — Richard Worth
  • Refactoring jQuery — Mike Hostetler
  • JavaScript for Designers — David McFarland
  • Building Robust jQuery Plugins — Jörn Zaefferer
  • jQuery Anti-Patterns for Performance & Compression — Paul Irish

All attendees will be receiving a free copy of the upcoming jQuery Cookbook, from O’Reilly. Additionally a number of prizes will be given away to attendees (books, DVDs, etc.) during the event.

If you would like to attend this virtual conference, use my discount code, JQRYCHRISS, to get 10% off the overall price when ordering. A portion of the proceeds will be going directly to help fund the jQuery Foundation.

The DIY Summit Recap

The DIY Summit took place last week was a virtual conference that didn’t have the burden of travel time and costs, we had attendees from all over America and all over the world. 

It wasn’t just the attendees that were scattered around the globe, our speakers came from different locations. 

Matt Harris beamed in from San Francisco to talk about WordPress, while Kevin Lawver in Georgia taught about Ruby on Rails. 

All of our wonderful speakers including Brian Fling, Kelly Goto, Dan Rubin, Ryan Irelan, Mark Trammell, and Juliette Melton talked about aspects of one-person Web design team: whether it be usability, branding yourself, raising your design skills, improving your workflow, introduction into a new programming framework, or finally using Subversion.

Even with interruptions by Kanye, over 7 hours in total of Web design and development education were had by people who wouldn’t or couldn’t travel to a Web conference with leaders in the field in an era of budget cuts and busy work schedules.

And we hosted the event in Austin at the University of Texas’ McCombs School of Business (who were also in the middle of launching their new site design!). Since it was UT, throwing horns became both a way to symbolizing rocking out and support for the Longhorns. I love efficiencies!

Special thanks to MailChimp for sponsoring the event and PeachPit for the books as door prizes!

If you missed out on the DIY Summit, don’t worry! 

We have another Web design virtual conference coming up in November: jQuery Summit featuring Jonathan Snook, John Resig and more! 

Transcribe Your Podcasts

If you are going to do a podcast, spend the money to transcribe each and every podcast. 

For the price of US$.75 a minute, you can get your podcast transcribed.

Feeling like balking at the price tag? 

Well, if you are serious about podcasting and even own an expensive microphone to get a rich sound, then is no excuse. 

With a transcription, you gain so much: 

  • improve search results
  • accessible content
  • browser-agnostic content

For the price of some decent hardware, you get to move your content to more eyes–not just ears. 

If you aren’t willing to put down the money do that, then why are you publishing in the first place?

Analyzing Form Element and CSS Support in Web Browsers

Last week, Kimberly Blessing and I gave a presentaion on Designing Our Way Through Web Forms at Web Visions in Portland, OR.

It was a bit more advanced talk in some ways than the one we gave at SXSW.

For this session, I dove into my research of the Web Form Elements to analyze which CSS properties and form elements are poorly supported in browsers.

I looked at each of the Web form elements to see if CSS property was supported on the form element--assigning it a value of Y for yes, N for no, S for somewhat and N/A for the CSS properties that didn't apply.

You can look at the start of this reseach in the lookup tables for Appendix D of the CSS Cookbook. It's available as a free download from the O'Reilly Web site.

To see which form elements and CSS properties did well, you can look into the presentation itself from my SlideShare account (see pages 33 and 37) or you skip down this blog post to read the lists.

Support for CSS Properties (Best to Worst)

  1. margin
  2. background-color
  3. width
  4. font-size
  5. border-style
  6. letter-spacing
  7. padding
  8. height
  9. color
  10. background-image
  11. border
  12. font-family
  13. border-width
  14. border-color
  15. font-weight
  16. word-spacing
  17. text-indent
  18. text-decoration
  19. text-align
  20. line-height

Support for Form Elements (Best to Worst)

  1. textarea
  2. input text
  3. submit buttons
  4. select (one item)
  5. select (multiple items)
  6. file uploads
  7. checkboxes
  8. radio buttons

Web Form Elements Design Quiz, Part 2: Radio Buttons and Background Color Property

Continuing with the quiz, I thought I'd ask a corollary to the first form quiz question since this question deals with radio buttons as well.

How do you think browsers should render radio buttons when a value for background-color is applied?

Pick your answer from the sample answers (which are taken from actual browser renderings) or suggest your own solution!

A. Background color is applied around the radio button control.


B. Background color is applied inside the radio button control.


C. Nothing happens.


Web Form Elements Design Quiz, Part 1: Radio Buttons and Width Property

Browser development is active.

Along with Opera and Firefox, there have been two versions of IE within the three years along with Google’s new browser, Chrome. 

These new developments in browsers are leading to some long desired features in browsers like opacity, auto-generated content and (maybe) embedding typefaces. 

However there is still an unresolved issue with browsers: Web form elements are inconsistently rendered.

While anyone can see that there are problems with how forms are rendered, the question is, “what is the best way to render for elements for a given form element and CSS property?”

Along the lines of Dan’s SimpleQuiz series, I figured it’s best to ask the Web design and development community for their opinions. 

Hopefully this discussion will lead to the appropriate solution that browser vendors could use when programming how browsers should handle the CSS-enabled design of Web form elements. 

The first question I would ask is one that I think shows readily the problem with Web form design: 

How should browsers render radio buttons when a value for width of a certain length is applied?

Pick your answer from the sample answers (which are taken from actual browser renderings) or suggest your own solution!

A. Radio buttons stretch to the size of the width property value.


B. Radio buttons do not resize, yet the space set by width property is applied and the radio buttons are aligned to the left.


C. Radio buttons do not resize, yet the space set by width property is applied and the radio buttons are aligned to the center.


D. Nothing happens. 


Looking into HTML5

In talking with one of the Mikes at the Dayton Web Standards Meetup about what topics people would like to hear at an upcoming meeting, I shot off an email half-thinking, "well, I would like a talk on HTML5 and CSS3."

I'm not exactly sure what his response was, but at the next meetup I was standing in front of about twenty people wanting to hear what I found out about HTML5.

That Mike sure is a sly one. Well, one of them, at least.

To be honest, I wasn't too thrilled about the prospect of HTML5. I'm a little weary of anything still in the larval stage of Web development after getting bitten badly by the poor Netscape Navigator 4 betas.

But, as I dove into a little bit of HTML5 and what bleeding edge browsers that support the unfinsihed spec. Below are my slides from the presentation that can help other people who were as clueless as I was about HTML5.

View more presentations from teleject. (tags: xhtml webdesign)

Roundtable with Jeremy Keith, Steve Krug and Christopher Schmitt

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.

NR: Right.

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.

NR: Right.

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?

JK: Well, it was interesting, because it was a half-day workshop - which I like, so it was condensing it all down to just a couple of hours. And I've given a full-day workshop before so I took that full-day workshop and crammed it down into about some of the early stuff, explaining how to do JavaScript and stuff.

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.

The funny thing was, he had a perception of JavaScript that was frozen in 1999.

NR: Interesting, interesting.

JK: ... familiar so he was....

Yeah, and I was educating him on what you could do with JavaScript these days, and he's educating me on what you can do with Flash.

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?

NR: Yeah.

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, 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.

SK: Exactly!

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?

SK: Yeah.

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,, 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.

SK: Exactly.

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, where you can search across all of their books and all of the books that we publish. And all of O'Reilly books and 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.

Using Yahoo! Pipes to Filter Blog Content

After writing my blog post about the Chopping Block blog adding new writers and thus, in my mind, diluting the brand, I decided to take matters into my own hands.

I took the blog feed graciously supplied by the Orlando Sentinel, put it into Yahoo! pipes. From there it was an easy step to filter out everything except Andrew Carter's blog posts and then take the resulting output into its own feed.

If you are an FSU sports fan and are so inclined, feel free to add the revised feed to your feed reader of choice.

If not, maybe the concept itself can be helpful.

Take a look at the (rather simplistic) solution to see Yahoo! Pipes was used and apply the same concept to other sites you read. (Maybe roll your own custom MetaFilter digest?)

Like I mentioned in my previous post, the Web is about one-to-one relationship. The Internet is about the making content free and allowing people to do their mixing or, in this case, stripping out what they don't like.

Announcing the In Control Web Design Workshop Conference

For the past few months, I've had the privilege to chair the creation of a Web design conference at AIGA Cincinnati, the Professional Association for Design, and, thanks to everyone's efforts on the board and wonderful speakers, it's shaping up to be a great one.

When tasked with this event, there were some parameters I wanted to set to make sure it wasn't your usual industry conference. The first parameter was to have quality speakers.

We have awesome speakers: Khoi Vinh, Molly E. Holzschlag, Stephanie Sullivan, Aaron Gustafson, Ethan Marcotte, Greg Rewis, Kimberly Blessing, Mark Trammell and Juliette Melton.

Second parameter is a major one: I wanted presentors to speak for longer than an hour. It's a little outside the norm, I know, but as our industry has progressed, easy tips and techniques have given way to expanding technologies and mapping long-term strategies. It doesn't make sense to simply brush the surface on subjects.

On the flip side, it's really hard to stay focused in a four hour workshop as an attendee.

So, as a comprimise our workshops run about two hours long. That is enough time for both speakers and attendess to dig deep and ask the tough questions without getting seriously bored.

The third key parameter was price. After doing a survey of numerous Web and design conferences, I'm very confident to say that this conference gives you a more than a fair deal for the price.

The early bird discount makes it affordable--and if you are an AIGA member, you get an even better break on the price. If you want the discount code and are an AIGA member contact your local chapter's board.

If you aren't an AIGA member, feel free to use my discount code, INCSCHM, and save $50.

The fourth parameter I looked at was the number of people that would be attending. I didn't want the conference to be a large event where one would feel overwhelmed by the sheer number of people or feel like you were one soul packed in an overcrowded theatre.

So, we've capped the attendance to the first 100 people that sign up. By the end of this conference, you should have a number of genuine friends with the similar goal of honing Web design and development skills, not just a list a business contacts.

The fifth parameter I wanted set was a one-track conference. I firmly believe in the power of having a natural, organic conversation taking place over time. With multi-track conferences, I always felt bad about missing a quality session over another one. The link with other people at the conference is broken and there's no replacement for hearing that amazing idea that changes your understanding first-hand as it's being relayed from the speakers' own presentation.

Also, at the end of each day, there is a Wrap-Up Panel with that day's speakers.

Ever wish you had time to ask that question at the end of a session or get your point across? Attendees will be able to ask follow-up question or cross-pollinate material from multiple sessions to help keep the conversation and the learning going.

And why have a Web design conference in Cincinnati? Frankly, this is a type of Web conference that doesn't happen in the Midwest, but it needs to.

The closest this list caliber of speakers has come to the Midwest is Chicago, which is five hours away by car. I'm sorry to say, but the Midwest needs Web design and development education just like the big cities seem to be in need of.

The benefit of also hosting the event in Cincinnati is the affordable hotels. I can't tell you how shocked I am that the Garfield Suites Hotel is offering loft-sized hotel rooms starting at $99/night. For those traveling out of town for a conference, you can't find the same price for a similarly sized room in Boston, Chicago, San Francisco or New York City.

And the final parameter? It had to be a conference I would not only want to go to, but I would put down my hard earned cash to see. In a tight economy, expanding or refining your skill set is crucial. The conference I want to go to needs to focus on practical, applicable skills I can use now, rather than the vague big picture stuff.

So, today with great happiness and pride, I'm announcing the In Control Web Design Workshop Conference produced through AIGA Cincinnati, the Professional Association for Design.

This upcoming June 11th and 12th, we are going to have a great time and I invite you to join us.