Drupal

Regular readers know that I've been working on a Drupal 7 book for beginners. We -- meaning Peachpit Press and myself -- are now faced with a decision. We could release it before, after, or at the same time as Drupal 7's release. Each option has its pitfalls. Release it too early, and it might not match the final Drupal 7 software. Too late, and we could lose the "first mover advantage" to another book.

Whatever our decision, we have to provide some date for potential distributors, booksellers, and customers. So we boldly decided we'd try to release it at the same time as Drupal 7 itself -- and announced the 24 January 2010 date you currently see on Amazon.

Webchick, when asked when Drupal 7 will be released, always says "When it's ready". Neither she nor co-maintainer Dries will set a date at this point, and for good reason: Neither of them are in control of when "ready" will be. Of course they could release it any time they like -- in an unready state. That would be bad for everyone who relies on Drupal, wants to switch to Drupal, has built a business around Drupal, who teaches or writes about Drupal... in short, bad for everybody. So their silence is as it should be.

But we, like IT professionals around the globe, still have to make decisions. In our case, we have to guess at Drupal 7's release date a few months in advance if we're going to hit that goal of simultaneous release. (Book publishing takes time!) And the sooner we make the decision, the better.

I'd personally love to announce the availability of Drupal 7: Visual QuickStart Guide on the same day as Drupal 7's own release. But I'm nagged by unknowns. What would it mean if it came out early? What if it came out after a similar book? Which situation is worse?

What do you think?

