During my DrupalCon presentation I asked themers to blog their toolkit so that we can learn from one another and work towards a "best practices" toolkit. There were lots of fantastic ideas during the session and I'm hoping that people will blog their toolkits.

Here's a summary of some of the tools that I use (and that I talked about during my session):

1. Browser plugins--make your browser a Web development environment instead of just a Web browsing window. Firebug allows you to edit your CSS files on the fly and to easily locate any element in the HTML source for your page. Victor Kane also recommends the Web developer's toolbar.
2. Testing services--stop asking your friends to take screen shots for you and start using one of these two testing services. The free service BrowserShots.org is perfectly suited to most people. It gives free screenshots from a variety of different configurations. The paid service, BrowserCam.com, is perfect for those who need to test interactive features as well. I have a BrowserCam account that I use to test fly-out menus on the sites I build.
3. The Drupal Devel module--a helper module for Drupal developers and themers. This module comes with an amazing Themer Info tool that allows you to "see" the contents of node and page variables.
4. Personal design library--Web sites change. Your favourite site today might be completely different tomorrow. Find a tool which allows you to save your favourites into a reference library. My favourite of tool is the browser plugin, Zotero. It was originally created for researchers, but it works well for designers too.
5. CSS Grid Systems--these CSS frameworks allow you to quickly create new Web sites that work in "all" browsers. One of the best documented grid systems is 960.gs. There is also a Drupal base theme that uses the 960 grid and a comparison chart that summarizes which of the base themes use what grid system (if one is used at all).
6. Version control--I don't care which system you use, as long as you use something. I personally enjoy the distributed version control system, Bazaar. A short tutorial of how I use it to upload my theme files to a Web server is available on the Bazaar Web site. 

What's in your toolkit? 

PS The Themer's Toolkit is available online as a video and as slides. The information presented here is also available in more detail in Chapters 2 and 3 in the brand new book Front End Drupal (pre-order today from Amazon.com and give a little love back to the Drupal Association while you do it).

I've been spending the weekend at SCaLE in LA. It's been an absolute experience. The first day was the Women In Open Source mini-conference. There were several excellent presentations and great discussion. I think we may have even made progress into creating a more focused and intentional WIOS day in 2010. I am planning a longer post on this when I've digested what happened and how this will affect the future.

The second day I went to a few talks and wandered around the booths and generally met up with old and new friends. For me it was really interesting to see the epiphanies that people were having in talks like Stormy's. In her talk she was talking about how you can use open work methodologies in all kinds of businesses regardless of whether the business is working with open software. To me it all seemed obvious and I was a little bit confused by the talk. But the chatter afterwards made me realize that the way I run my business isn't the same way that others are forced to work at their jobs.

And then it got to the Weakest Geek competition. I was exhausted. Beyond exhausted. You know when you're so tired that you forget your own name? Yeah. I was that tired. We got through the first round of questions and I had no idea who I wanted to vote off. So I turned to the guy next to me and said, "I'll vote for you and you'll vote for me." He said sure. And I wrote down a name. And then I realized that I might not have written down his name. So I turned to the guy sitting next to me did what I had to do, "What's your name?" Joe. Joe. Zonker. Brockmeier.

Yes. I. suck.

Fortunately I don't think he was too offended. And fortunately I got voted off.

zonker gave the keynote this morning and it was quite excellent. My rough notes follow. A little tip for presenters: zonker uses cue cards which means he isn't tied to the preview on his laptop. I haven't noticed many other speakers doing this, but I absolutely think this is a wonderful idea. He also used stuffed animals (geckos and penguins) to buy attention and love from the audience.

Reaching the Masses by Joe "zonker" Brockmeier

Notes on the keynote presentation at SCaLE 7x.

