Feeds

Author

Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Jun 08 2016
Jun 08

Last month, I gave the third in a series of front-end web development talks here in Taipei. The 10 attendees and I discussed style-guide-centric development and front-end development automation.

The seminar was designed to be hands-on, so we started by installing Node.js and downloading Zen 8.x-7.0-alpha8 so we could play with code while discussing the evening’s topics.

Putting the style guide at the center of your development cycle is something that I’ve talked about many times before. As you build out each component of your design, it immediately goes into a style guide. Visualizing the component in an isolated manner makes it easier to construct the component, its elements, and its variations.

While I’ve given talks and written blog posts on this subject before, I’ve never built a style guide for a Drupal 8 site. This third talk in the Taipei seminars gave me the chance to build incrementally on the previous two talks, component design and Drupal 8’s Twig. Ideally your style guide should be using the exact same CSS, HTML and JS that your application is using. With Drupal 7, integrating the PHPTemplate system into a style guide was a non-starter for me; technically possible, but too difficult to invest the number of hours it would require. In the week leading up to this seminar, I started porting the Zen theme to Drupal 8.

Using the Twig template language we played with during the second seminar, I showed the attendees for the first time how I imagined you could build a Twig-based component library and integrate it with Drupal’s theme layer.

With vanilla Twig, you can construct a very simple component with the exact HTML you wanted and the exact variable names you wanted. Then you can convert Drupal’s very Drupal-ly variables and render arrays into the variables that your component expects. Just use the *.html.twig template to convert the variables from Drupal into the variables needed for the component and then extend/embed/include the *.twig component.

I’ll write a more detailed blog post on this soon. But it was really cool to share this method for the first time and get some early feedback.

From there I showed attendees how to “start living the dream” by taking the component written with Twig, CSS and JS and pull it directly into a style guide with KSS comments and the first of our automation tasks. Since we’ve pulled out the Drupal-specific variables out of our Twig files, that allows kss-node to use the component Twig file with Twig.js (the Node.js port of Twig). We have once set of HTML (the .twig file), of CSS, and of JS and both the style guide builder and Drupal uses it. Hooray!

We then launched into using a task runner to control all of the front-end development tasks we need to do. Automating our best practices means we can spare time for improving our craft.

I showed them Gulp.js and its very simple API that makes writing new tasks a breeze.

The most fun part of the evening when was when someone asked me to demo the Browser Sync task that comes with Zen. I ran “gulp watch” from my command line and that started up a BrowserSync proxy server that served up my Drupal site and style guide on a special URL. Then all of the attendees went to that URL and I could control the scrolling of the page on their machines with the mouse on my computer. It was pretty cool.

This seminar was amazing for me. I love doing hands-on deep dives of concepts and technology. If you missed the class or don’t live in Taipei, I’m available to teach your organization remotely or in person. Just contact me!

Apr 17 2016
Apr 17

Last Friday, I gave the second in a series of front-end web development talks here in Taipei. There were 11 attendees as we discussed in length how to use the new Twig tempting system while building a Drupal 8 theme.

Like the first class, the participants were engaged and really probed the new concepts of Twig and its syntax. We talked for over 3 hours; here are some highlights:

We started the evening, not by talking about what’s new in Drupal 8 theming (everything!), but about the short list of what’s old in Drupal 8 theming:

  • Clearing the cache
  • The theme registry and "theme hooks"
  • Base themes and sub-themes
  • Render elements

We talked about how you need to define libraries of CSS and JS files instead of adding them directly to your .info file.

# Adds a library to all pages.
libraries:
  my_theme/my_custom_library
libraries-override:
  # Removes an entire library.

  system/base: false
  core/drupal.vertical-tabs:

    css:

     component:
        # Overrides a specific library asset.

        misc/vertical-tabs.css: css/zippy-tabs.css
        # Removes a specific library asset.
        misc/veritcal-tabs.js: false
libraries-extend:

 core/drupal.vertical-tabs:

   js:
      # Adds an asset to an existing library.
      js/even-more-vertical.js

I had to update my slides because one of the attendees pointed out I didn’t have an example of overriding a library asset. The full documentation for libraries is at: https://www.drupal.org/theme-guide/8/assets

I showed how the default values for theme settings are no longer stored in the .info file, but instead loaded from the config/install/THEME.settings.yml file:

# Define the default values of the theme’s settings.
zen_breadcrumb: 'yes'
zen_breadcrumb_separator: ' › '
zen_breadcrumb_home: 1

James asked if the form itself was still specified in the theme-settings.php file. When I went to double check in the Drupal 8 Theming Guide, we found that it literally said “TODO”. We did some Googling, found a rough answer on Stack Exchange, and then updated the D8 docs page

