|
 It's been roughly three years since we shipped the first version of GiftWorks (then GiftWorks 2006). We put out a bunch of free updates to that product but never sold an upgrade until now. The upgrade comes in three parts. In March we released GiftWorks 2008 Standard to new customers. In April we shipped the first update to GiftWorks 2008 Standard that included a database upgrader so existing customers could start moving over to 2008 Standard. Finally in the next couple months we will be releasing GiftWorks 2008 Premium which is what the product team is working on now. I would like to do several posts on how GiftWorks 2008 came to be and how it's turned out, but for right now just jump on over to the website and check it out.
 We've made GiftWorks available for a low fee on TechSoup Stock. Depending on the size of your non-profit, the software is discounted or will be donated to your organization. I think the quantities are limited, so get them while they last.
 Yesterday we launched our new Consultant Partner Program on the Mission research web site. If you are a consultant you can sign up with the program and take advantage of the benefits which include up to 5 free licenses of GiftWorks, phone support, co-marketing opportunities, training and you will be listed in our consultant directory. More information about the program is here.
If you are a consumer and are interested in finding a consultant to get your organization up and running, you can find a consultant near you by entering your state into the Consultant Directory search.
 I know I've been promising an SDK for some time now, but we've finally had some movement on that front. Some of you may have received an email announcing the first release. We've started a new web site to host all-things-SDK. Check out DevHero.com for everything you need to know to get started.
We plan to release the SDK in small pieces as beta downloads. We want to crawl before we run and we want your feedback all along the way. At some point, when the small pieces become mature and stable enough, we will add them to the release version of the grand SDK. The first download is some code and examples to create your own reports inside of GiftWorks. A recent survey of our customers indicated that reporting was a big part of what you'd like to customize. This should get you started. Please let us know what you think via the DevHero forums. Thanks.
 A common question we get from customers is "how do I access my GiftWorks database from outside the office?" We decided on using a file-based database for GiftWorks early on. We chose to go that path (instead of using a client/server database) to make installation, management and the user experience in general, very simple. I think the path we chose was a good one but it's not perfect. We knew that a file-based database would not address the needs of a small portion of of our customers. One of those needs is remote access. While remote access cannot be as good as if we had built GiftWorks using a client/server database, there are options available to you.
One solution is to use a Virtual Private Network (VPN) to connect your remote computer to your organizations internal network. If you have a VPN connection you can connect to your organization's network shares anytime and anywhere you have an Internet connection. It's basically the same way you would connect when you're in the office except the files and folders will be shared across the VPN connection. The two biggest problems with this solution is that your connection will likely be slower and it's not the easiest thing to setup a VPN for your office.
Because you will be connecting to your office network over the internet, the throughput and response of your connection will depend on the quality of your internet connection. It will never be as fast as when you're in the office -- you will have to adjust to the somewhat slower user experience when on the road, but it will let you access your donors and donations remotely.
 I have never had a lot of luck setting up a VPN connection. Microsoft Windows has VPN software built into it, but because of the common use of firewalls and shared internet connections through routers, it is very tricky if not impossible to make that software work. The good news is that there is a free alternative that is easy to setup and it works great. This "zero-configuration" VPN program is called LogMeIn by Hamachi.
LogMeIn is available as a free download. It's very simple! You download and install it to the computer that has your GiftWorks database on it (this will be in your office). Then you download and install it on the computers that need remote access to your database (likely a laptop or your home PC). Once installed you create a virtual network and give it a password. From your remote computers you connect to that new virtual network and enter the same password.  At that point you can browse your office computer from your remote computers. You'll be able to see all your shared folders and files. Run GiftWorks on your remote computers and tell it to open an existing database.
It may take a little bit to understand what's actually happening. Just think of it like your remote computer is actually on your office network. The main LogMeIn window shows the other computers in your network. Look at the image to the left. It should resemble the window on your remote computer. The office computer should be listed there. Just right click on it to bring up a menu and choose to Browse that computers files. That should open a window of shared folder on that computer. Click through the shared folder that contains your GiftWorks database. Once you see your database (the file with a .gds extension) you should be able to get the information needed to open that file within GiftWorks.
 In that browse window (as shown to the right) you'll see the path and filename that you'll want to tell GiftWorks about. As an example, the screenshot shows the path and filename \\5.118.37.163\giftworks\my-donor-data.gds. Give that path to GiftWorks when you choose to open an existing database.
