Journal tags: sxswi2012

I’ve been huffduffing talks from this year’s South by Southwest, revisiting some of the ones I saw and catching up with some of the ones I missed.

There are some really design and development resources in there that I didn’t get to see in person:

• Phil’s talk on Excessive Enhancement: JavaScript’s Dark Side,
• Samantha’s talk on Faster Design Decisions with Style Tiles,
• Josh’s talk on Tapworthy Touchscreen Design, and
• Scott’s talk on Why Mobile Apps Must Die.

One talk I did get to see was Andy’s CSS for Grown Ups: Maturing Best Practices.

It was excellent.

You can have a look through the slides.

He talks about different approaches to creating maintainable CSS for large-scale projects. He touches on naming conventions for classes, something that Nicolas Gallagher wrote about recently. And while he makes reference to SASS and Compass, Andy makes the compelling point that’s what more interesting than powerful tools is the arrival of powerful approaches like SMACSS and OOCSS.

Over and over again, Andy makes the point that we must think in terms of creating design systems, not simply styling individual pages—something that Paul has also spoken about. One of the most powerful tools for making that change in thinking is in the creation of style guides for the web and Paul has even created blog dedicated to the BBC’s style guide.

Andy referenced the BBC GEL style guide in his talk but pointed out that because it’s published as a PDF rather than markup, it isn’t as powerful as it could be—there’s inevitably a loss of signal when the patterns are translated into HTML and CSS. Someone from the BBC was in the audience, and in the Q and A portion, acknowledged that that was a really good point.

After the talk I got chatting with Lincoln Mongillo who worked on the recent responsive redesign of Starbucks.com. He mentioned that they created a markup and CSS style guide for the project. “You know what would be really cool?” I said. “If you published it!”

Here it is. It’s a comprehensive library of markup patterns; exactly the kind of resource that Anna wrote about in 24 Ways.

In my experience, creating a pattern library for any project is immensely valuable, whether you’re working in a team of two or a team of two hundred. I’ve found they work well as the next step after Style Tiles: a way of translating the visual vocabulary of a site into markup and CSS without getting bogged down in the specifics of page structure or layout (very handy for a Content First approach). The modularity of a pattern library enforces a healthy separation of concerns.

I’m really pleased to see more and more pattern libraries being made public. That’s one of the reasons why I shared my pattern primer and Dan shared his Pears theme for Wordpress:

Breaking interfaces down into patterns has been immensely helpful in learning and re-evaluating the best possible code to implement them.

But Pears isn’t about how I code these patterns—it’s a tool for creating your own.

I love that. These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

For that, I am very grateful.

If attending a web conference is like going to a concert, South by Southwest in Austin is like Glastonbury: a massive multi-track event where the people on stage aren’t as important as tracking down the friends you know are somewhere in the crowd.

An incredible amount of work goes into the event. When Jessica and I showed up in Austin last Thursday evening and headed straight to The Wholly Cow for a burger, there was a group of Southby volunteers at the next table, planning the next day’s activities like soldiers on the eve of battle. Make no mistake, South by Southwest is a triumph of planning and execution on a scale I can’t even begin to comprehend. I’m always amazed when I see Hugh wandering about looking cool as a cucumber—I’d be freaking out if it were me.

The interaction portion of South by Southwest has been getting bigger with each passing year. For a while this was a source of pride, then nervousness, and now …well, now it has become something quite different to what it once was. It’s not simply that the crowd is larger; the crowd is different.

Where once the core audience was made up of web-loving geeks, now the overwhelming majority of attendees are there to hawk their product/app/start-up by whatever means necessary. I tried to take a live-and-let-live attitude with those people, but it’s hard for me to maintain that attitude when I find them actively repulsive. I mean, honestly, it was like wading through a sea of spam.

I was chatting with Aaron in Austin airport afterwards and he said he was trying to take a City And The City approach to unseeing the douchebag world, but that’s difficult when they keep breaching by thrusting flyers and schwag into your face when you’re just trying to get into the Austin Convention Center (though you could potentially spend the entire event without ever entering that building, what with the panels spread out amongst many venues across town).

I did attend some great panels at South by Southwest, and I did have a great time meeting up with old friends and making new ones. But I felt like I had to work quite hard at it this year. I had a constant feeling of FOMO from all the talks I was missing and there were lots of friends who were also at the event that I didn’t even see once the whole time. So if you weren’t in Austin and you were watching from afar via Twitter, don’t worry: even the people who were at South by Southwest weren’t at South by Southwest.

Evan had a similar experience and I think he’s right about why there are so many desperate marketers showing up:

I think that’s largely Twitter’s fault; the company’s breakout at SxSW 2007 has made success at the event a Philosopher’s Stone for startups world-wide. Unfortunately, most of these folks have missed the subtle fact that Twitter wasn’t successful because it was at SxSW, but because it was useful and interesting to the kind of people who go to South by Southwest. The same goes for other South By success stories: Foursquare, Lanyrd. In other words: if you don’t appeal to that audience, dropping a trillion-dollar marketing bomb on downtown Austin for a week in March won’t make you Twitter. It’ll just make you poorer.

To be honest, I’m not sure I can justify another trip to South by Southwest if it means paying for an overpriced hotel room and wading through all the Conference Center crap to find the gems hidden within. But Evan points out the problem with simply giving up on the event:

South by Southwest has been a huge boon to the technology community. It deserves a better response than a sniffy adieu.

He’s right …but I’m not sure there’s anything that the event organisers (or the subset of attendees who aren’t meatspace spammers) can do about it. South by Southwest has become an unstoppable juggernaut.