We discussed the {% extends %} tag and how it is the perfect complement for theme hook suggestions.

{% extends "block.html.twig" %}
{% block content %}
  Just modify the block you want to be different from the default block.html.twig.
{% endblock %}

Kevin asked if we could do define nested blocks. I had no idea, so we tried it out. We modified the block.html.twig file to have:

... {% block content %} {{ content }} {% block nested_content %} HI, KEVIN! {% endblock %} {% endblock %}

And then modified the block—search-form-block.html.twig file to be:

{% extends "block.html.twig" %}
{% block content %}
  
    {{ parent() }}
  {{>

This was a great class. I learned a tremendous amount about Twig just preparing for it and the discussions that the participants started helped me learn even more. Thank you so much to all who attended!

Again, if you missed the class or don’t live in Taipei, I’m available to teach your organization remotely or in person. Just contact me!

Mar 21 2016
Mar 21

Last Friday, I gave the first in a series of front-end web development talks here in Taipei. There were 11 attendees as we discussed in length how to structure a site’s styles with CSS components and Drupal 8 naming conventions.

The success of the class was entirely due to the participants who were engaged and asked lots of questions to probe their understanding of the concepts and challenge me on things that seemed a bit off on my slides. We talked for over 3 hours; here are some highlights:

We started the evening by going over the core front-end development principles: progressive enhancement, accessibility, front-end performance, re-use, and automation. When we talked in detail about the layered approach for progressive enhancement, they noticed right away that it implies accessibility. Very astute! Now that I’ve had a few days to reflect on this, I can see a general pattern. Not only does progressive enhancement imply accessibility. Accessibility implies front-end performance. Front-end performance implies re-use. Re-use implies automation. They are all inter-related.

A few of the participants had used Angular.js, so we discussed how Web Components (the W3C spec), React.js components, and other framework components are slightly different than CSS components. Those components require a specific HTML element that contains any other markup; this forms a strict HTML structure that is always used when the component is used. CSS components, on the other hand, have a strict structure of class naming, not of HTML elements. The structure of our CSS component, e.g. .the-component, .the-component__an-element, etc., should never imply an HTML structure because they could be applied to different HTML structures. The classic example of this is the .button CSS component which can be applied to inputs (), buttons (), and links ().

They were amused by my drawing skills when I showed them my example CSS component: flower power.

When they saw my .flower__bed element, they asked how I would handle adding a .tree component that could also use a planting bed. Great question as it shows a very typical scenario in web development. I built the original .flower component with a simple initial requirement: the website only has one component. Now they were saying the requirements have changed; we have a design system with multiple components, a flower and a tree. Changing requirements on projects is natural. In this case we just need to do a simple re-factor. The .flower__bed probably needs to be refactored to be its own component, a .planting-bed component that can contain a .flower or a .tree.

They loved the class name of shame, .channel-tab__guide__upcoming-video__info__time. That name implies all sorts of HTML structure that makes the component difficult to refactor. .channel-tab__video-time is more flexible and much simpler.

One participant asked about an example class name I had shown, .the-component--modifier__an-element and we discussed how that should probably be replaced with .the-component.the-component--modifier .the-component__an-element as it makes it easier to create compose-able modifiers (e.g. .button, .button--big, .button--red can be combined to create a big button, a red button or a big red button.)

I love discussions of the ideas I present because I gain valuable insight from the participants. Thank you so much to all who attended!

By the way, if you missed the class or don’t live in Taipei, I’m available to teach your organization remotely or in person. Just contact me!

Aug 16 2013
Aug 16

Today I resigned from Palantir, a company I’ve called home for almost six years. I’ve done a lot of exciting work at Palantir, but it’s time for new challenges. I don’t even know what those new challenges are yet — I don’t have a job offer and I’m not starting my own company. (I will be trying to finish my book on Sass and Compass in between now and what happens next, so watch for that.)

In these past six years, Palantir has been very, very good to me. Before I started there, I contributed in small ways to the Drupal community as I built small client sites in Drupal. With the much larger projects I worked at Palantir, I no longer had to skip over interesting facets of Drupal due to short deadlines on small projects. Instead I had more time to shape those facets and then contribute the work back for everyone. The Zen theme and the Menu Block module are just two examples of work that exist due to my job at Palantir.

I also owe my current Drupal community prestige to the support of Palantir. (Thanks, George and Tif!) Palantir has a superb group of people that are a amazing to work with. If you want to work at company with amazing opportunities, you should check out Palantir. I have a feeling they’ll soon be posting a job opening for a front-end developer. ;-)

Sep 11 2012
Sep 11

At Drupalcon Munich, one of the awesome things was seeing so many people show an interest in helping out with Drupal 8’s Mobile Initiative. On the Friday after Drupalcon’s session, at that Code Sprint, there were four tables full of people helping out with JavaScript issues, Drupal’s administrative screens, responsive images, and HTML5. And, as Dries’ recent blog post shows, now is the perfect time for you to help out with the Drupal 8 Mobile Initiative. Feature freeze is coming on December 1st and we still have lots of things to accomplish.

If you’ve never worked on Drupal core before, no worries! The community is currently building a “Drupal Ladder” learning curriculum to help people level up their abilities as they climb its skill-based ladder. You can quickly learn how to contribute to Drupal development and then use your new skills to make Drupal 8 mobilicious! Jump on the Drupal 8 Core ladder at http://learndrupal.org/ladder/ee503327-50be-1904-8d04-9499098cad64

If you’ve already climbed the ladder, you can start helping out the Mobile Initiative immediately. With feature freeze so close, we’re having weekly initiative meetings to create as many opportunities as possible for newcomers. In fact, there’s a meeting today! http://groups.drupal.org/node/252318

What’s our focus?

The scope of the Mobile Initiative includes a few varied subjects, so there’s lots of different things you can work on:

  • Responsive Web Design
  • Front-end performance
  • Mobile administration
Slide from the progress report given at Drupalcon Munich.

Because we will still be able improve features and increase performance after December 1’s feature freeze, we will be focusing on those items that are “new features” for Drupal 8. Here’s three items I’d like to tackle first:

Admin navigation

When a user first installs a Drupal site and loads it up in their mobile device, the administration section of the site is literally the first impression they will have about Drupal’s mobile capabilities. Having mobile-friendly admin screens is a great way to quickly say “Hell, yes, Drupal loves mobile!”

In addition, being able to edit and draft Drupal content while waiting in line or or on the train (all the typical mobile locations) would be a big boon to productivity when administering a site.

Lewis Nyman’s early passion for this subject convinced me of how important mobile administration is to Drupal 8’s success. It’s why I made sure it was in the top goals of the Mobile Initiative. And now Acquia has taken up the cause with their Spark project; originally proposed as a Drupal 7 project, Spark received such wide praise during Drupalcon Munich, that the Acquia team has decided to first work on a Drupal 8 version before backporting to D7. But only if the Drupal community helps with the work!

Jesse Beach put up a demo site showing the current state of the work. (There's also a video showing possible admin navigation interactions a few comments earlier.) She’s currently looking for people to work on the code; just create an issue in the Git sandbox and Jesse can give you commit access.

Issue #1137920: Redesign Administration Tool bar for Small Screens & Touch Screens

Assetic

Assetic is a Symfony component providing pluggable processing of JS and CSS, making coffescript, Uglifyjs and custom aggregation groups easy and painless. Drupal 7’s current aggregation is a decent, general-purpose tool, but to achieve optimal front-end performance, engineers often have to work around the system and create custom solutions. A pluggable Assetic solution would make it really easy to extend and tweak the existing system instead of re-writing it.

Much of the front-end performance work we have planned can be continued through feature freeze, but this clearly falls in the "new feature" category, so we need to work on it now.

Théodore Biadala (nod_) has been heading up the JavaScript changes for Drupal 8. Since Symfony is a new part of Drupal, we need either need people with some Symfony or Assetic knowledge or people with a strong desire to learn these exciting new technologies.

Issue #1751602: Use Assetic to handle JS and CSS files

Responsive images

Responsive images is a serious front-end performance problem that the entire web industry is struggling with. Fortunately, the Drupal community has been very active in the proposed HTML element and we’ve made a commitment to provide a reasonable forward-looking solution to this thorny problem.

The current work is being actively worked on by Peter Droogmans (attiks). We’ve recently decided to break this task into several sub-tasks, listed below by importance. Drupal 8 will need a way to configure the different sizes used for a responsive image. And, while a UI for setting breakpoints for the site would be mighty useful, and API for setting breakpoints is needed first.

Issue #1775530: Move picture into core
Issue #1775774: Allow themes to identify their breakpoints to Drupal
Issue #1734642: Move breakpoints into core
Issue #1170478: Responsive images [meta issue]

Even more stuff

After feature freeze, the Mobile Initiative will be pivoting to focus solely on front-end performance and improving the features that make it into Drupal 8 before December 1. This includes improving our already-responsive themes and continuing to add to our Drupal 7 Mobile Guide.

Let’s get to work!

May 24 2012
May 24

Homebrew is pretty damn sweet if you are a developer on Mac OS X. It’s the package manager that doesn’t suck.

But the developers that run Homebrew aren’t PHP developers. And their official policy of not providing a formula (homebrew’s name for a “package”) for software already included in Mac OS X means that PHP wasn’t going to be available in Homebrew.

This is a pretty big problem considering many PHP developers need to test their application against a newer version of PHP than what Apple provides. Fortunately, they recognized this was an issue, found a PHP developer that was interested in this problem space and came up with a generalized solution to "how do we give specialized developers better control of Formulas in their field?"

The new Homebrew 0.9 adds a new command, brew tap, that allows you to “tap” a an alternative source of Homebrew formulas. (You can figure out if you have Homebrew 0.9 with brew -v. If you’re not up-to-date, simply brew up!)

And, (bonus!) there's already an official tap for PHP formulas. Setting up your homebrew install to use the new PHP tap is incredibly easy. Just: brew tap josegonzalez/php. And you’re good to go!

So far I’ve only had a chance to try out 3 of the PHP formulas:


brew install php53-xhprof
brew install php53-xdebug
brew install php53-uploadprogress

But it’s already saved me an immense amount of time. Installing Xdebug, xhprof and the uploadprogrss pecl needed by Drupal in under one minute? Priceless.

Looks like there’s formulas for apc, mongo, solr, memcached and several others. Go nuts!

There also might be a way to have multiple versions of PHP installed. See https://github.com/josegonzalez/homebrew-php/issues/8
I’ll let others figure that out and report back. :-)

Apr 18 2012
Apr 18

This Friday through Sunday, I’m going to San Francisco to attend a sprint to “rebuild the theme layer” in Drupal 8. This is the next exciting step in a journey I started nearly 3 years ago.

I’ll hope you’ll join me at the sprints as we combat Drupal 7 and the Arrays of Doom!

A Drupalcon 2012 film: Drupal 7 and the Arrays of DoomModified slightly from a tweet by @SGreenwellUT

Scene 1. [Day break. Our themer is hunched over his keyboard writing awesome themes in Drupal 6, but he’s troubled.]

The loose thread that unraveled our shirts

While using Drupal 6, there were often times themers would come across a template variable that they needed to alter, but, in drupal 6, all variables were PHP strings that had already been rendered into HTML. In order to alter the HTML they didn’t want, themers had to resort to using awkward PHP string manipulation functions or trying to retrieve the original raw data and starting over. While contributing to Drupal 7, I had a simple idea to make it easier to modify some template variables before they were rendered into a PHP string:

  1. Load the raw data in a template_preprocess_HOOK function,
  2. allows themes to alter it in their THEME_preprocess_HOOK function and
  3. then render it in template_process_HOOK (though I wanted to call it template_render_HOOK.)

You can see the results of that work in the $classes_array and $classes variables in Drupal 7.

theme_hook_process_fail()

I wanted to extend that idea to other template variables. But almost immediately after the process hooks were committed, I discovered another group of developers had been working on solution to the same problem. Their solution was to take Drupal’s Form API and extend it be able to take raw data (in “render arrays”) and render it inside the theme system’s template files. I opposed this change as I thought it was way too complicated for beginning themers, but I wasn’t able to build consensus as the “render API” was already about 80% completed.

So, once again, a module developer and a themer were working cross-purposes at the same problem. Each of us should have reached out to the other before doing the work in earnest. hook_process_FAIL(). I ended up working with those developers to improve the render API as my only other choice was to throw my hands up and give up. Mmmmm… Lemonade. :-)

