Posts Tagged ‘conferences’

Getting on stage at HTML5 Dev Conf

My friend Bill Fisher did me a big favor back in January.

“I had lunch with Dave Nugent of the HTML5 Developer Conference, and mentioned you as a possible speaker. Go on and contact him with the subject of your presentation!”

Gee, thanks, Bill! Uh, I think…

At that moment my career as presenter had included a couple of CSS workshops and my fifth-grade monologue about Pre-Cambrian fossils. When I pinged Dave, it was in a state of great anxiety: I wasn’t a performer. I didn’t know how to sing, do magic tricks, impressions. I sure as heck didn’t know, really, how to give a technical presentation to a room full of developers who’d paid to see me do something besides fall into shrieking glossolalia.

My crash course in technical presenting

Adapt to your own needs:

  • Read about presenting in general
  • Read about technical presentation in particular

    Those starting this process today can gain from Rebecca Grenier’s How I Wrote my First Technical Presentation as well.

  • Start fussing over slides

    I thought I’d go all Reveal or Prezy at this, you know, HTML5 conference, but I realized that of all the burdens to assume on the way to presenting, learning new software shouldn’t be among them. I barely knew Keynote as it was. I found an appealing presentation theme with a Saul Bass-like aesthetic, and built my slides around this Jet Age motif. It helped that the theme’s graphics included a bird silhouette–great for a presentation about Twitter Bootstrap.

    Now, what about the slides’ wording?

    And how to display code samples?

    • Jim Weirich: Presenting Code. How to put code text into a Keynote presentation.
    • Rebecca Murphey: On Choosing a Syntax Highlighting Scheme for Your Next Presentation. Most presenters choose dark color schemes for code samples these days, so Murphey seems a contrarian. Still, I was convinced by her discussion when watching some other presenters at the same conference–I could barely see the text in the comfortably lit rooms. I’m glad I used Ben Alman’s dark text/light background theme for my own slides.
  • Rehearse

    I rehearsed at least one section of my presentation every day for about a month. I had some transitions between Sublime Text, Chrome, and Keynote which I knew would be even more challenging when I was nervous, so I emphasized working on those.

    Bleeta listens patiently

    Bleeta listens patiently

    One tip that intrigued me was to mirror displays when I connected to a projector, so that switching between the various applications would be a lot easier.

    I rehearsed both with presenter’s notes visible and with them hidden–I wanted my patter mostly committed to memory.

    When I felt really comfortable with my presentation, I rented a conference room at TechLiminal and rehearsed in front of obliging superstar Angel Inokon. If you follow only one scrap of the advice I’m listing here, do something like this. Not only did it help to have an experienced presenter like Angel critique my rehearsal, I really gained from dealing with the projector and the strange world of mirrored displays.

  • Prepare the laptop for presentation

    An hour or two before I got on stage, I:

    • Went to iCal > Preferences > Advanced, and checked Turn off alarms
    • Closed email
    • Opened window groups in Chrome displaying the URLs for each section of my presentation
    • Saved all Web pages locally. There was, unusually, WiFi in the hotel meeting room, but I didn’t want to rely on it.
    • In Sublime Text, switched the color scheme to “Cowboy,” so that the live code would match the colors of the samples I’d put in my slides.

    When I connected to the projector, I made sure to choose “Mirror displays.” One thing I didn’t do was check that my laptop display was the correct resolution! As a result, I couldn’t see scrollbars on the distorted, oversized laptop display when I was doing a code demo–not a catastrophe, but not what you need on top of everything else.

  • Prepare one’s self for presentation

    I:

    • Wore something fun. In my case this was a 1970s-vintage Hawaiian-print ao dai. I figured I’d complement the bold graphics in my slides.
      Photo by Ellis Kim, https://twitter.com/ellisk01/

      Photo by Ellis Kim

    • Brought my own dongle to connect to the projector. So glad I did this–there weren’t any at the podium when I got there.
    • Remembered I’d done scarier things than give this presentation. I’d done a front walkover on the balance beam. I’d made a phone call to a curt Berlin cafe proprietor after only two semesters of German. I’d danced Argentine tango in front of one hundred people who confused the dance form with chacha. Forty minutes of word-jazz about Twitter Bootstrap? Piece of cake.

2013: the year we stop using PSDs

Posted on: 2 Comments

Today I’m deep into preparing my slides for the HTML5 Developer Conference. Topic: “Making Peace with Twitter Bootstrap.” I have forty-odd minutes to soothe everybody’s ills with this ubiquitous framework. Since it’s a developer’s conference, I’ll emphasize solutions for people like you and I: front-endy things about SASS and Bower and whatnot. This will be the reasonable-sounding part of the presentation. Then, in real time, I’ll fight the temptation to disintegrate into full-on rant mode.

Here’s what I’ll try to say with terse, politely worded slides, rather than foaming at the mouth:

No more PSDs.

