3 campaigners, 6 years, 7 schools: Building Tomorrow

Cross-posted from my EchoDitto blog.

How much did your elementary education cost? The clever folks at Building Tomorrow have found a great way to use that simple question to drive an innovative campaign that connects the costs of a primary school education in the United States to the work they do building schools in Uganda.

I first learned about the campaign through a friend’s Tweet, and followed the link thinking that I would learn just how ridiculously expensive education is in our country, and maybe be encouraged to donate money towards schools that need help in the United States. Much to my surprise, after answering two easy questions, I was brought to this page:

Inspired by their simple-yet-effective calculator app, I called up Maggie Kirkpatrick, Assistant Director at Building Tomorrow, to learn more about it.

The Organization
Founded in 2005, Building Tomorrow is a surprisingly small organization, consisting of only three people (yes, you read correctly). In spite of their small size, they have helped build seven schools in Uganda, and are in the process of building another three. All of their schools are, ultimately, public government schools. Building Tomorrow provides the infrastructure for the schools, and partners with local ministries of education who provide the teachers. The idea is, once Building Tomorrow leaves the area, the schools can still function at full speed. The schools are all primary, P1-P7 (equivalent to our elementary schools) and can host up to 325 kids per school. They focus mainly in rural Uganda, because, well, it’s where they have personal contacts and the rural areas are where the highest population of kids reside, with the least amount of access to schools.

Campaign Messaging and Strategy
I asked Maggie if they had implemented any specific kind of outreach campaign for the calculator, or if most of the publicity had happened organically. She said it was a combination: the outreach team consists of only 2 people. They spent a significant amount of time emailing blogs and news outlets, doing research to find out who might be interested in promotion, and doing their best to email people they thought might be willing to help. But, for the most part, it has spread organically via social networks.

The messaging, as Maggie put it, was “very deliberate. The only way people are going to buy in is if we don’t spam them with messaging,” and I argue it’s the messaging that made this campaign successful. It’s the reason I clicked on the link and followed through. Maggie made another point I thought was interesting: this campaign messaging won’t ever be out of date. It’s always relevant, it’s always going to be interesting to see how expensive your education was and how you might be able to contribute to someone else’s.

The key contributors to this campaign are young people in the United States. High school and college kids take the brunt of the workload in spreading the word and fundraising. Building Tomorrow takes the money they have raised and creates “challenge grants” in Uganda, proposing to local communities that the organization will fund the school if the community puts in the legwork. What results is a community effort to literally lay the brick for their schools, while the bricks are provided by Building Tomorrow. Schools are built by family members – grandmothers, fathers, sisters – and local community members.

Building Tomorrow currently has over 20 college chapters, all working to fundraise for schools in rural Uganda. In addition, they have a partnership with Key Club International. 100% of the money raised goes directly towards construction of the schools, and as Maggie said, “We work hard to make that a commitment.”

Finally, they have donors and do some grant writing that helps fund operating cost for the organization, but my guess is the operating cost is low given they are currently only a three-person company.

Tools and Technology
Clearly there is a technical aspect to this campaign in addition to the deliberate online strategy. Some resources that Building Tomorrow used included working with sparked.com to get tips on how to build an accurate calculator. The technology behind the calculator is relatively simple, and uses data from the National Center for Education. The calculator uses no more than some basic html and a “digital excel spreadsheet.” I wonder about the sustainability of such a simple system. The calculateit.org app itself is built on software provided by Exact Target, who also help with email campaign management, and hosts microsites and landing pages.

Statistics
The calculator has been loaded just about 2,000 times since it launched 2 weeks ago. Most donations are coming from first-time visitors to the site.

When I first clicked through to the Building Tomorrow website, it’s because, to put it simply, I was intrigued. To me, this was already a successful campaign having fit a few basic criteria:

1. I found out about it organically, not via an email list or advertisement. I heard about it from a friend.
2. I was intrigued, and not by the actual intent of the campaign, but by a very clever hook, and I participated as a result.
3. I told my friends about it. I’m blogging about it.

