Drupal Theming

typey has just turned 1.0, so I thought it would be a great time to show off some of its features.

A requirement that comes up from time to time is being able to use content stored in Drupal and produce rich HTML emails. In a lot of cases the design of these emails matches the design of the existing, already implemented front-end website.

In a recent project, we explored ways of creating HTML email’s which wouldn’t require us to start from scratch and would also evolve as the website’s look and feel did. Our design goals were thus:

• Use the existing website’s CSS to skin the emails.
• Use existing Drupal site-building tools to construct the markup for these emails.
• Allow admins to easily create and preview HTML emails.

Generally speaking hiding content goes alongside a bit of javascript that unhides the content under certain circumstances (think hamburger menu). Sometimes the content improves accessibility but is considered visual noise (says the designer). So as the developer you have a lot of ways to approach this.

At PreviousNext this past year, we have started using a style-guide-centric approach that matches our Agile development practices. We write our styles and markup as components and then use automation to build, test, and add them to a style guide.

Since we are a Drupal shop, you might expect that all our automation is done with PHP, but we’ve found, on the front-end side, the best tools are written in Node.js. Grunt, Gulp, Yeoman, Bower, Eslint and more are all written in Node.js and installed and distributed with its package manager, npm.

The traditional approach of directly styling default Drupal markup is not a scalable solution when we consider the volatility of the modern browser ecosystem. It is now necessary for front-end developers to abstract design patterns into manageable components. By using a styleguide we can automate the process of isolating and cataloguing patterns so they can be iterated and tested against independently. In this post I discuss ideas and put forward some informal rules around managing these components from within a styleguide.

During PreviousNext’s weekly developers meeting I recently gave a lightning talk about how to use kss-node to auto-generate a website style guide. If you’ve even tangentially followed front-end development, you’ll find that this is yet-another blog post describing “project A implementing technology B with hip, new language/framework C.”

But kss-node is really cool and useful, especially if you understand how it fits into the larger picture of the new web development process. Fortunately, my previous post provides that big picture, so if you’d like to understand how Agile is turning web development inside-out and how style-guide-driven development is the new website development workflow, please go read that first. Then head back here for the screencast to get you started with kss-node.

If you’ve looked at front-end development at any time during the past four years, you know that there has been an explosion of new technologies. We are inundated with new projects like bower and cucumber and behat and KSS. It is a lot to take in. At the past two Drupalcons there have been sessions about this overload, My Brain is Full: The state of Front-end developement. Essentially those sessions are asking “What the hell is going on?”

“Everyone is describing the one little piece they’ve created, but don’t explain (or even reference!) the larger concepts of how all of these elements link together.”

— Frank Chimero, July 2014 Designer News AMA

This is my attempt to explain.

John Albin Wilkins recently gave a session on The new Front-end work-flow from ticketing to building at DrupalGov Canberra. 

This session will outline our current mistakes and then introduce the basic techniques for CSS layering and using design components, the heart of any front-end CSS project. We will also discuss ticket structure, project organization, and tricks to implement components when you can't change Drupal's classes.

Join one of the world's leading Drupal front end development experts, John Albin Wilkins, on his first multi-city speaking tour of Australia.

User Experience is a much misunderstood discipline. For a start, in software and web development, we generally think of it as a design task, for design wonks, or some kind of process prior to real development where we determine some user needs or requirements. In particular, within web development, user experience is treated either as a step in a process, or a specialised skill, but almost never as a holistic development vision.