Why I'm voting for whom I'm voting for in the Drupal Association election

old voting machine

For those who don't know: I served on the DA Board in 2010-2011, and was on the Governance Committee that developed the new structures. Before that I was in the General Assembly. I'm currently on the Advisory Board.

But I share my opinions here as a long-time member of the Drupal community who cares about the future of Drupal.

Criteria: more than good intentions

Last year, the Nominating Committee (on which I served) considered many aspects when evaluating potential candidates for the Drupal Association Board, including (in no particular order):

  • Skill sets. (We needed people with diverse areas of expertise, be it financial, legal, organizational....)
  • Competence in their field. (We wanted A players.)
  • Industry. (We did not want to have a Board comprised of mostly Drupal consultants, for example. Given that consultants as a whole tend to be more active in Drupal than others, this is an issue we will always face. Even so, the perspectives of various sectors are valuable — government, publishing, education, not-for-profit, corporate, etc.)
  • Company. (We had a rule that we didn't want any one company represented by more than one Board member. This eliminated a handful of otherwise very qualified candidates. We made an "exception" with Angie Byron, because of her fabulous community leadership and because Dries, under the Bylaws, automatically has a seat on the Board.)
  • Geographic diversity. (We knew we had to reach out worldwide. This made for a challenge, because of the greater travel requirements that come from having Board members scattered across the globe, but considered it worth trying.)
  • Drupal Ecosystem. (We wanted the various perspectives of the members of our community: volunteers, small shops, large shops, large integrators, in-house teams, designers, end-users, etc.)
  • Outside perspectives. (We needed to reach outside of our own Drupal echo chamber so we could draw upon knowledge and expertise from, e.g., other FOSS organizations who faced similar challenges already.)

I am looking at the same things when considering the nominees who have put up their names for at-large Board members in 2013, but here are a few criteria that, for me, weigh higher than the others this year:

  • Skill sets and expertise. And in this, I mean awesome track record, not impressive resumes. Whether elected by the community or recruited through the Nominating Committee process, all of our Board members need to be A-players, not well-meaning B- or C-players. We should expect nothing but excellence from our elected Directors.
  • Geographic diversity. The DA is clearly still very heavily weighted towards a North American perspective. To me, the long-term viability of the Drupal Association depends upon geographic diversity of its decision makers, and right now I feel non-North American voices are needed. We're a global community, but how that's reflected in the DA Board is ... incomplete. I'm looking at non-North American candidates first.

However, with all that said, criteria for selection are only half of the equation. It behooves us all to consider....

The business of the Drupal Association

I feel it's best if those of us voting consider what the Drupal Association is doing, and what very real challenges the Board faces, before weighing the candidates to the above criteria (or whatever criteria you bring to bear). Here are just a few items.

Recovering contrib Image module's content in upgrade to Drupal 7

photo 3 versions

Once upon a time in the Drupalsphere, there was the Image module, which was the preferred image solution for all Drupal sites. It dynamically resized images for display, so you could upload one image and get other sizes. But it was limited to one image per node, which made it hard for situations where you wanted to insert several images into one article. All kinds of workarounds emerged, but it was all a bit kludgey. It was nice to have something, but people were looking for something better. When Imagecache came about, it was received with much excitement, and it soon took over as the preferred image handling solution for Drupal, because you could attach several images to a node, and because it was much more performant and scalable. When Drupal 7 was in development, this functionality was considered so essential that Imagecache was incorporated into Drupal 7 core and renamed "Image". (Yeah, it can be a bit confusing if you don't know the history.)

If you were riding Drupal through those image solution shifts, it could be a bit of a rough go. In my upgrades over the years, I lost my Image node-generated posts. They were there from 2006-2007, but my upgrade to Drupal 5, when I adopted Imagecache for my images, left them adrift. I had figured those posts were doomed to obscurity, with no hooks to pull them out of database obscurity. Oh, you could see the text, but the images were gone. And if you tried to edit the node, you got no node edit form, just a blank page. I wasn't going to try to fix that for a handful of posts. I figured I just had to write them off, sacrificed at the altar of progress.

I was wrong.

I recently discovered that this content loss due to Image module deprecation has a solution. When I first saw this, I guessed it was too late for me, as I should have done this in a previous Drupal upgrade, ideally when I made the initial jump away from the Image module.

But I thought, what the heck, give it a try!

Field Converter module

It was this module I found myself looking at that got me excited.

A framework for non-CCK modules to use to convert their Drupal 6 custom data to Drupal 7 FieldAPI fields....

...Currently, Image and User terms are using this framework to migrate their data to fields on Drupal 7.

Ooh! Maybe I can rescue my Image nodes after all!

I started digging around, and learned that there is really no documentation on this. You have to read the code and figure it out.

I went to look at the old Image module in contrib, where it said on the project page:

Upgrading ... from Drupal 6 to 7: Image node data may be converted to Image fields using Field convert module; the image_legacy module (in this project's git repository's 7.x-1.x branch) provides the necessary field conversion information.

Nice! Obviously I couldn't simply enable image.module, as it would conflict with the core module's namespace. So I looked for documentation, but didn't find any there, either. I explored the Image module issues, and found Image module migration, a critical open issue with lots of discussion on just this migration need. There I saw more mention of the image_legacy module, which, as it turns out, is a module within the Image module package. People were saying it was working, albeit with issues.

Hmmmm. I had the basic elements to give this a try. I made my backups and hunkered down in my dev environment for a potentially long session.

responsive pattern

HTML drawing by Laura Scott

It was 2001 when I first started blogging. It would be a few years before I heard the word "blog", so maybe my early endeavor in online journaling wouldn't count for purists, but I was journaling online. This was a rather introspective period in my life and I felt compelled to my thoughts and experiences in this worldwide web I'd been playing with for several years. So I hand-coded a site, a static HTML affair that I had to update completely every time I posted an update. (I didn't really care for the limitations of the various services out there.) Over the next year and a half, the site grew in size, making my deployments more complicated. The blog also became collectively more and more emotionally raw, until one day, in a fit of mortified embarrassment and disgust, I deleted the whole thing and didn't look back. So yes, I started blogging eleven years ago, but I haven't been blogging for eleven years.

In 2004 I started doing some ranty blogging with a political slant, and I've continued that over the years, pseudonymously, first on Blogger, then on a Drupal site I built myself (my first, actually). Chalk it up to political cynicism fatigue that I have scarcely looked at that site in quite some time. It's hard for me to allow myself to get worked up over political issues, especially when our politics are so broken. It's an emotional space I don't care for. It drains me. I remain engaged politically, but my engagement no longer includes political blogging. That may change in the future. Who knows?

This blog I started in October 2005 to blog about stuff that interested me. Those were interesting times in 2005. I was still absorbing the profound changes technology was effecting on our culture and in our daily lives. I'm still absorbing it, actually.

So, in technical terms, my online life has shifted from a self-built flat html site to a saas blog to some self-built blogs, commercial sites, and communities.

Over the last couple of years, the foci of my sharing compulsion have gradually shifted towards Twitter, Google+, Facebook, Tumblr, and the like. The interconnectedness of these networks is what appeals. It's what works better now for quick sharing, sad to say, and it's what I feel is more indicative of trends in the future.

So why spend time going back and updating this blog? It's a silo, for the most part. A year or so ago I tried an experiment ameliorating that feeling by replacing the Drupal comments system with Disqus comments, and I think that has helped make this feel less like a silo, more connected. People who have never seen this blog can follow a link and find that they are already logged in to share a thought in the comments. Others can log in using any of a number of existing accounts elsewhere. Identity management wins (albeit in the proprietary realm).

This blog is also my home, in a sense. I feel a responsibility to maintain its upkeep. And part of that is progressing with the rest of the Drupal community. I share in this fabulous commons, and the drop is always moving. I must keep moving, too, even for this oft-quiescent blog.

The theming firehose (NB for designers & front-end developers new to Drupal)

Drupal markup in a Wordle

You theme with the mark-up you have, not the mark-up you'd like to have.

That's the essential truth that designers and front-end developers new to Drupal need to understand. You don't get to construct your pages from scratch, building out essentials, never a wasted div, never an extraneous class. No, you have to flip the entire process around. With Drupal you're getting markup shot at you from a firehose, and as a themer you need to sop it all up and make it pretty. Don't spill a drop.

What this means is that, by default, you're spending a lot of time debugging the theme you're building so that it handles all the different configurations, content types, page structures, etc. that the Drupal site is throwing at you.

You have to be braced for it. It can be overwhelming. You can feel like you're drowning. Don't worry. You'll get used to it after a few months. Mostly.

Make friends with Firebug.

But wait, can't this situation be changed?

Well, kind of. You can intervene in the mark-up. You can write your own page templates. Your own fields templates. Your own views templates. Your own search templates. Your own node templates. Your own comment templates. But be warned: You're going to be working against a ton of mark-up. And you'll need to know some PHP to add your own variables — mighty powerful and nifty, but your Dreamweaver chops aren't going to help much.

You see, Drupal aims to be flexible, and it does that by throwing a zillion divs, spans and classes into the output. That means if you're not expert at CSS, you're going to be lost adrift in a sea of markup, and if you are expert at CSS, you have to learn how to see through the clutter — because when you have four or five nested divs to contain one single element, it's not necessarily obvious which one to target with your CSS. Especially if there's some nefarious Drupal core CSS already at work.

There are endeavors to make Drupal mark-up better, including in the HTML5 Initiative. But that's a slow process, and it sometimes meets heavy resistance.

Meanwhile, to get sites themed now, you may have to change how you work. Change how you view the web “page”. Get used to being the html sponge, absorbing and directing the firehose, using only the drops you want and letting the rest by without touching a thing. Let go of the idea that you're building from scratch, and get used to the mindset of diagnosing what's already there.

That's the price of power. Drupal is incredibly powerful. You need to flex your theming muscles to match what Drupal throws at you. Work through the complexity. Trust in Firebug. And don't despair. In the end, the resulting webapp is orders of magnitude bigger and badder and more kick-ass than what you could have done on your own, having 100% control but going it alone.

How is "great content" found?

Dead Sea Scrolls photo

In a provocative assessment of Google’s Google+ strategy of launching a “recommended users” list (a topic of its own), Robert Scoble shared an assumption behind his conclusions:

If you have great content you will get found by one of the folks on this list.

It’s an interesting claim. I've heard this kind of thing for years, and always wondered: Is it true? My intuition always said it's not. So last night I questioned Robert's statement in a tweet, and he replied:

@lauras it's pretty rare that good content doesn't get shared with others.

How do we know that it's "rare" that good content doesn't get shared? We know only about the good content we've already found. We have no idea how much good content has not been found. So how can we lay any odds as to how common or rare it is for good content to be found?

And "found" ... by whom?

I thought I'd lay out some thoughts on this and see what people think.

What does it take?

  1. The content must be "good".

    We all know that there's a ton of bad content that gets much more attention than good content. But for good content to get found, the question assumes good content. What makes content "good"? That's a question that is addressed piecemeal in the following points.

  2. The content must be on a viable platform, in a viable format.

    The content must exist in a form that can be consumed if it is found. A book in Braille is not going to influence many. Your handwritten novel may be fabulous, but the single copy's being on yellow pads, with all the words scribbled in your poor penmanship ill serves your great novel.

  3. The content must be findable.

    If people can't get to it, you can't share it. For online content, it must be in a format to be indexed by search engines. For movie content, it must have distribution. Your painting that's viewable only from your livingroom is not findable by others except your house guests. (If only you had a gallery showing!)

Is the site logo content?

A brief exchange on Twitter with Jen Simmons (@jensimmons) and Morten Heide (@mortendk) about how to best incorporate a site logo into a Drupal theme got me cogitating on this question. Jen tweeted:

...What should go is the habit of hardcoding content into the theme. #separationplease #drupalwtf


"Content"? Hmmm. This got me pondering: Is a logo "content" per se? My immediate response was in the negative. But upon further consideration, I don't think it's all that clear cut; I'm definitely less certain today than I was yesterday.

This post is a bit of thinking out loud on this question. Comments welcome! (But no need to shout #wtf, okay?)

Content or architecture

To me, "content" in a Drupal site is the content, as in nodes, comments, image uploads, embeds, etc. The content is the information. Come back to an article on kitten care a year from now and the content will be the same (or at least it should be).

The logo, on the other hand, is a graphic component of the user interface as well as the branding. The logo is the visual representation of the site identity. It may change and evolve, as logos do, as user interfaces do.

But functionally the logo in the web application is really a part of the site's architecture. The logo is "home." Redesign the site, revamp the logo, change its colors, replace it altogether — it is still "home" in terms of the functionality of the application. In that sense, it is fundamental architecture.

When planning, designing and developing a custom website, the theme is custom, a part of the entire design that includes architecture. (At least, this is the assumption I'm working from.) One typically does not move a logo around on a page willy nilly. One typically does not swap out the logo for another — not unless you're also changing the theme as well, as part of an entire redesign. The logo is a part of the whole user interface, the whole user experience, the whole compositional balance of the page. Conceptually it's hard for me to split out the logo as represented on the page itself as somehow apart. Logos have their own separate life, yes, but in a user interface context matters. One might even argue that the entire user interface is all a part of the branding, with the logo just playing one part. One might....

One of the advantages of a Drupal site is that a site administrator can actually manipulate the site architecture without touching code. This helps site building happen much quicker than it would otherwise. This admin control over architecture also can be handy for site owners, even if used only once or twice in a year. And it constitutes configuration stored in the database.

But does that make architecture "content"?

Drupal is very good at blurring the lines between functionality and presentation because of this paradigm. In puritanical (small "p") terms, it's undesirable, this blurring the lines. But in terms of usability and convenience for site owners, it ends up being empowering. Site menus can be modified, added to, deleted from. Blocks can be repositioned. The user interface, in other words, ends up being extremely malleable and subject to the whims of any user with the appropriate administrative permissions.

But is it content? I guess it depends upon what you mean by content. In terms of interaction design, I tend to view the site logo as a component of the entire user interface design, as part of the architecture in terms of functionality.

What is DrupalCon to you?


Yesterday, we had a Drupal Association Board Meeting to discuss upcoming DrupalCons. The meeting ran very long as we discussed and debated what criteria we should consider in selecting cities for DrupalCons in 2012, 2013 and beyond. Passions ran hot at times as we hashed out our thoughts on our evolving process for making these decisions.

  • What is the purpose of DrupalCon?
  • What components make for a great DrupalCon?
  • What factors play into selecting a city for throwing a majorly successful DrupalCon?

In the end, I feel that we made a lot of progress in this meeting. This post is not a debrief of this meeting, though, but rather is a collection of some of my own thoughts about DrupalCon, shared as a member of the Drupal community.

Growing presents challenges

As Drupal continues to grow so quickly, the Drupal Association has been working hard to adapt. The community is many times larger than when I joined it over 6 years ago, even since when the Drupal Association launched in 2006.

  • Members on Drupal.org are now over 1 million 515784. [I stand corrected. User id's are over 1000000, but many accounts have withered, were never used after registration, or turned out to be spammers who were blocked. And since about uid 600000 the uid numbers have been incremented by 5 2, not 1. Even so, that's a lot more than when I first joined.]
  • There are more Drupal Meetups happening around the world ... and many meetups are growing in size.
  • Drupal Camps in various cities are proliferating and growing. Many are now bigger than DrupalCons were just a few years ago.

No question: People want their Drupal, and they want their Drupal events.

Worldwide there are all kinds of Drupal community events of all sizes. For the Drupal Association, we've decided to focus our attention (for now) just on DrupalCons, as they are the most challenging to pull off, most expensive to produce, and are the only Drupal events that are primarily international in nature. Who else but the Drupal Association is in a position to produce DrupalCons?

(We've been testing ways to support regional Drupal Camps, and are looking for ways to help support Drupal Meetups, code sprints, hackathons, and other smaller community events that help people get better at Drupal and get more involved in the Drupal community. More on that in 2011....)

On the Drupal Association Board, I think we're all in general agreement that DrupalCon is about serving the Drupal community. But what that phrase "serving the Drupal Community" actually means can differ, depending upon whom you ask. Each of us on the Board has his or her own idea. This is what we ended up discussing in great depth — or as much as could be covered in 6 hours.

But difference of opinion about DrupalCon mirrors the diversity of the greater Drupal community. Indeed, yesterday, as word of our discussion got out, some people began tweeting thoughts and attitudes about DrupalCons. (I'm not going to try to characterize those tweets, or the thoughts of anyone else. We all have our own ideas. Perhaps you will share your own thoughts in comments below?)

It's about the community

Drupal is fabulously powerful software, no question. The ways it can be used to build quickly all kinds of powerful websites and web apps that otherwise would require potentially tens of thousands of programming hours to get off the ground make Drupal extremely appealing to businesses and individuals alike. I'm simply thrilled by the success Drupal has enjoyed in the online world, and delight being able to draw upon Drupal for solutions to challenges I face every day at work at PINGV Creative.

Certification schmertification! Metrics schmetrics! Measuring the Drupal social/rockstar graph

Drupal disciplines Venn diagram

Certifications in software make me sneeze. Or roll my eyes. Or shrug. Yes, I'm a skeptic of certifications, and leery of motives of people pushing them. To me, certifications are a way to make money not from clients but from peers. It's like a tax. Do not pass Go. Do not collect $200. Instead, pay thousands to some firm so you can get that seal of approval. And in the end, does it mean anything?

And yet there is this obsession with measuring people. It's a way of gatekeeping, of creating scarcity, of one-upsmanship. I don't think such things are a measure of quality. They're typically market tools employed to help one group of people compete over another group. It's part of a "there oughta be a law" approach to life.

Goodness knows there are a lot of people out there who have no business building websites, yet do. Rare is the experienced Drupal developer/themer/site-builder who hasn't been shown some unsightly mess of an implementation that hardly works, if it does at all, with unmaintainable hacked code and untold violations of best practices. But color me an unbeliever when it comes to the salvation offered by some certification system. Certifications don't measure the things that are crucial to effectiveness. They don't measure ability to solve problems. They don't measure those intangible qualities that make people worth working with.

And they can't measure the unknown. Certifications look backwards, and tend to reduce the beautiful and complex to the dry and limited. Are certifications what we want? Really?

Is "Rockstar" measured in inches or decibels?

Certified to Rock attempts to bypass certifications by disrupting them using a mysterious automagical formula. The Certified to Rock algorithm is secret. That's purportedly not a flaw but a feature — presumably because if the algorithms were known, they could be gamed. The blithe response is "if you continue to rock it, your score will increase."

Of course, all this depends upon what you consider a "rockstar". Forget Ozzy and Rod and Moon and Mr Mojorisin. Unlike old-school rock stars, who burned guitars, wrecked hotel rooms, drove cars into swimming pools, bit heads off of doves and passed out on stage, and were paid millions for it, Drupal "rockstars" participate and engage in more socially constructive ways. Yes, baby boomers, the rockstar is the new square. But is your notion in alignment with the notions behind the secret CTR algorithm? Who can say?

I confess that when I first saw Certified to Rock, I thought it was a joke — a kind of frivolous, er, let's say extraordinariness meter for geeks to see how they measured up — "frivolous" because it claims to distill what is ultimately so vague and diverse and multidisciplinary and, well, human that applying a single scale is like comparing apples and cinnamon rolls. And machines are not good at vague and human.

This challenge is not unique to Drupal. Just last week this challenge of defining and measuring qualifications arose at a data science unconference:

One of the best sessions I attended focused on issues related to teaching data science, which inevitably led to a discussion on the skills needed to be a fully competent data scientist.

Ada Lovelace was a Drupalchick

Okay, it's a whimsical title. But on this Ada Lovelace Day, I was thinking about how, if Ada Lovelace were alive today, she no doubt would be in technology. After all, the creator of the first "computer" wouldn't stop there, would she?

In my daily life I get to work with some amazing women who are working in, with or on Drupal. I wrote an appreciation over at PINGV Creative.

My DrupalCon San Fransciso session: Grok Drupal (7) Theming

The Way Drupal Theming Was

When I started Drupal theming in 2004, it was all a bit overwhelming. Back then, the core theme engine was something called Xtemplate, and it gave the impression to the n00b themer of being a great big mess. When you looked at the page template, it was one big blob of markup and logic, and it was very hard to figure out to change just about anything. What's more, it seemed to be very brittle: change something and you got the white screen of death.

And thus life was for the themer through Drupal 4.5 and the beginnings of 4.6.

New Drupal Theming Power

Then, in 2005, came the PHPTemplate theme engine, thanks to Adrian Rossouw (now with Development Seed), and the heavens opened up.

Suddenly (well, not suddenly, as it took a lot of work) Drupal templating had a structural logic: a nested system that simplified the clutter, gave us defined variables to work with, and provided the basis for extending the system. This was really really cool — so cool that it immediately became the theme engine of choise, and, with Drupal 4.7, it became the theme engine for Drupal core.

I was so excited about it, I did my first Drupal conference presentation on it, at OSCMS 2007 at the Yahoo! campus in Sunnyvale. (It was part of a larger topic of overriding display upon which I collaborated with Greg Knaddison and Ezra Barnett Gildesgame, now of Growing Venture Solutions. The PDF of my slides are available here, though they're pretty outdated now.)

Since then the Drupal theming system has evolved and improved. There are a lot of nifty techniques, tricks, best practices that are available to the themer. What's essential is having a good understanding of the underlying architecture, because that's how you can figure out where to look, how to go about making the changes you want to make the theme yours.

No PHP knowledge is required ... beyond knowing not to muck with what's between the <?PHP ... ?> tags. Of course, knowing some PHP can help. But you can also pick up the basics as you go, if you want to delve into the coded bits.

Learning Drupal Theming in 2010

My session proposed for DrupalCon SF on Drupal theming basics brings a comprehensive look at the Drupal theming system and how the front-end developer new to Drupal can take charge of the output by taking advantage of what Drupal gives you.

You won't come out an expert — that would be a ridiculous promise — but you will come out able to start rocking your own themes. You will have a solid understanding how the Drupal theme is structured, how the various templates work together, how to define regions, how to add your own targeted CSS files and scripts, use of subthemes, some good base themes to work from, how to do custom overrides of obscure, quirky or persnickety output using preprocess ... and you'll grok theming in such a way that even if you don't know how to do something, you'll know how to go about figuring it out, where to look, what to change, etc.

And because we're about to enter the age of Drupal 7, this presentation will be about these things for Drupal 7 (with some notes on how things have changed from Drupal 6). So this session could also be of interest to the experienced Drupal themer who hasn't had a chance to delve much into Drupal 7 yet.



Get occasional email updates on what I'm doing (and not blogging about).

Powered by MailChimp

Subscribe to Drupal