Posts in the Standards Category

I’d like to tell you a little story, if I may, from way, way back in 2002.  (The exact date is lost to the mists of time, but the year is pretty solid.)  Like a lot of stories, it’s little bit long; but unlike some stories, it’s true.

As the engineering staff at Netscape prepared a new release of Mozilla, the browser off which we branched Navigator, those of us in the Technology Evangelism/Developer Support (TEDS) team were testing it against high-ranked and partner sites.  On a few of those sites, we discovered that layouts were breaking apart.  In one case, it did so quite severely.

It didn’t take much to see that the problem was with sliced images in layout tables.  For some reason, on some sites they were getting pushed apart.  After a bit of digging, we realized the reason: the Gecko engine had updated its line-layout model to be more compliant with the CSS specification.  Now images always sat on the baseline (unless otherwise directed) and the descender space was always preserved.

This was pretty new in browserdom, because every other browser did what browsers had always done: shrink-wrapped table cells to an image if there was no other cell content.  The only problem was that behavior was wrong.  Fixing the flaws in the CSS implementation in Gecko had broken these sites’ layouts.  That is, it broke them in standards mode.  In quirks mode, Gecko rolled its behavior back to the old days and did the shrink-wrap thing.

We got in touch with the web team at one of the affected sites, a very prominent social networking site (of a sort) of the day, and explained the situation.  We already knew they couldn’t change their DOCTYPE to trigger quirks mode, because that would break other things they were doing.  We couldn’t offer them a simple CSS fix like td img {vertical-align: bottom;}, because their whole layout was in tables and that would throw off the placement of all their images, not just the sliced ones.  All we could offer was an explanation of the problem and to recommend they class all of their sliced images and use CSS to bottom them out, with assurances that this would cause no change in other browsers.

Their response was, in effect:  “No.  This is your problem.  Every other browser gets this right, and we’re not mucking around in our templates and adding classes all over just because you broke something.”

The truth, of course, was that we were actually fixing something, and every other browser got this wrong.  The truth was not relevant to our problem.  It seemed we had a choice: we could back out the improvement to our handling of the CSS specification; or we could break the site and all the other sites like it, which at the time were many.  Neither was really palatable.  And word was we could not ship without fixing this problem, whether by getting the site updated or the browser changed.  Those were the options.

Let me reiterate the situation we faced.  We:

1. Had improved standards support in the browser, and then
2. Found sites whose layouts broke as a result
3. Whose developers point-blank refused to alter their sites
4. And we had to fix the problem

We couldn’t back out the improvement; it affected all text displayed in the browser and touched too many other things.  We couldn’t make the site’s web team change anything, no matter how many times we told them this was part of the advance of web standards and better browser behavior.  Two roads diverged in a yellow web, and we could choose neither.

So we found a third way: “almost standards” mode, a companion to the usual modes of quirks and standards.  Yes, this is the reason why “almost standards” mode exists.  If I remember the internal argument properly, its existence is largely my fault; so to everyone who’s had to implement an “almost standards” mode in a non-Gecko browser in order to mirror what we did, I’m sorry.

We made “almost standards” mode apply to the DOCTYPE found on the offending site—an XHTML DOCTYPE, I should point out.  While we were at it, we rolled in IBM’s custom DTD.  They were using it make their site validate while doing all kinds of HTML-invalid stuff, and they were experiencing the same layout problem.  And lo: a third layout mode was born.  All because some sites were badly done and would not update to accommodate our improvements.  We did it so as not to break a small (but popular) portion of the web while we advanced our standards support.

(By the way, it was this very same incident that gave birth to the article “Images, Tables, and Mysterious Gaps“.)

Now take that situation and multiply it by a few orders of magnitude, and you get an idea of what the IE team faces.  It’s right where we were at Netscape: caught between our past mistakes and a site’s refusal to accommodate our desire to improve support for open standards.

Some have said that Microsoft is in a unique position to take leadership and spread the news of improved standards and updating old sites to its customers.  That’s true.  But what happens when a multi-billion dollar partner corporation refuses to update and demands, under the terms of its very large service contract and its very steep penalty clauses, that a new version of IE not break (for whatever value of “break” you like) its corporate intranet, or its public e-commerce site?  It only takes one to create a pretty large roadblock.

