Software4Nonprofits Blog

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!

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.