At the end of the day, it’s not a campaign that has been earth-shattering in terms of numbers – it’s not seeing 100,000 or even 10,000 views every day. But right now, a small 3-person organization that has existed for 6 years has funded the construction of 7 schools in rural Uganda that host a total of 2,275+ children. I think that’s pretty amazing.

Updating your Drupal site using Drush

A few weeks ago, Alan wrote about how to find out if your Drupal and Wordpress sites are up to date. So, what if you find out your Drupal site is horribly out of date - core, modules and all? What then? If you run the script Alan wrote about, or you simply notice the alert in the admin section of your site notifying you that your site has updates available, most of the time you'll want to implement at least some of these updates. Note: The notice for updates is powered by a module called Upgrade Status. It's a good idea to install this module on your Drupal site so you don't let updates go by the wayside. When you see the update notice, click “available updates” and see which updates are necessary. You can also reach this page by going to admin/reports/updates in your browser (for example, www.yoursite.com/admin/reports/updates). The updates page will display which version of Drupal you are running as well as the recommended version of Drupal, and the same for each contributed module running on your site. If something is highlighted in green, it is up to date; yellow means there is an update but it’s not critical; red means you should update right away. So, how do you update Drupal Core and contributed modules? Generally, if your site is hosted with EchoDitto and/or you have a technical retainer with us, we will inform you of any critical updates and estimate the time needed to implement these updates. If you are hosting outside of EchoDitto or do not have a technical retainer, however, what follows is a step-by-step guide for updating your Drupal site safely and efficiently. Note: As always, it's a good (read:great) idea to have a development site, separate from your live public-facing site. This should be used for any testing purposes, including updating Drupal core and modules. You should always do updates and testing on your development site first, before ever touching your live site. In addition, it is always best to have a developer on your team take care of updating your site. Generally, site updates are tech-heavy, and require intimate knowledge of version control systems and database configurations. My preferred method for updating modules and Drupal core is via Drush. You’ll find a few possible ways of updating your modules and Drupal core below. I generally think you should follow whichever steps are appropriate depending on your knowledge of the tools at hand. Keep in mind the following steps are for updating on a development site only. For the purposes of this post, I'll go through the following scenarios:

• Updating via Drush (with svn)
• Updating via Drush (without svn)
• Updating manually (with svn)
• Updating manually (without svn)
• Updating on your live site

Updating via Drush (with svn)

1. Change to the root of your Drupal install
2. Back up your database
3. Run 'drush upc --version-control=svn --svnsync'. 'drush upc' updates all contributed modules, without running update.php OR updating core
4. Update core: run 'drush up'
5. Run 'drush updb' to update your site locally.
6. Test locally before committing to your development site.
7. Add any new files and commit your changes. Use 'svn add --force *' to force the addition of all new files.
8. Use 'svn commit' to commit your changes.
9. Run 'drush updb'
10. Test

Updating via Drush (without svn)

1. Back up your database
2. Run 'drush up' or 'drush upc'
3. Run 'drush updb' - this will run update.php

Notes:

• The 'drush up' command updates modules, core, and runs update.php
• The 'drush upc' command updates modules only, and does not run update.php

Updating manually (with svn)

1. Back up your database
2. Download the new version of the module from drupal.org
3. 'svn remove' the old module file ('svn rm sites/all/modules/modulefolder')
4. 'svn commit'
5. Extract the new module and place it in sites/all/modules
6. 'svn add' the new module folder
7. 'svn commit'
8. Run update.php. Do this by going to www.yoursite.com/update.php
9. Test, test, test

Updating manually (without svn)

1. Back up your database
2. Download the new version of the module from drupal.org
3. Delete the old module directory, and replace it with the new downloaded copy
4. Run update.php. Do this by going to www.yoursite.com/update.php
5. Test, test, test

Updating on your live site

