Donor Tools has a new home page – check it out!

Beautiful Printable Pages with CSS

In Donor Tools every page is a report. Adopting this simple philosophy has allowed us to almost completely eliminate the need to build dedicated reporting features. And it was almost effortless to implement – it took maybe a couple of hours.

CSS aficionados should recognize this trick already: it’s called print style sheets. Basically you have one set of stylesheet for screen display, and a separate set of styles for printing. This works in just about every modern browser, even the inferior ones. And the great thing about print styles is that we often don’t need to worry about complicated positioning or page flow – just provide some basic style instructions, hide non-printable controls and headers, and it looks beautiful on paper.

This has, of course, been discussed elsewhere, but I’m going to show you how we put it to work for Donor Tools.

I like to use CSS Edit, which in my opinion is the cream of the crop of CSS editors.

The first thing I do when I’m ready to start working on the print style sheet is to think about what I want to show up on paper, and what should be hidden. Opening up my page in CSS Edit, I use the X-ray tool to examine the blocks and divs that construct the page. Good HTML construction at this point is crucial to being able to target specific areas of the page.

Next, I turn off all the screen styles and switch the print stylesheet to display on the screen. Donor Tools is built in Rails, so a quick edit to the application.html.erb file is all that’s needed:

Flipping over to CSS Edit, now I can edit my print.css stylesheet with instant feedback.

I’ve turned off a lot of divs by targeting the names of the elements, and then applying display:none;. I also made a generic style called .noprint that I can apply to any random elements that should not print.

That’s it! Now, when someone uses their browser’s print function, they’ll get a beautiful, well-styled printout of what they’re looking at on the screen with no extra effort.

I talked about another approach in Easy Printable Pages with Rails

- or –
Why I plan not to renew my subscription
- or –
Why, Rupert Murdoch, Why?

John Gruber calls out the Wall Street Journal’s declining quality: An Aug 1 front-page article drives home my increasing gripes with the WSJ with a front-page article “addressing the issue of whether Barack Obama is ‘too physically fit’ to be elected president”.

• Read the “article” here: http://online.wsj.com/article/SB121755336096303089.html
• Gruber’s source

Ok, that’s it. I’m done.

For months I’ve felt this welling up of frustration every time I open the morning paper. Sometimes I just let it sit in the driveway all day. I no longer feel the smug satisfaction that I used to feel reading the best newspaper available.

It seems to me that Wall Street Journal front pages are increasingly given over to eye-catching illustrations and info-graphics. The format and content of the articles seem now to be designed to appeal to “the masses”, or the “more sophisticated consumer”. They even changed the size of the paper, so it’s no longer the trademark WSJ wide-format. It fits on the newsstand next to the New York Times and the LA Times and the Austin American Statesman, and it still jumps out at you. It feels “mainstream”, and appealing in a mass-market sort of way.

But I subscribed to the Wall Street Journal precisely because it wasn’t appealing. I wanted to read the news that the economic elite reads; I wanted information that the common citizen wasn’t interested in.

I’m not interested in Barak Obama’s waist size, or what John McCain is mad at him about today, or Heath Ledger’s fantastic performance as The Joker – I can get all that “news” from our local rag. I’m not interested in op-ed articles masquerading as reporting – I can get that from Fox News and CNN. I’m interested in the impact of Congress’ offshore drilling policies on oil futures, and who just joined whose board of directors, and what are Starbucks’ plans to compete with McDonalds.

It’s a sad day.

The Wall Street Journal no longer offers anything of greater value than I can get from my local rag. Oh where, oh where will I turn?

... then what?

This is a short rant about a really minor irritation that’s kinda funny.

One of my little pet peeves is when someone begins a request with “if you could”. For example, “if you could pass the salt….” The request invariably trails off with no resolution. It bugs me, so if I’m in a devilish mood I’ll stare at the person (usually my wife) expectantly until eventually prompting them with “yes, then…? If I could pass the salt then what?”

The thing is, I write code for a living, so when I hear or see the word “if”, my brain immediately starts compiling the statement. If there’s no “then”, my brain will raise a syntax error.

Funny thing is that I find myself saying this too, much to my chagrin. But it’s everywhere – I hear it in movies, talking to my neighbors, you name it. So, as a public service announcement, please, for the sake of the English language that we leave for our children, please remember to close your if statements.

Importing Donors with Donor Tools

Everybody has at least a few donors already, right? And some have lots and lots of donors – too many to type in by hand. What do you do if you want to get get started with Donor Tools? Easy, just import them.

New Feature: Users and Roles

Since Donor Tools is web-based, your users can access your Donor Tools account from anywhere – office, home, or on the road. Here’s how to set up different roles for different users of your system.

Feature Spotlight: Recording Donations

One of the things that we wanted to accomplish with Donor Tools was to provide workflows that help you get closer to your donors while still working efficiently. So we’ve made it really easy to enter a lot of donations very quickly while still giving each donor individual attention.