Stop it with the goddamn PSDs already. Fer Chrissakes, it’s the year 2013. High time to stop pretending to simulate Web applications with twenty-three-year-old image editing software.

Okay, so you’re a visual type, and you like to sketch your ideas in Photoshop? Fine. But for the same reason you don’t hand a page torn out of your Moleskine to your developer, you shouldn’t hand her a freakin’ PSD either: both formats communicate very little about what you intend for the application interface.

As Mule Design Studio puts it,

A PSD is a painting of a website.

If your interface links to framework stylesheets, and your application’s stylesheet bristles with !important rules overriding those styles, it’s a definite sign your project isn’t using the framework’s styles effectively. There are a couple of sources for this problem: 1) a developer not understanding how to use CSS selector specificity to create new styles; and 2) a design completely, totally detached from what the framework offers.

Want to drive Web developers insane really fast? Require them to cram Twitter Bootstrap, ZURB Foundation, or pretty much any CSS framework into a design dictated by PSD. In this workflow the designers and developers never discussed nor established viewport breakpoints, element widths, line heights, and such ahead of the design and development process, and fashioning something resembling the Photoshop comp out of pre-built components becomes an exercise in crazy-making CSS stunts. Meanwhile, the really necessary work of creating responsive design goes undone–what really happens is more like Reactive Design, when somebody glimpses how awful the interface looks like on somebody’s phablet, and then there’s a mad scramble fifteen minutes before the client meeting to patch over the rough spots hoping nobody notices.

My freelance rate is by the hour, and this kind of unanticipated rush developing can be lucrative. But it enrages me instead, because it’s entirely unnecessary. These days a Web design is properly devised in markup and CSS. Don’t like the associated learning curve to do this by hand*? Then use any of the following alternatives to Photoshop:

  1. Adobe Edge Reflow. Even Adobe wants you to stop delivering paintings of Web sites.

  2. Easel. Design for the browser–in the browser!

  3. Jetstrap. Get rid of that whingeing front-end developer and make the interface yourself.

Why are you still designing Web applications in Photoshop?

* A link to a design blog post from over three years ago.

Ada Lovelace Day: Estelle Weyl

Posted on: 1 Comment

By late afternoon that day in September 2002, I was getting pretty grumpy. The sandwich at lunch had dissipated into low blood sugar; the files I’d placed on the server just moments before had disappeared (and we had neither backups nor version control); the room was stuffy on an uncharacteristically hot day in San Francisco. And here comes this woman from one of the rival teams in the hackathon, introducing herself, trying to make friends, or at least, acquaintances.

I don’t remember being very effusive. The day had been grueling–I was on a team of four, working feverishly to develop an an accessible, yet visually appealing, Web site in just a few hours here in the Mission High School computer lab. But we shook hands. I recognized this woman’s name from the discussion list for SFWoW, at the time indispensable for finding out about tech events like this one. I hadn’t known how to pronounce it.

“Estelle Weyl. Like ‘while,’” she said. Within moments we all learned how excited she was about CSS, a technique new to many people at the hackathon, which was just one day of the Accessible Internet Rally. At another gathering we’d learned about various accessibility techniques, such as supplying text alternatives to images, offering keyboard shortcuts, and using CSS for presentation. The last had been my M.O. for three years already–I was puzzled how slow acceptance of it was.

I’d recently left a job at a software company which assembled a bunch of open source superstars, both actual and self-proclaimed, and then hired some front-end types like me to rework the clumsy, visually unappealing interface for the superstars’ application into something more usable. The low status of front-end work became obvious to me upon my introduction to one of the engineers.

“Oh, one of the pixel people,” he sneered, then lumbered off, leaving me to read the absurd style guide the UI lead had delivered. CSS was too “unsupported,” the guide admonished. Use <FONT> and <CENTER> to render the design atrocities we build in the browser. I didn’t stay long at this pointless gig.

So Estelle’s bouncy enthusiasm for CSS didn’t seem infectious to me, but instead, rather nai (more…)

Random stuff about the first Fluent JavaScript conference

Posted on: 1 Comment