For all we did in publishing great content to DevEdge, proactively helping sites to update their markup and CSS and JS to work with Gecko (while not breaking in other browsers), and helping guide the improvement of standards support in Gecko, we could not overcome this obstacle.  We had to work around it.

Looking back on it now, it’s likely this experience subconsciously predisposed me to eventually accept the version targeting proposal, because in a fairly substantial way, it’s what we did to Mozilla under similar conditions.  We just did it in a much more obscure and ultimately fragile manner, tying it to certain DOCTYPEs instead of some more reliable anchor.  If we could have given that site (all those sites) an easy way to say “render like Mozilla 0.9” (or whatever) at the top of every page, or in the server headers, they might have taken it.

But had we offered and they refused, putting us back to the choice of backing out the improvements or changing the browser, would we have set things up to default to the specific, known version of Mozilla instead of the latest and greatest?  The idealist in me likes to think not.  The pragmatist in me nods yes.  What else could we have done in that circumstance?  Shipped a browser that broke a top-ten site on the theory that once it was in the wild, they’d acquiesce?  Even knowing that this would noticeably and, in a few cases, seriously degrade the browsing experience for our users?  No.  We’d have shipped without the CSS improvement, or we’d have put in the targeting with the wrong default.  We didn’t have version targeting, but we still made the same choice, only we hinged it on the DOCTYPE.

A short-term fix for a short-term problem: yes.  Yet had we not done it, how long would Netscape/Mozilla’s standards support have suffered, waiting for the day that we could add that improvement back in without breaking too many sites that too many people would notice?  Years, possibly.  So we put in a badly implemented type of version targeting, which allowed us to improve our standards support more quickly than we otherwise would have, and it has been with us for the more than half a decade since.

So maybe I’m more sympathetic to the IE predicament and their proposed solution because I’ve been there and done it already.  Not to nearly the same degree, but the dilemma seemed no less daunting for all the difference in scale.  It’s something worth keeping in mind while evaluating what I’ve said on this topic, and whatever I will say in the future.

• Almost Target was published on Thursday, January 24th, 2008.
• It was assigned to the Browsers, History, and Standards categories.
• There have been eighty-two replies.

So yesterday was interesting.  In a whole lot of ways.

As I expected, there were some widely varied reactions (there’s a good list over at Digital Web, if you’d like to taste the rainbow) and many of them were in opposition to the whole idea.  The opposition was fine, but the tone taken by many was not.  Even though I expected some flaming, I admit I really didn’t expect the overall tone to be so vitriolic, and I found it to be profoundly depressing.  I’m not talking to everyone here, but it still needs to be said: if you feel the need to impugn the integrity or intelligence of another person to oppose an idea, you’re undercutting yourself, not your target nor the thing you oppose.  It’s the dialectical equivalent of “considered harmful“.

A number of people said things to the effect of what Roger said: “explain why we’re wrong to oppose this”.  That I cannot do.  I was hoping for opposition, because that’s the only way to really test an idea.  I’m not so arrogant as to think that I alone can account for every variable and forecast the eventual outcome.  I can only explain, as I tried to do, why I think it’s a good idea, and listen to the reasoning of those who think it’s a bad idea.

No explanation is ever complete, of course, so here’s some followup.

I suspect that a good deal of the emotional objection springs from a perception that the proposal is to require all browsers to implement targeting.  Not at all.  Please be clear on this: nobody is saying this should be required in any browser.  It can be interpreted as a requirement for authors, which is a separate issue, and I think one that’s quickly becoming negated as people work through the details.  Not necessarily negated in a way Microsoft would like, but that’s really their problem.  (See, for example, Sam Ruby’s solution.)

One very likely outcome here is that IE does this and all the other browsers don’t.  In a lot of ways, I’d be happiest with that outcome, because it would give us the opportunity to evaluate both approaches in parallel.  Personally, I think other browsers should adopt the same mechanism only if they feel they need it.  So far, they’ve indicated that they don’t.  Fair enough.  IE gets to try its hand at maintaining multiple internal versions, and everyone else can continue as usual.