An obvious product placement in the middle of our movie

Front cover of Drupal 7 Module Development Drupal 7 Module Development

After the Drupal 7 code freeze/slush date, I got the chance to help write the “Drupal 7 Module Development” book with some great Palantiri (we all worked there when we started the book.) I wrote the theming chapters and I tackled documenting the Render API for module developers.

It was a big challenge because I had previously only thought about how to explain the theme system to themers. But I’m proud of the results. Chapter 3 and 4 of that book probably have the best, fullest explanation of the Render API available.

Uh-oh.

But after completing those chapters, I started thinking about how to explain the Render API and the rest of the Drupal 7 Theme System to theme developers. One day in IRC, chx asked me a question about the render API and it took me about 10 days to figure out the answer. And, when I did find the answer, I realized that I had written the code in Drupal core that answered his question! It had gotten complicated enough that even the developers who wrote it had a hard time understanding it.

A mess of arrows pointing at 17 different parts of the theme layerA simplified wiring guide to the Theme Layer

I knew we were in trouble so I submitted a session to the very first Core Conversations at Drupalcon San Francisco 2010. I showed this infamous slide and boasted I would try to explain the entire theme system in under 60 seconds. I almost made it. I shocked core developers with my presentation, but there were very few themers there. And it sparked almost no follow-up conversation.