Like I said earlier, the experience could be slow depending on your internet connection, but it should work. I have used LogMeIn on several occasions with good results. Let me know how it turns out for you.
In November, the Fundraising Effectiveness Project (FEP) launched their annual Fundraising Effectiveness Survey. This survey asks charities to compare their 2004 and 2005 fundraising results. The results of the survey are intended to enable non-profits "to compare their growth-in-giving results across a variety of measures with the performance of similar organizations." Russ Burke has published an article about how this helps your organization.
 FEP partnered with over one dozen software firms in assisting their clients with the survey. Here at Mission Research, Chris Walker, a Product Manager donated some time to building a GiftWorks add-in that would automatically gather and send the survey data for GiftWorks users. This is a great example of how GiftWorks can be extended to support additional functionality. And truly it's not very difficult to do given the proper documentation (which is only available internally right now).
I'm very curious how the FEP survey was exposed by the other partnering software makers. If any readers have used the software by the other partners, please let me know your experiences.
 In a lot of organizations, the fundraising is at a very personal level. In those cases you might find it useful to keep photos of your donors in your records. A new GiftWorks add-in will now enable you to do that for your donors.
Steve Fafel has created a sample add-in to demonstrate some of the extensibility of GiftWorks and it has turned out to be a very popular add-in. Please download and try it out. The source code comes with it, so check that out too.
Many of you have probably received the latest GiftWorks update automatically. If you have GiftWorks set to check automatically (recommended because we only support the latest update) it would have notified you already and hopefully it updated you without problems. If you don't have GiftWorks set to check automatically or you didn't get notified yet, just click the Check For Updates link at the bottom of GiftWorks and follow along. The update should bring you to version 2.1.112.00 which can be seen in the Help>About GiftWorks window. The official release notes have been published at missionresearch.com. Check them out to see what's been updated. One item that made it into the update at the last minute but is not in the release notes is described on Steve Fafel's website.
 Vista is not officially released yet. Until then we cannot officially support customers running GiftWorks on the new operating system. However, we have been doing some testing with the latest release candidates of Vista and it looks like we shouldn't have too many problems (if any) adding support. If anyone is daring enough to try GiftWorks on Vista, make sure you are using the latest update that has been built to support Internet Explorer 7 and turn of Data Execution Protection. If you run into any problems please let us know via feedback to this blog. Please don't contact customer support with the issues because they won't be able to help you yet.
In this post I present an example add-in that adds a new report category and one new report to GiftWorks. Unfortunately there is way too much stuff going on here to explain everything, but the ambitious user should be able to make some headway with adding custom reports to GiftWorks. There are two files that are necessary to add a new report. You need to write an add-in file (newreport.xml) that defines the add-in and tells GiftWorks about the new report category and the new report. The other file (GRDF-donors-by-number.xml) tells GiftWorks what to display in the report. For this example to work, both files need to reside in the same directory.
newreport.xml
1: <gml id="missionresearch_newreport"> 2: <info> 3: <title>New Report</title> 4: <versions> 5: <version match="2.0" module="version2" /> 6: </versions> 7: </info> 8: <module id="version2"> 9: <objects> 10: <object id="Handler" type="vbscript"> 11: <![CDATA[ 12: Const CategoryKey = "my-reports" 13: Sub AddNewReportCategory() 14: Dim oCat 15: Set oCat = App.Modules.GiftWorks.Reports.GetNewCategory 16: oCat.Key = CategoryKey 17: oCat.Name = "My Reports" 18: oCat.Description = "These are my reports that I have built." 19: App.Modules.GiftWorks.Reports.Categories.Add oCat 20: End Sub 21: Sub AddNewReport() 22: Dim oReport, oCat 23: For Each oCat In App.Modules.GiftWorks.Reports.Categories 24: If oCat.Key = CategoryKey Then 25: Set oReport = App.Modules.GiftWorks.Reports.GetNewReport 26: oReport.Key = "donors-by-number" 27: oReport.Name = "Donors By Number Of Donations" 28: oReport.Description = "This report let's me filter my donors by the number of gifts they have given." 29: oReport.Path = App.Modules.missionresearch_newreport.Path 30: oCat.Reports.Add oReport 31: End If 32: Next 33: End Sub 34: Sub EventHandler(Ev) 35: Select Case Ev.Key 36: Case "reports-categories" 37: AddNewReportCategory 38: Case "reports-categories-reports" 39: AddNewReport 40: End Select 41: End Sub 42: ]]> 43: </object> 44: </objects> 45: <taskmenu/> 46: <handlers> 47: <handler id="reports-categories" object="Handler" /> 48: <handler id="reports-categories-reports" object="Handler" /> 49: </handlers> 50: </module> 51: </gml>
This file should look familiar to those that have been following along with my blog. You can view previous posts to see how to install add-ins with GiftWorks. There are two lines that I'll explain. Line 26 assigns a key to the new report. This key corresponds to the filename of the GRDF report. Line 29 tells GiftWorks where to look for the report definition file. In this case it uses the Path property for the current module. "missionresearch_newreport" is the Id of this module as identified on Line 1.
download files
You can download both files: newreport.xml, GRDF-donors-by-number.xml
what's next
Like I said, I don't go into a lot of detail. The GRDF file can be very confusing so I'll wait for interest and/or feedback before I spend too much time describing its functionality. Please let me know if you want to see more about either file.
 This week we will being posting an automatic update for GiftWorks (the 5th update for GiftWorks 2006). The timing of the update is to prepare customers for downloading Internet Explorer 7 which will be sent out to Windows customers in upcoming weeks. Besides working with IE7, the update includes some bug fixes and a functional change to the way GiftWorks interacts with QuickBooks. Here are the major bugs that were fixed:
- For some customers, saved SmartList settings created in previous versions were causing errors.
- Labels and envelopes printing blanks has been fixed.
- In some cases, the importer would cause the database checkup to fail. This has been fixed.
- Database compacting errors have been resolved.
The functional changes to QuickBooks integration are summarized as follows:
- Individual Donors that have transactions will be posted to QuickBooks as customers.
- Accounts used in the posted transactions will be added to QuickBooks if they do not already exist in QuickBooks.
- Each journal entry will now consolidate the donation transactions, posting one line per asset account and one line per fund for each income account.
We will be detailing all the specific changes when the update has been released which will be this week. When we release updates to customers we do so gradually. This means some customers may get updates a day or two before others. You can avoid the wait and download the full, updated release from our website.
This week (November 7th - 10th) in Las Vegas, Mission Research will be exhibiting GiftWorks at The Sleeter Group 2006 QuickBooks Consultant's Conference. As I mentioned before, we have been named as one of the conference's Awesome QuickBooks Add-Ons for 2007.
 I found a nice write-up about GiftWorks from Doug Sleeter in The CPA Technology Advisor. I've re-printed some of that article here...
GiftWorks by Mission Research is one of the most well-designed applications I’ve seen in a long time. This product does a great job of providing for virtually all of the donor-tracking features demanded by nonprofit organizations. GiftWorks manages donors, fundraising efforts and volunteers through a simple, well-designed user interface. Designed specifically for small to medium-sized nonprofit organizations, GiftWorks provides data management capabilities that are complete and far-reaching. The software meets and exceeds the administration needs of nonprofit organizations with donor tracking and mail production functionality and serves the needs of board members by generating insightful donor and donation reports. The unique “SmartLists” feature of GiftWorks allows customers to create lists of donors and donations based on sets of data criteria that the user defines. This feature makes it easy to create quick, automatically updating mailing lists and custom reports.
I've recently corresponded with a GiftWorks consultant Joel Schuman about using the GiftWorks API's to do some batch updating of his client's records and wanted to post a cool quote he allowed me to use.
"BTW, I don't think I've told you directly how much I appreciate and admire GiftWorks. In 33 years as a designer, developer, and consultant I've done many systems and installed or modified dozens of packages, and GW might present the best user experience I've seen."
Thanks Joel.
 We recently found an article on TechSoup.com which told the stories of three different donor database users. One of them uses GiftWorks for their donor data. She says GiftWorks is great for the non-technical crowd. This is one of the keys to GiftWorks. We realize there is high turnover in non-profit orgs and getting new employees or volunteers up to speed is important. We try to make GiftWorks intuitive and usable without having to trudge through documentation. We mostly get it right. Marcie (from the article) also mentioned our technical support a couple times. We get a lot of compliments on our technical support. We have a great group of people in support.
 GiftWorks has been named one of 13 Awesome QuickBooks Add-Ons for 2007 by the Sleeter Group. GiftWorks was chosen from over 400 QuickBooks add-ons that are now a part of the Intuit Developer Network. Below are the reasons GiftWorks made the list:
- The product shows superior design, implementation, and features.
- The product has superior integration with QuickBooks. It passes
data to and from QuickBooks using best practices of the QuickBooks SDK
programming interface.
- The product uses appropriate transaction types and field
population for recording data into QuickBooks so as to preserve and/or
enhance the standard reporting features in QuickBooks.
- The product conforms to good accounting and operating standards.
- Your company has shown outstanding customer support. Your firm
provides the highest level of support to both end users and consultants.
This area is a key element to the overall satisfaction of an add-on
product.
QuickBooks integration is something we are continually trying to improve. We have been working with external QuickBooks consultants and accountants to get the functionality right. We will be improving the whole accounting experience within GiftWorks in upcoming releases. Being named a Awesome Add-on means we're headed in the right direction. Thanks Sleeter Group.
 GiftWorks gets a lot of praise for our user interface design. We spend a lot of time making sure the way it works can be easily figured out without having to jump into the documentation. There is actually a term for this: Affordance. At Mission Research we refer to this as Usability.
