Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Apr 29 2014
Apr 29

Devsigner is celebrating the cross-overs, the multi-disciplinarians, the coders who paint and the designers who send pull requests — and those who want to develop some new left-right brain skills.

We’re looking for folks to break out of their familiar meetup silos and apply their knowledge across the crafts of development and design.

Join me at Devsigner in Portland, Oregon, May 23-25!

Tickets are now on sale, and session submissions are open until this Friday, May 2! Devsigner: Portland, OR, May 23-25

Sessions will include things like:

  • responsive web development for graphic designers
  • color theory for coders
  • industrial design for web apps
  • why bad user experience is a bug
  • what web technologies can learn from analog design
  • iterative design in open-source communities
  • your great idea — submit a session now!

We’re going to mix it up with a variety of session formats:

  • Traditional presentations (45-60 minutes)
  • Panel and roundtable discussions (45-60 minutes)
  • Hands-on, deep-dive workshops (2 hours Friday, 3 hours Saturday and Sunday)
  • Lightning talks on Saturday night (more information to come)

We’re also kicking off the event with a keynote presentation from a surprise guest!

Who should attend?

  • graphic designers who want to hone their web design chops
  • developers who want to the beauty of their projects to match the beauty of their code
  • artists who are tired of ugly or unusable websites
  • branding experts who want to tell developers a story about the cobbler’s children
  • Sass/Puppet/Angular/Grunt/Node evangelists who want to spread the good word
  • you!

I hope to see you there!

May 21 2013
May 21

This is an intervention.

CSS is pretty simple. Classes, IDs, elements and pseudo-elements, with style definitions attached to each. Calling it a “language” is a bit of a stretch (though preprocessors like Sass fit the bill).

But let’s be honest, for years our stylesheets cascaded right on out to infinity.

Huge files with table-of-contents comments to try to make some sense of it — until a quick fix got pasted down at the bottom. Brittle style definitions relying on tight coupling with HTML structure. Pieces of styles being replicated here and there for different components with similar features, without any way to tell they were related in the CSS.

My stylesheets were like that too, because strategies for writing CSS had barely altered since the days when it was used to change the colors of the scroll bars in Internet Explorer. Luckily, in the past couple of years both CSS architecture and CSS preprocessors came into their own.

Jonathan SnookSMACSS, or Scalable and Modular Architecture for CSS, was developed by Jonathan Snook, a featured speaker at Drupalcon Portland. I’m really excited to get the opportunity to have Jonathan speak, not only because of my personally well-dog-eared copy of SMACSS, but because Drupal itself is adopting a SMACSS approach to its CSS.

I spoke with Jonathan about sustainable stylesheets and the future of SMACSS. For an even more detailed look, please join me at Jonathan Snook’s featured Drupalcon Portland this afternon, Tuesday, May 21 at 4:30 PM.

IB: What’s the biggest mistake you see people making when writing CSS?

JS: I think the biggest mistake is thinking of everything in the context of a single page. We’re no longer just building sites with a design for a home page and an inside page. We’re developing complex systems that need to work in a variety of contexts and we need a development approach that complements that.

SMACSSIB: What’s the biggest “win” you see in using the SMACSS approach? Why should frontend developers change their approach to CSS?

JS: The biggest win is maintainability. The SMACSS methodology makes it easier to build larger projects by breaking things down into smaller components. Like the move from spaghetti code to MVC frameworks on the server side, this separation of concerns on the CSS side improves the process of putting a site or web app together.

IB: In the last part of your book, you talk about how the SMACSS approach fits in to work using a preprocessor like Sass. There have been a lot of developments in Sass in the past year — have they had any positive effects on your use of the SMACSS approach?

JS: With Sass, the introduction of placeholders was a positive step forward. Overall, Sass (and other preprocessors) are a great way to augment — but not replace — the way people write CSS.

IB: What are your thoughts on BEM? Do you see it as compatible with SMACSS?

JS: I see BEM as very compatible. BEM really enforces naming convention, which is a very important concept in SMACSS. They both take a modular approach to site development.

IB: What are you tacking next when it comes to CSS and frontend development? Will there be a “SMACSS Part Two”? Or something else entirely?

JS: I’d love to augment SMACSS with case studies and expand on some of the ideas in the book based on things that come up in the workshops I do. I’d also like to work on a prototyping/site development tool that uses the SMACSS concepts. We had built something like this when I was at Yahoo! that I think many people in the industry would find really useful. Hopefully I can find the time to work on it!