I've been busy writing Drupal 7: Visual QuickStart Guide for Peachpit Press over the last couple of months. I'm pleased to say that all the main chapters are done, and most of them are already available for preview on Safari Books Online. (I've given the table of contents below.)

Now it's time to write the appendices, and I'm not sure what would be most useful. We're thinking:

• Extending Drupal, including a list of the most popular modules, and whether they're expected to be available for D7 (thanks to the #D7CX project)
• Differences between D6 and D7
• Interacting with the Drupal community

Here's what the book contains so far:

Chapter 1. Getting Drupal Up and Running

• Fulfilling Drupal's Requirements
• Downloading and Unpacking Drupal
• Creating the MySQL Database Using phpMyAdmin
• Installing Drupal

Chapter 2. Establishing Your Drupal Site

• Performing Common Post-Installation Tasks
• Giving Your Site Its Identity
• Selecting a Visual Theme
• Monitoring Your Drupal Site
• Packaging Your Drupal Site

Chapter 3. Creating and Managing Content

• Gaining More Control of Individual Nodes
• Creating Other Types of Content
• Finding, Editing, and Deleting Content

Chapter 4. Customizing Content

• Defining Custom Types of Content
• Putting Images and Styled Text in Content

Chapter 5. Making Content Interactive

• Enabling Interactive Content Types
• Categorizing Content with Taxonomies
• Mastering Text Formats

Chapter 6. Improving Access to Content

• Making Content Searchable
• Directing Traffic with Menus
• Laying Out Your Site with Blocks

Chapter 7. Wrangling Users

• Managing User Accounts
• Controlling How Users Interact with Their Accounts
• Defining User Roles and Permissions
• Building and Protecting User Community

Chapter 8. Customizing Drupal's Look and Feel

• Creating a New Theme
• Changing Theme Graphics and Typography with CSS

I'm sure I'm not the first to discover this, but...

An online dictionary search for "Drupal" says it's a synonym for "drupaceous": that is, "resembling, related to... [or] producing drupes". A drupe is a fruit whose seed is covered by a tough endocarp, like the red peaches you see here.

Juicy!

Look at the top keyword searches that bring people to my site, according to Google Analytics:

1. tom geller (O.K., that's a gimme.)
2. wamp drupal
3. drupal wamp
4. (content targeting)
5. drupal on windows
6. drupal windows

Further, about one in five requests for support sent through my site's contact form is WAMP-related.

So -- what's the story? Is it that WAMP is hopelessly messed up? Is there a vacuum of relevant information out there? (My Running Drupal on Windows using WAMP article is Hit #4 on Google.) Have you had problems running Drupal on WAMP? Does the Acquia Drupal stack installer for Windows help?

At last I can announce the release of my new six-hour video series from Lynda.com, "Drupal 6: Online Presentation of Data", which you can check out with a free one-day pass. (Of course it's also available to anyone with a Lynda.com subscription, starting at $25/month for all-you-can-stand training in over 600 topics.)

I first talked about this course in January and was able to implement at least one suggestion from your comments (about creating calendars). There are also videos about mapping, charting, and preparing data for tabular export, all built on a foundation of CCK and Views.

Since Lynda.com's audience is mostly graphic designers, the course starts out with an in-depth description of data structure: As you know, data planning is at least as important as implementation! And it's an essential subject whose subtleties elude most beginners.

One wag in IRC questioned the need for such a course. "Presentation of Data?," he said. "Isn't that what Drupal does anyway?" He's right -- in the same way that a car is a tool for going shopping. But I believe that many people who would benefit from Drupal's data-presentation features simply don't know about them, because their knowledge of it stops at Stories, Pages, users, and blocks. They need a bit more information to make the leap, and could become fierce advocates for Drupal when they see all it can do in this area.

Extra bonus: For giggles, check out the Introduction video, which includes some live-action video of me looking goofy. :)

Thanks, as always, to the Drupal community for both helping me to understand these topics myself, and for making Drupal the Web development powerhouse it is.

First things first: I've you've ever looked at Acquia's documentation, read this post and take the survey. You're welcome, jam. ;)

Now, a confession: I went to the Drupal.org documentation sprint at DrupalCon. And I tried to be useful, really I did. But I found myself frustrated, unable to really engage in it, and left mid-day feeling horribly guilty. Why? I think there were two causes:

1. The task is so immense. Drupal.org's documentation has grown like topsy, and now useful information is dispersed throughout several unconnected areas. The search function is really all that brings them together.
2. Quality varies wildly. The biggest sin is, as usual, too much writing. As I often say, writing is easy; editing is hard. Brevity is the soul of wit. Your mama wears combat boots. And so forth.

I wrestled with the task facing doc team lead Addison Berry: What would I do in her place? My answer surprised me: I'd burn it all down and start again.

I'm reminded of the real-estate markets of Detroit, Cleveland, and Buffalo. In those cities there are blocks full of houses that are worth less than nothing: They're too dilapidated to restore, and the cost to demolish them (about $8,000) is greater than the land's value. And ashes are cheaper to truck away than lumber, even if the burning dumps toxins in the soil.

What "city blocks" on Drupal.org are like that?

Such arson is unlikely to happen on Drupal.org. For one thing, it's discouraging to sweat out a long document, and then discover that it's disappeared. How many people would stop contributing documentation as a result? How would the community's soil be poisoned?

I'd still recommend cutting mercilessly. I believe at least 75% of the words on Drupal.org could and should be lost. But who would do the cutting? It's tough work, and without glory. Converting Drupal.org's documentation into a wiki(-like) format might help "crowdsource" the task. Or maybe not. Nobody likes to cut. Editing is hard.

Which leads us back to Acquia.

Acquia is a "third-party documentation provider", like the Lullabots and GotDrupal and DrupalTherapy and many others... and me. It's tempting to say that we thrive because of the weaknesses in Drupal.org -- that is, that they create a vacuum that we fill -- but it's not really true. After all, Apple's documentation is pretty good, but that supports outside writers rather than cannabilizing their work. In a healthy project, there's always a new audience to reach.

But we outside doc providers have an advantage over Drupal.org: a clear field. Arson is unnecessary, and will put no toxins in the soil. Each building we create on these virgin plots can reflect a different architecture, each fitting a distinct family of users.

That's why I think it's great that the Lullabots' CCK and Views videos will be available alongside my own: Theirs reach a certain audience, while mine will reach a different audience. And both of us can only do what we do because of the base provided by Drupal.org's documentation. Together -- we outside doc providers and Drupal.org -- we all grow the Drupalsphere.

I visited my site a couple of weeks ago and discovered a pile of comment spam. That's not unusual, of course; what *was* strange was that Drupal's Comment Notify module hadn't told me about them. Some poking around revealed that, lo and behold, the site wasn't sending any email. The problem's nature meant I had gotten no notification: It was the silent site-killer.

So first off, I want to apologize to anyone who's tried to contact me thorugh tomgeller.com or gellerguides.com and not gotten a response. Simply put, I never got your message: If you remember your query, please send it again. The fault was entirely mine, because I hadn't instituted a simple procedure that would have prevented the problem. To wit: I should have tested the site periodically.

And so should you.

In fact, here are five areas every Web admin should test regularly:

1. Anonymous user experience. Log out, then test your site's appearance and function. One mis-set permission can stop visitors in their tracks.
2. Sign-up experience. The sign-up email is your users' first personalized encounter with your site. Are you sure it represents your current message? And do the sign-up screens lead logically from one to the next?
3. Links and scripts. File paths sometimes change during system updates, but you'll never know until you try to access a link or script... and have it fail. Discover the problems before your users do!
4. Images. Ever had your images disappear after an upgrade? There are two common causes: putting image files in the wrong place (such as /files), and forgetting that you'd modified pieces of a theme when you upgrade it. Which leads us to our last test...
5. Backup and restore. "You're only as good as your latest backup", they say. Further, "Your backup is only as good as your ability to restore from it". Whether a backup is missing or unusable doesn't matter: The result is the same.

I'm sure this isn't a complete list, and fear the next time my site dies a silent death. So help me out: What other areas do you think site admins should test regularly?

I'll soon be recording a video training course at Lynda.com similar to the one I created last year. To demonstrate various technical points, I'd like to show photographs of people's faces on a fictitious Web site. So I need some headshots, and think it would be especially fun if they were of recognizable Drupal community people. Would you be willing to let me use one of yours?

If so, here's what's needed:

1. Send the graphic itself by email to tom -at- tomgeller.com. It should be cropped fairly close to your face and no smaller than 400x600 pixels.
2. Sign and return the two attached forms. You must have rights to the photograph!
3. Prepare to become "Internet famous"! ;)