I was way ahead of the pack. Drupal 7.0 was still 9 months away and I was probably the only theme developer using D7 at the time. I kept my fingers crossed that it wouldn’t be as bad as I feared.

Oh, crap.

It turned out, it was probably a little worse than I originally feared. We discovered its impossible to determine if a render element is empty. You have to change the render element to a string before you can tell if it generates any markup. This makes it really quite awkward when you want to add some wrapping HTML, but only if the variable has any markup in it. That bug is unfixed and unfixable without radically altering a common template pattern.

And the more I thought about how to explain the render API to themers the more I realized that, for themers, the render API is undocumentable.

Why? Why, for the love of god, why?

  1. The theme functions we inherited from Drupal 6 were not flexible enough to allow re-use within the render API. For example, theme_links only accepts text or rendered HTML in its list. Putting rendered HTML in a renderable array is nonsensical. Each module developer would have to solve this problem their own way since core lacked this ability.
  2. Each render element is unique. The first item in this list naturally leads to this item. The sad truth is you have to have a custom solution to build each variable in the theme system.
  3. An inconsistent HTML spec for form elements led directly to an inconsistent API. Form API’s job was to render forms, but HTML form elements are the most inconsistently implemented elements in the HTML language. Because of this, there are lots of “exceptions” and special cases built into the Form API to handle the inconsistency. Each of these special cases were given a “generalized” solution to fix with the form HTML problems, but that meant we had several generalized solutions to markup problems. Render API, as the sucessor of Form API, inherited every single one of these special cases. And, unfortunately, there are no hard-and-fast rules for when you should use #pre_render or #theme_wrapper or #prefix or #post_render or #suffix or #kill_me_now.
  4. Render elements modify themselves as they go through the system. To make it easier to create a form definition, the Render API has “default element info” and “shorthand formats”. You don't have to create the full, verbose render array that is needed to generate the HTML. All the array #types have default properties that get added to the array; unfortunately, those only get added after the array is passed to render(). So themers examining the render array won’t see any of the default properties, which may be the very ones they want to alter. But there’s a special kind of rage I reserve for #types that add default #pre_render functions. Pre-render functions are executed on the render elements before any of the other code in render() is run. And those functions can alter the render element in any way they want. Dante would be proud of us.
  5. Render elements are undocumented and undocumentable. While the Render API is documentable for module developers, the same cannot be said for the elements that are built with it. Because of item #4 above, the same render element is different depending on whether you are inspecting it from inside the template’s preprocess function or from within the template itself or from within the theme function that is used to render the element. If we document what’s in the render element while in the template file, we have an incomplete picture of how to alter it. If we fully document each element, it would take pages of writing.