If you need to create a wizard, with forward and back buttons for several different steps, a great way to do it is to use the acts_as_state_machine plugin.

But for just two or three steps, loading a whole plugin seems like overkill. Instead of loading a whole plugin, you can simulate the same functionality by dropping next! and previous! methods into your model like so:

  # State Machine 
  # Guilt-free stateful modeling! 
  # These two simple methods simulate all the goodness of 
  #   acts_as_state_machine without the added fat of an included plugin. 
  def next!
    next_step = case self.state
    when "step1" 
      "step2" 
    when "step2" 
      "step3" 
    when "step3" 
      "step3" 
    end
    self.update_attribute(:state, next_step)
  end

  def previous!
    previous_step = case self.state
    when "step1" 
      "step1" 
    when "step2" 
      "step1" 
    when "step3" 
      "step2" 
    end
    self.update_attribute(:state, previous_step)
  end

  def current_step
    @current_step ||= self.state
  end

I was debugging css today, and I ran across some strange behavior with our pagination links. Occasionally the number of pages would wrap around, which is normal, but I noticed that in Safari the right side of the last element in each row was getting chopped off.

Here’s a picture in Safari (and Webkit):

Here’s the same page (what it’s supposed to look like) in Firefox:

Here’s the HTML:

<div id="pagination-links"><strong>Pages: </strong>
  <ul>
    <li class="selected"><a href="#">1</a></li>
    <li><a href="#">2</a></li>
    <li><a href="#">3</a></li>
    <li><a href="#">4</a></li>
    <li><a href="#">5</a></li>
    <li><a href="#">6</a></li>
    <li><a href="#">7</a></li>
    <li><a href="#">8</a></li>
    <li><a href="#">9</a></li>
    <li><a href="#">10</a></li>
    <li><a href="#">11</a></li>
    <li><a href="#">12</a></li>
    <li><a href="#">13</a></li>
    <li><a href="#">14</a></li>
    <li><a href="#">15</a></li>
    <li><a href="#">16</a></li>
    <li><a href="#">17</a></li>
    <li><a href="#">18</a></li>
    <li><a href="#">19</a></li>
    <li><a href="#">20</a></li>
    <li><a href="#">21</a></li>
    <li><a href="#">&#8594;</a></li>
  </ul> of 21 total pages
</div>

And the CSS:

#pagination-links {
  color: #404040;
  line-height: 25px;
  margin: 0 15px 15px 15px;
  font-size: 12px;
  width: 300px;
}
#pagination-links strong {
  padding-right: 10px;
}
#pagination-links ul {
  display: inline;
}
#pagination-links ul li {
  display: inline;
}
#pagination-links ul li a {
  background-color: #fff;
  border: #c5c0c0 1px solid;
  color: #5b969f;
  padding: 2px 6px;
  text-decoration: none;
}
#pagination-links ul li a:hover {
  border-color: #404040;
  color: #404040;
}
#pagination-links ul li.selected a {
  background-color: transparent;
  border: 0;
}

This display behavior only appears in Safari. It looks correct in Firefox (2 and 3), as well as IE 6.

Safari version: 3.1 (5525.13) Webkit revision: r31388

At first blush, this looks like a browser bug. But before I get too much farther in tracking this down, has anyone else encountered this? Any insight would be appreciated!

Update:

Here’s a zipped file with everything you need to reproduce the bug: cut-off-test.zip (86k)

Speaking of Edge Rails… attachment_fu will break because Edge has extracted callbacks out into a separate module.

To prevent unnecessary pain and suffering, see http://blog.methodmissing.com/2008/1/19/edge-callback-refactorings-attachment_fu/

Just paste that whole blob at the bottom of your attachment_fu.rb file and you’re good to go.

I was having an awful time submitting a form with a check_box. No matter what I did, it would only return “0” or “false”, never “1” or “true”, no matter how hard I mashed the mouse button on the check box.

  <%= check_box :fund, :tax_deductible %> <%= f.label :tax_deductible %>

I finally tried moving to edge Rails (from Rails 2.0.2), and the problem went away. Anyone else experience this?

Calculating dates is arguably one of the most complicated parts of programming. Ruby eases the stress with some great tools to help parse and calculate dates.

But lately I’ve run into some really strange behavior, and I’m kind of at a loss. I’m posting it here in the hopes that somebody can shed some light on why this is happening.

Basically I’m getting inconsistent results with the different parsing libraries. I’d like to be able to pass dates like “2/22”, “2/22/08”. Parsing a date like “2/22/08” should return February 2, 2008. But here’s what happens in the different parsing libraries:

>> Time.parse("2/22/08").to_date
=> Fri, 22 Feb 2008

>> Chronic.parse("2/22/08").to_date
=> Fri, 22 Feb 2008

