Software4Nonprofits Blog

Sorry to bug you again so soon, but I suddenly had a thought about a somewhat signficant change that I wanted to get people’s opinions on.

Currently, if you create a receipt (or receipts) using Receipt menu options other than Current Donor Sample, and then close the receipt-viewing window without printing them, saving them to PDF or sending them by email, a question pops up. It asks whether you want to save the receipts back to the database anyways.

I find what happens a lot is that people answer Yes to this, when they should have answered No. Then when they go to run the receipts later (perhaps at the year end), they find out that some donations have already been receipted, even though the receipts weren’t sent to the donors, and those donations thus aren’t included on the new receipts. The solution is usually to delete all of the receipts with Receipt -> Delete Range, and then recreate them. But this leads to a lot of support calls and emails!

What I’m wondering is, maybe I should just remove the option to save the unprinted receipts to the database. So if you have only viewed them, and close the window, they are gone. It is just a preview, in essence. (There would be a message explaining that, but no option about it.) That would eliminate that support headache for me, and that problem for those users who have that problem.

I really can’t think of a situation in which I would want the receipts to be saved even though I hadn’t printed (or PDF’d or emailed) them. Can any of you? You can always recreate them with the same Receipt menu option you just used, of course.

Another slightly related change that I already made yesterday was, if someone uses Receipt -> All Donors and it’s before the year end, to put up a message saying that that menu option is usually only used after the year end, and confirming that the user wants to do that.

Any thoughts? Thanks.

I have just added two more reports to the Reports -> Donation menu, One Date Details and Summary, and One Date Details and Summary with Member/Env. #, which combine the One Date Details reports with the Summary by Category part of the One Date Summary report. That will allow some users to print only one report, who previously printed two, to confirm one date’s donations.