In that vein, I have to admit that I don’t understand the assertions that this will make life harder on other browsers, that they’ll have to support all the various rendering modes in IE.whatever.  Can someone explain that to me, please?  I’m not saying the assertion is wrong.  I’m saying I don’t understand why that would be the end result.

At a wider level, I think a lot of people are discounting the fact that version targeting is absolutely nothing new in the standards world, let alone the web development world.  Conditional comments, CSS hacks, and the DOCTYPE switch itself are all examples of version targeting.  When I write *+html… I’m doing it because I know IE7, and IE7 alone (at least for now), will see the declarations in that rule.  I did exactly that just the other day, in fact.  There’s a whole sub-set of the current CSS corpus based on figuring out parser bugs to exploit into hacks that are used to feed rules to specific browsers or specific versions of browsers.  We’ve been doing this for years.  I mean, okay, if you’ve recently done client work where you didn’t need any form of detection at all—as in, you quite intentionally used none of the things I just listed—then you can exempt yourself from the “we” in that statement; furthermore, my hat is off to you.  Seriously.  Because I can’t remember the last time I was able to avoid using at least one or two CSS hacks in a project in order to deal with browser inconsistencies.

I’m not going to claim that these mechanisms are universally broken.  In fact, I believe exactly the opposite: they’ve long since proven their utility in an imperfect world.  (The perfect world being the one where all browsers implement all standards correctly and no form of browser detection is ever needed.)  That alone made me reconsider the targeting proposal in a whole new light.

The handling of JavaScript libraries in a world where the pages calling the libraries will determine how the JS is interpreted—that’s definitely something I hadn’t considered.  As I understand it, the problem case is one where a JS library that uses (say) IE9 features is loaded into a page that triggers the IE7 engine.  The library would need to preserve backward compatibility with all the IE versions that could be used.

But isn’t that already the case?  Every library whose source I’ve studied has all kinds of detection, whether it’s feature or browser detection, in order to work with multiple browsers.  I would think that under version targeting, the same thing would be necessary: you do feature detection and work accordingly.  Again, it’s entirely possible I missed something there, so feel free to let me know what it was.

As for the proposed default behavior, where no X-UA-Compatible information gets you the IE7 rendering, I can’t defend that, nor do I have any wish to defend it.  I tried for most of an hour to convince a member of the IE team that the default behavior should be “latest”, not “IE7”, and was unable to make a sufficiently persuasive case—by which I mean a case that overcame the (perceived) needs of the IE team.  My hope is that someone will succeed where I failed.

Because yes, I too want to be able to leave off the meta, leave my server’s HTTP headers alone, and still get the latest and greatest in standards support from IE.whatever.  That’s how browsers have always acted, and it’s what I’m used to handling.  If someone can convince the IE team that doing this would be in their (and their company’s) best interests, then we’ll all be in your debt.  With the growing collection of workarounds, I think it might be possible to convince them that the default behavior we want is going to quickly become the de facto standard, they should go with the flow and make it the default internally.  I don’t know if that will work, but it’s worth a try.

It has to be realized that this may well be the only way for IE to advance its standards support in a reasonable time frame, or at all.  Version targets let them avoid breaking existing sites, especially intranet sites, while fixing and adding their DOM, CSS, and other implementations.  That has to be understood and accepted if the discussion is to be anything more than people talking past each other.  Within the world of IE, they must have a way to uphold backwards compatibility with sites developed under older versions of IE.  Without it, they will largely stop fixing bugs they discover in their standards support.  It really does come down to that.  The fact that their current situation is their own fault is not really relevant to the topic of moving forward.  This is a way forward for IE, just as the DOCTYPE switch was a way forward for a number of browsers (including IE) back at the turn of the millennium.  It may be the best way.  If there’s a better way for them to meet that need, then I absolutely want to hear it.  But remember, “let old sites break” is a non-starter.  You might as well say “let old sites not load at all in any browser”.

At any rate, I’m opening comments on this post, and I do hope there will be reasoned discussion of the pros and cons of version targeting.  As always, I’m going to enforce civility in the discussion.  Disagreement, opposition, objection: all fine, and in fact encouraged.  Flaming: not fine, and will be deleted.

