The transcript from our panel at SXSW Interactive 2006. You can get the mp3 on the SXSW Podcast page, and see the original presentation if you want. Panelists were:
Kevin Lawver: Good morning. This is the "How to Convince Your Company to Embrace Standards panel." I am glad all of you survived last night and could make it up.
Kevin Lawver: I am going to introduce our panelists. To my left is Arun Ranganathan. He does not have a sign; I do not know what happened. He and I worked together on representing AOL and W3C. He is currently our AC representative, which means he votes on many things and goes to many meetings and exotic places. I am not going to read through his entire biography, because you can read (I hope, or this will not be of much use to you).
Kevin Lawver: Kimberly Blessing, worked today a while with me and co-founded the pirate organization about which we are going to talk today, and is currently a member of the Web Standards project and worked really hard on their very cool re-design.
Kevin Lawver: Alla Gringaus was a calculus professor, so she is smarter than all the rest of us. She works for Time Inc Interactive, turning a traditional print company into a standards-embracing powerhouse within Time Warner, which is very cool.
Kevin Lawver: Steven Chipman is a JavaScript god and web experimenter on SlayerOffice.com. He was also a founding member of the pirate organization, which we will talk about.
Kevin Lawver: I am Kevin Lawver. If I did not say--we almost all worked for AOL or Time Inc. Kimberly who no longer works for us--through no fault of her own--she escaped. I am a member of the CSS and now Web API working groups. I have worked for AOL for over a decade now, and I, with Kimberly, co-founded the pirate organization. So, that is what we are going to talk about today. This panel does not necessarily have to apply to web standards. Hopefully, the things are general enough so that you can apply them to anything that a small group of people within a larger group wants that larger group to do. It is [about] how to subvert hierarchy, and it is the whole ClueTrain thing made real in seven easy steps. You ought to read all 95 theses, but you can just do seven steps.
Kevin Lawver: First, a quote: this is from last year's South-by-Southwest: So, as you can see, people do not really think of AOL as a standards powerhouse. We are not the first company that people think about open, or standards, or even the web. We started this about two-and-a-half years ago, so we had much baggage to overcome, many people to convince an entire company. We are now part of Time Warner. They are huge; they print books, magazines, and other things. As a huge organization that had much momentum going in a certain direction, we had to overcome it and get them to go in our direction.
Kevin Lawver: The first step is to find; you all know who you are; you know who the people who agree with you are, and the people who rage against the handshaking--it is just a disguise--this is wrong and stupid, and we can do this-and-this better. They are usually all alone. But you have to find each other somehow and start with a very small group. I think we started, really, just with Kimberly and I talking at the W3C technology plenary with Beth Epperson, who worked at Netscape, about the lack of community, the lack of a real drive for web standards, organizationally. It was just these single pockets of single developers, who turn their products into something cool, standards-based, fast, and accessible.
Kevin Lawver: But, we found all these other products that needed all of this help, and we wanted to drive that, saying that this is really important and wanting the whole organization to do this. We found people like Steve Chipman, Steve's wife Kate, and Porter, and many other people who felt the same way and had the same passion about these things that we did. So we found them and brought them together.
Kevin Lawver: Then, we found the sponsor. If you are a small start-up, you probably do not need a management sponsor, but in a large organization, where you are probably not a manager and probably do not have roots into every single corner of the organization, you need to find someone in management who has those skills and connections to fly cover for you. We were really lucky in finding a guy who was conspiratorial like us and subversive, who said, "Yes, let us screw things up, let us just go change everything." He flew cover for us, so whenever we had to deal with a manager, we would send Roger to take care of it, so we can go being nerdy over here and you can go be managerial over there. We could all do our thing. We used Roger to find larger sponsors, so as we got a little bigger, we found higher-up, longer titles, more acronyms. That was cool.
Kevin Lawver: Once you have that small group and someone to fly cover, you have to give yourself a name--nothing exists until it has a name. For instance, XHTML HTTP Request is too damn long. It existed for years. But once we called it "Ajax," it became cool and everybody had to do it. So, you have to give it a name that sounds dignified. We were going to call ourselves "Flying Monkeys," "Snot," or "Joe and the Pirates," or something like that, but that is not dignified at all. We chose the "Web Standards Advocacy Group," which sounds just unofficial enough that we could get by as a grassroots movement--we are not sanctioned by management, we are doing this for fun.
Kevin Lawver: Then, build an activist spirit. You have to imagine yourself as a pirate captain, or as a virus, or as a gorilla. You are a small band of people, trying to effect a really large change. That can get really daunting, so unless you turn it into a game, it is going to suck really fast. It is going to get really old and feel too big and daunting. However, if it is a game, it is fun. If you went to the [...], you find levels. You can say, "well, we are going to infect three people this week, get our website up, we will start these brown bag things, we will have people show up, teach them all this cool stuff and then they will go infect other people." The other thing is not to be negative; you have to keep it friendly. Because, the whole point is not to sledgehammer people, as in "You will do Standards!" Rather, you have to make them want to do it. We will talk about that more later, but keep it friendly and encourage interaction and debate, so that everyone may feel like they are involved, part of something larger.
Arun Ranganathan: I come to AOL from Netscape Communications. That is where I would like to start my narrative. I was part of a team of technology evangelists, and I would like to share about why we came into being, what the background and back story are.
Arun Ranganathan: Netscape Communications, around 2001 and before, charted the technology evangelism group largely because the flagship product that we were releasing broke the web. It was based on Mozilla open source code, which itself was spawned by Netscape. It supported standards in a way that the previous version of the browser did not. So, essentially, websites were breaking left, right, and center, and the modus operandi that had to fix that was evangelism. This was a complicated problem, because we had not only to convince the outside world--that is every single site out there--but also management. Time Warner wanted to know why this was important in the first place. This was essentially a coda to the Browser Wars. Market share had dwindled so rapidly that the active convincing websites was largely an uphill struggle. We had to find people to convince. We had to start not only inside the company, within Time Warner, but look outward as well.
Arun Ranganathan: Largely, success was achieved by sheer panache and also serendipity. Audacity played a vague role. We would start off by writing to websites and webmasters: "Dear webmaster, could you please do this." But, in order to move and shake and really effectuate change, we had to find the real decision-makers and influencers. That took place in a variety of different ways. I am not above saying that I schmoozed often, looked for contacts where they were not to be found. We were managed by someone quite extraordinary, who is an excellent networker, Suzy Wyshack. The goal of trying to find these people and tell them why what we were doing was important was largely what we were tasked with.
Arun Ranganathan: Finding high-value targets was something that is probably the first step. For any of you that today use Firefox and bank with it on sites such as Bank of America and Wells Fargo, the reason you can get in without being blocked owes itself largely to what our group did. I remember being on the phone with Wells Fargo, trying to explain to them how to change their sites. I did do a little bit of work for them, sending them snippets of the websites, saying this is how you unblock a browser that supports standards; this what you should do with your DOM sniff, this is how it works. I was on the phone with Yahoo and MSN--strange bedfellows for AOL to be talking to, but largely, the bigger picture was that we wanted to propagate standards. So, this was in the larger interest of the web. Finding that story and a way to convince them was a piece of what we did. The upshot is, because of redesign inside the house, Molly on her blog, Molly Rothflag, posted about AOL's side redesign based on standards. That was a big deal for us--to have AOL.com be redesigned according to standards.
Arun Ranganathan: This is the part about spreading the message and how we did it. Some developers in the room will recall with a mixture of affection and maybe a little resentment, devedge.netscape.com, developer.netscape.com, the content we put up on it, and the way it was an outreach for anything Netscape-related. It became less-and-less significant, since this was, after all, the coda of the Browser Wars. But, it became more significant when we started talking about standards and ways to do things, posting snippets of code that would work on IE as well. This re-gaining developer trust, when we had lost it by breaking the web, by changing the browser, was an important part of gaining credibility again, showing them how they could do thing in a way that would reach a wider audience. We had to show them best-case scenarios. Performance, the way that they would reach other browsers and platforms, how accessibility would often come "for free," with a few caveats if they did things the standards-way. Maintainability and code re-use, how easy it was to change one style sheet and thus change the way your content would look without having to dig in to the way the various font elements and intricate things you would do within the markup.
Arun Ranganathan: Of course, we had to create a love affair with the standards-compliant platform. Some of that love affair lingers now with the people who use Firefox in such a die-hard manner. We would try to propagate that with variations of the Mozilla code that existed in the Netscape browser. Standards was an important part of that story; people really wanted standards, while developers really wanted to build sites that worked and that would work on a variety of browsers without doing too many browser-specific things.
Arun Ranganathan: That team's mission lives on in a sense that our work really is not done. Having worked on evangelizing standards, so that Mozilla and Firefox would be supported, I feel a deep and empathic connection with a small company in Norway. Not so small, actually, any more. Opera is still blocked on some parts of our web real estate. Just the thrill that I would experience when we would be able to bank with the early versions of Mozilla and Netscape on bank sites--I am sure that somebody in Opera goes through that same thrill today, and I feel that empathic connection, owing it to them to work on unblocking us. I probably will take that as something to do.
Arun Ranganathan: We also work on numerous other W3C initiatives. As we build up our web real estate, we want to think about scaling the mobile and other things. Kevin sits on the CSS working group. I sit on the mobile web best practices working group. We continue to have concerns about the evolving web platform; Ajax has hot-wired browsers to do things. W3C is taking a look at Web-API's and what it means to have DOM3 events and how to do that properly, what it means to have a standards Ajax-API, if there is such a thing, how to rework the Windows API. So, this is part of the ongoing thing that we would like to work on as we build our web real estate. I would like to pass it on, now.
Kimberly Blessing: While you are out there looking for your compatriots and looking to network to influence things around you, of course, you also need to be keeping house--looking to effect change with the things you are actually working on. So, from 1999 to about 2002, I worked on the commerce platform, which, in particular, had one product that was what we called co-branded. It was available on AOL, Netscape, CompuServe, and in fact, our marketing folks had the brilliant idea, "Hey, we can make more money off of this if we throw an icon up on the Netscape Navigator 4.x toolbar." Unfortunately, that really shifted our strategy with the product, because, so long as that button was getting clicked, we had to have a product that actually functioned on that browser. What is more, they also insisted that the product from brand to brand looked and functioned exactly the same. Unfortunately, our server architecture did not allow us to do any kind of dynamic detection of the user age, so we were really forced into a corner with having to deliver one single experience.
Arun Ranganathan: I could lock them down so that other folks couldn't fiddle with them. So I just proceeded to do what I was able to do. I started with adding a doctype and working to ensure that all of the template code at least validated against that.
Kimberly Blessing: While we weren't fully standards complaint in the sense we using CSS for our layout and didn't have entirely semantic code. There was incredible code bloat too. Over time spending an hour or two a week, we could back and slowly make changes. Going through our own little QA process, incrementally roll-out changes that drastically changed our code. That was a great place to start.
Kimberly Blessing: Of course, this isn't an overnight process. As I'm saying, every week one or two hours doesn't get you incredibly far. So, it took almost a year for us to really knock out a significant chunk of the code.
Kimberly Blessing: And even once we had really done a good job of optimizing our templates, we still had to look to other folks that had a hand in the code. The people who were actually putting products and advertisements on to our pages, they also had access to little snippets of code. And it took some time to work with them in order to get them to understand, this is how we need you to write your mark-up in order to go along with our plan. So you need to provide them with information and tools to make that happen.
Kimberly Blessing: So documenting your expectations for code is one thing that's very important. Setting requirements that they'll understand and working with them if they don't have a skill-set to support that, to help them attain it. For some folks, where we knew there was very little knowledge of HTML itself, simply giving them templates and then going a step further and creating small little forms on web pages where they could enter text, using some DOM scripting just generate the code that they would need that they could copy and paste into the tools that they were using.
Kimberly Blessing: Things like that made a huge leap for them, helped us ensure that we were moving towards a standards complaint site, but also made them feel like, "Hey, these people care about what I'm doing and they're looking to make my job easier." So that really changed their perception and made them willing to work with us. And that was incredibly important. So you're attitude as you're trying to effect change is really going to be important.
Kimberly Blessing: Once you've done all of these things, once you've move towards standards, or if you've have fully moved to standards you still want to use that to show others the benefits. This is the kind of stuff, you know, you've read Zeldman, you've follow all of the blogs. These are the points that you already know. What's important and what Alla's going to talk to is, what's the language you're going to use. You can't go in there and say, "Hey, we knocked out 40k and blah blah blah." You need to understand your audience's concern and speak directly to that.
Kimberly Blessing: But, so switching tracks a little bit. After I stopped being a developer, I did something else for a little bit. But then I turned to the dark side, I went on to management. And I heard a lot of managers, both inside AOL and elsewhere saying it's really hard to hire somebody whose standards experienced. It's really hard to find training programs, things of that sort. Actually it's very easy for managers to just do it as well. I actually rolled my own training program so to speak. We were spending about $1, 500 to $2, 000 to send people to HTML boot camp in Washington DC, there was a training company. They'd come back after a week and still only table based layout and we still had tons of work to do. But for $2, 000 a day, you can hire -- there are some pretty predominant folks in the industry. $2, 000 a day they can come to your company, they can present to 10, 15, 20 people. And that's going change things a lot more rapidly and be a much more effective use of your funds.
Kimberly Blessing: Also, utilizing the folks that are within the company or within your team, asking them to do sort of brown bag presentations that folks can attend. You also want to use whatever additional time you have with your team to evangelize and instruct. Even just five minutes in a team meeting to quickly point out some of the differences between HTML and XML can be a huge thing for somebody to take away as they're walking back to their to continue with their work.
Kimberly Blessing: And finally, some of the folks in this audience use to work for me, and they may not realize this but I use really try to pair folks. The folks who I knew where standards evangelists and really bought into this and knew their stuff, I use to try to get them to work directly with others who hadn't quite gotten yet, or still were not quite believers. I did this by trying to get them together on projects, by doing code reviews with one and another. At one point, when we had the opportunity to move with our building, I even rearranged our seating chart so that we had our evangelists strategically placed. So that way they could kind of effect the folks around them.
Kimberly Blessing: So, ultimately, no matter what your role is in an organization, there is something you could be doing, so just go out and do it.
Alla Gringaus: Hi, my name is Alla Gringaus. As Kevin said, I work for Time Inc. My part of presentation, Perestroika -- I'm here to tear the iron curtain down. Time Inc. Interactive, which is a part of Time Inc., is responsible for distributing magazines through the web. With Time Inc is major and primary content producer and publishing arm for Time-Warner. We have about 200 websites, and some of them are people.com, time.com, In-Style, Teen People, People Espanol and so forth.
Alla Gringaus: Just a couple of years ago, when our goal was to clone the magazine feel and look and quickly get it up on the web so that we have something as soon as possible. Another words, print was going to print basically. Soon it became obvious that engaging content, text content and visual content, to match the desire of the expected audience became necessity to the company in order to be as big of a web presence as they big of a print presence. Almost every -- actually every website is affiliation for the magazine.
Alla Gringaus: And then, I met Kevin. The problem was defined, but not yet solved. Whether you work for a large cooperation like myself or for smaller company, in order to start any new initiative you all know that you need to go through multiple layers of management approval and different people -- people's roles -- different people who play different roles. Ad, sales, marketing, communication, mobile usability, design and so forth.
Alla Gringaus: One of the most critical objectives for me was to determine the major stakeholders in every project. Each of them I created for their own perspective in terms of client expectations. The more you know about your client's agenda, the more opportunity you have to be, I'm not saying final authority, but to be pretty major authority on many issues that concern your client. It all boils down to the point; your best skill is listening skill. Listen and ask questions. Find out what matters to them most.
Alla Gringaus: And once you -- as you ask them questions, once you've found their weakest point, their weakest point is the key to your success. Why? Because all they want, this or that way, they want more traffic. Learn how to speak their language. I remember when some time ago, the design team came to presentation development team, which formerly was known as HTML team not HTML anymore. They told us the content increased and they have much longer pages now, but our major object to retain the content is galley. So, obviously the business and usability objective was to rotate the content without page rewrite.
Alla Gringaus: We said, "Fine, we're going to use Ajax." They said, "What?" Okay, we explained to them what Ajax was. How to explain to not as technical people as us, the creative and usability people what Ajax is? So we said, "Ajax -- we're going to use Ajax approach (of course, not technically) that allows web client to submit and retrieve data from the server without reloading the whole page. It also allows the user to keep doing his task while the data gets processed and retrieved."
Alla Gringaus: We never mentioned XML or HTTP requests. They don't care. What they cared about is the business that -- getting what they wanted, to retrieve the data. So they got it and the word Ajax became the buzzword among all the groups. Now every time they come to us and they say, "Can we do Ajax?" without even knowing about XML/HTTP requests.
Alla Gringaus: Of course, you can get them to do what you want them to do, but the important thing is to get them to want to do what you want them to do. Blah. Right? Yeah.
Alla Gringaus: And, for example, at some point I had to add additional time in order to meet accessibility requirements. So, I came to the managers and I said, "We need more time." They said, "Why?" I said, "I need to meet accessibility requirements." It's embarrassing, but they said, "How many blind people are out there anyway?" Or, "Why should we care?"
Alla Gringaus: So, I wrote a proposal. I went to the president of the company and it just happened that his wife had medical vision problem. She legally visually impaired basically. Legally visually blind, I don't remember the exact term. He felt the pain. How was it for me to convince everybody else? So I called my friends, my best friends, AOL and I said, "I need Tom Lebowski, director of disability of AOL to come here and demonstrate to us how he uses screen reader." He's born visually impaired.
Alla Gringaus: He came in. I got everybody in the room, and the day became the day of accessibility. Accessibility became best practices requirement.
Alla Gringaus: You have to victory any way you can and of course, compromise. Even if you have all their websites and you need to use HTML, if you use proper doctype and you validate HTML, you make progress. If you tables, but for tabular data, you make progress. If you tackle some accessibility issues and maybe pass the checkpoint priority one, you make huge step forward.
Alla Gringaus: Everything calls, but from that point on, by building web standards, there will be no way for you to go back. I'm going to quick show you the case study, and the reason I choose this website -- you can all check whenever you can -- was that just launched it a few days ago. The reason we successfully launched -- okay, I just saw it before this presentation that my team put up my photography everywhere, as the biggest jackass. It's really funny website. OK, don't look.
Alla Gringaus: So, the reason we were able to launch this website 33% faster was because we used web standards and we were able to separate the presentation level from content from behavior. As soon as the Y frame was approved, everybody designed HTML and development started at the same time. We finished all at the same time much earlier than we supposed to because we used web standards.
Alla Gringaus: Visit office pirates. Steve...
Steven Chipman: I didn't know I was going to follow the daily jackass.
Kevin Lawver: We'll get you tomorrow, Steve, don't worry.
Steven Chipman: Excellent. So for a long time, AOL existed within a walled garden. A lot of our content was not available to the greater web community. We baked -- we still do bake IE into the client and there is not, for a very long if you weren't in the client you weren't going to get the content.
Steven Chipman: So this fostered a community of developers at AOL that simply weren't aware a standards community existed. So a logical first step to getting people on the standards bandwagon is to introduce them to that community. A list apart, mailing lists like WD and CSS-D, great starts for this. Given people blogs to reads. I have a huge list in my sidebar on SlayerOffice, and I hit these sites everyday. I see a lot of the people that read in the audience, which is pretty cool.
Steven Chipman: And also, community -- content aggregators like delicious, I hit that everyday too. Popular/JavaScript, popular/css, great places to find out what's going on in the community.
Steven Chipman: For the executive, when you're company does things that cause the standards community to smile, it casts a positive light on the company, which is always good, especially for someone without a stellar reputation like AOL.
Kevin Lawver: It's getting better though, right?
Steven Chipman: [laughing] It is. And of course you have to give your people examples. Obviously, the Zen Garden, there's just nothing else on the web that illustrates why these things are important better than the Zen Garden, as you all know. But real-world examples, as in what they're doing, are even better. I've done several exercises with people on my team where I'll take something they've built and I'll rebuild it and we'll do side-by-side comparisons. So "Here's my version, this is semantic accessible markup. Here's your table-based version. See how much easier it is to read now? It's smaller, it's lighter, it loads faster." Once they see the difference, and that it still renders the same way, you see the lights go on in their head.
Steven Chipman: And once you've done that, you can fire up Jaws or something and show them "Check this out. When people use Jaws they can tab through all the headings in the document. If you don't have those heading tags in your document, then guess what? You've crippled this user; you're making it very difficult for them to use your content. So once they see this they're like "I was being a pain in the ass for these people!" And nobody wants to do that. And of course accessible websites prevent you from being sued, which AOL has been, for being inaccessible.
Steven Chipman: Give these people homework. If they don't have a personal site, encourage them to get one. Everything that I know how to do currently is from things that I've been playing around with on SlayerOffice for the past four or five years. It's a sandbox for experimentation, people come by, they see what you're up to, they make comments on what you're doing and that's a great way to learn these things and keep up. Encourage them to try their own Zen Garden design; they don't even have to submit it. They just have to download the markup and try it. That's a great way to learn. Or have them Zen Garden-ify a page that already exists. This is an example of one of the UIs for.
Steven Chipman: Free.AOL, which is the team that I work with. This the same markup, just like the Zen Garden works. You click the default blue UI, same markup just different CSS. And I actually showed this to an executive at AOL. Like I said, I work for the marketing organization and what we have on Free.AOL is called the control. That's the default UI flow. From that we have thousands and thousands of branching logic that will do things like "move this paragraph over here," or "change the background from a gradient to solid," and these are all things that marketers try to do to get a lift in registration. If something gets a lift in registrations, that becomes the control and we do further tests from that. CSS based design, semantic markup, all of this stuff lends to this incredibly well. I put this example together for an executive, I showed it to her and immediately she realized that this would cut development time nearly in half. And she literally stood up and hugged me.
Kimberly Blessing: You don't want to be hugged by folks at AOL.
Steven Chipman: Another exercise. Have people find high-profile sites on the web that don't use standards and do a recode of their main page. Any of these examples, and I'm not going to ask anyone to raise their hand, but if you're responsible for any of these sites and you're here today, come talk to us. Absolutely. For the boss, let your people experiment and play on company time. If there's some downtime, let them mess around. It's going to benefit you in the long run. They're going to be able to provide solutions faster for you because you've given them the time to play with this stuff and learn.
Steven Chipman: Give them the rules too, code requirements and documentation. And definitely make it part of the QA process because a div with a class of header that should be an h1 is simply a bug, that's plain and simple. And don't allow for "Oh we've got to make this deadline, but I can't get this aligned right. Screw it; I'm just going to put it in a table." No. No, no, no. Don't allow that.
Steven Chipman: Do code reviews. Get together once a week and have somebody say "This is what I'm working on now," and everyone can sit down and have a look. Bring food to these things because then it becomes a bunch of friends hanging out looking at code rather than "Code Review!" Don't make it a witch hunt for bad code. Don't nitpick. Make it fun; make it constructive, otherwise you're just going to build resentment.
Kimberly Blessing: Don't attack.
Steven Chipman: For the boss, familiarize yourself with these rules. It's important. Walk by a desk or something and ask "So how's that semantic markup going?" Just drop buzzwords. [laughter] As Jeremy would say, bluff your way. The fact that people are aware that the guy signing their paycheck knows this stuff is really good motivation to keep people compliant. You have to give yourself rules too. It's very important that you guys make yourself available for questions from the people you work with because you are the expert. And they're going to have questions. So it's very important that you stay patient, be diligent and just hang in there.
Kevin Lawver: So to wrap up, before we open this to questions, I just want to... Ok, I'm just going to wrap stuff up, cause that's what I'm going to do.
Steven Chipman: It is really hard to get started, to be the first one to put your neck on the line and raise this stuff. It's really frickin' scary. But do it. Nothing bad will happen to you. And that's why I said at the beginning to have that group behind you can run back to and say "Ok, it's your turn. That first one really sucked, so it's your turn to do it this time and maybe next time we'll go in pairs, " because with pairs you can at least hold them in front of you as a human shield.
Steven Chipman: We started doing guerrilla redesigns and we were like "Hey this is going to help people! They'll love it that we've taken their site and made it better, faster!" The first one was a nightmare. Because we didn't do the constructive part, it was more "This sucks, and this sucks, and this sucks. And look how much better we did it. Ha ha ha, we are awesome and you are not." It didn't go over real well.
Steven Chipman: Not at all, not at all.
Kevin Lawver: We learned, we got better. The second one we did was much more constructive. It was "see how much faster this is, you could do this fairly easily." And we picked a target that we knew was going to redesign anyway, so it wasn't anybody's baby that they coddled. We don't want to call anyone's baby ugly. We offered to help, "when you the redesign look at this. It could save you X number of dollars and bandwidth," which is a really good thing to figure out. Talk to your network operations people and ask "Hey, how much does bandwidth cost us?" Then do the math. A number with commas in it works really, really well.
Kevin Lawver: Give people places to go. You don't want to become the single point of contact for this stuff because you'll get tired very quickly. Again, that's why the group is important. But it's also important to have a place, virtually, for people to go and hang-out and ask these questions in a very non-threatening way. A wiki is a good place to start because they're butt-simple to set up and run. For a while we ran ours on my desktop machine. Use Drupal, we love Drupal to death because its' super easy to setup... ok, kind of super easy to setup. And its self maintaining now, I don't really have to touch it. People just post questions, we have polls. We do brown bags every month, so we pick a victim and say "Here, present on this. Go!" and people show up. We take a survey and put the highest ones on the docket for the next quarter. And even if you can't set something up like that, a flat site that just has info on it is fine to start with. Do what you can.
Kevin Lawver: Again, easy participation, you need to make it as painless as possible for people to be involved at whatever level they're comfortable at, whether its signing up for a listserv where they only get the digest, or coming to a brown bag once a month, or whether they come to all the meetings. We used to have meetings every other week where we'd organized the troops and plan our next coup. "Who are we going to sack this week?" And then offer training. We made an outreach to other groups. The whole goal was to infect groups. We knew that we could infect our own groups but there were all these other groups that did web stuff. So we'd pick off someone and say "hey you need to come to our little thing and then talk to your manager," and "we'll come do training for your group." We had all the slides and we'd go do big classes. And then plant people. So if you do a brown bag, be sure that the other people in the group are there ready to ask the simple questions that people are too nervous to ask, like "Why do I really have to close all those tags?" Most people are too nervous to ask that question so if you have someone in the audience it usually gets things rolling. I didn't plant anyone for this, so if someone wants to ask that, that's fine.
Kevin Lawver: Learn from your mistakes. We screwed up quite a bit at the beginning because we didn't know what we were doing. We'd read the ClueTrain and we were all on-board. We were like "subvert from within! Whohoo! Links subvert hierarchy, we're all there!" But it's really harder that that. When people tell you you've screwed-up, accept it and say "Ok, how can we fix it? We're sorry, we didn't mean to. We're just trying to help." And if that's your attitude you won't get in trouble for it. People won't resent you for trying to help them. If you go in with that spirit you'll be fine.
Kevin Lawver: Don't just tell them, you have to show them something. This is part of Kimberley's "just do it." Once you have a product inside the company that you can point to as a win. That really makes a difference. It doesn't really matter about the external ones; it's got to be the internal ones. So, for example, Steve's CSS thing works really well. We redesigned AOL.com last summer and its super accessible. If you look at it [typing sounds]. Awesome. What the hell? Ok, never mind. Stupid network. Trust me, its really cool. Go to AOL sometime and resize the fonts and watch what happens. Nobody else does that.
Kevin Lawver: AOL is really trying to get out there. And we've infected enough people and enough executives that people are curious about this stuff and they want to be seen as a company that embraces standards. So we launch things like IM Alpha which is a site where we've put up a microformat for widgets and a way for developers to interact with AIM users and show off their web services and mash-up things. So if you're just Joe Developer out there and you really like Flickr and del.icio.us you can go make a widget that throws the two together in some unique crazy way. And the AIM users can play with it. And it's a microformat, so if you built a parser for the microformat you could put it on your site and let your users play with it. There's a lot of really cool stuff going on that two years ago we wouldn't have thought possible. It's not impossible, it takes a while. You have to be patient and you have to keep working at it, but you'll get there. I promise, really you will.
Kevin Lawver: You can ask about Steve's shirt if you want. You can't IM me because I can't get on the network, so forget that. You have to go to the mike because I can't hear for crap. So go to the mike if you have a question and.
Steven Chipman: Uh-oh.
Kevin Lawver: Uh-oh, here he comes. I knew this was coming. As soon as I...
Marc Canter: Ok, thank you. First of all I want everyone to know that Kevin and the team at AOL is kicking serious butt and they have some amazing stuff coming out really soon. I can't tell you or I'd have to kill you.
Kevin Lawver: He could too.
Marc Canter: And it's really, really very cool stuff so I'm completely in shock that they're called AOL because they're not acting like AOL.
Kevin Lawver: It's a pirate ship.
Marc Canter: So that was the friendly part of the question.
Kevin Lawver: Bring it on.
Marc Canter: I love the W3C. I love guys in white coats with long beards who go to meetings or young guys who go to meetings. But that isn't necessarily how I believe standards evolve. Let's take case in point the modules microformats. There's a little company called Google.
Kevin Lawver: I hear an axe grinding Mark.
Marc Canter: And they have modules. What I'm trying to say is that the W3C is irrelevant. It's the marketplace. And what you should be worried about is being compatible and working with Google and Microsoft and Yahoo! Not sucking up to the W3C because that isn't going to do doodly-squat.
Kevin Lawver: The W3C really doesn't like microformats either. So we're not in bad company there.
Marc Canter: Ok. So the other thing is this panel could probably be the most important panel at this entire conference because getting standards to be accepted is really important. So I would recommend or plead that you support other standards. To me CSS, DOM, that's great but that's six years old, it took you six years. It didn't' take you that long to support RSS and you've got a blogging tool, that's cool (you could make it a little better). And so to all companies, standards are really, really important to everyone. You should all get your companies to support CSS and DOM but there are a lot of other cool burgeoning standards as well.
Kevin Lawver: Ok, I'll take this one. It doesn't matter what the standard is really. We chose to address the module thing. Not really the place for it but I'll talk about it anyway. We did look, we followed the microformat plan, which is you have to look at existing prior art so we looked a dashboard and Microsoft gadgets and Google's home page stuff. We looked at Opera's widgets we looked at everybody who has a widget format. And none of them follow any existing standards. So we said "This doesn't make any sense at all. So we're going to develop a microformat where you can do your development, testing and documentation in one file deliver it to us." Simple, easy-peasy and easy enough to validate. So that's why we did it that way. And I have talked to Opera, Microsoft and Google and we are going to work together and try to come up with something. It's very early on and I probably shouldn't have said anything but I did anyway. We're at least talking and that's the first step.
Arun Ranganathan: Marc I agree that W3C is often very big-lab-coatish and often calls into question its relevancy. And I agree that the W3C should not have a monopoly on web standards in fact there is no monopoly as such that exists today because small community standards are propagating. Microformats are one such example. You yourself are behind another initiative, microcontent as you would call it. I agree that there is a question of relevancy especially when you look at certain things that are going on including the fate of the html working group which is confusing at best. But browser vendors still do come to the table at convenient if not exotic locations such as Mon de Leau in France where people can meet to raise issues about the future of platforms. That is useful to us because the future of the platform is of importance to us. So we will go the meetings and we will raise our issues. It happens to be a convenient forum. We've also paid attention to the small community standards. We've paid attention to microformats, we've paid attention to OPML, we've paid attention to different kinds of things of that sort. Since the Netscape legacy we really do take W3C seriously. We continue to do so but we're not blind to the fact that a lot of other thing exists and we can build cool stuff based on those things. RSS for example let's us build really cool things. Atom is sanctioned under IETF so there's an Atom spec, there's RFC out for Atom, an RFCish kind of thing.
Kevin Lawver: Let's make it practical. One thing probably should of mentioned that we didn't is be realistic. You don't go "We're going to get the company to adopt XHTML 2!" because there's no good reason to do it. You should use standards because they actually help you get something done. If they don't it doesn't frickin' matter. The standard is only good if it's implemented and it helps you do something better, faster, more accessibly, makes you more money, saves you cash on bandwidth. That's why you use standards; you don't do it because it's cool or because some guy in a black Nehru jacket said to.
Arun Ranganathan: And that is in fact also why evangelism was successful. Because people could get stuff done.
Kevin Lawver: That's really all you have to say. We'll get stuff done faster
Woman 1: This is probably a nasty question.
Kevin Lawver: Yeah, bring it on.
Woman 1: I completely get that in a tech company where there are people to convince to do the work that the way to do it is with a "find your fellow people." What about where all the development is outsourced? I work for Proctor and Gamble. It's a big company. I would love for us to have all our outside websites to be accessible. Myself and a blind girl I work with, every time they bring something up we call them up and tell them how crap it is. But it's very difficult because it's all done by vendors.
Kimberly Blessing: I was going to talk about the job that I had between being a developer and an evil manager. I actually was responsible for working with the companies that we outsourced development to. We actually did do and still do to a certain extent a fair amount. I say we like I still work at AOL!
Kevin Lawver: She did, till she abandoned us.
Kimberly Blessing: You know the real story Kevin.
Kevin Lawver: I know it's more fun that way though.
Kimberly Blessing: My job there was to essentially ensure that the standards that we were working to set, which we hadn't yet accomplished entirely internally, we met. I was pushing harder on the vendors to meet them as a way of saying "Look. If we can hire folks to produce the code, then sure as heck we can do it internally."
Steven Chipman: That's the whole finding high-value targets thing. You have to find the person who writes the contracts and say "Include in that contract it must be valid, accessible, passed through a CAD level one." Then you've won because then it's in the contract. You don't have to always convince the developer. Sometimes you have to convince the developer's boss or the bean-counters.
Kimberly Blessing: Yeah if the legalese is there you have a pretty good footing to start from. But even when its not you have resources like technical documentation that outlines how the code is supposed to be written, delivered, what browsers its supposed to work on and how. If you provide that up front when the project's getting started, in a lot of cases even if it's not in the legalese you have a footing to go off of later on when the deliverable doesn't meet your expectations. You can say "We told you this is what we wanted. You guys need to go back and fix it."
Steven Chipman: We're not paying you till you do it right.
Kevin Lawver: Jeremy, go ahead.
Jeremy: So you've all been talking about how to convince your teams internally and you're talking about things like wikis, stuff that's within the company. I'm interested in hearing how it works when you open it up to the wider web. For instance, I know Steve; you gave a talk at AOL about JavaScript. But then you also put the mp3 of that talk online with the slides. I linked to it; other people linked to it and said "check this out. This is cool." So you were getting kudos from the wider community. It seems to me that a lot of the big companies are vying to be the coolest developers. Yahoo! With its developer thing, at Microsoft the people making IE7 are blogging about it. Does a lot more openness and transparency at the big companies help the cause? Does that go down well? When you release all that stuff you do internally to try to convince people to the wider community, does it help?
Steven Chipman: I think absolutely. Because AOL, as you are well aware, is AOL. Your example of the presentation I gave, I put that up on the web because while I want the people at AOL to benefit I also wan the people outside of AOL to benefit from that same information. Maybe they'll come work for me one day.
Arun Ranganathan: I'd also like to tag on something. When we were working on developer.netscape.com, which doesn't exist anymore (but does exist as developer.mozilla.org, its all wikitized, it's all migrated over), we had very prominent people. I'd like to give kudos Eric Meyer worked for Netscape Communications and created really kick-ass content on developer.netscape.com. I'm really glad that content has migrated over to Mozilla, but one of the points is that wasn't only an internal tool but an outfacing tool at the same time. When Eric interviewed the guy from Wired Magazine, I think it was Doug Bowman, talking about why Wired Magazine did a big redesign; we were exchanging mail with our internal people saying "look at this cool stuff. Wouldn't you like to be cool like this?" So it was both an inside and outside tool. It was blogging before blogging really because we wanted to make a formal looking developer outreach site and Chipman and others continue that same formula. That was the way we did stuff.
Arun Ranganathan: Right. It's almost better when you air semi-dirty laundry because it actually causes more internal pressure. When they know that it could show up in business week or on CNet.
Jeremy: Thank you.
Kevin Lawver: You're welcome. Brian?
Brian: Do you have any specific recommendations for discussing, with back-end developers, using a technology like ASP.net that they are going to have to configure things and probably work longer in order to get the tool to produce valid HTML, if that will ever happen? As far as I can tell, right out of the box, when you're developing in ASP.net or other backed technologies; I don't mean to pick on them.
Kevin Lawver: Oh please do.
Brian: It takes a lot more thinking, saying "Ok, I've got to use a repeater here instead of a data list because a data list is going to put out a table and I don't need a table here?"
Kimberly Blessing: The way the process worked at AOL for a long time was that people were writing the front end and then handing that code over to the folks writing the back end, saying "Here, you need to integrate this." Sometimes we'd get the resulting product back and say "What happened to all of our markup?" It had been totally bastardized, attributes removed or not quoted any longer. And the response was "Why does that matter?"
Kevin Lawver: It's the same education process. You just have to show them the benefit. I don't know. I did back end stuff and it's just as hard to convince a hard-headed DBA as a hard-headed manager.
Brian: It seems like it might take ten times as long to code a particular element on the page using a repeater than it would with a data-lister.
Kevin Lawver: Right. If there's a huge technology investment, I'm sorry you have your work really cut out for you. Because it's much easier to change philosophical than it is to buy new hardware, software and completely change how you do things. Good luck with that.
Brian: [laughs]
Kimberly Blessing: It also depends on how close the various technical folks are. Our server administrators, back when I was on e-commerce, when they saw what we were doing with the code and how we were allowing them to reduce the number of servers that were hooked up for the e-commerce system. They were overjoyed. They were like "This is great, we have less work to do!" And of course they weren't telling their managers. They became an advocate for us in helping to convince the back end develops who saw the administrators as being more technical than the folks writing the front end.
Kevin Lawver: Eric, I think you're our last question.
Eric: Really? Well first of all, Steve, nice shirt.
Steven Chipman: Thank you.
Eric: I just wanted to share something that I learned working with a client who should probably remain nameless but let's just say that one of their goals would be to have their website be very lickable. [laughter] You can ask me later Kevin. I see you're interested. What they found was having teams compete in who could make their pages smaller really worked out well. I got some of the email forwarded and they were literally trash-talking each other "I got my page to be 60% smaller. Beat that!" That's a good way in large corporations, or small corporations with a lot of trash talking.
Kevin Lawver: We talked about that and we were afraid that it would turn ugly. We really didn't want that.
Eric: I suppose it helps if the teams like each other at some level. They seemed to. Either that or they were very competitive. It's something people might consider as friendly competition. Use prizes, bring food. Just a thought.
Kimberly Blessing: It's an excellent thought and really we did kind of do that because it was the interior proprietary stuff AOL was doing vs. web. When we first got the, as it's called on AOL, the main page of the e-commerce platform, shop at AOL. When we developed a web page that looked exactly like the small screen that AOL had natively but loaded in half the time, we were finally really breaking ground. People were like "Yeah, this web thing. Why are we still doing the Rainman thing?"
Arun Ranganathan: I guess that's one of the paradoxes of working at AOL for a longtime. Simultaneously, while we were working for Netscape, AOL's big flagship product didn't really even use web standards. It used a proprietary means of reaching the masses. That paradox is resolved. Mark, it felt really good what you said. I'm glad we're cool again or at least on our way to being cool again.
Kevin Lawver: Thank you for coming, we're out of time. Go out, kick some ass!
Steven Chipman: Smile everybody.