A gradual realization

After Drupal 7.0’s release, themers started to complain about the lack of documentation for the render elements. A few people volunteered to document it. Rather than shout “GIVE UP! YOU’RE ALL DOOMED!”, I crossed my fingers that they would prove me wrong. Unfortunately, they did fail. (Incidentally, I ate dinner with one of these brave souls at Drupalcon Denver and he was extremely relieved to hear me call render elements “undocumentable.”)

The fact that some template variables could NOT be printed the same way was confusing and led to calls to remove data structures from templates. But, it turns out its more than a documentation problem, you can actually kill your site by using the wrong print method. For example, don’t try this from within comment-wrapper.tpl.php: Looks harmless enough. But, trying to render $content from within that template will lead to a White Screen of Death due to an infinite loop as it recursively tries to render comment-wrapper.tpl over and over.

As themers started using dsm() to drill into the render elements, their complaints just grew louder. After Drupalcon London 2011, they started swearing like sailors in the issue queue.

And then Jacine started writing up her thoughts on how to design an improved theme system. She shared some of her early thoughts and I promised I would try to summarize the problems highlighted in several lenghty threads on drupal.org and present a Core Conversation at Drupalcon so we could drum up support for actually doing something about it. I started by asking Alex Bronstein to co-present with me and asked Moshe to review the Core Conversation proposal before it was submitted. We themers needed developers on the same page from the get-go.

Catharsis

On the first day of Drupalcon Denver, Jacine posted a blog with her thoughts. On the second day of Drupalcon, we had our core conversation, “Re-thinking the theme/render layers”. The full video is available on the Drupalcon Denver site.

Some people called it surreal. I was just hoping we could drum up support for trying to redesign the theme system for Drupal 9. I only had two slides (including the one from my San Francisco talk) because I wanted it to be conversation rather than a presentation. So five minutes in, we started taking questions and comments. People kept getting more and more animated and excited as they spoke.