Image credit FlickrFlickr is a social media site for photographs and digital images. Like a social network, it allows users to “friend” one another, join groups, and see a recent-updates feed of their own and their friends’ images. Flickr is owned by Yahoo!. user stevensnodgrass. It’s spaghetti! (As in code.)

May 17 2013
May 17

Media queries are a key part of responsive web design, because they control at what width (among other things) different CSS rules kick in.

Breakpoint makes writing media queries in Sass super simple,” say Mason Wendell and Sam Richard, creators of the extension to Compass, and they’re right. It’s not surprising that we’d want them to present at Drupalcon, since design in Drupal, like web design everywhere, has been embracing responsive web design as a fundamental principle. (Side note: This website is in the midst of a responsive web design overhaul. Cobbler’s children and all that.)

I spoke to Mason and Sam about how Breakpoint makes responsive web design even easier. Don’t miss their Drupalcon Portland frontend session, “Managing Responsive Web Design with Sass and Breakpoint,” on Thursday at 10:45 AM.

IB: What motivated you to create Breakpoint? How has it changed your own workflow?

MW: Before Sass 3.2 came out I had written an article for The Sass Way that previewed some of it’s new features, including the ability to use variables in media queries. I created an example that baked in some names for breakpoints into a kind of “master mixin” for media queries. On my next responsive project I put the theories I’d written for that post into practice, and found that I could refine that approach. If I assigned a variable to each media query first the approach would be very flexible. Then when noticed that I wrote min-width queries way more often than any other type I set up defaults that made creating media queries very fast.

MW: There was a side effect that I think is more useful though. By assigning names to each of my media queries I’m able to keep them in context in a much more effective way. If I some media queries to deal with the width of a nav element, and then later I add an item to that nav, I can change the value of that variable and all the associated queries are adjusted. This is even more effective when handing code back and forth within a team.

SR: Breakpoint was created with the motivation to ease many of the pain points of working with media queries in CSS. The biggest pain point that Breakpoint solves is providing meaningful semantics to your media queries. When building content based responsive sites, early in your design process two unrelated items may happen to break at the same points, but as your project grows, those points may change and a simple find and replace will have unintended consequences. This is probably the biggest workflow win to using Breakpoint, all of your media queries now have proper semantics.

SR: The other big win for my workflow is Breakpoint’s no-query fallback, allowing me to very easily add in fallback code for any of the media queries I write.

IB: What can Breakpoint do that just assigning variable names to specific min-widths can’t?

SR: For starters, Breakpoint handles much more than min-width queries. It is designed to be future friendly and currently supports all CSS level 3 and level 4 media queries. Additionally, it’s syntax is easy to use to create complex media queries, including both and and or media queries. It has native handling for all of the different media query requirement for resolution (of which you need to write at least four different queries for currently) while just writing the standard. The no-query fallbacks are a huge win as well.

MW: The main benefit is that you can assign names and manage your media queries with variables. This helps you avoid having them scattered around your SCSS, and makes is easy to understand how they’re related and affect each other.

MW: While Breakpoint is optimized for min-width because they’re used most often it doesn’t stop there. There are a number of shortcuts built in, for fencing min- and max- values, converting pixels to ems, and even vendor prefixed queries like resolution.

MW: We even created a way to Breakpoint to report back to you what queries are in a particular context. Singularity GS uses this feature to kind of magically create responsive grid systems.

SR: Of all of Breakpoint’s features, probably the least used, but most powerful is Breakpoint Context. This allows you to call a function anywhere and get the current media query context allowing for amazingly intelligent mixins and functions to be written in Sass, something unique to Breakpoint that you simply don’t have with interpolating variables.

IB: Are there any responsive web design aspects specific to Drupal theming/frontend development that Breakpoint helps with?

SR: There is nothing Drupal specific that Breakpoint helps with. Breakpoint, like Sass, was built to be backend independent. This means that if you are building any site, regardless of if it’s a Drupal site or a Node site or a static site, Breakpoint is able to do its job handily without being caught up in being tied to a specific backend technology.

MW: One of the things I love about working with Sass is that it’s not Drupal-specific, and it’s meant to be used anywhere on the web. Breakpoint follows that example.

IB: Is Breakpoint a successor to Respond-To, or will that continue to get developed?

