Notes from BADCamp 2014
BADcamp 2014 was an amazing success. Thank you to all the volunteers who made it happen. From the summits to the informal convos, everyone at Kalamuna got a lot out of it. Since I did get to go to a handful of events, I wanted to share some notes and insights from a few I think you’ll find useful. This post isn’t a “review” of panels or anything like that; it’s a collection of my thoughts and others’ ideas that might help you with your Drupal-ings. Enjoy.
The Kalamuna team inside the Palace of Fine Arts, posing before our Great Wall of BADcamp.
The BADcamp Vibe
I haven’t been to too many “trade show” type things in my life, but if forced to put BADcamp into that category, I’d say it stands out with friendliness, people’s openness to share information, and a general aesthetic of awesomeness. For example, did you see the event branding by designer Darius Garza? Amazing. Even people who don’t know Drupal would wear those badass hoodies. And at the Front End Summit, folks had a couch on the stage instead of those cold stools you usually see at something like this. Things like that, throughout the camp, really set a great tone.
Friday: Front-end Summit; Multiple Speakers
Jesse Beach (@jessebeach), Morten Birch-Heide (@mortendk), Ian Carrico (@iamcarrico), John Ferris (@pixel_whip), Darius Garza (@darius_garza), Megan Erin Miller (@meganerinmiller), Meghan Pelagyi, Sam Richard (@snugug), Sally Young (@justafish)
Some cool things I learned:
Jesse Beach (@jessebeach): Quail + Accessibility Testing
As Jesse so eloquently put it, “we are all temporarily abled.” Everyone will have to deal with some variety of disability, and as I squinted to see all the way to the stage enjoying my minor monitor-induced myopia, it was easy to remember the importance of web accessibility. Quail is a jQuery plugin that helps make sure that accessibility standards (like the 50+ in WCAG 2.0) are fulfilled. For Drupal users, it’s integrated into the accessibility module. Although the speaker noted that Quail isn’t quite production-ready, it’s a great starting point. Former Kalamuna UX engineer, Steven Bassett, made a very good comment noting that the verbosity of Quail means it can often encourage slavish accessibility implementations that can confuse people using screen readers and others with reading disabilities.
Sally Young (@justafish:) Views, drupal_add_js, and Other Annoyances
Interesting to hear folks’ Drupal pet peeves. We’ve all got ‘em. Sally recommends: hook_page_build() and the #attached attribute instead of drupal_add_js so you won’t have JS added to non-HTML requests. I’m kind of curious about this, particularly considering drupal_add_js is being deprecated in Drupal 8.
Sally dislikes Views, so she writes custom code using Entity Field Queries to grab the entities she wants to display, and then renders using Entity View Modes. HERESY! But very efficient heresy that doesn’t leave a bunch of Features-generated code cruft that’s impossible to QA in a diff. If you must use Views, Sally recommends using Entity View Modes to generate the individual pieces.
Thanks Sally for giving us this overview!
Saturday: Drupal Commerce in Drupal 8, Ryan Szrama of The Commerce Guys (@CommerceGuys)
Ryan (@ryanszrama): Commerce Kickstart in Drupal 8
Ryan was surprised at how many people have actually launched sites on Commerce Kickstart, the demo framework for Drupal Commerce. What was intended a demo has become a viable out-of-the-box solution for a small- to medium-sized online merchant. It’s a winning combo of streamlined admin, responsive theme, content-rich product catalogue with zooms, slideshows, and other effects to highlight merchandise, faceted product search, and integrated payment gateways.
Drupal Commerce 2.0 wants to take some of the functionality from Kickstart and integrate it into core Commerce. The Commerce team started from scratch. Some big differences and improvements include…
- Improved data model that moves from basic 5 entity types (product/order/line item/customer profile/payment transaction) to nine, adding a store model, invoice, and payment allocation models. These should allow for better handling of complex business logic like refunds and handling of multi-store/multi-vendor setups.
- A hierarchical product model for handling variations on products. For example, different colors/sizes of shirts should inherit attributes from the parent shirt product.
- Flexible workflows for “order status”: imagine if you could define a mandatory workflow for different types of orders that it must go through a flow of order statuses with permissioning and actions required to move the order status.
- Discount handling in core.
Ryan views stand-alone PHP libraries that tackle universal commerce problems, like tax management, address management, currency handling, etc. as being valuable contributions from the Commerce project to the greater PHP ecosystem. Some libraries include…
- Addressing: Uses a Google dataset to build dynamic address forms appropriate to different regions.
- Zone: International taxation zones.
- Tax: International taxation zones.
Commerce Guys hopes to maintain single libraries for these core commerce problems that MANY PHP commerce projects can use; already Symfony folks are contributing to these libraries. Drupal 7 may even benefit from the Addressing library in a backport.
I’ve recapped ideas from some great BADcamp speakers. I hope that those of you who weren’t able to attend will be able to get something from my notes. Thanks again to everyone who helped make BADcap awesome -- especially the speakers who put so much time into preparing for the sessions and summits.