Only five days after its latest release, Acquia today released another update to its namesake Drupal distribution -- and it's a doozy. The package itself includes modules that give you the first chance to try out the company's new search product, while a separate release ("DAMP") will help get Drupal beginners up and running MUCH faster than before. (It also includes another gorgeous new theme from TopNotchThemes, which I might use in one of my own projects.)

Acquia has talked quite a bit about their hosted search solution, so I won't talk much about it here. It's based on Apache Solr, and I believe that the Drupal.org site is already using it. (To see how it works, do a simple search on that site, then notice all the ways you can "filter" the results to drill down to the ones you want. I've found that especially helpful when searching for modules.)

But the only reference I've seen to the Drupal-Apache-MySQL-PHP stack before now was in a comment by former Acquia VP of Marketing Jeff Whatcott last November. In my opinion, it should get more press: It has the potential to be a REALLY BIG DEAL for Drupal.

Why? Simply: Installing Drupal is far beyond the ability of most people. When I was a newbie, I stumbled over installation for weeks before learning to use MAMP instead of Mac OS X's built-in AMP stack. And installation questions are overrepresented in the support queue for my Drupal video course. As soon as you tell someone they have to change permissions, or type a Unix command, or download two separate packages, you've lost them.

So I eagerly downloaded and tried Acquia's new Drupal Stack Installer (on the Mac), and found that it successfully avoids all these problems. Most importantly, it installs like a Mac application. Double click it, and it goes! For end users, that's huge.

Acquia's DAMP is not without its faults. While it mostly behaves like a Mac program, it suffers from several "look and feel" holes. For example, the "Control Panel" application (which appears to have been adapted from MAMP) lacks an "About" box and other touches Mac users expect; you can't tab among fields in the installer; it launches Safari instead of your preferred browser; and the log files have an inconsistent interface. I'm not sure these errors would be as noticeable on the Windows side, which I didn't try; I'd be interested in hearing someone else's impressions there.

But enough about that: I have to go to bed for an early flight tomorrow to DC. See you there!

TopNotchThemes just released my "How to make an online store look great with your new theme from TopNotchThemes, which I'm happy to say has gotten Ãœbercart founder Ryan Szrama's endorsement as "helpful and thorough". If you haven't grabbed your copy yet, grab PDFs of it and TNT's basic guide to give out to your Drupal-newbie friends. And please do let me (and TNT) know what you think.

TNT's customers span the range from shopkeeps with no Web experience to experienced Drupal developers who appreciate their themes' special features. These guides aim primarily to help the first group: that is, folks who think of themselves as something other than "Drupal people". Helping them be successful with Drupal is crucial to whether the platform will cross the chasm to move on to mainstream success. But they've not gotten much love from the Drupal community before now. In short, it's hard to point mainstream people at a single, easy-to-digest document that helps them get up and running quickly.

Before you suggest Drupal's official site, try this experiment: Send a couple of (non-techie) friends to the site and ask them what it's about. It's notoriously hard to navigate -- especially for beginners. The problem isn't a lack of information: It's too much information. As the pros know, writing is easy, but editing is hard. And organizing others' writing is even harder.

The average Drupal user has an absurdly high technical level, which leads to the second big problem: Nearly all of drupal.org is beyond the neophyte's abilities. That's as it must be at this stage of Drupal's maturity. Drupal is still a developer's tool; does it have the potential to become usable to the average person who wants a Web presence beyond WordPress and Yahoo! SiteBuilder? Maybe. But it's not there yet.

These two factors -- Drupal's promise for ordinary people and the disorganization of its official documentation -- add up to a market opportunity for those who are able to capture it. And yet, I would argue that nobody's really captured this market. Taken medium by medium:

• Training: Of those people and companies listed in Drupal.org's training directory, the best known is probably Lullabot, whose past courses have generally focused on advanced topics. (The success of their "Do It With Drupal" course stands out as an exception. I have to wonder, though: How many attendees were "beginners"?)




• Books: I think O'Reilly's Using Drupal reaches out to beginner/intermediate Drupal users well, while sales copy for Wrox's new book "Leveraging Drupal" promises that it's for "users of all levels of expertise". And yet... The O'Reilly brand has little currency outside of hard-core tech geeks, and many people (me included) don't know what "leveraging" is supposed to mean as Wrox uses it. Further, both books are nearly 500 pages! It takes fearlessness to dive into a book of that size, no matter how good. (Full disclosure: I have a contract with Peachpit to produce a shorter, beginner's-level Drupal book later this year. More on that later.)




• Videos: Obviously, I'm biased. :) I've been impressed with the number of people who have made Drupal video screencasts -- although again, most have been for highly technical topics. Frankly, production values have been very mixed: I find some of them unwatchable. One sparkling exception is Matt Petrowsky's free GotDrupal.com lessons: They're concise, well-made, and conveniently tagged so that beginners can easily find videos they're likely to understand.

So there are gaps in the curriculum. Personally, I've bet that filling those gaps is good business -- and so far that's been an extremely winning bet. That first Lynda.com course has led to a second, the TopNotchThemes work has been both enjoyable and fruitful, the Peachpit book will come out with Drupal 7, and several other clients have asked for these sort of explanatory materials for Drupal. Professionally, it's a good time to reach beyond Drupal's existing circle of technologists; Drupal's growth from such actions is a fortunate side effect.

[Graphic source: Craig Chelius on Wikimedia, based on work by Geoffrey Moore. License: Creative Commons Attribution 3.0 Unported.]