In GiftWorks, we try to break down tasks to individual screens so that the user can concentrate on a single task for a single screen. For example, in the mailing section we use minimum of 5 screens to prepare a mailing. That may seem to be a lot, but screen navigation is very simple (using tabs) and each screen focuses on one part of the mailing. See the screenshot to the right.
 On a single screen we try to limit input to only those that are necessary. Non-necessary input is moved to the background; maybe to another screen or or collapsed behind a link. The final screen of the Add A Donor popup can be seen to the right. The primary task for this popup is to confirm the addition of a new donor, but we do give the user an easy way to fill in additional (non-necessary) information for the new donor. The link takes them to another screen that shows all possible fields for a donor.
It's never easy to make a screen obvious to use. At some point we have to make an assumption about our user base. For example, we have to assume a user understands what to do when they see a text box, a checkbox, or a dropdown menu. We assume that if a user is running our software they understand these basic input fields (called user controls in Windows terminology). Problems arise when the standard suite of Windows controls do not offer enough control. We have to invent our own controls and try to design them in a way that is obvious to the user. One example of this is Drag and Drop. From a functional perspective drag and drop is very powerful, but it is an advanced concept that is difficult to make obvious. We haven't used drag and drop in GiftWorks yet.
An important part of usability is getting feedback and revising designs. We are not likely to get a user interface right the first time out, but through user feedback we can get there. Let me ask you this: what area of GiftWorks is hard for you to figure out or understand?
We occasionally get requests from customers about doing batch updates to donor records. We have plans to address this within GiftWorks in the future but until then it has to be done manually. This is obviously not a great answer, but since GiftWorks has an API, developers have an additional option. Below is some VBScript that formats the addresses for all donors in an individual SmartList. Because this is an example, the only formatting I show is converting all text in an address to uppercase. There's no reason the script couldn't be extended to reach out to the postal service and validate the address. I'll leave that as an exercise for the reader.
**This script is provided only as an example and should be used with caution. It will modify data in your database. Running any scripts against your database should be done only after your database has been properly backed up. Also, scripts that modify your database should be done when nobody else is signed into it. There are mechanisms to protect multi-user access, but this script does not utilize them.
1: Const typeIndividual = 0 2: 3: ' create an instance of our application 4: Set App = CreateObject("MissionResearch.GiftWorks") 5: 6: ' Make sure the user is signed in so a db is selected 7: If App.Security.SignedIn Then 8: 9: ' make sure the user is viewing a SmartList 10: If App.Shell.History.CurrentTask.Urlpath = "/list-browse-list" Then 11: 12: ' get a reference to the current SmartList based on the id passed to the page 13: Set smartlist = App.Modules.Donor.ListManager.GetList(App.Shell.QueryString("id")) 14: 15: ' make sure we have an Individual SmartList, or error out 16: If smartlist.ContentType = typeIndividual Then 17: 18: ' get a recordset based on the SmartList 19: Set rs = smartlist.ItemList.Recordset 20: 21: ' go thru each donor 22: Dim donor, address, changed 23: Do While Not rs.EOF 24: changed = False 25: Set donor = App.Modules.Donor.DonorManage.GetIndividual(rs("id")) 26: ' go thru each address for this donor 27: For Each address In donor.Addresses 28: ' call the reformat method 29: ' this example just uppercases all text 30: changed = ReformatAddress(address) 31: ' if the address was modified, 'changed' will be True 32: Next 33: ' if any address was changed, update the entire donor 34: If changed Then 35: App.Modules.Donor.DonorManage.UpdateIndividual donor 36: End If 37: rs.MoveNext 38: Loop 39: rs.Close 40: Else 41: App.Shell.MsgBox "Must be viewing an Individual SmartList" 42: End If 43: Else 44: App.Shell.MsgBox "Must be viewing a SmartList" 45: End If 46: Else 47: App.Shell.MsgBox "You must be signed in before calling this script" 48: End If 49: 50: ' this function just uppercases all text 51: ' return True if it needs changed 52: Function ReformatAddress(Address) 53: Address.Street1 = UCase(Address.Street1) 54: Address.Street2 = UCase(Address.Street2) 55: Address.City = UCase(Address.City) 56: Address.State = UCase(Address.State) 57: Address.Zip = UCase(Address.Zip) 58: Address.Country = UCase(Address.Country) 59: ReformatAddress = True 60: End Function 61:
We have not released a GiftWorks SDK yet so there is no documentation available to show you the rest of the properties for a donor, but those that know how to use an object browser can check out the files: msdsvc.dll and gitwks.exe.
 I've seen a couple request from customers wanting the ability to keep some of their users out of certain areas in GiftWorks. Below is a small addin that attempts to solve that problem by removing the toolbar buttons at the top of the window. In this example I remove every application button except the Donors button (see the picture to the right).