>> Date.parse("2/22/08")
=> Wed, 22 Feb 0008

But as you can see, passing “2/22/08” to Date.parse we get the Year of our Lord, uh… 8. That’s obviously not right.

What about a date with no year, like “2/22”? I’d like it to return the date in the current year.

>> Date.parse("2/22")
=> Fri, 22 Feb 2008

>> Time.parse("2/22").to_date
=> Fri, 22 Feb 2008

>> Chronic.parse("2/22", :context => :past).to_date
=> Tue, 15 Feb 2022

Date and Time do pretty well, but even with :context => :past Chronic returns the year 2022.

What’s going on here? I’ll keep playing with it, but any insight would be appreciated.

I saw a great presentation about Git by Rein Henrichs at Austin on Rails the other night. I’ve heard a lot about Git, but based on what Rein said, I finally and decided to give Git a try. So far I have been extremely impressed. So impressed, in fact, that I’ve migrated the Donor Tools repository to Git, and I haven’t looked back since.

One of the best little benefits is the fact that Git only puts one .git folder at the top-level of your project, unlike Subversion, which litters every folder in your project with a .svn directory. Nice. I’m also loving the ability to branch and merge without tearing a whole in the space-time continuum.

Git takes a little getting used to. It was created by some extremely smart people (namely Linus Torvalds, who also created Linux), so the inner workings are completely beyond the scope of my comprehension. (Thanks for trying to explain it though Rein.) One of the toughest things to wrap my mind around is how to push and pull branches from remote repositories. But even baby steps with Git are more powerful than Subversion, so I’m really looking forward to becoming more experienced with Git.

The cost of freedom is always high.

Most of the republican candidates in the race today are in favor of maintaining the war in Iraq. One of them even said that he’d keep it going for 100 years if necessary!

Now, I once heard that The War is costing us about $100,000,000,000 ($100 billion) per year. In sheer morbid curiosity, I was wondering how much that would end up costing us after 100 years. So I fired up Numbers and ran a quick, very simple calculation. Using an inflation rate of 3%, 100 years of war with Iraq would cost us…

$60,728,773,269,521

That’s 60 trillion dollars.

Please correct my math. I was wondering, maybe you can explain this to me… how would we come up with $60 trillion and still lower taxes?

I’m a little late on posting this – I was so relieved to be finished with my graduate research project that I have been loathe to pick it up again. But, I promised to post the results, and folks have been asking about it.

Quick link to the report: http://www.artofmission.com/survey/

We had a great response for Survey Version 2.0 — 219 responses in about a month! In all, I looked at over 220 church websites. The feedback we received was wonderful – thanks so much to everyone who participated.

Surprisingly, I found that there was not as much connection as I expected between the cost of a church’s website and its quality. Of course, in my opinion, more expensive church websites tended to look better. But many churches are endowed with generous and talented volunteers that help keep the costs low.

The most important factor seemed to be attitude. From my executive summary:

churches that embrace the web as an opportunity tend to get more value out of the medium than those that approach it as a necessary evil. It can seem obvious when a church has forgotten about their website, or “slapped one together” just in case it turns out that they need one. At the same time, it can also be obvious which churches genuinely expect to connect with people through their website.

You can download the final paper and presentation from http://www.artofmission.com/survey/. Enjoy!

P.S. Congratulations to Garet Robinson, who won the iTunes gift card! (Garet was randomly selected by a computer program from a list of everyone who filled out the second survey and provided an email address.) Happy listening Garet!

With a little bit of fanfare, we recently announced Donor Tools, a new donor management app for non-profits.

I used to work at a small non-profit, and I was never satisfied with the software that was available to us. It all seemed either too hard to use, too clunky, too slow, or 20 years old. Ever since then I dreamed of making a killer app for non-profits – one that’s easy to use, has just a few features that every non-profit needs (and not a lot of extra features that only a few need), helps non-profits get to know their donors better, and is affordable.

We’ve been writing code for Donor Tools since July, and it’s exciting to watch it take shape. There’s still a lot to be done. If you’d like to keep an eye on the development progress, be sure to subscribe to the news feed.

Pretty soon we’ll need some beta testers. If you know of any nonprofit organizations that might be interested in helping us beta test, please invite them to subscribe to the mailing list on www.donortools.com

• Donor Tools
• Donor Tools Blog

Say hello to Radiant Factory, our new theming service for Radiant CMS.

Basically, Radiant Factory is a theming service for Radiant CMS. We take your design and content and turn it into a series of layouts, snippets, and pages that you (or your client) can manage with the fabulous Radiant content management system.

I’ve fallen in love with Radiant’s easy, straightforward website administration. Honestly, I always hated content management and website update tasks until Radiant came along. The idea behind Radiant Factory is simple: share the love. Radiant Factory is my way of helping web designers provide an even better product to their clients.

So check it out and let me know what you think. Your feedback is appreciated!