The Drupalcon Chicago 2011 track chairs met for the first time last week. Our first task is to come up with track descriptions. For the first time, Theming is going to be separate track from Design and UX. While this shows a nice focus on these interrelated but distinct topics, I'm still trying to come up with a good description that helps define the dividing line between design and theming for sessions proposals like “Designing with CSS3”.
Anyway, here’s my first draft for my track’s description:
Theming Track
As Drupal’s mighty hands build markup, styling and dynamic behaviours, the lowly Newbs have forever strived to comprehend this Magic. With gnashing of teeth, wailing and despair often being their pitiful state. But, lo! Behold the mighty Drupalcon Theming Track. Forthwith, We, the Gods of Drupal, beseech the worthy to attend this track and despair no more.
[insert thunder crack here]
Hmm… I may have to tone it down. A bit.
So with a theming track that will focus on the nuts and bolts of actually building design, interaction, usability, accessibility and navigation, what sort of sessions should we have in Chicago? And I mean what sessions do you want to see, not what sessions are you going to propose.
Sound off in the comments below.
Comments2
"For the first time, Theming
"For the first time, Theming is going to be separate track from Design and UX."
Words cannot express my joy.
Off of the top of my head, sessions that I want to see include:
- Theme layer performance optimization - focusing on Drupal specific stuff in tpls and template.php, not so much general front end code optimization
- The Drupal execution stack for themers - truly understanding the order of things, for themers who aren't afraid of PHP. More than just "here is how you use a preprocess function", but really getting into the nitty gritty of what's going on.
John, I think there is a
John,
I think there is a niche to deliver sessions aimed at developers that use Drupal for advanced needs and find themselves longing to hack the hell out of the existing code to achieve non-standard functionality.
Anything related to inserting JS effects, rendering customized Views based on certain parameters such as user interactions, or modifying the look and feel based on the site’s areas, such as special theming for paths, Views, node types, taxonomy types, etc.
Perhaps I have not searched enough or have done it without sufficient inspiration, but I find that there is a big hole in the general Drupal knowledge base regarding guidelines, rules, best approaches and so forth when it comes to getting a website to perform in new theme-related ways.
For instance:
When inserting a Views page in a region based on content type
Have we gone too far if the type-node.tpl is the one inserting the View? Should we use a Block with PHP visibility settings instead? What’s the Drupal Way for this situation? What happens when the visibility settings get more complicated, say, there’s a need to interface with an external API to determine visibility settings – should this be a module or is it fair game to write this code into the theme and put some UI controls in the theme’s configuration page?
I think it is important to set a precedent of best practices to avoid unchecked Drupal code-hacking, and to help developers understand their options and predict possible conflicts down the line. I know my team is having a small struggle in this department as we make way to fulfill project needs.