SR: In a way, yes and no. Respond-To was written before Breakpoint, but upon Breakpoint’s release, it was decided that our efforts should be focused on a unified Media Query engine, with Respond-To as a wrapper syntax for Breakpoint. This is how the current Respond-To project exists. As of Breakpoint 2.0, the Respond-To mixin has been incorporated into Breakpoint core, so you now can use Respond-To without needing an additional Compass extension!

IB: Do you use Breakpoints module (in Drupal 8 core)? Or do you just do all of that through Sass?

SR: I personally truly dislike the Breakpoint module. Every use case I’ve heard for it seems to be based on the thinking that sites have three or four breakpoints and that everything can be boiled down into an easy to use admin interface. There are no standard breakpoints, period, and good, reasonably complex responsive sites will usually have 20 or more breakpoints. Responsive cannot be done from the backend, and the Breakpoint module encourages you to do so (as does the Spark layout initiative).

IB: Do you think any aspects of Breakpoint might get rolled directly into Sass in the future?

MW: It’s possible, but we probably won’t move the obvious parts to the Sass language. There are some helper functions that we’ve written in Ruby that would be very useful in Sass core. Once that’s in we’ll be able to offer Breakpoint without Compass.

SR: I do not believe Breakpoint will be rolled directly into Sass, nor would I want it to be, as it is out of scope of Sass core. As much as I like them, I even think the color functions in Sass are out of scope for it. Sass core should simply be the language and the bare minimum function base for it to be useable. Sass doesn’t ship with any mixins, and I think it should probably stay that way. That being said, Breakpoint is fairly stable; our 1.3 release stood stable for six or so months without needing any changes until we rewrote the whole thing for our 2.x release, so maybe being merged into Compass isn’t out of the question, but I do not see a need for that.

IB: I hear in addition to Breakpoint, Sam went and created some kind of magic box of Sass called Toolkit. Want to say more about that?

SR: Toolkit started life as RWD Kickstart, a project Mason and I kind of made up on the spot a year ago at one of the first New York Sass meetups. Its original goal was simply to be a collection of Compass templates to make pulling in media query and grid solutions together easily. Since then, it’s evolved to be more of a collection of Progressive Enhancement, Design in Browser, and Modern Web Development tools, a toolkit if you’ll let me, of useful tools. I’d say the four biggest thing that Toolkit has are a modern Clearfix mixin, progressive enhancement replace text mixins, a triangle generation mixin, and an intrinsic ratio mixin to make using intrinsic ratios super easy. It also adds *, *:before, *:after { box-sizing: border-box} and img, video { max-width: 100%; height: auto; } to your stylesheets, which are the first two things I do for any responsive project.

SR: Toolkit’s templates have also evolved, Where originally there were five some odd different templates to choose from, now there are just two, a basic one to set up a basic partial structure, and a responsive web design one that pulls in Breakpoint 2.x for media queries and Singularity 1.x for grids.

IB: You sure know those late twentieth-century presidents.

MW: With a name like Breakpoint, how could I not revisit the cinema classic Point Break. Bodhi and his gang of thrill-seeking bank-robbing surfers evaded the FBI for years until the newly minted Special Agent Johnny Utah was on the case. I think we can all agree that there’s a poignant metaphor for web designer there. And some pretty sweet gifs.

Image credit Flickr user missnita

May 17 2013
May 17

A new theming engine, Twig, is coming along with DrupalDrupal is an open-source content management system (CMS) used for many complex nonprofit sites. Other examples of CMSes include WordPress, Joomla! and Plone. 8’s adoption of the Symfony framework. And it’s downright magical.

Instead of having theme functions that have to be overridden, everything becomes an (easy to read, easy to modify) template. Instead of having to figure out render arrays, themers can use consistent template variables. And instead of having insecure output, Twig sanitizes everything by default.

If you’ve ever worked on a WordPressWordPress is an open-source content management system (CMS) used for many blogs and nonprofit sites. Other examples of CMSes include Drupal, Joomla! and Plone. or Tumblr theme, the approach will feel pretty similar. Here’s what it looks like:

Example of Twig template in Drupal

And oh by the way, it’s well-documented — no small point in the Drupal community!

Sound too good to be true? Well, it almost might be, because a lot has to happen in order to get this into Drupal 8. There’s a Twig-focused sprint happening right after Drupalcon, so if you think this is great, come pitch in! Because if things don’t get done, Twig will be held until Drupal 9. No Drupal themer, veteran or newbie, kitten or human, wants that to happen.