1. Back up your database.
2. Put the site into maintenance mode. You can find that setting at /admin/settings/site-maintenance and select “Off-line.” Customize your offline message as appropriate.
3. Update modules and core (following whatever steps you followed above: drush (with or without svn), svn, or manually).
4. Run update.php. Do this by going to www.yoursite.com/update.php.
5. Test.
6. Take the site out of maintenance mode.
7. Test more.

Want more info? Here are some helpful links:

• Drush: http://drupal.org/project/drush
• Subversion: http://subversion.apache.org/
• Coder: http://drupal.org/project/coder
• Tutorial: http://www.lullabot.com/videos/porting-drupal-modules

Making Drupal Happy: When Themes and Modules use the same name

We came across an issue with a site recently, where the name of the custom module file was the same as the name of the theme. So, for example, if the theme name was Bork, the module name was bork.module. This can cause a variety of problems since the two share name space. Problems can include blocks disappearing (both from your site, and from the /admin/build/blocks menu), printing $content returns only 'array,' and more. There are a few ways you can remedy this. We had already created another module file, called bork_helper.module, so the best option seemed to be to merge the contents from bork.module into bork_helper.module, and rename functions accordingly. It's a relatively easy process as it turns out. I first backed up the database (always, always), disabled the module, merged bork.module into bork_helper.module, and did a search and replace for the function names: bork_form_alter became bork_helper_form_alter, and so on. I initially considered doing this from the command line using sed, so: sed -i '' -e "s/bork_form_alter/bork_helper_form_alter/g" * Unfortunately when I did this I got a message, "sed: modules: in-place editing only works for regular files." Meaning, you can't pass this in a directory. If any directories are included in *, sed will fail. Ethan suggested I try using 'find . -type f' instead of * which would search for all files in the current directory and sub directories, but then you also need to exclude .svn which can get tricky. I opted instead to do it a "simpler" way, and use TextMate's search and replace function. This worked wonders, until I saw after running svn status, that it thought I had edited every single block template in that directory. I hadn't touched any block templates. What I found upon using svn diff was that each file had removed the newline at the end of each of these template files. In Drupal, it's standard practice for all text files to end in a single newline (\n). This avoids the verbose "\ No newline at end of file'' patch warning and makes patches easier to read since it's clearer what is being changed when lines are added to the end of a file. Read more about it here (I did): http://drupal.org/coding-standards. I still don't quite understand why TextMate did this automatically, but it was at least relatively easy to fix. I reverted to the old block templates. After merging and renaming functions, I committed the new module file, bork_helper.module back, and re-enabled it via drush. I tested the site, and all was well! Lessons learned? Never name your module file the same as your theme. But if you happen to inherit a site that does, immediately fix the problem or you'll run into bugs you can't explain.

Customizing ShareThis WordPress plugin

I wrote about this on my personal blog after realizing that having the ShareThis links at the end of my blog posts might actually prevent them from being shared as much, assuming that most people won't read the posts in their entirety (sad, but probably true). For those of you already confused, ShareThis is a WordPress plugin that enables users to share your content. It places icons after each post to share via Twitter, Facebook, Email, etc,

So in addition to having ShareThis links after each post, I decided to add them to the left sidebar where it lists the date of the post, and comments.

Once you enable ShareThis, and set the links to show up for each post, it automatically grabs the information for that post when you share it. So, if you just copy the code for ShareThis to another place on your site, it won't work, because it's no longer pulling the actual post info: Title, URL, etc.

I fixed this by adding in a few WordPress functions that call for the title and URL of the post. For example, instead of doing this:    <span class='st_facebook' st_title='{TITLE}' st_url='{URL}' ></span> I called for the actual permalink and title of the post. Like so: <span class='st_facebook' st_title='<?php the_title()?>' st_url='<?php the_permalink()?>' ></span>

Seems to me this is a pretty awesome (and super easy) tweak to ShareThis if you don't want it at the end of each post.

Twitter by any other name

The other day, The Washington Post advised its journalists NOT to engage with their readers on Twitter. Mashable reported that a memo was sent to staffers specifically telling journalists not to use their Post Twitter accounts to respond to critics, or their personal accounts to "speak on behalf of the Post."