See my HelloWorld post and my What's In A GiftWorks Addin post for more details on using the following addin file. This post will skim through the details and assume you've already created and used an addin file.
1: <gml id="MissionResearch_DisableExample"> 2: <info> 3: <title>Disable Addin Example</title> 4: <versions> 5: <version match="2.0.*.*" module="version2" /> 6: </versions> 7: </info> 8: <module id="version2"> 9: <objects> 10: <object id="MyObject" type="vbscript" url="" cache=""><![CDATA[ 11: Sub EventHandler(Ev) 12: If Ev.Data.Url = "toolbar" Then 13: For Each button In App.Shell.Toolbar.Buttons 14: If button.Title <> "Donors" Then 15: App.Shell.Toolbar.Buttons.Remove button.Title 16: End If 17: Next 18: End If 19: End Sub 20: ]]></object> 21: </objects> 22: <handlers> 23: <handler id="module-execute" object="MyObject"/> 24: </handlers> 25: </module> 26: </gml>
toolbar buttons
The toolbar buttons at the top of GiftWorks are the main navigation elements for the application. GiftWorks inserts several by default and addins can modify those buttons or add their own. This post just concentrates on removing existing buttons. GiftWorks gives you access to these buttons through a Buttons collection.
App.Shell.Toolbar.Buttons
Each button has several properties that you can modify with code.
Button.Order - a number indicating the sort order the buttons should use for display
Button.Action - the action a button executes when clicked
Button.Title - the title of the button displayed
Button.ImageUp - the image file used when the button is in normal state
Button.ImageDown - the image file used when the button is in clicked state
Button.ImageOver - the image file used when the button has a mouse over it
Button.ImageDisabled - the image file used when the button is disabled
event handlers
You can embed event handlers in the addin file to handle events raised by GiftWorks. Event handlers are the primary means for addins to integrate with existing GiftWorks elements. This addin handles a general framework event called 'module-execute' which is fired whenever the framework needs to initialize the toolbar. GiftWorks fills the toolbar first with it's buttons then fires the event so addins can handle it as well. An addin can add toolbar buttons using a simpler interface which will be shown at a later time. This event enables an addin to modify buttons that have already been added. You could rename buttons or other things. This addin just checks for the Donors button and removes everything else. The <handler> element simply tells GiftWorks your addin wants to be called when the 'module-execute' event is raised. It then calls the EventHandler subroutine in the 'MyObject' script.
Try this our and let me know what you think. In later posts I will try to expose some more of the many GiftWorks events.
Updated 9/14/2006
Thanks to some helpful members of the IE7 compatibility team at Microsoft (specifically Keryn Mark), we were able to identify the reason GiftWorks was crashing. GiftWorks has code to keep IE from beeping every time a page changes which was causing the crash. I guess IE7 made some changes around calling the beeping function and our code was no longer valid--or most likely was never valid in the first place even though it worked. The good news is that we have a fix. The bad news is that it won't be available until the next update to GiftWorks which doesn't have a date yet. I will keep you posted.
 For the past several months Microsoft has been beta testing a new release of Internet Explorer, version 7. As some of you may know, GiftWorks uses Internet Explorer internally for its user interface. Since the first IE7 beta, GiftWorks has not worked correctly and even crashes for some customers when they have the beta installed. We were hoping that the issue would have worked its way out by now, but Microsoft released their first release candidate (RC) of IE7 and the issue remains.
We are working with Microsoft to have this issue resolved for RC2, but you can actually help us raise the priority of this issue. For those that have installed IE7 beta, you were asked to join the beta program and provide feedback. Please sign in with your account at http://connect.microsoft.com and do a search for "GiftWorks". You should get at least one feedback item in the results. Please open that item and make sure it applies to what you're experiencing (typically a crash of GiftWorks), then submit a vote for the issue. Thanks and we'll keep you informed.
Updated 8/29/2006
 In a previous post, I showed how to use a GiftWorks Addin. In this post I will expand on that same HelloWorld example by explaining the contents of the addin file. The HelloWorld Addin is simply an xml file with a specific structure recognized by GiftWorks. There are several more elements that can be included in an addin file, but for this example we will only focus on the <taskmenu> element.
