A Day Apart Seattle – my thoughts on the workshop

Last week, I posted my thoughts on Day 1 of An Even Apart  (Seattle). I had fully planned on writing on both day 2 & the 3rd-day workshop, but after somehow losing a longish post to the ether, am skipping day 2. Suffice to say, the quality of the talks continued, as well as the laser-like focus on what can be accomplished with HTML5 and CSS3.

The A Day Apart Workshop was my primary reason for attending the conference. I wanted some hands-on learning & experimentation with these new tools that I had been unable to play with much. I have seen both Jeremy Keith & Dan Cederholm speak previously, so knew they would be good. And they were good. In fact, I would argue that the only thing that made this workshop worthwhile in the end was the quality of the presenters, who overcame everything to actually deliver quality.

This was the first A Day Apart put on by the AEA folks, so I expected it to not be perfect. But I did expect more. I’m certain that the next iteration will improve slightly on this one, and so on and so forth. But let me list my complaints, with some hopefully helpful critique:

  • Size of workshop: There were simply too many attendees in one room. It meant, for the most part, that it was hard to carry on a Q&A thread, because you don’t want to take up everyone else’s time & B, radically changed the possibilities of how run the workshop. To fix, I’d recommend a)lessening the number of spaces available and b)split the audience into 2 groups. Group A would get presenter #1 in the AM, presenter #2 in the PM. Group B would get it in reverse. Yes, this would double the work-load for the speakers – but I think would vastly enhance the experience for the attendees.
  • Format of workshop: The workshops were really just extended seminars – not so much a workshop.  While Jeremy’s seminar & workshop topics were different, Dan was talking about CSS3 in both, so his workshop felt like an extension of his earlier seminar. Jeremy had us guess the definitions of elements from the HTML 5 spec, and actually work that out. The result? I remember those definitions more than virtually anything else. Because I got to actually interact with the material. So here’s my suggestion to fix this: Each workshop was divided into 3 parts (if I recall correctly). If, let’s say, 10 minutes was cut out each (maybe even 20 minutes) and replace with a related exercise for the audience to do, suddenly the interaction with the material would increase greatly, and, I suspect, both people’s comprehension & retention of the material. If, in addition to 10 minutes of homework, there was schedule in 10 minutes for post-homework Q&A, that provides a nice way to summarize each content block.
  • Density of Material: The material-to-time ratio was way off, which meant we raced through the material. Either cover less or make the workshop longer. Both spent a long time on the history of the material – this was useful, but could likely have been done quicker, given the quality of the rest of the meat they were delivering.
  • Related Assets/sample code: We were all given a book with all the slides printed and bound into it. This is a great reference. But an online wiki, perhaps specific to the course, that was setup by the creators, but, going forward, be looked at, edited, updated by the attendees would be awesome. If a laptop was required (given the audience, I don’t think that’s an unreasonable request) and we were provided links to download some source code, we could then, in the workshop, very quickly build a site each, to see the material in action ourselves – this would work great with the ’10 minutes of homework per section’ model – you just keep building on. This has been, more or less, the standard for programming workshops I’ve attended. For me, this is likely the biggest miss.

Despite everything I’ve written above, I do feel that I came out that workshop with a better understanding of the two tools I went into the workshop wanting to learn. As I said above, this is almost entirely due to the quality of the speakers, not the format of the workshop itself. If there was to be another A Day Apart at a future conference, on a topic of interest to me, I would certainly consider attending it again. But while it was OK, it could have been great.

Update (2010-4-12): I had initially remarked that both workshops felt like extensions of the seminar. Jeremy, thankfully, corrected me that his seminar and workshops were quite different. My apologies.

An Event Apart Seattle (2010) – Day 1

I spent the first 3 days this week at An Event Apart (Seattle). This is a conference that I’d been wanting to attend since its inception, but somehow never actually made it down to one. I was really looking forward to a few days of self-affirming web-geekery. And that respect, I wasn’t disappointed.

I don’t know the process by which An Event Apart selects their speakers, but whatever it is, it is good. From start to finish, the quality of the presentations were excellent – even those whose content I wasn’t particularly interested in. Jeffrey Zeldman got us started in fine form, with a talk, essentially, about mistakes that would be good to avoid in running a studio. Having been running a shop (or studio) for the past 7 years, this was of very little interest to me – I’ve made those same mistakes previously, I’ve come to many of the same conclusions, I’d offer the same advice to anyone wanting to strike out on their own. But! I still thoroughly enjoyed it. A light hors d’oeuvre before the meaty sessions that followed. He’s a great speaker, which made this otherwise too-low-level talk appreciable by all.

Of all the talks, Nicole Sullivan‘s, who followed next, was the least inspiring. It fell between two worlds for me. She was talking about object-oriented CSS. Given her background, I was hoping for a super-nerdy, intense look at site-speed optimization & whatnot. We got a little bit of that – but not with the detail I’d like, and then the second-half of her talk was spent looking at her wish-list for things to be included in future CSS spec. So, not even actual proposed spec. Things that she proposes should be in proposed spec that I might get to use in bleeding-edge browsers 3-4 years from now and actual projects a decade or so in the future. Which felt like a waste of my time, to be honest. So, while I’m down on her talk, her answers in the brief Q&A were great and I’d love to hear her do a “developer” talk, rather than a “designer” talk, which this seemed to be.

Dan Cederholm talked CSS3, and gave some nice tips & tricks. His presentations are fantastic – but I’ll talk more about him later. Luke Wroblweski gave the talk that I wish every designer in the world could hear. Titled “Mobile First!”, I think Jeffrey Zelman summed it up best: “Luke Wroblewski’s extraordinary “Mobile First” presentation changed the way I think about web design”. It was compelling, well-backed-up with samples, and, perhaps best of all, seemed very easy to implement.

Aaron Walter‘s talk ‘Learning To Love Humans—Emotional Interface Design’ was funny, humble  and very very smart – all about how to create an emotional response to design, and moving beyond the idea that functional is the goal (paraphrasing Aaron to sum it up: You never hear a chef say ‘taste this, it’s edible!’ so why should a designer).

If you’ve never heard Jared Spool talk about usability, design & process, chances are you’re doing it wrong. His insights are incredible. His talk here was about the anatomy of a design decision – what ‘kind’ of design to teams do, how they arrive at that process, and what effect it has both on productivity and on end-user experience. The 101-take: Experience is what happens in the space between actions. His talk, to me, nicely summed the internal conflict that makes Pencilneck Software work so well. I am, by default, an intuitive developer. I rely on tips, tricks, experience and instinct to guide me through what I do. Jeff, by contrast, is a firm believer in process & methodology to get things done right. Where we meet in the middle is why we are successful where lots of other firms have failed, I feel – and Jared Spool really captured both the differences in approach and how they each affect teams & workflow.