However, that brings the number of options on the Reports -> Donation menu to 16, which is a lot. The more options on a menu, the harder it is to find things. So, I’m thinking of moving the now 5 different One Date reports (3 if you have the Member/Envelope # field turned off, so you don’t see the related reports) to a new submenu.

There are two options. The first is to have it be a submenu off of Reports -> Donation, e.g. Reports -> Donation -> One Date, so the first such report would be Reports -> Donation -> One Date -> Details, and so on. The advantage of that (over the next option I will present) is that it will be easier to find for existing users. The disadvantage is that it’s another mouse click or keystroke to select those reports, which especially for churches are among the most commonly used reports. Also, for those entering the program with the Limited User password, who currently have only those One Date reports available under the Reports -> Donation menu, it will look strange to have to go down an extra level to get to those reports.

The second option is to have a new submenu under Reports, namely (say) Reports -> One Date, or perhaps Reports -> One Date Donation, with the 5 specific reports under that. The advantage of that is that it keeps it to the same number of mouse clicks or keystrokes to get to those reports as it was before. The disadvantage is existing users will have to figure out where to find those reports now. (At least, those who don’t read and understand my notes about what’s in the new version that I send out with the release emails!)

Or of course, I could just leave things alone, and let people suffer with a long list of 16 reports on that Reports -> Donation menu.

What do you all think I should do about this? Please Comment on this blog post to let me know. Thank you.

I’m working with a fundraising consultant who helps churches with multi-year capital campaigns, and we are designing a set of improvements to DONATION to more properly handle multi-year pledges. (Currently, as you probably know, DONATION has only an Annual Pledge field for the current year’s pledge, which is assumed to be for the donor’s total donations.)

I’d like your comments on the following suggested set of features. Anything sound wrong? Anything missing? I’m not trying to cover every possible pledging situation at this point, just targeted multi-year campaigns, but if you feel that focus is inappropriate, do let me know.

• Sort of like with the Donation Description field, add an option (in Maintenance -> Main Windows Options’ Donor Details tab) to add a drop-down arrow on the Annual Pledge field, that if clicked, brings up a small window for specifying multi-year pledge information. If this option is not selected (which by default it will not be) then multi-year pledging will not be supported in the program, and most of the following features will not appear. (Annual pledging will still work as it does now.)
• If you do select that option, then if you click on the drop-down arrow in the Annual Pledge field, a small window will come up that allows you to enter the following fields:
  • Number of Years in the pledge. The control for this might be one of those controls that shows a number, and has up and down arrows to increase or decrease it, between specified limits (such as 1 to 10).
  • Start Date of pledge
  • End Date of pledge (not entered – calculated based on the previous two fields)
  • Total Pledge Amount (i.e. for the entire multi-year pledge period)
  • Perhaps also a not entered but calculated field for the annual pledge amount, which is the total divided by the number of years?
  • Drop-down for the Donation Category that the pledge is for. (This will show all categories, and also have an option “All Categories”, which means the pledge can be fulfilled by any donation the donor makes in any category. If a specific category, like “Capital Campaign”, is selected here, the pledge can only be fulfilled by donations in that category.)
  • A button to display the current Amount Outstanding (not yet paid) on the multi-year pledge. (I don’t think this should be displayed immediately and automatically, because it wouldn’t make sense while the user was filling in these fields, or while they were in the middle of changing them.)
• If the user has entered multi-year pledge info in this way, then when they return to the main window, the field label “Annual Pledge” in the Donor Details area will change to something appropriate, like “5 Year Pledge”.
• Also in Maintenance -> Main Windows Options’ Donor Details tab, there will be a drop-down for “Default Multi-Year Pledge Category”, with the same options as in the popup pledge details window – “All Categories”, plus all donation categories. If this has been specified, then whenever the multi-year pledge window is opened for a donor, where that info has not been previously filled in for that donor, this selection will be made automatically.
• When you start a new year, with Maintenance -> Change Year -> Next Year, and it is copying the donor details from the one year to the next, all multi-year pledge fields will also be copied. The one exception will be pledges that have expired (their end date was in a previous year) – those will be deleted, but only from the new year’s donor record.
• Two reports will be added (can you think of others that might be needed?):
  • One report with the columns donor name, start date and # of years (also end date?), category, pledge amount, and total given against that pledge (e.g. in the category) within the time range. Maybe also amount still outstanding? Sorted by name?
  • One report of only those who have fulfilled their whole pledge, sorted in descending date order of when it was fulfilled. For organizations that are collecting pledges through monthly pre-authorized debits, this could be used to determine when to turn off the preauthorized debits for those donors who have paid up in full.
• Add mail-merge fields (at least to the Total Donations Information letters) for Total Pledge Amount, Pledge Duration (e.g. “5 year”), Pledge End Date, Total Pledge Paid, and Total Pledge Outstanding (unpaid so far). The three amount fields are already there, but will be re-interpreted to apply to multiple years in the case of multi-year pledging.
• Add a sample mail-merge letter for informing donors about the status of their multi-year pledges.

That’s all I we have come up with so far in terms of requirements. Note that some things I am not proposing to handle are partial-year pledges (e.g. monthly or quarterly), or pledges for multiple categories (so much for the General fund, so much for the Building fund).

Please give me your comments, as usual ideally through a Reply to this blog posting. Thank you!

There is part of the Letters -> One Letter and Letters -> Mass Mailing windows that I suspect is very little used, and can be confusing.

That part is Section 3 in Letters -> One Letter and Section 5 in Letters -> Mass Mailing: the parts where you can specify the name of the file in which to save the merged letters, and whether or not to use a standard filename.

My impression is that first, there is very little reason to use this to review previous merges – you can always just re-merge a letter or letters instead. And it just adds to the confusion.

The only reason to pick a different (non-standard) filename for the merged letter(s) is if you want to keep old merges on file, each with its own name. But that also is going to become very confusing, and if you really want copies, you could print them instead.

Does any one reading this use those options, or think I should keep them in the program? Please let me know by writing a Reply to this blog. And if you don’t use them or see a reason to keep them, a quick reply to let me know you’ve thought about it would also be great! Thank you.

I’ve been doing some more thinking further to my previous post about changing DONATION to run not as an Administrator. In that post, I said that all of the settings that are currently stored in the Registry (in a place that can only be written by programs running as an Administrator) would move to a settings file in the new data directory for the program, which would be under the All Users Document folder, e.g. places like C:\Users\Public\Documents\Cooperstock Software\Donation, in Windows Vista or Windows 7.

My further thinking is that there are actually 3 different levels of setting that I’d like to store:

• Overall settings for the whole program, e.g. for things like the location of the database file and the current database filename if you are using Database -> Switch Databases.
• Per-database settings, like which donor and donation fields to display (which may be different if you have multiple databases, perhaps one for a church, and one not for a church).  These settings will come with you if you backup the database and restore it on another computer, unlike the other two levels of settings.
• Per-user on that computer settings, like the user’s desired location and size for the program’s main window. (I know that it will be fairly rare for multiple users to be logging in to the same computer and all using DONATION, but it’s certainly possible.)

So, my plan is to have three places to store those things – an INI settings file in the new data directory, for the overall settings; a new hidden SETTINGS table in each database for the per-database settings; and the HKEY_CURRENT_USER area in the Windows Registry (which can be written by non-Administrators!) for the per-user settings.

Does that make sense so far? I will have some detailed documentation in the program of which settings are stored at which level, for those who are really interested.

Further, I’d like to run by you which specific settings I plan to put at which levels, to see whether any of you have counter-arguments for any of them. Here’s what I’m thinking. (You will note that some of these are settings that correspond to obvious things in the program, and others are things you may not have been aware I was storing anywhere.)

Overall Settings

• Location and name (probably just the extension, since it MUST be named donation4.something) of the current database file.
• Other database connection properties, like whether it’s a Standalone, Network Client or Network Server install.
• Most of the settings from Maintenance -> Email Sending Configuration, except the From Name and From Email which may vary per database.
• The contents of the mail-merge letter and receipt templates will be consistent across all databases (though you may choose to develop separate letters for separate databases). They will be stored in a Letters directory under the new data directory.
• The list of databases you have in Database -> Switch Databases, if you use it. (It’s currently in a file databases.txt in the DONATION installation directory. That file will move to the new data directory.)
• Whether or not you wish to be reminded monthly to check for updates to the program, and if so, the last date on which that check was done.
• Your registration information, if you have used Help -> Register by Email. (Yes, you might have multiple databases/organizations, but from my standpoint if you are doing that from one computer, you should only have one registration record. You can put inform me separately of your additional organization names, or I will pick that up from your license key requests.)
• The size of mailing label you use, and print margins for them if you change those margins.
• The last folder you stored PDF files in.
• The current version number of the program.

Per-Database Settings

• The three optional passwords (Program Entry, Receipting, and Limited User). These are actually already stored in each database.
• All settings from Maintenance -> Organization Info are already stored in each database.
• All settings from Maintenance -> Receipt Options, including the Receipt Style For (e.g. Canada, USA, Quebec etc.). Believe it or not, I actually have at least two users with one database/organization in Canada, and another in the USA, so each database has to have its own settings for this. While some receipt options (like Location Issued) are probably really overall settings, I think it will be clearer for the users to leave them all as being per-database.
• All settings from Maintenance -> Main Window Options. Again, if you have multiple databases, the way you store the data in each, and which Donor or Donation fields you want to see etc., may vary per database.
• The From Name and From Email settings from Maintenance -> Email Sending Configuration.
• Memorized settings from the Letters menu windows (like which type of letter you are currently using, its filename, etc.).
• Memorized settings from Importing windows, like Database -> Import Donors and Database ->Import Donations, for which fields to import etc.
• The last date on which you did a database backup, and location to which you did it, plus your desired backup reminder frequency.
• The name and email address you send email backups to, if you use that feature.
• Whether envelope printing should include your organization address and logo. (You might have pre-printed envelopes for one organization, but not for another.)
• There will have to be a per-database place to store any bitmap files you use for the logo and signature for receipts. (This will be tricky for me to make the receipts use them in different locations – have to think on that!)
• The settings for One Date Batch Entry (e.g. which fields to show, and whether to include existing donations).
• The Subject and Body of the email to which the PDF receipts are attached if you use the option to email receipts.

Per-User Settings

• Various menu options, like the Letters menu options, prompt you to read the Help on the relevant topics when you use those options for the first time. Whether or not you have used those options for the first time will be stored per-user, since each user will use them once for the first time!
• The size and location of various windows in the program that are resizable and movable, which the program stores. (For instance, the main window, the Batch Entry window, and the Mail Merge editor window.) Each user might have their own preference about this.

Whew, that’s a lot of settings!

As usual, if you do have any comments, please Reply to this blog post, so we can all see them. Even if you just think this is all fine, a quick reply on the blog, or just by email, would really be appreciated, so I at least know some people have thought about this with me! Thanks.

One thing that isn’t ideal about DONATION, when run on Windows Vista or Windows 7, is that you have to run logged in as an Administrator. Not only that, but when it runs, if you have User Account Control (UAC) turned in Windows, which is the default, it prompts you as to whether it’s OK to let the program make changes to your computer every time it runs.

That’s really not how well-behaved programs are supposed to work, unless they absolutely have to have those Administrator rights. Until recently, I knew of no way to get around this, because if you use the Database -> Switch Databases menu option, it had to change an ODBC data source to do that, which could only be done as an Administrator.  Fortunately, I have figured out a way to run DONATION without needing to use ODBC data sources, so that problem goes away.

The Administrator privileges are also used, however, to allow DONATION to create and modify files under its own directory (normally C:\Program Files\Donation), because normally Windows will not allow non-Administrator programs to modify anything under C:\Program Files. Examples of files that are currently written there are your license key file, mail-merge letters and receipts, a file for tracking which database you are switched to if you use Database -> Switch Databases, and of course, your database file itself – donation4.db, in the Data subdirectory. If users want to supply a logo or signature bitmap file for the receipts, they have to be put into C:\Program Files\Donation as well, which is even harder, because the users have to do that with some other program, which means they have to explicitly run that other program as an Administrator.

To make all of this more “correct”, in Windows terms, I need to stop running DONATION as an Administrator, and move all of those changeable files under its directory to somewhere else that all users can write. My proposal is to use a subdirectory under the All Users Application Data directory. (This is one of Microsoft’s recommendations.) This would be:

• “C:\Program Data\Cooperstock Software\Donation” on Windows Vista or Windows 7
• “C:\Documents and Settings\All Users\Application Data\Cooperstock Software\Donation” on Windows XP
• “C:\Windows\All Users\Application Data\Cooperstock Software\Donation” on Windows 2000

Unfortunately, there are some drawbacks to this change. The first is that it will be harder for users to find those files (including their database file!) if they are looking for them, and harder for me to even tell them where to look for them, since they are in different directories on different versions of Windows.

Another problem is that those are “hidden” directories, which you normally can’t even navigate to with My Computer, Computer, or Windows Explorer, unless you explicitly type in their names. You can only get to see those directories if you go to Tools -> Folder Options in one of those program, switch to the View tab, and check the radio button for “Show hidden files and folders”.

By the way, another change would be that many settings that the program stores, like various settings from Maintenance -> Main Window Options and Maintenance -> Receipt Options, which are currently stored in the Windows Registry, would now be stored in a text-based profile file in that folder mentioned above. This is because I want DONATION to work for any users logged on to the computer, and the Registry settings for all users can only be written by an Administrator. (I know that very few installations of DONATION are on computers with multiple users logging in to them with different logons, but it could certainly happen, and I think it’s best to make it work in that situation.) I may also move more of those settings into the database itself, mind you, which would be good, because they would come with you from computer to computer if you moved DONATION.

So, I’m asking for your opinions on my making this change. Except for not having to be prompted every time DONATION starts to say it’s OK, and for some new users, not having to obtain an Administrator Windows logon if they don’t already have one, there very little no real “win” in this change, and some real losses (harder to find those changeable files that were previously under C:\Program Files\DONATION).

What do you think? (As usual, please Reply via the blog, if it’s convenient.) Thank you.

There are a number of options around how to do email mail-merge letters in DONATION that I’d like your opinions on.

Currently the only thing you can mass email is the built-in receipts. When you do that, they are saved as PDF files (which is necessary for receipts, at least in Canada, so they aren’t modifiable by the donor who receives them). The program’s user also specifies a text message to go in that email, though no merge fields (like the donor’s name) can be merged into it.

When I add emailing of mail-merge receipts, they will be done basically the same way, as attached PDF files, with (probably) a fixed, non-merged, text portion of the email. (Though that could change if option (1) below is implemented.) This may be the only email mail-merge feature to be added in the next release – I’m not sure yet. Part of that will depend on which of the options below is chosen, and how complex it is to do.

Whenever I do add email merged letters (as opposed to receipts), though, they require some different considerations, because they don’t necessarily have to be sent as PDFs. Here are some options:

1. Plain text emails only, with merge fields as in the current mail-merge editor, though probably with some limitations (like no <<DetailsTable>> or <<SummaryTable>> fields). This is probably the easiest thing to do, it creates the smallest emails, and has the least issues with compatability between different donor’s email programs. But it also gives the least ability to make the emails look good.
   
2. HTML emails, created with DONATION’s current internal mail-merge editor (which is Internet Explorer in edit mode behind the scenes, and is thus editing HTML). These would then be sent as an HTML email (not a PDF). This is fairly simple to do, but has one big problem – different email programs handle different parts of HTML differently, and some are very limited in what HTML they can handle. But the internal mail-merge editor tends to create very complex HTML, and thus when letters edited with it are used as an email, they may not come out well in all donors’ email programs.
   
3. HTML emails, created with DONATION’s current internal mail-merge editor, but then saved as PDFs and emailed as attachments, with a standard (non-merged) text portion. This is safe in terms of working well with donors’ email programs, but obviously slower for large numbers, because of the delay for generating each PDF file individually.
   
4. A combination of (1) and (3) – a merged plain-text portion, with an attached PDF from a merged HTML portion from the current internal editor. This has the same advantages and disadvantages as (3). However, in terms of the text portion of the email, it’s a bit more complicated, though more flexible in terms of the results, for the user.

While (2) above, a straight HTML email, is the most obvious choice in a way, the concerns about how the HTML emails will come out in different email programs really worry me. Also, there are apparently still people who have email programs that don’t handle HTML at all (or choose to turn off the option to handle HTML in their email programs). To account for that, if you send HTML emails, you must also include a plain-text version that non-HTML email programs will display. (It can be auto-generated by the sending program like DONATION, and HTML email programs will ignore it.) Also, I’m told by the email sending service that I use that mass mailed HTML-only emails, with no plain text version included, are more likely to be classed as SPAM by ISPs or by individuals’ anti-SPAM programs. So, the program would have to add in an automatically converted plain text version to any HTML emails anyways. (You do not want to be classed as a spammer by any of your recipients’ ISPs – that sticks to you, and you may never be able to send to them again!)

This problem about being classed as a spammer by ISPs is actually a bigger problem overall with the whole idea of mass emails. That’s why I switched to using an email-sending service, instead of sending the emails myself, because I started having problems with this when I was sending thousands of emails to DONATION users directly. (The services do all sorts of magic to avoid the problem.) I suspect that if you only have hundreds of donors you are mass emailing to, it’s not very likely to be a  problem, but I will have to warn the larger users of DONATION, with thousands of donors on their mailing list, about this concern!

When I currently send out my HTML emails to DONATION users, I hand edit them to use only extremely simple HTML, to avoid the problems with different email programs’ limitations. That’s obviously not an option that I can force on DONATION users who want to send mass mail-merged emails to their donors!

So, I’m really unclear on what the best solution is here. I could offer only one of the four options above, or more than one, though obviously that significantly increases the complexity for the user, if they have to choose between multiple ways of doing mass emailed letters to donors, and understand their pros and cons. Plus, again obviously, it increases my development time.

What are your thoughts? As usual, please comment by adding Replies to this blog post, if it’s convenient, so we can all join in the discussion and see each other’s thoughts. Thank you!