Here is the HelloWorld Addin file:
1: <gml id="MissionResearch_HelloWorld"> 2: <info> 3: <title>HellowWorld Addin</title> 4: <versions> 5: <version match="2.0.*.*" module="version2" /> 6: </versions> 7: </info> 8: <module id="version2"> 9: <taskmenu> 10: <menu task="graphite://provider/startpage"> 11: <item section="RELATED TASKS" type="script" text="Hello World" before="Add a Donor"> 12: <![CDATA[App.Shell.MsgBox("HelloWorld!")]]> 13: </item> 14: </menu> 15: </taskmenu> 16: </module> 17: </gml>
identify your addins
Lines 1 and 3 are used to identify your addin. The id attribute in line 1 is a key that uniquely identifies your addin. The contents of this attribute are up to you. It just has to be unique among other addins used within your copy of GiftWorks. It can only contain alpha-numeric characters and underscores. I will typically use something prepended with my companies name. This should be unique enough as long as someone else in my company doesn't have the same idea. The id in Line 1 is not something seen by GiftWorks users. Line 3 is the <title> element. This title will show up in the GiftWorks Addin Manager and will identify your addin to the GiftWorks user. This example doesn't use them, but you can also include <publisher>, <description> and <website> elements to further identify your addin.
addin versioning
Supporting addins becomes very tricky as GiftWorks functionality is enhanced. For this reason our addins need to specify the version of GiftWorks that it will support. Depending on the functionality of your addin you may need to update it when a new version of GiftWorks will be released. A single addin file can target several versions of GiftWorks. When we officially release a software development kit (SDK) for building addins we will document the rules that we use when incrementing version numbers within GiftWorks. You will be able to use these rules to know when to provide updates to your addin. Along with the addin SDK we will support a developer community that will get notified of version changes and have the opportunity to test prerelease versions of the software.
Like I said, a single addin file can target multiple versions of GiftWorks. Minimally you need a single <version> element with a match attribute and a module attribute in every addin file. The match attribute is used to figure out what version should be selected and the module attribute points to the corresponding <module> section within the addin. If you need to support multiple version you can include more <version> elements and <module> sections within the file. The <version> elements will be processed from top to bottom in case there is any overlap.
For this example, I'll target a small range of GiftWorks' versions. GiftWorks will support addins starting from GiftWorks Update 3 (version 2.0.80.00), so by using '2.0.*.*' I've enabled the use of my addin for GiftWorks version 2 or higher. By specifying the match string like this it should allow future updates of GiftWorks 2006 to use this addin.
adding a menu item
This HelloWorld example just inserts a menu item on the start page in GiftWorks. When the user clicks on the new menu item a script is called which displays the message "HelloWorld" in a popup. Lines 9-15 defines where the menu item is inserted and what happens when you click the menu item. There are several options when defining new menu items, but to keep this post as short as possible I will only describe the ones used in this example.
Line 10 specifies the menu to modify. From a high level, GiftWorks is just a series "pages" that the user navigates thru (very similar to a website). Each page performs a unique function. Along the left side of each page you will typically find a menu--a list of links that the user can use to perform a function related to the current page. In development, the "pages" are called tasks and they are uniquely identified by a URL. At any point while using GiftWorks you can see the current task name by pressing SHIFT-F6. The "current task" line lists the task's URL. This is how we identify what menu we want to modify in our addin. We use 'graphite://provider/startpage' in line 10 of our example.
Each menu is divided into sections. On the start page we have two section: RELATED TASKS and DID YOU KNOW. The <item> element in line 11 of our example represents a single new menu item that gets placed in the RELATED TASKS section directly before the existing 'Add a Donor' menu item. The text attribute contains the name of the new menu item as seen by the GiftWorks user. The type attribute tells GiftWorks what should be done when the user clicks the menu item. In this case it executes a script which is included within the <item> element on line 12.
Line 12 contains the actual script that is executed when the user clicks the new menu item. I have enclosed the script within CDATA brackets so we can use characters that may not be recognized in xml. I recommend you that you just use them around all your addin scripts.
the script
Explaining everything that can be done with scripting is way beyond the scope of this post. GiftWorks Addins support Microsoft's ActiveX scripting. You may use any ActiveX scripting language by specifying a language attribute in the containing element tag. The default language in an addin script is VBScript (Microsoft Scripting).
The key thing to note in this example is the App reference. This single reference gives the addin developer access to the entire object model within GiftWorks. The same object model that the Mission Research developers use to create GiftWorks. I won't go into detail yet, but most Windows developers will know how to view the GiftWorks object model in an object browser. If you aren't familiar with object models or App references, you will need to wait a bit until I can go into more detail or find a resource that can help you figure it out.
 We recently put out Update 4 for GiftWorks. The update was needed to support our recent release of GiftWorks Volunteers as well as fix some of the top bugs that our customers were experiencing. When updates are released the dev and support teams are on high alert. Dev watched the monitoring software for customers that install the update and have problems. Most of the updates go as planned, but there are some where things "just happen". I handled one of the early problems that came up. A customer had installed the update but it appeared a component had not been updated correctly by the installer and the customer was receiving errors. To make sure this was not a problem that was going to affect a lot of people, I looked up the gentleman's registration information and gave him a call. It's always awkward "cold-calling" a customer about issues we have detected, but this customer was thankful and more than willing to let me fix his problems. It turned out to be a fluke and a quick re-install of the update got him back on his way.