I’m in the middle of changing jobs. To train my soon-to-be-former co-workers on how to get along without me, I spent three days this week at Fluent. What I garnered:

  • Watching my audio-engineer husband in action. An unusual perk of this conference was that, for the first time, the Binkster was doing sound for an event I attended. It was fun learning from him some of the backstage scuttlebutt. In turn, I enjoyed explaining the in-jokes about semicolons and Internet Explorer. Something that was really beneficial was finding out which presentations impressed him—he’s not a developer, but he’s seen more PowerPoint than any human not being punished should, so if you reached him, you must be very engaging.
  • Being reminded how unhealthy I feel sitting all day in a hotel ballroom. Spending all day inside usually makes me feel pretty bad, and so does sitting down a lot. Even worse is when the room is air-conditioned into that Atacama Desert level of humidity: we’re being mummified as we sit there enraptured by CoffeeScript. I swallowed zinc tablets and muscled through, but I skipped a few sessions because I just had to get outside and breathe real air. My admiration for my husband grew as I realized that he tolerates these conditions all the time for his job.
  • Tips about the new recruiting laundry list items. What many people talked about: JavaScript MVC frameworks, responsive (design|development), non-blocking script loading, knowing buck-naked JavaScript and not just jQuery.
  • Some great one-liners. There was frequent discussion about how JavaScript’s finally become accepted as a genuine programming language, worthy of study and standards. Along those lines were calls to take your JavaScript projects seriously:

    “Your JavaScript is software. Let’s treat it like what it deserves to be.” —Davis Frank

  • No t-shirts. I guess I could’ve obtained one, but I don’t usually wear them, so didn’t bother. Conference swag I’d really wear: something like a high school varsity sports badge. Heck, I’d even sew it on my letter sweater, right next to my junior-year award for cross-country. You’re welcome, O’Reilly, for my excellent idea.
  • Appreciation for the kinds of people who use JavaScript. I didn’t see any of the chest-thumping geek jousting I’ve seen at other conferences; doesn’t mean it wasn’t there, of course. Saw instead a greater spectrum of ages, ethnicities, and gender identities than the usual Meetup or hackathon offers. There was even a line in the women’s restroom at one point!
  • Yearning to learn more CoffeeScript. But I wonder if this won’t become the future’s version of “learning jQuery, not JavaScript” debate. In the backlog for now.

What not to buy in 2011

This is the time of year when the Interwebs are flooded with “what to buy…” consumer guides. In contrast, the things I discuss below are much cheaper, saving you both time and money, because in the end you won’t be shopping for them at all.

(An aside to Web services freelancers: you know, if we stop offering these things, people will stop thinking they can obtain them. Give it a thought.)

What not to buy in 2011

  • Support for IE 6. Freelancers–put a clause in your contracts that requires a $10,000 deposit before you even start up IETester or the like.
  • Meetings requiring developer attendance.

    "Sunday," © Peter Paul Jacques

    Described variously as “toxic,” “a disaster,” and “the biggest productivity killers for programmers,” meetings are relics from the twentieth century which have as much relevance to your technology projects as do carbon paper and stenography.
  • The cost of a stern “butts-in-chairs” policy. Savvy, experienced developers know what conditions make them productive, and these are various. Nobody lists compulsory enclosure in a cube farm among those conditions.
  • Huge office spaces. Since you’re not having meetings, and you’re letting your team co-work or telecommute, you don’t need all that much space anymore.
  • Fake work.
    Fake Work: Why People Are Working Harder than Ever but Accomplishing Less, and How to Fix the Problem

    This should be obvious, but somebody had to write a whole book about it to expose the problem.

  • Expensive conference fees. As Rebecca Murphey noted, the most useful conferences for Web technology seem to be ones organized by and for practitioners, who aren’t always bankrolled by deep-pocketed corporations.
  • Tag soup, nouvelle cuisine style. Regrettably, HTML5 provides just as many opportunities for lousy markup (“<div>-itis,” overuse of class and ID attributes) to the novice and/or the unconcerned, as  did earlier HTML standards.

What’s dropped off your 2011 shopping list?

Blog Action Day 2010: Water

Posted on: 2 Comments

Yesterday I opened the fridge at home, and was astonished to find these:

1.5 Liters of Bottled Water

Fifteen, even ten, years ago, these items would be unremarkable in my kitchen. I might’ve even remembered purchasing them, rather than regarding them as puzzling stowaways. But thanks to the Web, I’m now enlightened to these harmless-looking bottles’ sinister nature. Each is a crystalline vessel of needless expense, inefficient resource usage, and toxic compounds . So how did they end up in my house?

Each bottle is an artifact from a conference. Each is the result of a conference organizer’s good intentions and relatively enlightened self interest. The original notion seemed to be concern for conference attendees’ physical comfort (“Keep hydrated through those long days of sitting in chilly, darkened meeting rooms! Here, take a bottle of water…”), combined with greater awareness of the ruinous health consequences of drinking soda, and the practices of corporate branding, to create the now ordinary half-liter water bottle such as you see here, and such as you probably have lurking in your own refrigerator.

How is this a problem? We got something for free, right?

Uh, no.  We’re paying for it,  whether we drink this water or not.

We’re paying for:

  • The delivery of so many single-serving bottles full of what is often just tap water
  • The janitors necessary to remove these used-only-once water bottles from conference rooms and wastebaskets
  • The energy inputs required to recycle these bottles, if that’s even available.  (To that conference’s credit, one of these party favors used 100% recycled plastic for its bottle)
  • The landfill space required to bury these bottles when recycling isn’t supported

And we’re missing a great opportunity for tech conferences to be as innovative as they claim to be in their publicity. Want to be truly “disruptive, or “2.0,” or “the future”? Hand conference attendees collapsible steel cups with the conference logo printed on them, and point the way to the drinking fountains.

I doubt we will notice anything missing from our fridges.