• The chief problem is no longer technical. The problem is education and getting the word out.
• Have goals. Have very realistic goals. "We want more contributors." "Great." "What kind?" Need to have ways to measure your progress.
• Opt-in to send your hardware information is really important because you can use it to lobby vendors.
• Mailing lists are not the right tool if you want to have a detailed conversation. Move talk to the wiki. There are fewer arguments on a wiki because argumentative people don't bother to sign up for an account and take the time to not be friendly.
• Have a solid project infrastructure--y'know the Fail Whale.
∘ unclear trademark guidelines. Legal infrastructure. Software Freedom Law Center.
∘ have docs for beginners.
• "leader get out of the way" lead AND get out of the way as a spin on: lead or get out of the way
• If you step away, and no one steps in maybe it wasn't that important in the first place.
• When you are distributing your project make it really easy for everyone to install your software. It's not good enough to have svn and git repositories. It's barely good enough to have a .deb if it doesn't install really, really easily.
• Evangelists: know them and love them. Developers were asked to look at the people who don't self-identify as a developer. You need these people. You need them to help your project to succeed. "I've read some of your documentation." If you have a very small project your first step might be to recruit amplifiers who can help bring people to your project.
• Freedom is important. But people don't realize how important it is until it's taken away. You'd think that it'd be easy to explain DRM, but it's easy to download iTunes to iPhone. It doesn't make sense until someone can't move a movie to a device that is connected to a computer. Then it starts to hit home.
• If your software isn't better than proprietary, you're going to lose. Be sure to sell the community in why you are better than proprietary.
• "a non-practising journalist" not "former". Be cautious when you work with a journalist. How will what you say to a journalist look when it's in print. Assume nothing is off the record. Reach out to journalists who cover the area you're in. Not press releases and things that are really meant for investors. Make it personal. Offer to help journalists. Coverage means more users and more contributors. Everything you say online (and not just to journalists) is fair game. Be careful.
• Become the media yourself. Don't wait. Finding authors who can hit your deadlines. Offer to write tutorials and HOWTOs. you can make money doing it by writing for magazines. $200 for your project for the article pay can be contributed back to the project you're writing about.
• Your project should have a planet feed and a news page. You need to have things for Google to pick up for journalists to pick up. Podcasts.
• Even if you know that something is off the record. They can find another source for the same information.
• Collaborate with other projects. Where is there duplication and figure out where you can eliminate that duplication between the two projects. Spreading Linux first and openSUSE second. Expand the philosophy before you extend the brand.
• Do something even if it's wrong. Stop talking about things and start doing things. Even if it's wrong.
• Schools want to use old machines and community projects as well. But the hardware vendors are less likely to support this, but they're trying.
• Determine the baseline you are trying to address when preparing your marketing material and your documentation. School teachers are not the same as SCaLE attendees. You can't boil the ocean, so don't try to hit everyone with a single document. Run your documents through people that are an example of who you're trying to reach.
• Why didn't you advocate for community managers in your talk? What are your goals though? it's good for projects that have the money to hire one.
• Q: How do you sell the transition costs? A: Look for pain points where there is a return on investment. Don't try to get people to switch based on freedom--they will find new pain points that will really negatively impact you later. Focus on green field adoption where they've already made a decision to switch.
• Linux Dairy Council. groups.google.com/group/linux-dairy-council

This post could have also been called, "How to win friends and influence people" as part of my presentation included a give-away. I handed out ten free Flickr Pro account to each of the people who asked a question at the end of the presentation. That's right kids, I bribed people into asking questions by handing out schwag! These accounts came via a Flickr sponsorship of a HICK Tech event. Thanks Flickr, you rock!

With a couple of minor glitches my presentation on Drupal Multi-site at FOSDEM 2009 went really well yesterday. You can view the slides on slideshare.net and the video is now available as well (scroll down to see mine). If you want to understand how Drupal Multi-site works and you missed the presentation, please read the on-line documentation (instead of/as well as the slides). The talk itself was really short (about 20 minutes) with lots of time for questions afterwards. This presentation is a variation of the one I gave at DrupalCon Szeged Open for Small Business (video and slides are available for this prezzo) and also at FSOSS in Toronto. There will also be an article in the Open Source Business Resource later this year.