I spoke to Jen Lampton (with a contribution from Fabian Franz) about how Twig will result in happier veteran Drupal themers, happier new Drupal themers, and happier Drupal kittens. Be sure to show up for their featured Drupalcon session (along with Drupal CSS innovator John Albin Wilkins), “Using Twig: The new template engine in Drupal 8,” on Wednesday at 3:45 PM.

IB: What’s one thing you’re most excited about with Twig?

JL: Replacing the template engine with something completely different means that we get to take a good hard look at absolutely everything in the current theme system, so we can do a clean sweep.

FF: What I love the most about Twig is the syntax, and how it cleverly makes it possible to lazy-render things. The possibilities of having an interpreted language are endless.

IB: Can theme developers start converting/creating their themes now?

JL: No! If you have the time to start converting your own themes, then please, please, please use the time to help us make the theme system what you want it to be — instead. There will be time to convert your themes later, but Drupal itself can only be monumentally improved right now.

IB: Will frontend developers and themers coming from other CMSes — like WordPress — find Twig easier to use?

JL: Yes. Front end developers coming from everywhere will find Twig easier to use. For starters, Twig looks a lot more like HTML, so if you don’t know PHP you’ll still be right at home. For people who do know PHP and don’t know Twig, there will be a learning curve, but it’s far far FAR less steep than learning about what Drupal had done to PHPTemplate.

IB: Twig sounds great! What can people do to help make sure it happens for Drupal 8?

JL: There are four main areas where we need help right now, as outlined in our Twig TODO wiki.

1. Help us test all the patches.

2. Help us fix issues with the patches.

3. Help us improve the markup in core (after being converted to Twig).

4. Help us clean up the rest of the theme system.

If people are interested in any one of these four areas, they can come to the sprint immediately following DrupalCon and get some hands-on help making Drupal better. We need all the hands we can get since we are up against some major deadlines, so please please please come help us!

Image credit Flickr user cgc

May 16 2013
May 16

I’m a millennial, but even I remember the experience of calling the telephone operator and getting a live human to look up the number of a business or place a collect call. We have the digital means to complete lots of tasks like that today, but that doesn’t mean all of our methods are equally effective for everyone.

Drupal's new mobile-friendly toolbar“Drupal 8 will be the most accessible version of Drupal yet,” declare J. Renée Beach and Wim Leers in their Drupalcon Portland session description.

They’re both part of the Spark team, an initiative to improve the authoring experience in Drupal for everyone.

Spark is more well known for things like in-place editing and a mobile friendly toolbar, which you can see at right. But from the beginning, improving the experience for everyone has been a big priority, and one of the most exciting developments is a new aural interface.

That’s right, Drupal is getting a switchboard operator:

Drupal announce log showing three 'polite Drupal announcements'

OK, so that doesn’t look terribly exciting all on its own. But trust me, when you watch the videos of people interacting with Drupal 8 and having menus and selections read as they go, it’s pretty cool.

When I spoke with J. Renée about Drupal 8 and the nature of working on accessibility, the passion for this work really shown through. I’m really looking forward to their session with Wim, “Drupal Speaks: Aural user interfaces, new Drupal 8 accessibility features,” on Wednesday at 10:45 AM. Hope to see you there!

IB: What are we missing when we talk about accessibility right now?

JRB: I want developers to understand that accessibility is fundamental to user interface development. We tend to talk about accessibility like we talk about gender. Both have coded values. When we speak of being gendered, we are often talking about being non-male. Male is a kind of genderless base state. So is it with accessibility. When we speak of making something accessible, we tend to refer to making an interface for blind users or for users with physical capabilities that make keyboard and mouse use difficult, as examples. Visual is a kind of accessible base state.

We risk “othering” folks for whom accessibility is an issue because as developers, in general, non-visual accessibility has not been a primary concern. I know what is is like to be othered. In some ways, highlighting otherness can be an effective way to bring focus to a problem. Eventually though, we need to resolve those issues and close the loop on the otherness. We can be other and also be equal. Now is the time for front end developers to start thinking about accessibility as a multi-modal effort. We no longer have the excuse that the tools and technologies available to us do not support efficient workflows for non-visual UI development.

IB: Where is Drupal 8 going to do better?

JRB: Most importantly, we have more individual core contributors this cycle who truly believe in addressing accessibility issues. And they are all smart, wonderful people which makes working with them a pleasure!