• Version Two was published on Wednesday, January 23rd, 2008.
• It was assigned to the Browsers and Standards categories.
• There have been ninety-four replies.

You probably don’t need me to tell you about today’s issue of A List Apart, but just in case you hit this entry in your feed reader before reaching the ALA feed, head on over.  If you have anything to do with web development, there’s news of a coming change that you absolutely need to read.

I know there will be many people who disagree with my take on version targeting.  As did I, at first.  Originally I wasn’t even going to be part of this ALA issue but as I argued with Aaron about it on the ALA editorial board and started to shift my perspective, we realized that having someone document that thinking process would be valuable.  So I did.

Already I’ve seen a lot of negative reactions to the idea, and they remind me of my initial reactions.  That’s not to say that my views are more advanced, nor that everyone will eventually come to the same way of thinking.  It’s entirely possible that after due rational consideration, many people will come to the conclusion exactly opposite my own.  I still thought it might be useful to share my thoughts on the matter as someone who has been concerned about browser compatibility and standards advancement for a very long time now.

Comments are closed here, but discussion is open at ALA.

Update: I wanted to point to some other material about this topic.  I’ll probably keep updating this as time goes on.

• Compatibility and IE8 — a post by Chris Wilson about the challenges faced by browsers when advancing standards, and the particular situation experienced in the IE7 deployment.  You don’t have to agree with the conclusions, but understanding the problem is important.

• The versioning switch is not a browser detect — this is vitally important to any hope of useful debate on this topic.  I tried to clearly make the same point in my ALA article, but reiteration doesn’t hurt.

• Broken — Jeremy objects to the default behavior.  I actually agree with him, and made that case at length with a member of the IE team.  I couldn’t make what I wanted square with their requirements, and came to see that I couldn’t, and was deeply saddened by it.  I sincerely hope that Jeremy, or indeed anyone, can succeed where I failed.

• That Red-headed Monster Next to You? Yeah, that’s Anger — no, I didn’t link this because of the hair-color reference.  I’ve been deeply disheartened by the overall tenor of the reaction.  Disagreement is fine, in fact welcomed; but the level of vitriol, name-calling, and outright personal attacks came as a rude and unwelcome surprise.

• Targeted was published on Tuesday, January 22nd, 2008.
• It was assigned to the Browsers, Standards, and Writing categories.
• There have been nine replies.

Opera fired a broadside at Microsoft today.  In accompaniment, Håkon Lie posted “an open letter to the Web community” in which he says:

To those of you who build and shape the sites and services we use everyday — and who will create those in the future — I ask for your support. You will be the ones who ultimately benefit by having a Web that works seamlessly and effortlessly across devices, browsers and is equally open to everyone. That new day is just over the horizon…

Yes, it is.  Or maybe it was, until this happened.

Look, the time to file this motion and make this appeal was in 2005, when Internet Explorer had been dead in the water for years and it was genuinely holding back web design.  Then there’d have been a case to make.  When IE7 came out in late 2006, it wasn’t a great leap forward for web development, but it did bring IE more or less in line with where browsers were at the time—which was, frankly, a pretty large leap.  After all, they were doing five years of catch-up with a pretty small team.  Now we have IE8 in development, and there is a real chance that it could push standards support forward in a significant way.

But not if developing the browser becomes more of a liability than just walking away from it altogether.

They can’t do that, you say?  Oh, but they can, and at a corporate level would probably love nothing more than to do so.  With Silverlight, there’s the opportunity to create browser-like internet applications that support no open standards, answer to no external specifications.  The IE team would likely disagree strongly with such a course, but cut funding to the team and there’s little they can do to change it.  If you think web development is horrible now, how about a future where there literally are entirely different browsers to support?  Or a future where the open web is largely shriveled and dead thanks to wide-scale abandonment by the Windows community?

I am not advocating that we hold ourselves hostage to what Microsoft, or indeed any company, might try to do.  We’re already held hostage enough to the glacial pace of the W3C (and Mr. Clarke has some ideas on how to fix that).  What I’m advocating is that rather than attacking the laggard right when he’s showing promise of catching up and being part of the team again, it might be better to help him along, maybe even say a few words of encouragement.  Unless, that is, this attack springs out of some sort of perceived threat—in which case, just say so, and don’t use web standards as a fig leaf.

