Matt Mullenweg and Jane Wells kicked off WordCamp Atlanta this morning by tag-teaming a general WordPress Q&A session. It was convivial if not terribly informative for me (probably plenty informative for others). During the Q&A, one person reported having had difficulty getting support some time back for some blogs she had set up at WordPress.com and had gone back to Typepad for that reason and others. Since I work on WordPress.com, and on the support team in particular, I felt pretty bad about this. Luckily I was able to track her down after the session and reach out to try to provide some one-on-one, in-person support. I think I made her day a little brighter, and it felt nice to try to help.

Next I headed to the Happiness Bar, a room that users can go to when they have questions about WordPress that they’d like to help get sorted out by an expert. I was ostensibly one of the experts staffing the bar (which is not, sadly, in fact a bar). After a few minutes chatting with a couple of people from WP Engine, I snagged someone who came in for help and brightened her day as well. Helping people is fun.

Next up, I gave a presentation titled Hassle Free Blogging with WordPress.com. It was fairly sparsely attended (though better attended than I had feared it might be, given that most people who attend WordCamps already have, or are interested in having, self-hosted blogs), and I think it went pretty well. Several people told me afterward that they had thought my presentation had been good. I was well-prepared and wound up not being nervous at all, so maybe I’ve conquered my fear of public speaking.

At lunch, a number of us who organize meetup groups were going to chat, but the conversation wound up being monopolized by one guy asking things he should have simply read about on Jane’s recent post, and I wound up bailing early to make sure I could get a seat in my first real session of the day.

Mark Jaquith, Creating and Maintaining WordPress Plugins

I’ve watched one or two of Mark’s presentations on WordPress.tv and found him to be just as clear and concise in person as on the tubes. He started with a brief overview of why one might use plugins vs. hacking code into functions.php, for example. Then he gave some general advice about good code patterns to use. For example, he favors using classes to avoid polluting the global name space and setting up convenience methods to make life easier. You should also defer actions (no point in registering an admin action for non-admin pages), and he showed off a handy way to keep a plugin’s options in a single array rather than storing a WordPress option per plugin option; this was one of those convenience methods. Even while showing us his particular ways of doing these things, he acknowledged that we might have our own preferred methods and made it clear that his intention wasn’t to peddle his particular kool-aid but just to give us some general ideas.

Next, he talked a bit about why and how to use the WordPress.org plugin repository, suggesting that having plugins in the repo makes you feel good (helping others), is great for professional credibility, and is a great way to keep track of your own plugins. The how of it was old news to me, with one exception — he gave the tip that when releasing a new version of a plugin, you should first tag your code and then repoint the readme, which isn’t something I necessarily would have known to do.

Finally, he talked for a few minutes about what he called sanity. He suggested not giving your plugin too many options, especially in early releases, as the more options, the more questions people will have and the more support. He cited the core WordPress team’s emphasis on “decisions, not options,” which is a little vague but which I take to mean basically that rather than giving people dozens of knobs to twiddle to change minor things, you should worry more about the big things that make real differences in how your plugin operates, that make people ask themselves “do I wish to have my site do biggish thing X or biggish thing Y?”. He also emphasized the importance of just saying no to users sometimes; in other words, don’t be a slave to the random requests of users. If you don’t think a feature suggestion is a great idea, you don’t have to implement it. Just Say No. And finally, he impressed upon us the importance of encouraging good behavior. For example, don’t build plugins that allow users to do spammy things.

It was a solid talk. Again, this wasn’t one that actually taught me new skills, but Mark is an earnest and engaged speaker, and I felt as if it was important to him to explain things clearly and logically, with no agenda other than helping. I’d love to attend a talk by Mark on a more advanced topic.

J. Cornelius, HTML5 — Hell Yeah!

Uninspired talk title notwithstanding, this was probably the best talk I attended all weekend. It was packed with information I didn’t know (partially because this is an area I’ve never looked into at all, which was exactly why I was interested), and the presenter seemed really well-informed, with slides that did a great job of demonstrating the principles he talked about. It was a standing-room-only talk.

The speaker started off with a brief history of HTML, from its beginnings as part of the SGML standard through HTML5. He marked the milestones with musical milestones featuring the likes of Eminem, Usher, and — gulp — Kenny G.

HTML5 is important for the following reasons:

• Semantic markup is markup in which the markup is relevant to the meaning; since HTML5 provides more (and more precise) elements, it affords our markup more and better meaning.
• New parsers that accommodate HTML5 will also do a better job of doing things like fixing incorrect tag nesting. Since 95% of the web doesn’t validate (!), this is good for the web.
• HTML5 is better for mobile platform usability, which we all know is of increasing importance.

Some neat tidbits I learned about the spec:

• In-line elements can contain block-level elements now. This is important because it makes for more concise, cleaner markup. For example, rather than having <h2><a href=”#”>Foo</a></h2><p><a href=”#”>Foo</a></p>, you can have <a href=”#”><h2>Foo</h2><p>Foo</p></a>.
• The <nav> element is a lot more meaningful than a <div> that contains a list.
• The <time> element is machine-readable, providing for the first time a document that provides information about itself that doesn’t require human interpretation.
• There’s a <nsfw> tag that will pull contained elements out of the DOM. There is not, however, a <noscript> equivalent that will show alternate content.
• You can do some form validation without having to implement your own screwy javascript.
• The <article> and <section> elements can be a little confusing. You should consider <section> to be a logical section of a document, while <article> conains content that could be used elsewhere without losing meaning. I take this to mean that in a site that has all kinds of moving parts, a <section> might describe a subset of moving parts whose functionality is constrained to the site’s display properties, while an <article> contained within a section describes the text and media that could meaningfully be syndicated without the baggage that the <section>-specific bits would bring along (e.g. UI controls).

Some helpful sites/resources:

• html5shiv (forces IE to recognize html5 elements)
• html5boilerplate.com
• modernizr.com
• Polyfills
• html5doctor.com
• html5please.us
• constellationtheme.com (a good starting point for building html5 themes for WordPress)
• html5gallery.com

This presentation wasn’t especially geared toward WordPress (though I took some good-natured flak for raising my hand as the only person still using a default WordPress theme — but bear in mind that I’m in a room full of designer types), but it was certainly relevant material, and the room was very interested in the presentation. I learned more at this one than at any other over the weekend, even if it wasn’t especially technical material or information I’m likely to use on any sort of regular basis in the near term.

Kristina McInerny, Cool Tools for Customizing WP

This presentation got off to a bad start when there were technical problems with the presenter’s laptop displaying properly to the projector. I offered my laptop for her to use, and though this got us over the technological hump, it’s got to be discombobulating as a speaker to have to change environments. We had to stop partway through and install a piece of software she had planned on demonstrating, for example. Further, although her presentation assumed use of Firefox and associated tools, several in the room were Chrome users. Luckily, I’m a Chrome user and knew about equivalent tools. At the risk of hijacking the presentation and with (I think) approval and even thanks from the presenter, I spoke up and briefly demonstrated the equivalent tools.

The tools covered were Firebug for easily viewing and manipulating CSS, FirePicker (not installed in my Firefox and so unfortunately not demo-able), which lets you choose colors easily from within Firebug while working on your styles, and FileZilla. After going through how to find a style snippet in Firebug, the speaker showed how to edit the style sheet using the WP Admin style editor and how to comment out the original style definition for restoration should your change go awry. She then tried to explain how you might use an FTP client to transfer files and particularly to back up your style sheet prior to making changes in the admin editor. The talk was revelatory for the gentleman beside me, who said enthusiastically that this session alone had been worth the price of admission. So I think it was well-received among at least the less experienced among us.

The talk was billed as not being suited to beginners, but neither was it quite an intermediate talk. For example, I can’t imagine an intermediate user actually editing styles through the WP admin editor. And the explanation of how to use FTP seemed off target. That is, she seemed to suggest that you could download your style and save it in a backup folder before editing via WP admin. But why not just edit the files locally and transfer up afterward? Or, if that’s too sophisticated a use pattern, why introduce the FTP complication at all rather than just suggesting saving a backup copy locally via copy/paste (which, to be fair, she covered, but I didn’t really understand adding the FTP complexity if it was going to be used in the way suggested).

For me, the talk was a little disappointing, though again, for those who were dabblers or seemed to be pretty beginner-level users, it seemed to be very well received, so I think I just chose the wrong topic for my experience level.

General Impressions

The Atlanta WordCamp seemed to be really well organized. Things ran very smoothly, or if they didn’t, it sure seemed to a non-insider attendee as if they did. The facility was great, the food adequate (boxed lunches can be only so good, and the breakfast and snacks were good). Registration was a cinch. The projector issue in my last session was apparently the first tech glitch of the weekend. I was very impressed overall. I wouldn’t have minded if the sessions had been more clearly marked as being for beginners, intermediate, or advanced users, but that’s a minor nit. I had a good time and found it to be a really rewarding experience, especially my Saturday morning of helping others and giving my talk (which I had been nervous about, having always been afraid of public speaking, which I think I may now be cured of).

The experience proved revealing to me in one big way. I think that WordPress experts who go to WordCamps must go not for the sake of learning anything but for the sake of helping others learn things. Although I work for Automattic, I actually don’t have a whole lot of experience working on the core WordPress software (I work mostly on things tangential to it), so an honest assessment of my skills as a WordPress developer would be that I’m intermediate. Yet the WordPress-specific sessions this weekend didn’t really teach me anything I hadn’t already known. So for core developers like Westi and Jaquith and Otto and Nacin, WordCamps are for meeting people and helping teach them about the software. The other big thing I learned, of course, is that that’s ok. Helping out was what I most enjoyed about the conference, and I’m already beginning to outline mentally a talk I might like to give at a future WordCamp.

I’m crummy at photography, but I snapped a few photos with my phone, mostly of buildings and of art within the SCAD building that housed the conference.