For example, take this issue about requirement warnings during installation. For a sighted user, a warning during installation is immediately apparent. The missing requirement is made distinct with color contrast. For a blind user, they must traverse every cell in the table to discover a missing requirement. Would we ever impose such a burden on a sight user through the UI? No, not without grumbles in the issue queues at least. With more contributors invested in improving these types of non-visual details, we are polishing all the rough edges — the ones we see and the ones we don’t.

IB: How important is context in aural interfaces?

JRB: Context is important to all interfaces. As front end developers we build templates that expose context in a predictable, consumable way. As a practice we have established and then refined patterns of visual expression over the past 30-plus years.

Metaphors grounded visual pointer displays on a virtual desktop. We talk of visual affordances in rounded, gradient-embellished, reflective buttons. Skeumorphic designs bring our understanding of the physical world to bear on pixels and bits.

Where are the metaphors in aural interface design? I know of none. To me, these interfaces are flat. The metal is bare underneath them.

Perhaps non-visual interfaces have one less level of abstraction to traverse. Maybe there’s no need to translate language into symbol and then back into language. But that little bit of designer in me, that memory of a linguist I almost was, remembers being thunderstruck with insight reading Jackendoff’s unfurling of metaphor after I had just so recently fallen smitten with the strict generative grammar of early Chomsky. Jackendoff gives us a way of understanding language that starts at basic physical dichotomies — up/down and near/far — and from there offers us a model of communication. He gives us pattern. (Early) Chomsky gave us metal. So much that we humans do starts with structure that softens with time to fit our curvy, winding nature.

I want to believe that the aural interfaces we have today still just the awkward first attempts to build an abstract audio interface pattern language. That non-visual interface design is still working through its structuralist phase. We are still learning how to pack context into denser forms through non-visual expressions.

IB: Will the Drupal 8 improvements have things to offer module developers?

JRB: In Drupal 8, we are building tools that manage a couple of the trickier components of accessibility in a browser. These are:

1. Outputting audio updates

2. Managing tabbing in constrained workflows

Module developers will be able to pass a string to a method called “announce” on the Drupal object and have that string read by a screen reader.

Another method on the Drupal object called “tabbingManager” will constrain tabbable elements on the page. A developer will select those elements, either through JavaScript methods or jQuery, and pass them to the tabbingManager. Tabbing is then constrained to those elements until the constraint is superseded or released. I know that must not be completely clear, but that’s why we’re presenting a session about aural user interfaces and how we can use these new tools to build them!

Top image: Public domain. Drupal images from the drupal.org issue queue and the session slides.

May 15 2013
May 15

Ah, base themes.

If there’s an analogue to the Windows/Mac/Linux battle in DrupalDrupal is an open-source content management system (CMS) used for many complex nonprofit sites. Other examples of CMSes include WordPress, Joomla! and Plone. land, it’s probably Zen vs. Omega vs. AdaptiveTheme.

Garrett Dawson and John Ferris have a way out of that eternal struggle: Custom base themes. As they put it in their Drupalcon Portland session description:

“By necessity, base themes make assumptions about how teams and individuals work. By rolling your own, you’ll become much more comfortable and informed about the Drupal theming layer, and have a better launchpad for your front-end projects.”

Here in Portland we take home gardening and permaculture seriously, so what better place to talk about “growing your own” custom base theme!

I spoke with John and Garrett about how creating your own base theme can make work for you and your team easier. Take a gander at their session, “Dapper Drupal: Custom Tailored Themes,” on Thursday at 2:15 PM for the full story!

IB: Base themes that are out there make some assumptions about how you want to theme. What’s the advantage to rolling your own base theme rather than finding the theme that already makes the assumptions you do?

JF and GD: If you can find a base theme in contrib that fits perfectly into your workflow, by all means, use it. There’s a lot of solid tools out there. We don’t want to deter people from using and contributing to them. With that said, we feel it’s unlikely a contributed base theme will be ticking all the boxes and making all the right assumptions about your workflow.

There’s no one-size-fits-all approach. Your front-end process is heavily influenced by team dynamics, contrib module choices and a whole host of other considerations. The majority of base themes cannot account for those variables like you can. We want front-end developers to take a critical look at their tools to see where they can make improvements. That may mean creating a custom base theme; a custom starter theme for use with an existing base theme; or even a set of helper modules.

All the popular base themes started because someone wasn’t happy with what was available at the time. The ultimate goal is increasing efficiency while improving the quality of the final HTML, CSS and JS.

