Software4Nonprofits Blog

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!

Do you use an HTML editor of any sort, other than the one built into DONATION for editing the mail-merge letters and receipts?

The reason I’m asking is that some types of documents, especially the receipts, can be hard to do complex design on in the built-in mail-merge editor in DONATION. That’s why on its Actions menu (and the toolbar) there are options for View/Edit Source (which edits the HTML in Notepad) and Edit in Microsoft Word.

A user recently informed me that they use Dreamweaver, and since that is so popular, for the next version of DONATION, if it detects that Dreamweaver is installed on your system, it will add an Edit in Dreamweaver menu option to the Actions menu.

I’m wondering if I should add any other “Edit in …” menu options, if my users are using other well-known HTML editors, such as Microsoft FrontPage, the new Microsoft Expression Web, etc. So, if you are using something other than a plain text editor (like Notepad), or Word, or Dreamweaver, please drop me an email with details. I may then ask if you could help me a bit to figure out how that program is started, by letting me poke around with a remote control session on your computer for a few minutes.

Thanks!

Hi all. Sorry for two posts in quick succession!

Recently, I have found out that several churches never found the One Date Donation Entry window, for quick entry of lots of donations all made on one day (e.g. the Sunday collection). 

I also had a couple of bizarre support calls, where the described problem was that each week’s donations disappeared (from both the main window and all reports) after they entered the next week’s donations. It turned out that the users were entering the donations on the main widow, and rather than pressing F2 (or clicking New) to create a new line for the new donation, they were overwriting the fields from the previous week’s donation each time, thus replacing the old donation with the new one!

To address both of these concerns, I have come up with a set of changes/improvements to make to donation entry, which I want to run by you, and also ask you about a couple of naming issues. Here are the changes:

• Remove the New (F2) button.
• Whenever a new donor’s donations are displayed, an empty row for a new donation will immediately be added (as if you pressed F2 or the New button in the current program, but without putting you into edit mode, so you don’t have to use Save or Cancel before you can do anything else!). As usual, the default date and category will already be filled in to this empty row.
• It will go into edit mode when you enter the Amount field, or change any other field on that new empty row or any other row, and then you will have to press Save or Cancel to continue as usual.
• The menu option File -> New -> Donation  F2 will be renamed to File -> New -> Donation (Edit empty row)  F2, for clarity. This means that although there is no longer a New (F2) button above the donations, those who are used to using F2 to get into editing a new donation can still do so. (Or, just click the mouse into the new donation.) All this menu option or F2 will do will be to put you into the Date Received field for the empty row for a new donation, rather than adding another empty row.
• There will be a new option on the Donation tab of Maintenance -> Main Window Options for the donation Sort Order, choosing between “Oldest to Newest” (the current behaviour, which will be the default) and “Newest  to Oldest”.  (This is not directly related, but I’ve had it requested several times, and personally I think Newest to Oldest maybe more helpful.)
• The new empty row that’s added for inserting new donations will be at the end of the list when the sort order is “Newest to Oldest”, and at the start of the list when it is “Oldest to Newest”
• Where the New (F2) button used to be, there will be a new button, tentatively labelled Batch, that runs File -> One Date Donation Entry.
• File -> One Date Donation Entry will be renamed to something else, for clarity.

So first of all, how do these changes seem to you? I think they will actually simplify data entry of donations on the main window, and help avoid stupid errors like that described in the 2nd paragraph above. (Errors like that could cause some users trying out DONATION to think it’s buggy and give up on it, without even asking me what’s going on!)

I’m not entirely happy about the inconsistency these changes add, where there’s a New (F3) button for adding a new Donor, but adding a new Donation is automatic and doesn’t need a button. But given the layout, it makes sense, because obviously you have to display the existing donor when you select it from the list.

I want your assistance to help think of wording changes, though. The new button, that I said was tentatively called “Batch”, has to have a shortish one-word name so it fits into the current design, without taking up a lot more screen space.  Any better ideas than “Batch”? I’m hoping that by having this button in the row of buttons above the Donation details, users in Churches who never found File -> One Date Donation Entry will at least think to try this, and then see what they were missing! 

And what about a clearer name for One Date Donation Entry on the menu? I have considered “Quick Batch Entry” (to tie in with the “Batch” button), and “Sunday Collection Entry” (though I think that’s too specific to Christian churches, and not even all of them have their main services on Sundays). Any other ideas? I could go a bit longer, like “Quick Batch Donation Entry”, or “Sunday Collection Batch Entry”, or “Daily Collection Batch Entry”? What’s your preference?

Thanks.

In my previous blog post, I proposed a new feature of DONATION that would allow you to backup your database to “the Internet” somehow. Fortunately, however, some of you readers informed me about significant problems with that plan, including conflicts between Canadian privacy laws and the US Patriot Act, that would prevent Canadian users from using this feature if the Internet storage service I was using was based in the USA or even if it was based elsewhere, but run by a subsidiary of a US company. There are also apparently other laws governing transferring of encrypted files across country boundaries that could be relevant and a problem for this plan.

So, I have given up on that plan as such.

Instead, what I’m working on is a facility to easily email database backups as an attachment, to whatever email address you specify, and of course to restore those attachments after you save them back to your hard drive. This actually provides some of the benefits that the Internet backup idea had, namely storage elsewhere (either in an email program on another computer, or on an email service such as Hotmail or Gmail), and database transfer between computers. (It won’t help if one of the computers you need to transfer the database to or from isn’t connected to the Internet, but neither would the Internet backups idea have helped with that.)

I would plan to compress the database backup before sending it as an attachment, to speed up your email sending and receiving and reduce store requirements. One question I have, because it seems difficult to find an affordable and reliable single program that both compresses and encrypts files (with strong enoung encryption to be worthwhile) is whether you would feel that it is necessary to encrypt your database backups before sending them by email. Please let me know with comments to this posting.

As a prior requirement for this feature, I will be adding a feature to DONATION to allow you to specify how you send emails via your Internet Service Provider (your SMTP setup, for those who know what this means), so that DONATION can send the emails directly. (Currently, when it sends emails, for instance to request a license key, it uses a trick to send it via the Software4Nonprofits.com web site. That would not be acceptable for multi-megabyte emails – too much traffic for me, and too slow for you!)

I’m going to make this email sending setup as simple as possible, by having the program try to figure out which email client program you use (for instance, Microsoft Outlook, Outlook Express or Windows Live Mail, or Mozilla Thunderbird) and read the settings from that program. If you don’t use an email client program, for instance if you only use webmail, I will prompt for your email address, and try to fill in the correct SMTP settings based on research I have done on the SMTP settings required by the major webmail providers like Hotmail, gMail and Yahoo.

This email sending setup will then give me a great start on adding the other emailing features I have been wanting to add to the program, namely individual or mass emailing of receipts and letters. I don’t expect those further features to be in the next release (though I might include a simple feature for emailing just one receipt at a time), but the building blocks will at least be there.

I welcome your comments about any aspect of this post!