We have very detailed monitoring built into GiftWorks that let's us detect and get to the bottom of bugs before they cause too much of a problem. I only wish we had the resources to handle every customer's problems the same way--where we call them instead of the customer calling us. Who knows, maybe someday you'll have a problem with GiftWorks and we'll call you.
 Users of GiftWorks can now purchase the GiftWorks Volunteers addin which seamlessly integrates volunteer management with existing donor and fundraising management. This is a big step for Mission Research in a couple ways. First, volunteer management was at the top of our customer's wishlists -- almost half of the customers surveyed had asked for it. I hope it meets their expectations (please let us know if it does). Second, it moves us one step closer to opening up third-party development of GiftWorks addins. GiftWorks Volunteers was built using publicly exposed (but as of yet, undocumented) APIs. In the near future we will make them open APIs so you (or others) can build your own addins.
GiftWorks Volunteers can be downloaded as a 30-day trial and purchased for an introductory prices of $149 (regularly $199). Please stop by our website and give it a try.
Peter Campbell has published an N-TEN article called Seven Questions for Peter Campbell on Open APIs. The article tries to answer some common questions about software and their open APIs. It's a good read and provides a high level look at the subject.
In short, open APIs enable customers to extend their software to better meet the needs of their organization. To me, this is one of the most important features software can have. This is especially true if you're part of a growing organization, because you never know what your software needs will be in the future. Here are some examples of things that open APIs can provide:
Third-party development: Other software companies can build retail software that can extend or integrate with the APIs . For example, Quickbooks has an open API which allows other software to synchronize accounting records with it.
User-interface customization: Customize the way the software works. For example, with GiftWorks, if you want to install it for your data entry people and don't want them to use the Reports or Mailing section you can use the APIs to remove those sections. Or if you want to be able to store and display a picture of your donors within the software, good APIs would allow you to add that functionality.
Website integration: Give your web server the ability to present data that is stored in your donor database. For example, if your organization wants to allow their donors to change their information through your website, good APIs would give your website developers the ability to do that.
Data access: Move data into and out of your database using different sources. For example, if you have an Excel spreadsheet that you use to collect information in your laptop when you are on the road, good APIs would allow you to synchronize that spreadsheet with your database when you are back in the office.
Automation: Have certain functionility of your software happen automatically. For example, if you have a Membership Renewal field in your software, good APIs will enable you to have your software automatically send you an email of expired memberships at the end of every week.
Web service integration: Leverage other web sites or services to extend the functionality of your software. For example, you can use the Google Maps web service to plot a map with your top 100 donors.
Notice I used the term "good APIs" above. Not all APIs are created equal and they should be evaluated when deciding on which software to purchase. Also, most APIs require some programming knowledge. If this knowledge is not available within your organization, it is available outside using consultants.
A note about GiftWorks and open APIs... GiftWorks was designed and developed from the ground up with open APIs in mind. All the scenarios I listed above, and more can be done with GiftWorks *BUT* until we are able to release documentation and examples of using the APIs (also called a Software Development Kit (SDK)), it is still out of reach for our customers. Our SDK is a high priority for us and we are commited to supporting a development community around the GiftWorks SDK. Hopefully you won't have to wait too long.
 Recently GiftWorks was reviewed by FundraisingKnowHow.com. Here are a couple exerpts from the review.