I wondered, upon having this instinctive reaction unfold, whether I was completely off my rocker.  But then I asked myself what I’d think if, say, Opera or Microsoft or anyone had pulled a similar move against Netscape circa 2001, when Netscape 6.0 was out and causing widespread grief while the programmers struggled to update and fix its standards support.  The answer came back the same.

It’s the wrong move at the wrong time, sending precisely the wrong signal to Microsoft about the importance of participating in development and support of open standards, and I can only hope that it comes to a quiet and unheralded end.

• Bad Timing was published on Thursday, December 13th, 2007.
• It was assigned to the Browsers and Standards categories.
• There have been sixty-two replies.

“This page best viewed in…”

If that phrase doesn’t provoke a shudder of horror and loathing, it should.  It’s the battle cry of the Browser Wars, those terrible and ultimately futile years at the end of the last milennium.  It’s the rallying cry of those who would take the open ubiquity of the web and fragment it into a collection of gated communities, where entrance to each is predicated on running a specific browser.

“Your browser is not compatible and must be upgraded…”

All too often, because developers are too fearful or prideful or just plain lazy, they put up unnecessary barriers to entrance.  They prevent people from using their sites based on choice of browser.  Of course there are situations where the experience will be different—nobody expects Netscape 4 users to be able to see all 2007’s pretty CSS effects, just like table-based sites look beyond bizarre in Mosaic.  That’s no excuse for sites that intentionally lock users out just because their choice of browser doesn’t line up with the developer’s expectations.  It’s regressive, short-sighted, and just plain unprofessional.

“This site is for iPhone users only.”

STOP IT.  Stop it right now.

The fact that optimizing pages for an iPhone makes the development of such specialized pages attractive in no way excuses lockout of other users.  I might be willing to entertain the argument if the iPhone’s browser were some specialized non-web contraption.  It’s not.  It’s a full-fledged XHTML+CSS+DOM browser that happens to lag a bit in some implementation areas and won’t run some plugins.

Besides, if you’ve developed a version of your site (or application or whatever) that works well on the iPhone, then why in the name of Tim Berners-Lee would you deny other people that optimized experience?  You might find that they prefer to interact with the site that way no matter what platform they’re using.  You might find that you don’t need a separate iPhone version after all.  The iPhoned version might be the only version you need.

Designers will argue that pages optimized for the iPhone screen will look bad on a desktop browser.  Maybe, and maybe not, but stop preventing your users from making that decision for themselves.  Nobody says you have to convert your whole site to be iPhoney.  But your lockout of non-iPhone users is worse than rude.  It’s stupid.

We finally learned, after much sweat and a fair number of tears, that “best viewed in” is a fool’s errand.  Are we so eager to rush back into that morass and fight the war all over again?

Please.  Just stop.

• The Veteran’s Charge was published on Wednesday, August 8th, 2007.
• It was assigned to the Browsers, Rants, Standards, and Web categories.
• There have been eighty-nine replies.

Among all the other stuff this past week, I let something slip off the radar: an interview with me over at the Lunartics blog.  The interview was conducted via e-mail by Amy Armitage, who I briefly met last year at the Webmaster Jam Session in Dallas.  It’s not your usual “why is CSS important” kind of interview; Amy likes to keep things fun while still covering serious questions.  It’s definitely worth a read.

It also scoops news of a development I’ve never gotten around to mentioning: in October 2006, I was inducted as a member of the International Academy of Digital Arts and Sciences.  It’s a pretty incredible honor, given that it’s an invitation-only body of 500 members including “David Bowie, Virgin Group founder Richard Branson, Internet inventor and Google Chief Internet Evangelist Vinton Cerf, ‘Simpsons’ creator Matt Groening, Real Networks CEO Rob Glaser, and fashion designer Max Azria”.  The fact that my name appears on the same list as those people is jaw-dropping enough.  To me, it wasn’t the most stunning part by a long mile.