IB: Do you recommend custom base themes for big shops? Small distributed teams? Freelancers? Everyone?

JF/GD: Yes, all of the above. At least consider it as an option. If you find yourself doing any kind of repetitive work, there’s an opportunity for improvement. The only people who should steer clear of custom base themes are those new to Drupal. You need to be familiar with the tools that are available before setting out to create your own.

IB: Besides your the custom base themes you developed yourselves (Center and Prototype) what other custom base themes have you seen in the wild?

JF/GD: Yes! We’ve learned a lot working with and iterating on Center and Prototype. They work well for the structure of our team and the type of work we do at Aten. However, we realize every team is unique. We were really interested in seeing how other organizations were approaching the front-end problem space. We chatted with a range of teams of varying sizes working across different industries. Everyone has their own unique set of tools based on their own strengths and constraints. We’re excited to share those with you, but you’ll just have to come and see for yourself!

Images: National Archives and FlickrFlickr is a social media site for photographs and digital images. Like a social network, it allows users to “friend” one another, join groups, and see a recent-updates feed of their own and their friends’ images. Flickr is owned by Yahoo!. user McBeth.

May 15 2013
May 15

It’s fair to say that in the last year, adopting the CSS preprocessor SASS has completely changed frontend development for me. That’s a sentiment I’ve heard others express when they started using it — and I was pretty late to the party.

I got attracted to it initially through variables. We’ve all been there when a client or a designer wants to change a color and suddenly we have to change dozens or hundreds of values across CSS.

Dale Sande captures that kind of revolution in efficiency that SASS brings, as seen in a screenshot from his upcoming presentation at Drupalcon Portland.

But Dale, who’s spoken plenty on SASS and organizes the Seattle SASS meetup, is taking us way past the SASS basics like variables, and that’s why I’m excited to see his presentation next week.

Around the same time SASS came onto the scene, some thoughtful people were exploring more maintainable frontend development and CSS architecture through ideas/acronyms like OOCSS, SMACSS and BEM, and folks like Nicole Sullivan, Jonathan Snook (a Drupalcon featured speaker!), Nicolas Gallagher, and Harry Roberts.

I spoke with Dale about SASS, object-oriented CSS and some the things he’ll be covering at Drupalcon. Be sure to join me at his session, “Sass: OO’S’CSS w/Extends and Silent Placeholders,” on Wednesday at 2:15 PM!

IB: Some people argue SASS creates bloated code — do you see placeholders addressing that concern effectively?

DS: Sass doesn’t create bad code. Bad coders do.

The whole concept of placeholder selectors was designed to fight code bloat and be a more pragmatic solution to OOCSS. In my presentation, I illustrate how using the various techniques generate code.

The real “ah-ha” moment comes when we see how using placeholder selectors makes it easier to manage and literally re-use code — thus reducing dreaded CSS bloat.

IB: What’s the advantage to using silent placeholders over mixins for a set of rules?

DS: Simply put, being able to re-use code without duplicating code. The use of mixins was the first part of being DRY with our code. Looking at the Sass it felt AWESOME! But when we looked at the output CSS, this is when we realized that we were all living a lie.

Our CSS rules were being duplicated tens, if not hundreds of times. We weren’t being DRY, we simply put the onus of duplication on the machine.

Placeholder selectors embrace the one of the oldest concepts of CSS and that is to extend the CSS selector for reuse. But with traditional CSS this was difficult to do, especially when you were dealing with thousands of lines of code. Sass’ @extend directive allows developers to create name-spaced reusable chunks of code that is portable, re-usable and extendable without duplicating anything.

Fighting tight coupling in CSS by keeping code separation in SASSIB: Do you see placeholders as helping to reduce the amount of tight coupling — scattering pieces of styles in multiple places?

DS: While Placeholder Selectors are a tool that can help with scattered code, it is not the only solution. Having a file/folder structure that embraces the different types of code, e.g. CSS selectors, placeholder selectors, mixins and functions, can assist in creating reusable modulare code and maintain a process of control over the many parts.

Images: Screenshot from Dale Sande’s presentation.

May 13 2013
May 13

The big news at Drupalcon Portland is that, for the first time at a Drupalcon, we’re having separate frontend and user experience (UX) tracks. That means we were able to offer even more sessions targeted directly at frontend developers, and as the local track chair for frontend, I’m really excited about what we’ve ended up with!

Groundbreaking frontend featured speakers