I had one little glitch in the presentation was because had the wrong permissions on the settings.php file when I was trying to demo an installation of Drupal. Let this be a lesson to all presenters: test ALL of your demo ALL the way through! Wim's screen cast was much more reliable for presenting and probably what I will use in the future. I forgot that my laptop didn't have the Web server in the same group as me so the settings of 664 should have been 666 to make the file read-writeable by the server. If you want to see Drupal installed, you can check-out the awesome Lullabot video on Installing Drupal 6. My apologies for not having tested all of the install beforehand!

There were some excellent questions after my short tour of Drupal Multi-site. I forgot to repeat the questions into the mic and they aren't necessarily covered in the slides or in the Drupal.org documentation. In no particular order, here are the ones that I remember.

What about backups? How often and what tools do you use?
The clients that I have on my multi-site install update their site about once a month. This means that weekly backups are more than enough. The module Backup worked well for Drupal 5; but moving forward check out Backup and Migrate for Drupal 6 and beyond. For more information on Backup and Migrate you can also read this quick tutorial.

Does Drupal Multi-site have an administration interface that allows you to jump into all of the Web sites from a single place (like WordPress's Multi-user)?
No. But I like it this way because some of my clients have full administrative access to their sites. More about WordPress MU is available on-line. 

When is your book coming out and where can I buy it?
The current schedule shows that we'll be printing at the beginning of April. Konstantin and I are currently waiting to review the final PDFs before the book goes to print.

How much power do you give your users within their sites? Do they get full administrative rights?
My goal isn't to prevent my clients from having full access; but I do want them to be limited to asking questions related to the tasks they perform on a regular basis. This means I give them fairly limited "content manager" roles to start. As they grow into their site I reveal more tasks (for example: adding new categories). This controlled release of power has worked well for us.

What about Plesk/cPanel? Do you give your clients access to a Web admin panel?
Nope. For the most part these clients are using @gmail addresses and don't want another email address to remember. They are very happy for me to shield them from having yet another thing to learn. In fact all of this is hosted on a Dreamhost VPS. Of course I have corporate clients with much more rigorous needs. They typically host their site in-house, or have dedicated hosting. They are not part of the Drupal multi-site installation.

Do your clients know they're on a shared system? Do they care? Do you promote it?
I find clients are very happy to get free security updates during the year. This means they're on a shared code base, but they also know their site is completely unique (because it is its own database). I haven't been promoting the group as a marketing techique, because I'm at the maximum number of people I want to help in a single night. I may open up new help nights for other industries though. For example: right now they are almost all small businesses; but I have enough Not For Profit companies that I could add another monthly help night for just these clients.

How does multi-site work with multilingual Web sites?
Unfortunately, I'm not sure. I've played a little bit with the I18N functionality in Drupal 6, but I haven't tried it with a multisite install. Does anyone else have experience with this? Please leave it in the comments! There was also a question about different regions and domain access. Check out the module Domain Access if you want to know more about that.

Do you use any kind of version control system?
Yup! I download files directly from Drupal's CVS repository (brief tutorial) and local changes to themes are stored in Bazaar on my laptop and then pushed up to the server using bzr upload.

So you have to run update.php for each site individually? That's really annoying. Why don't you automate it?
I seem to recall someone mentioning a Drupal module that would automate updates across a multisite install; but I can't find a reference to it now. I personally do my updates by hand and one at a time because I want to know if something has failed as part of the update. The process goes as follows: check the sites directory for all domains that need to be pulled offline; pull all sites into maintenance mode; take a snapshot of the db and all core files; update from CVS to the latest stable version of Drupal; individually update sites and bring them back online. I have about 20 sites and this takes me about an hour to do. Your mileage may vary.

Please let me know if you have more questions and be sure to check out the documentation on drupal.org on how to set up multi-site.