We've seen instances of Twitter getting journalists into trouble, including Octavia Nasr, former correspondent for CNN, who was fired for tweeting that she respected a prominent leader of Hezbollah.

There are quite a few things at play here, but I immediately question The Washington Post's decision to specifically advise its journalists against engaging on Twitter. Just because it's Twitter, does not mean the level of engagement should change. Just because it is the internet, and not TV, does not mean the level of engagement should change. What should change is the kind of engagement, the kind of thinking that goes behind your words.

I think there's a tendency to treat the internet, and Twitter specifically, as a different kind of world from anything else, especially for those who work outside of this industry. Many people still don't understand or even use Twitter. But really, for journalists, how does it differ from any other kind of information dissemination? It shouldn't. The truth is, The Washington Post should not have told its journalists not to engage. Rather, they should be doing what we are doing here at EchoDitto: teaching people how to use Twitter and other tools successfully.

In working at EchoDitto for many years, I have learned that very rarely is the answer to not engage. We teach our clients how to engage their audience in a productive way. Journalists are taught to be, and try to remain, unbiased. In the end, it is not Twitter, it is simply the written word. As a journalist, when you are writing, you should always keep in mind the publication you work for, the story you are reporting, and the brand you represent. Whether it's Twitter, Facebook, FourSquare, or the front page of The Washington Post, your words will be judged. So choose wisely.

WordPress Stylesheets: wp_enqueue_style

If you're building a Wordpress plugin, or simply dealing with including Wordpress stylesheets in your theme, there are a few approaches you can take. For the most part, I've included stylesheets for Wordpress sites in header.php, since (obviously), header.php is included in every other site file. It seems this is relatively standard practice for Wordpress sites. I see it all the time: However, as it turns out, there's a better way of doing this - using wp_enqueue_style. Why not just include them in header.php? It seems pretty simple to do that and never think twice. Well, first, using wp_enqueue_style ensures that your stylesheets will load in the correct order. Second, it comes in handy if you're trying to restrict scripts and/or css from loading on certain page (for scripts you'd want to use wp_enqueue_script), or alternatively, if you want to load specific stylesheets only on plugin pages. You can execute this in a number of places, including functions.php, or, if you're building a plugin, from within your main plugin file. There are a few parameters for wp_enqueue_style including $handle (the name of the stylesheet), $src (the path to the stylesheet), $deps, $version, and $media. I really wanted to include a bit about template_redirect in this post, as it is related, but "a bit" turned into three paragraphs, so stay tuned!

Making your Community Matter

Sometimes, when I'm working on a project, I tend to read or say the name of the project so many times that it loses meaning. Community Matters, Community Matters, Community Matters.

But then, suddenly, the project comes to fruition. It's not just a project anymore, it's not code or strategy or even just an idea. Suddenly the work comes alive.

Earlier this year, we wrote about welcoming the Orton Family Foundation to EchoDitto. Today, the Community Matters Conference kicks off in Denver, Colorado. The Community Matters conference is "a commons for individuals and organizations working to steer change, engage citizens and build strong, vibrant communities from the ground up."

The conference will focus on enabling community leaders to make changes that are important to people like you or me. The conference not only focuses on providing tools to community leaders, but helping them connect with each other as well.

We built the communitymatters.org website primarily to be informational - attendees can visit the site to find out more information regarding the conference, register, and read about the speakers and panels. A few months ago, in discussions with the Orton Family Foundation, we began to implement a "Connect" section of the site, to enable the attendees to connect with each other in a number of ways.

Via this Connect page, attendees of the conference can find each other on Twitter, read each others blog posts, and interact with and meet each other via an online forum. Those who work in this industry, who help build connections between people on the ground, know just how important these connections can be in helping make real change.

The conference will allow the work that so many community leaders have been doing for months, or even years, to come to life in their own neighborhoods. So check it out: read about it on the website, their blog, or read more conference news on Twitter.