About 49 minutes into the presentation, Chx got up to the microphone, outlined his thoughts on the problem, and culminated by saying “I don’t think anything we have currently is salvagable. We need to throw it out.”, “We need to restart absolutely from scratch. Come up with an architecture and implement it.” and ”We cannot release Drupal 8… we just cannot… with this current system where you have these arrays of doom”. He got a standing ovation.

Hitting the ground running

Immediately after the session, right outside the doors to the room, several of us kept talking. Chx was pretty emphatic about getting started right away and wanted to have a sprint at the beginning of April. I pointed out some of us needed to finish our taxes before April 16, so we ended up picking April 20-22.

Jen Lampton at Chapter Three has done a fantastic job organizing the sprint. My flight arrives at SFO at 9am on Friday and I’ll be packing my toothbrush and my bullwhip.

I AM SO EXCITED!

Jan 16 2012
Jan 16

Kevinjohn Gallagher recently wrote “WordPress has left the building”, expressing his colleagues’ and clients’ frustration at trying to use WordPress when CMS capabilities are required. His 15 points of pain for developing usable sites with WordPress are an interesting list for Drupal developers as well. We have good solutions (that are still improving!) for many of the items on that list. Yet, we still share a few of those pain points with WordPress.

Unfortunately, Kevinjohn has been getting attacked by many of the WordPress community. While many WP fans have been writing “How WordPress took the CMS crown, his piece about his agency dropping WordPress as its go-to website solution as provoked vitriol. Over at the WP Tavern, he writes:

[…] there are more posts on WordPress community sites discussing my CV and dyslexia than the actual content of my post. Sadly in the last 7 days I’ve had 3 ddos attacks, 14 threats (4 “credible”) against myself or my family, multiple requests to have me removed from speaking at WordPress events

I know that many online discussions quickly devolve into ad hominem attacks rather than proper discussions of the issues. But there’s something slightly different going on with the WordPress community. Kevinjohn continues:

Worse of all though, is that the rhetoric of “there’s a plugin for that” is now so deeply imbedded in the WP community psyche that they constantly spout it without actually knowing if its true or not.

That one hit a bit close to home as my book, Drupal 7 Module Development, actually includes a similar quote:

There’s a hook for that.™

It seems that many in the WordPress community take its “superiority” for granted and see honest criticism as an attack against WordPress. Fanboyism has overtaken listening to the users.

Drupal has had its share of well-known community members switching away from Drupal. Development Seed, James Walker’s walkah.net and Steven Wittens’ acko.net are now all built with Jekyll.

There’s a lesson for the Drupal community there. Don’t be complacent. Don’t be tone deaf. Don’t get cocky.

Nov 23 2011
Nov 23

The Zen theme had its fifth birthday on October 11, 2011. While that milestone just slipped past without my notice, I’ve recently been thinking a lot about things that I’m grateful for. Zen, like Drupal core, improves because of the influx of new ideas and solutions to shared problems. And I’m extremely thankful to all those that have contributed their work.

More than simply saying “Thank you” to all those who’ve contributed patches to both the code and the documentation, I’ve decided to convert each contributor’s name into an actual Git commit. That sounds pretty geeky, but the real purpose of those commits is so each person’s name shows prominently where it belongs… on Zen’s Maintainers page.

I have a really useful Git tip for project maintainers below. But I’d also ask that you please join me (in the comments of this post) in thanking all of the people who have contributed to make Zen great.

How I thanked all the contributors

Zen has had a CHANGELOG.txt since I started maintaining the project. I’ve used it for two reasons: to list all the significant changes to the software and to thank everyone who helped with a patch.

While Git (and that troll of version control systems befor it, CVS) does have a ”log” of all the commits, its not a very useful list of important changes to a project. It’s littered with trivial messages and project maintenance notes like “Fixed typo in README”, “Added docblock” and “Fixing code formatting“. So I’ll continue to use a CHANGELOG to note the most important changes to the software. This also makes it really easy for people to see what’s happening in the latest -dev release.

After today, I will stop using the CHANGELOG as the primary way to thank everyone who helped with a patch. Not enough people look in that file.

How I now thank multi-contributor patches

However, while converting every contributor’s name into a real Git commit, I realized how I can leverage the CHANGELOG so there's one commit per patch author.

The following line in the CHANGELOG is nearly identical to the commit message for the patch. But, of course, the “author” of the commit will be me even though multiple people helped had contributed. So only I would show up on Zen’s maintainers list.

#200495 by JohnAlbin, caroltron, and Toe: Split up monolithic zen.css into smaller, logical stylesheets

Since the Drupal community has moved to Git, dealing with a patch with a single author is easy. I simply follow the advice in Drupal’s Git Handbook and use this command to commit the patch:

git commit --author="rfay "@30906.no-reply.drupal.org>