I’ll admit, though I’d heard of The Webbys, I assumed the IADAS was one of those name-collector groups, like those “Who’s Who in America” books where you pay to be listed.  Instead, I found that the IADAS levies no membership fees, and I was deeply surprised and pleased to discover that they invite people based on their actual qualifications.  How do I know?  Because my welcoming letter didn’t praise my web design work.  Instead, it cited my “dedication to promoting Web standards”, my “international recognition on the topics of HTML and CSS”, and proclaims that I’ve “helped inform excellence and efficiency on the Web”.

Yes, the text string “HTML and CSS” was actually in the letter.

It’s a little difficult to express how important this recognition is to me.  See, most of the time, I’m introduced and perceived as an influential web designer, which is frankly insulting to actual web designers everywhere.  If you aren’t reading this post via RSS, look around.  Does this look like influential web design?  Hell no.  At best, we can call meyerweb’s design minimalist and maybe—maybe—possessed of a certain elegance.  And it only took me five years and ripping off ideas from Khoi Vinh to get here!

But I’ve never claimed to be a designer.  I think the perception that I am one arises because I get linked to from people who really are designers.  I’ve always claimed to be a communicator.  I’m someone who’s done his best to explain, promote, and advance the technologies that let designers do their work.  I’ve invested tons of time and effort into making good web design easier without sacrificing clean and semantic markup.  I wouldn’t say that work is done by any stretch, but there’s been a lot of progress.  Sometimes I forget just how much.

And so, to be invited to join the IADAS not for what I’m usually thought to be, but actually for who I am—it’s an indescribable feeling.  A fantastically good one, certainly!  But not one I could describe no matter how many words I threw at the problem.

It’s a delicious irony, and I do so love my irony:  my powers of communication fail me when I wish to express my feelings over being honored for my communicating, over all those years, my love of the web and my passion for getting it right and the inner workings of how to make that happen.

But I can at least say this:

Thank you.  Thank you for coming to read my posts, for reading my books and articles, for listening to me speak.  Thank you for being the other end of the conversation.  Thank you for being open to what I have to say, and for responding with your insights and perspectives, all of which have changed me in untold ways.  Thank you for making everything I’ve done and said and written about the web worth far more than what I put into it.

Thank you for making this honor possible.

• I’d Like To Thank The Academy… was published on Saturday, February 3rd, 2007.
• It was assigned to the CSS, Interviews, Personal, Standards, and Web categories.
• There have been eight replies.

Let’s cut right to the chase: An Event Apart is growing to become a two-day conference.  We’ll have at least four two-day shows in 2007; see the announcement for more details.

The first show, in Boston, is already confirmed.  We’ve signed the contracts and everything.  Registration isn’t open yet, and won’t be until early January, so you have plenty of time to get the budget approval and be ready to sign up as soon as seats go on sale.  Like I said, early January.  A more specific date will most likely emerge near the end of December.

You’re going to want to get geared up for this, because the speaker list is flat-out amazing:

• Steve Krug (that’s right, Mr. “Don’t Make Me Think!” himself!)
• Dan Cederholm
• Molly Holzschlag
• Andrew Kirkpatrick
• Cameron Moll
• Ethan Marcotte
• Jason Santa Maria
• Eric Meyer
• Jeffrey Zeldman

Honestly, I can hardly wait to hear everyone on the list.  Well, except me.  I hear me all the time.  But everyone else?  Total gold!

Note that this is the speaker list for Boston; the other cities will have different lineups.  Obviously not 100% different, but I expect each one will be fairly different.  Still awesome, of course.

So what are we going to cover?  Best practices.  That’s really what it’s all about, whether we’re dissecting code or talking about usability or whatever.  Jeffrey and I are going to push every last speaker to pack their talks with insights regarding the current state of the art in their respective fields.  We’re going to push ourselves twice as hard to do the same.  What we want is to have everyone walk out saying, “Now I know where things are and where they’re going”.

The size of the event will increase along with the days, from our usual 100 seats to 400 or so.  AEA is now, as I said, a full-on conference.  It’s a big step, but it’s the right one.  The most common feedback from this year’s attendees was that one day just wasn’t enough, and looking back, we have to agree.  That’s especially true given that the feedback from our only two-day event of 2006 indicated that people really liked the length and the amount of information they got out of it.  So it’s time to step up.

