Drupal

Thanksgiving wishes for Zen contributors

and how to do the same in your project

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.

Building in the buff

the developer’s “designing in the open”

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.

Stop ignoring Lorem Ipsum

And learn to use your tools properly

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.

Theming the Drupalcon Chicago Track

Tales of a Track Chair

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.

A complete idiot’s guide to git-svn-migrate

3 steps to batch convert Subversion to Git

If you read my previous post about converting Subversion repositories to git, you’ll know that to do a proper Subversion-to-Git transformation on a batch of repositories is going to take some time (what with all that command line typing). I had 142 legacy project Subversion repositories lying around I wanted converted to Git and, since I’m lazy, I pulled on my bash boots and wrote me a script to do the work!

With the git-svn-migrate scripts I wrote, you can batch convert all of your Subversion repositories in just 3 steps. And I’ve GPLed them and put them on GitHub if you’d like to collaborate and improve them; see the git-svn-migrate project page.

svn boxes go into the factory; git ponies come out.
git-svn-migrate: a reverse glue factory

Pages

Subscribe to RSS - Drupal