For a multi-author patch, I now leverage my CHANGELOG.txt to give everyone a proper Git commit.

First, I’ll add this to CHANGELOG.txt:

#200495 by JohnAlbin, caroltron, and : Split up monolithic zen.css into smaller, logical stylesheets

And commit that new line using this command:
git commit --author="caroltron "@171342.no-reply.drupal.org>

Then I'll modify that line to read:

#200495 by JohnAlbin, caroltron, and Toe: Split up monolithic zen.css into smaller, logical stylesheets

And commit that change using this command:
git commit --author="Toe "@10587.no-reply.drupal.org>

Now both caroltron and Toe have real Git commits and show up on the Maintainers list for Zen. And, while the commit doesn’t show the actual code or documentation changes they made, it shows the issue number where you can explicitly see how much they contributed. So, while the changeset of the commit is a bit weak, I feel strongly that the commit itself is profound.

I hope other contrib project maintainers start using Git commits to thank their contributors.

And, again, thank you all for helping out! I’ll see you soon in the issue queue.

Jul 06 2011
Jul 06

Steve Fisher and I have talked about “designing in the open” on our Using Blue video podcast. The current design on that website is a work in progress; as we figure out how users are interacting with the content, we’ll tweak and refine the design. The concept is particularly useful in combating “the perfect is the enemy of the good.”

With my personal website, I’d like to extend the designing in the open concept right down to the roots. This site needs to be upgraded to Drupal 7, so I’ve decided to document and illustrate the entire process of rebooting my website.

This will not be a simple upgrade. I’ll be re-thinking the purpose and goals of my site and rebuilding it from the ground up. And I’ll be attempting to incorporate a myriad of design principles and best practices as I go.

  • Drupal 7 upgrade process
  • Content strategy
  • HTML5
  • Sass
  • Zen 7.x-5.x
  • Design techniques in this order: typography, color, composition
  • Mobile first
  • Responsive Design
  • Flexible grids
  • Flexible images + Drupal magic
  • Front-end performance

I’ve actually been meaning to re-design my site since reading Mark Boulton’s Designing for the Web almost two years ago. But, if you’ve listened to Episode 3 of Using Blue, you’ll already know that I think the web is about to undergo a profound shift in the way we build sites. So now’s the time to stop listening and discussing and to start building and discussing.

Sounds good, but what’s with the crappy design?

Some of you are asking “Why should I bother following this discussion when your site looks like a time traveler from Netscape 1.0?” A fair question, actually.

Most designers would be horrified to present something so unpolished and lacking in any good design principles. (And to add insult to injury for many designers, I’ve added Photoshop-nauseu-inducing blue guide lines to the background.) But I am unafraid. Or rather, I’m shameless.

The current “design” is a mixture of:

  1. Browser defaults
  2. Drupal 7 defaults
  3. Zen 7.x-5.x-dev defaults
  4. A very minimally tweaked Zen sub-theme (Adding support for my blog posts’ title/tagline combo.)

Since I’ve had a hand in creating many of the defaults in Drupal 7 and in Zen, I should own them.

The markup and sytling you currently see is the Pǔ (樸), or the “uncarved block”. It has no right or wrong, no beauty or ugliness. It is markup in the receptive state, ready to become.

Or to put it in site builder terminology: One of the purposes of Drupal’s and Zen’s default markup and CSS is to be easy to alter and extend. And to be a reasonable starting point. But it’s just a starting point, you will need to alter it to meet the needs of your site.

What’s next?

As you can see from the site, I’ve already done some of the work. In fact, you’re looking at a brand spankin’ new Drupal 7 site. The next post in this series will describe the upgrade process I used to get my site off of Drupal 6.

When are you rebooting?

May 03 2011
May 03

A quick Google search shows the “Death to Lorem Ipsum” meme is a reoccurring one that is once again hitting the twittersphere this week while An Event Apart is in Boston. Their points about understanding the content during the design phase are completely essential when creating websites, but their rallying cry is completely off base.

Crying “death to lorem ipsum” because real content keeps breaking our design is like crying “death to hammers” because we keep hitting our thumb.

Imagine if Vera Wang was asked to design outfits for a team of people.

Let’s say her client doesn’t initially tell her anything about the people she needs to design clothing for. So, Vera uses Elle McPherson as the model. And the client approves of the design because, of course, it looks fantastic on Elle.

But when Lebron James and the Miami Heat show up for their outfits and look completely ridiculous in misshapen clothing, let me be clear…

Do not blame Elle McPherson!

Lorem ipsum is just a model of real content. If the designer uses the wrong model, its not the model’s fault.

How did we get here?

“Death to
Hammers!”