Even from this side of the Atlantic, I hear the cries of our European brethren.  When will we visit your worthy shores?  It’s a fair question.  It could happen in 2007, or it might not be until 2008.  How’s that for precise?  I’m sorry, but I can’t do any better than that right now.  Our original plan had been to run a year’s worth of events to shake out the bugs and then look to other lands.  Instead, we discovered that the events were too small, temporally speaking, and needed to be dramatically revamped.

So now we need to run a few of the larger events to get the bugs worked out before going afield.  The good news is that a lot of the bugs are already smoothed out.  We just need to get a handle on the larger format, which has a whole new set of requirements.

So we’ll be at the Boston Marriott Copley Place at the end of March.  I hope you’ll be there too!  (And if you are going to be there and are a member at Upcoming, add yourself to the listing.  Otherwise, feel free to leave a comment here.  Thanks!)

• AEA To Grow in 2007 was published on Wednesday, November 15th, 2006.
• It was assigned to the An Event Apart, Speaking, and Standards categories.
• There have been seventeen replies.

When it isn’t buried under a flood tide of web geeks, band groupies, and filmgoers, Austin is a nice little town.

Or maybe it’s just a nice little downtown; thanks to a visit with Angela and Dan, I found that the greater Austin area is a good deal larger and more urban than I’d realized, not to mention growing at a rapid clip.  At any rate, being there for An Event Apart Austin was markedly different than the SXSW experience (in which I’ll once again be partaking, come March) just by dint of not being nearly so noisy.

While we didn’t contribute too much noise to the area, I fervently hope that we added a whole lot of signal.  I know that from my spot on the charmingly petite stage at the Alamo Drafthouse Downtown, the people in the audience really seemed to be enjoying themselves, and I at least felt like I was communicating well.  I think the other speakers did too, so hopefully they got the same feeling.

Part of that, without question, was due to just how friendly and welcoming the audience was.  We had a few glitches here and there, but so far as I could tell, nobody let it get them down.  As we said to ourselves a few times, “When you choose quirky venues, you get quirk”.  I still really enjoy putting on events in not-the-usual-suspects places like the Alamo, and I’ll miss that aspect of AEA when it grows larger, but it’s definitely the case that you take your chances at a smaller venue.  I think we did well at the Alamo, and several attendees mentioned how cool it was to attend an event there.  I’m glad we picked it.

It’s still a gamble, though, and after a year of AEAs, I understand better than ever why so many conferences and other events are held in hotel ballrooms.  It may be bland and a little soulless, but as a presenter, you know they’ve done it all a thousand times before.  You know they can handle any routine problem, and in fact have.  It’s comforting.  You give up charm and funkiness, but in return you get stability.

I think there’s an analogy to dating in there somewhere, but I’m not going to pursue it.

After we were all done with the speechifying, the fine folks at Knowbility threw an after-party on the upstairs terrace of The Belmont, and a good time was had by all, what with the open bar and all.  I even got to meet and talk with Jim Thatcher, the man responsible for PCSAID, one of the first screen readers.

If you’re wondering what it all looked like, or if you were there and want to relive the moments, there’s (as ever) a Flickr pool for your perusal.  I threw in a few pictures of my own, including one for those of you who’ve ever wondered about the view from the stage.  The Austin Flickr pool even has, somewhere in its depths, a picture of me being a naughty boy.  Find it if you can!

All in all, the folks in Austin made it a great end to the 2006 AEA season, so thanks, y’all!  I always like to finish on a high note.  We’re going to take a little break in the AEA schedule while the event gets retooled and expanded.  We haven’t officially announced the next show, but I’ll let you in on a little secret, just between us: it looks to be in Boston at the end of March 2007, it’ll be two days long, and I already want to see and hear our lineup of speakers.  More when we have official word, which hopefully should come within the next week or so.

• Austin’s Powers was published on Thursday, November 9th, 2006.
• It was assigned to the An Event Apart, Speaking, and Standards categories.
• There has been one reply.