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


    • 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,
      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.

The latest in HTML

No question, HTML5 is big news. It’s the subject of sold-out conferences, mobbed Meetups, and recent best-sellers. It’s even become a catch-all marketing phrase perfectly contoured to shove into presentation slides. But HTML5 better watch its back. There’s yet another promising HTML standard out there. It’s what you’ll want to use on your next project–hip, cool, and wholly cross-browser compatible.

Get ready; here comes HTML 3.2!

Whether you’re looking for a new front-end dev gig, or just trying to freshen up your skills, learning HTML 3.2 in the upcoming months will be crucial. Fortunately, it will probably be a skill you’ll enjoy using once acquired.

When you convert your legacy markup from HTML5 to HTML 3.2, you’ll find some elements familiar to you: <P> and <BODY>, for instance. The biggest task you’ll have is removing all that CSS cruft so you can take advantage of HTML 3.2’s many presentational tags and attributes, such as <FONT> and <CENTER>. You can also replace many lines of CSS rules by using <TABLE>, <TR>, and <TD> for layout (a technique possible in HTML5 as well, but rarely explored).

Other features of HTML 3.2 include the useful <BLINK> and <MARQUEE> tags, though, regrettably, these have poor cross-browser support. You will have to polyfill with JavaScript to assure that all users can access this content.

Attendance at the recent HTML 3.2 Hackathon was small but enthusiatic

If your legacy HTML5 code base is extensive, you might find the job of converting it all by hand a daunting challenge. This is a situation ready-made for a WYSIWYG editor. Software makers have taken notice of the opportunity to jump on the HTML 3.2 bandwagon; you’ll have your pick of user-friendly tools. The most popular choice seems to be Microsoft’s FrontPage. Adobe isn’t far behind with the PageMill application. If you have the Netscape browser installed, you’ll find its built-in Composer product easy to use for your cutting-edge HTML 3.2 project.

True, it can be frustrating sometimes to keep current. Just when you thought you knew the difference between <article> and <section>, along comes an HTML standard which includes neither. Yet think of the compensations–you’re not losing <canvas>, you’re gaining <LAYER>.

Sh*t People Say to Front-end Developers

  1. We really don’t need a designer.
  2. What’s an information architect?
  3. Nobody will be looking at this page with a mobile device.
  4. This style guide from 2002 is still good.
  5. We really don’t need localization.
  6. This Excel spreadsheet is our issue tracker. Works great!
  7. Using Flash would make this so much easier!
  8. HTML5 is too risky and experimental.
  9. What’s a validator?
  10. Browser support? All of them, of course.
  11. We really don’t need a copywriter.
  12. Of course our users will sit through this thirty-second auto-play splash video.
  13. We really don’t need JavaScript testing.
  14. The database guy already did the HTML and CSS, so you just have to add a few tweaks.
  15. Of course our users will submit this twenty-question form before seeing our content.
  16. This will be a short project.

HTML5 Boilerplate Rolls Into Town

Standing room only, and a waiting list besides–what was the attraction bringing so many to the tech college conference room at Fisherman’s Wharf?

Haloed at one end of the room by the glaring video lamp, a man, a laptop, and the new way you should build the front-end of your Web app. Ladies and gentlemen, presenting Paul Irish, in turn presenting the HTML5 Boilerplate.

There’s much you can gain just downloading it, of course. You could opt to pick through the unzipped goodies and apply them piecemeal to your aging markup, refinishing your early 21st-century XHTML with some latter-day varnish. But there’s a lot more in the Boilerplate than too-hasty reading of the docs will reveal.

Irish, one of the mod squad behind the informative and massively entertaining YayQuery podcast, delivered a quick, focused survey of the Boilerplate’s many benefits to those eager to follow advice like Steve Souders’s 14+ rules. Among these is a customized .htaccess file, for those of us with good intentions of, say, gzip’ping assets but only rudimentary Apache admin skills–that’s worth the attention of a full room all by itself. Another is the built-in provision of QUnit: no more chasing this down to install separately. And coming along in the bright future is the Boilerplate for mobile.

Build an ant!?

But best of all is the build script. No wonder Irish calls it his favorite part of the Boilerplate.