"...Mission Research's GiftWorks software catches our attention because of its $299 price tag--a bargain compared to other non-profit administrative packages that can cost up to $5,000 or even more."
It's very hard to beat our pricing, especially if you consider the amount you'll save in training costs with the rapid turnover in non-profits.
"The software has a short learning curve, so there's no training sessions required. The interface is quite intuitive, and it will be easy for anybody with a basic level of PC competence to teach them self how to operate the software."
Please check out the site to read the entire review.
 On August 19th in San Francisco, Mission Research is sponsoring our second Nonprofit Boot Camp hosted by Craigslist Foundation. We sponsored our first one in New York back in June. It was a great event with lots of attendees and some good workshops. The one in San Fransisco looks like it will be a bigger event and there will be several Mission Research poeple there to speak to and demonstrate GiftWorks. I think our CEO, Charlie will also be leading a workshop. If you live in the area and are interested in using GiftWorks for fundraising, try to make the event.
 We are coming to the end of another product cycle. This time for GiftWorks Volunteers, our first addition to GiftWorks. It is a new product that is released as an add-in for GiftWorks. There were a lot of challenges, both in architecture and design. For one thing, we needed to finalize our add-in API built into GiftWorks. This API enables us to deliver other products that integrate seamlessly into GiftWorks. Those changes required us to simultaneously deliver the volunteer add-in plus a major update to GiftWorks. Another major challenge was adding a considerable amount of functionality to GiftWorks without making the existing software more complex and harder to use. We've spent a lot of time and effort in getting things right. I know we've slipped our release dates a few times which is a hard thing for our customers and is equally painful for myself and my co-workers. I'm hoping you'll find it worth the wait.
We have two interns working at Mission Research this summer. Jon Hollinger and Rob Payeur are students of Millersville University. They will be working with us for 10 weeks and are tasked with researching, designing and building some software using the addin functionality built into GiftWorks. They are already starting their 4th week and are in the process of deciding which of three projects they are going to move on.
They are maintaining a web site to document their progress and showcase some of their work. Feel free to send them email asking questions or making suggestions. They would really like to get some feedback.
In the next couple months we will be introducing a companion product to GiftWorks for volunteer management. This product is built entirely on our GiftWorks Addin platform that we will gradually be making available to our customers. Why is this important? We know that every organization is different and that by providing GiftWorks at such a low price point, we cannot meet every need that our customers will have with our software. Even if that was possible, you as our customer would not want that. Every “feature” that we add increases the complexity of the software which is ok as long as the added “feature” is something that your organization needs or uses. If you don’t use the “feature”, then it is just making your day harder.
By creating the GiftWorks Addin platform, we are giving tools to our teams and 3rd-party companies to build “features” that can be plugged in when they fit the need. For the larger organizations, the platform allows them to build these addins themselves.
As I mentioned earlier, this post will show how to create and use a GiftWorks Addin
of your own. I will not go into too much detail about how an addin is written in this
post. I will describe the internal of an addin with the next post.
what is a giftworks addin
Strictly speaking, an addin can be as simple as a text file written in Notepad. This
file contains instructions that GiftWorks reads to expose custom functionality. The
addin file can be located on your computer or it can be located on a remote server
somewhere on the internet. GiftWorks doesn't care. The only constraint about using
an addin that is located on a remote server is that you need to be connected to the
internet in order to load that addin.
the helloworld addin
For this discussion I will use an extremely simple addin. In fact, this addin is so
simple it doesn't do anything useful (besides demonstrating how to work with GiftWorks
Addins). Most programming
examples start with a "HelloWorld" example, which is what I will show here. This
example just inserts a menu item called "Hello World" on the start page of GiftWorks.
When you click on the menu item, it pops up a message. You can probably guess what
that message says.
You can download the HelloWorld addin here: http://daveweaver.net/media/downloads/HelloWorld.xml.
If you click on this link it will open up in your browser. Most browsers will show
the contents of the addin file. Like I said, I will explain this stuff in a later
post.
let's install it already
If you have GiftWorks with Update 3 installed (requires
version 2.0.80.00 which will be publicly released at the end of February) you
will have an Addin Manager which can be launched from the Help menu. Launch that now.
The Addin manager shows what addins you have installed. You should see nothing installed
at this point. To install the HelloWorld addin, simply copy the URL above and paste
it into the top text box. Click the Install button and you should see the addin show
up in the list.
The checkbox next to the addin name just indicates the addin is loaded. You can have
addins installed but disabled which effectively turns them off. Once you see the HelloWorld
addin installed and loaded, click the Done button. That's all that is involved with
installing a remote GiftWorks Addin. To install an addin that is located on your computer,
simply enter the filename of the addin and click the Install button.
make it do something
Now that the addin is installed you can use it. Don't get too excited, this addin
doesn't do too much. In GiftWorks, make sure you are signed in, then click on the
Home button at the top-left to go to the start page. On the start page you should
see Hello World listed on the left menu like below. Click the menu and you will see
the message.
|