Lorem ipsum has been a tool we’ve been using for decades. Because real clients never hand their homework in on time. And designers almost never get the content before they are required to start the design.

If we use realistic-looking, but fake content, the client often freaks out saying “That text doesn’t reflect our brand message. You can’t use that!” And even though we assure them its just dummy text, the unease they feel sets the tone for the rest of the design review. Its a losing formula for designers. And Karen McGrane elegantly describes why using real draft content in designs is a never-ending battle.

So we invented Lorem Ipsum. Completely fake content that is so far off message that the client can’t even attempt to improve the content or disapprove of it. At worst, it creates initial confusion about what’s going on. But after some reassurances and eduction, the client can settle down and get down to the business we want them to focus on: our designs.

So where did we go wrong? We repeated the phrase “just ignore the lorem ipsum” one too many times. It’s a mantra that we used to get clients to ignore the fake content. But unfortunately, we now ignore the fake content too.

We’ve forgotten the fake content is supposed to be a model of the real content. By ignoring Lorem Ipsum we’ve ignored the living, breathing content that it is supposed represent.

Getting out of the trap we built for ourselves

We’ve been doing web design for nearly 20 years and we still fall into the trap of wanting perfectly sized content. There is no such thing on real websites. If your designs have features that require the content to be limited to a certain number of characters, I highly recommend you re-think that approach. Why?
  1. The people signing off on your design are often not the people writing the content. This is a reality of large organizations. The people with the authority to approve representations of the company’s brand are not the same ones in charge of writing the copy. It’s likely the copy writers will never hear your recommendations about content length.
  2. The content that fits in your design today will not be the same content that is put into the website tomorrow. Organizations change. Whether its their writing style, the people, or their goals, you shouldn’t rely on what you “know” about the content today. Because it will change over time. And your designs have to be able to cope with those new parameters.

I know. I know. Design loves constraints. (I do listen to Mark Boulton.) And, yes, your design may not be as pretty when the client puts a “too long” piece of content into your designs. But it shouldn’t break! Create a design that looks great for the 80%, but also looks fine for the other 20%. Your design must be flexible.

The perfect solution to the problem of not knowing what the real content looks like is to use Lorem Ipsum. But you have to learn how to use it properly. Stop editing it to fit perfectly in your design.

Learning to use “Real Lorem Ipsum”

I’m not a designer (as you can see from my blog’s design); I’m a professional site implementer. And I know where the pain points are when putting real content into carefully crafted designs. Here’s a short checklist for you to double check your designs against Real Lorem Ipsum™:

  • Headlines. If you have a list of content and they all have titles with roughly the same length, then you’ve only designed for the 80%. You’ve forgotten about the odd-ball 20% that every site has. Make some really long titles. Make some really short ones.
  • Tables. Those grids of text next to images where the bottom of the text perfectly aligns with the bottom of the image? That never happens with real content. Make some of your Lorem Ipsum text be longer than the image for some examples.
  • Names. If you’ve designed any name tags, you’ll already know what I’m talking about. Al Grey and Dikembe Wamutombo both have to fit.
  • Small boxes/labels. Those tiny boxes of text better be able to handle a concept longer than 4 words if you know what I mean.

There’s lots more examples, but that should get your left brain thinking in the right direction. ;-)

Finally, a compromise

I hate ending on this note, but I’m radical centrist by nature. Sometimes, not often, but sometimes, you really do need to constrain the content. In those rare cases, I cannot stress enough that you need to:

  1. Get the client’s buy-in now. If there is a limitation to the length of content, make sure the client agrees to every single limitation.
  2. Educate the client. Provide documentation so that everyone can understand why the constraints are necessary.
  3. Re-educate the client. You’re building the site in a CMS, right? Make the CMS notify the user about the constraints as they enter the content. I’m a big fan of (and contributor to) Drupal. In Drupal, you would add a description for the field with the constraint. Make the inline help short and to the point so the user will actually read it.
  4. Optionally, force the client to listen. Again, using a CMS, you should be able to validate the content as they submit it. I’d recommend against cutting off the extra characters. Instead prevent the form from submitting, display all the content and display a helpful error message so the user can edit the content to match the required limitations. In Drupal, you’d just write a custom validation function for that form field.

A summary slightly too long for twitter

Instead of just dumping fake Lorem Ipsum into your design and editing it to fit your design, create “Real Lorem Ipsum” where the content challenges the design to think about real world problems.

Update: Oooh. Rachel Lehman has a great idea in the comments below. “You can even ask for the draft content, then place the Lorem Ipsum in the length of the draft content! Then you get the best of both worlds - no distractions from unfinished content, but realistic length representation.” Fantastic!

Sep 09 2010
Sep 09

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.

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