Here’s where mere mortal front-end devs can finally scale the Olympus of best practices. Need to combine your CSS files? Your JavaScript? Optimize, minify, them? Remove test suite leavings? Excise all those dangerous calls to console.log? Boilerplate’s build script does this for you. Hurrah; I didn’t need yet another checklist to consult.

I was gratified to hear someone take HTML seriously. For too long writing markup‘s been dismissed as a simple, easily acquired technique that any drooling idiot can/should perform. Now there are Meetups full of software engineers anxious to learn things like table-less layout. Hah! Isn’t the Web fun?

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?

HTML5 Forms: browsers get jetpacks

Self-identified standardista Estelle Weyl enlivened a recent HTML5 Meetup with her summary of the neat stuff we could use if only everybody used, say, the latest version of Opera.

How many lines of JavaScript have you written to enforce a pattern on user input? To set focus on a certain form element? To mark input required, and bark at the user who doesn’t supply it? How about offering a calendar pop-up for a date picker? Between HTML5 and CSS3, there are new options for markup–no scripting necessary!–which handle these scenarios.

Well, that’s the promise, anyway. It’s nice to hear the future is nigh; it somewhat offsets the discouragement you’ll feel when you obtain the latest statistics on how many Web users continue to use terrible software such as Internet Explorer.

Carefree living post-IE 6

Hearing about nifty HTML5 wonders at present feels a lot like watching those filmstrips about “life in the year 2000 A.D.!” when I was a kid: substitute attributes like “placeholder” and “datetime-local” for “flying cars” and “robot servants” to update to the latest shiny, optimistic vision.

Yet it’s not we shouldn’t use HTML5 forms–we’ll just have to prop them up with JavaScript crutches, until the browsers of Tomorrowland are in common usage.

Note: Estelle’s presentation might be expanded for SXSW 2011.

A visit with HTML 5

Now that HTML 5 has been declared victorious over XHTML 2, the last six to eight weeks have yielded a bouquet of tutorials, introductions, cheatsheets, and blog postings about it. I guess we’re so excited about anything new in markup we’ll even cheer a draft proposal. I can’t excuse myself from the mob, having joined it on a recent project for a future-minded client who encouraged me to take up the fashion for <!DOCTYPE html>.

On first and even second glances, the HTML 5 element list seems conservative, not much of a change. There are the intriguing new tags like <canvas>, but with limited cross-browser support. <menu>returns from, what, HTML 3.2?, but this time dressed up as a way to group form inputs (easy to confuse with how we’ve been using <fieldset>). Other elements, such as <header>, <footer>, and <section>, are good substitutions for the over-worked <div>, which lingers in HTML 5 for your block element needs. <article> is interesting–it’s supposed to enclose “standalone” content. <nav> is easy to type and remember.

However, some of these tags seem to presume usage in rather old-fashioned situations. For instance, which of the navigational blocks on your application screen will you exalt with <nav>? No fair using it more than once–it’s supposed to designate your primary navigation. And which of your content blocks are <section>s and which are <aside>s, especially if the user can rearrange them?

Where HTML 5 seems more ambitious, seems to pose more of a learning curve, is on attributes and APIs. Form elements seems especially enriched in this specification. I didn’t use any of these on this project, but I’m eager to try them when the browser support is sufficient. Many of the proposals will remove tedious DHTML chores, if ever supported; for instance, this block will replace all those unordered lists distorted by CSS and JavaScript into popup menus:

<menu type="popup">
    <command  label="Check messages" icon="messages.gif"/>
    <command  label="Logout" icon="logout.gif"/>

By now I expect you’re asking, “But what about IE?”

Yeah, what about that? Hmmm.

I was blessed to have a client who’d discarded concern for IE 6. Problem solved, you think?

Not at all. IE 7 ignored even the most basic HTML 5 tags–even <section> proved uncharismatic. To the rescue, JavaScript; more specifically, the “HTML5 Shiv” (love the name, which captures the mood of destructive exasperation IE inspires) script popularized by John Resig and Remy Sharp.

Overall, it was an enjoyable stroll through HTML 5’s more accessible areas. Maybe XHTML 2 would’ve been a more thrilling excursion, but I’m content. Shiv or not, it looks to be sunny ahead.