Jonathan SnookFirst and foremost, of course, we have Jonathan Snook presenting on his concept (and book) Scalable and Modular Architecture for CSS.

MortenDK at Drupalcon SydneySMACSS has had a big impact on a lot of frontend developers and themers — and in fact it’s had a huge impact on Drupal itself. The Zen base theme, the most-downloaded Drupal theme out there, has adopted a SMACSS approach.

And Drupal itself is moving toward SMACSS with a re-organization of its CSS in the upcoming Drupal 8 release.

Join Jonathan Snook at Drupalcon Portland on Tuesday, May 21 at 4:30 PM.

Drupal 8 and Twig

Oh yeah, so there’s this new version of Drupal coming out pretty soon.

Among the many, many awesome things happening with Drupal 8, one of the most relevant to frontend developers is the adoption (with a little luck) of the Twig templating engine.

Twig, a component of Symfony — a framework being adopted by Drupal 8 — will enable themers to write much cleaner (and safer!) code, and enable module developers to simplify the theming components of their modules.

No joke, at the BADCamp 2012 Twig session, there were literally gasps in the audience as we all saw how cool it was. If you’re a themer or a frontend developer, don’t miss this!

Join Jen Lampton, Fabian Franz and John Albin Wilkins presenting Twig on Wednesday, May 22 at 3:45 PM.

And so much more!

I’ve just touched on two of the featured sessions at Drupalcon Portland. In the coming week I’ll be posting more about some of the other sessions, but you can browse the frontend sessions right now and start planning to attend your favorites! (Don’t forget the User Experience sessions too.)

And if you don’t yet have your ticket to Drupalcon Portland, there’s still time! Grab your ticket by this Friday and save $50 off the on-site ticket price.

I can’t wait to see everyone here in Portland!

Feb 15 2013
Feb 15

As the local track chair for the frontend track, I’m posting this to encourage any last-minute session proposals bouncing around in your head to get typed out and proposed today.

That’s right: Today’s the Portland Drupalcon session proposal deadline. Submit your proposal now!

(And yes, nonprofit and nonprofit developer friends, there’s an NGO track too.)

This year, the frontend track has been split off from the user experience track, so you can be even more specific in your proposals. Here are the descriptions for both tracks:

Frontend: Connecting new tools and techniques to create an effective Drupal frontend experience

The frontend experience of a website is crucial to its success. Though the backend of a site may be impeccable, the frontend experience gives the user the first impression of an organization or company. Without a good frontend experience, a site can turn users away. Let’s discover ways in which we can connect our knowledge of different frontend tools and techniques with Drupal — and make Drupal a better experience for all users.

Main Themes

  • The importance of frontend development in creating websites + web apps
  • What frontend developers need to know to work well with backend devs, PMs, UX, Content Strategists
  • Preparing frontend devs for D8 and Twig
  • Frontend for mobile
  • Using frontend frameworks such as Foundation and Bootstrap
  • Speeding up the design process
  • Frontend development for multilingual sites

Audience

  • Frontend developers
  • Backend devs that do Frontend work
  • PMs that work with Frontend devs

User Experience (UX)

The User Experience process is key to the success of the development of websites and web applications. From user research, interviews and analytics, we learn what the user actually wants and needs; not what we assume they want. At this year’s DrupalCon we present a new User Experience track to show our community’s dedication to user needs.

Main Themes

  • Explaining what user experience is and why it’s important
  • UX for mobile and tablet, Responsive UX
  • Speeding up the design process using UX tools and techniques
  • UX for multilingual sites - especially RTL
  • Content Strategy

Audience

  • UX professionals - Drupal
  • UX professionals outside of Drupal
  • Backend devs that are interested in UX
  • Frontend devs interested in UX

For the frontend track, global track chair John Ferris and I are looking for balance among three big areas: CSS and CSS metalanguages like SASS and LESS; jQuery and JavaScript; and Drupal 8’s new template engine, Twig. There are also topics that span those areas, such as frontend mobile development (including responsiveness) and multilingual frontend development.

If you’re wondering whether you should submit a session proposal, as track chair let me clear it up for you: You should!

Awesome frontend speakers

Drupalcon has some exciting keynote speakers, such as Karen McGrane. But the frontend track has some special guests we’re really looking forward to:

So if you haven’t already, be sure to grab a ticket and get your travel figured out to my (new) hometown of Portland for the 2013 North American Drupalcon!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web