And what rough beast, its hour come round at last, slouches towards Austin to be born?

Y’know, I’m okay with South by Southwest being a different kind of event now than it once was. I’m glad that it’s successful. And it’s not like there aren’t plenty of other excellent events for web geeks.

If I don’t end up returning to South by Southwest, I’d definitely miss it. And I would definitely miss Austin. I’m looking forward to going back to that most excellent town for An Event Apart in July—it will be my first time being there when it’s not South by Southwest.

An Event Apart, by the way, had an excellent one-page advert running on the back cover of the chunky South by Southwest printed program. It simply said: One Track.

South by Southwest has become a vast, sprawling festival with a preponderance of panels pitched at marketers, start-ups and people that use the words “social media” in their job title without irony. But there were also some great design and development talks if you looked for them.

Samantha gave a presentation on style tiles, which I unfortunately missed but I’ll be eagerly awaiting the release of the audio. I also missed some good meaty JavaScript talks but I did manage to make it along to Jen’s excellent introduction to HTML5 APIs.

Andy’s talk on CSS best practices was one of the best presentations I’ve ever seen. He did a fantastic job of tackling some really important topics. It’s a presentation (and a presenter) that deserves a wider audience, so if you’re involved in putting together the line-up for any front-end conferences, I highly recommend that you nab him.

Divya put together an absolutely killer panel called CSS.next, all about how CSS gets specced and shipped, and what’s coming down the line. All of the panelists were smart, articulate, and well-informed. The panel was very enlightening, as well as being thoroughly enjoyable.

And then there was the Browser Wars panel.

This is something of a SXSW tradition. Arun assembles a line-up of representatives from browser makers—Mozilla, Google, Microsoft, and Opera—and then peppers them with some hardball questions. Apple is invited to send a representative every year, and every year, Apple declines.

There was no shortage of contentious topics this year. The subject of Google Dart was raised (“Good luck with that,” said Brendan). There was also plenty of discussion about the recent DRM proposal submitted to the HTML working group. There was a disturbing level of agreement amongst all the panelists that some form of DRM for video was needed because, hey, that’s just the way things go…

As an aside, I must say I found the lack of imagination on display to be pretty disheartening. Two years ago, Chris was on the Browser Wars panel representing Microsoft, defending the EOT format because, hey, that’s just the way things go. Without some form of DRM, he argued, we couldn’t have fonts on the web. Well, the web found a way. Now Chris is representing Google but the argument remains the same. DRM, so the argument goes, is the only way we’ll get video on the web because that’s what the “rights holders” demand. And yet, if you are a photographer, no such special consideration is afforded to you. The img element has no DRM and people are managing just fine, thank you. Video, apparently, is a special case …just like fonts. ahem

Anyway…

The subject of vendor prefixes also came up. Specifically, the looming prospect of non-webkit browsers parsing -webkit prefixed properties was raised.

I saw a pattern amongst all three subjects: the DRM proposal, Dart, and browsers implementing another browser’s vendor prefix. All three proposals were made to address a genuine problem. The proposals all suffer from varying degrees of batshit craziness but they certainly galvanised a lot of discussion.

For example, Brendan said that while Google Dart may not stand a hope in hell of supplanting JavaScript, some of the ideas it contains may well end up influencing the development of ECMAScript.

Similarly, Mozilla’s plan for vendor-prefixing certainly caused all parties to admit the problem: the W3C was moving too slow; Apple should have submitted proprietary properties for standardisation sooner; Mozilla, Microsoft, and Opera should have been innovating faster; and web developers should have been treating vendor-prefixed properties as experimental features, not stable parts of a spec.

So the proposal to do something batshit crazy and implement -webkit-prefixed CSS properties has actually had some very positive effects …but there’s no reason to actually go ahead and do it!

I tried to make this point during the audience participation part of the panel, but it was like banging my head against a brick wall. Chaals kept repeating the problem case, but I wasn’t disputing the problem; I was trying to point out that the proposed solution wouldn’t fix the problem.

It was a classic case of the same kind of thinking we saw in the SOPA proposal:

1. Something must be done!
2. Implementing -webkit prefixes is something.
3. Something has been done.

The problem is that it won’t work. Adding “like Webkit” to the user-agent string will probably have much more of an effect and frankly, I don’t care if any of the browsers do that. At this point, a little bit more pissing into the bloated cesspool of user-agent strings is hardly going to matter. A browser’s user-agent string isn’t an identifier, it’s a reverse-chronological history of the web. Why not update the history booklet to include the current predilection amongst developers for Webkit browsers on mobile?

But implementing -webkit vendor prefixes? Pointless! If a developer is only building and testing their sites for one class of device or browser, simply implementing that browser’s prefixed CSS is just putting a band aid on a decapitation.

So I was kind of hoping that Mozilla would just come right out and say that maybe they wouldn’t actually go ahead and do this but hey, look at all the great discussion it generated (just like Dart, just like the DRM proposal). But sadly, no. Brendan categorically stated that the proposal was not presented in order to foment discussion. And in follow-up tweets, he wrote that he actually expected it to level the mobile browser playing field. That’s an admirably optimistic viewpoint but it’s sadly self-delusional.

And what will happen when implementing -webkit prefixes fails to level the playing field? We’ll be left with deliberately broken browsers.

Once something ships in a browser, it’s very, very hard to ever remove it. During the Dart discussion, Chris talked about the possibility of removing Dart from Chrome if developers don’t take to it. Turning to the Microsoft representative he asked rhetorically, “I mean, do you guys still ship VBScript?”

The answer?

“Yes.”