4.3 launch and aftermath
Version 4.3 was launched on December 14th. It was a tough call whether to launch on that date or wait until the New Year. Our email notices about the upcoming upgrade did get a number of heated responses - people were unhappy about a major software upgrade so close to the holidays. Now that it's been more than a month after the release and most of the dust has settled, I feel that my call to release it in mid-December (versus, say, mid-January) has been validated. Wild Apricot has been around for more than 5 years - so by now we know that January and the first quarter overall brings a big spike in activity -- both from our current customers and new people signing up. Conversely, in December and especially at Christmas time, we see a drop in activity. Thus, releasing the new version on December 14th minimized the potential impact from bugs, while still giving us a sufficient usage level to uncover any problems. This way we had a headstart on the bugs before the big activity spike in January.
And, unfortunately, we did have a number of nasty bugs -- even after all of the testing conducted the preceding two months:
- Payment integration problems -- some were related to recurring charges and affected several accounts due to very peculiar settings they had in Authorize.net.
- Issues with email sending and stats calculation -- we did a complete changeover in our emailing code and apparently our testing did not use enough data to properly simulate the full load of our production system.
- Overall database performance problems (sometimes resulting in slower performance; timeout and 'Internal error' messages) -- some of this turned out to be hardware-related. We managed to mitigate this to a large degree but now have to wait a couple of weeks for some additional hardware to be delivered and set up at our hosting center.
- A bunch of other small, random things.
Our development team responded quickly and most of the urgent issues were fixed shortly after the release (Hotfix 4.3.1 was published on Dec 20th and 188.8.131.52 on Dec 28th).
Besides bugs, there were three areas of changes in how system works that caused grief to a number of clients, namely:
- We did not realize that quite a few clients were relying on some specific data to show up in their merchant account statements. When payment workflows were redesigned in Version 4.3, new code sent much less information to the payment processor. We are now working to provide extended information and expect this to be released by end of January.
- A number of clients missed our version upgrade notifications and did not clean up their financial records -- which caused headaches when their members got access to the financial history of their own accounts in the new version. For now the only real solution is to update the invoices and payments, though we are collecting feedback to consider other changes -- see this thread, as your input would be most appreciated.
We appreciate all the positive feedback we have received from clients taking advantage of the new features, and for your patience while we are squashing the remaining bugs. We are fully committed to keep improving our product and addressing your feedback and requests -- which brings me to the next topic:
Our next frontier is Version 4.4, planned for release in May-June 2012. The three largest changes/enhancements we have planned for it are:
A long requested feature -- I am very excited that we are finally able to move forward on it. For now this mostly applies to our international customers - e.g. HST in Canada or VAT in Europe -- but more and more US states are also moving to enforce sales taxes on online transactions.
Here's a brief summary of what we have planned (click to enlarge screenshots):
- Ability to define tax names, whether taxes are included in or added to item prices, tax rates based on specific buyer locations.
- Ability to disable taxes in particular membership events and levels
- Display taxes on invoices (click to enlarge screenshot)
- Reporting on invoiced (or invoiced and fully paid) tax (click to enlarge screenshot)
We have worked for a long time to bring built-in Wild Apricot emailing functionality to the point when our customers do not have to use external dedicated emailing services (iContact, ConstantContact, etc.) -- unless they have very sophisticated needs for emailing functionality. Version 4.3 brought us one step closer with the release of email deliverability tracking and stats.
In fact, some of our customers have already told us that as of now they plan to do all of their emailing directly from within Wild Apricot.
Still, we feel that one more step is critical to make the most use of Wild Apricot emailing -- providing built-in templates. We have always offered robust email formatting tools and it was always possible to edit HTML directly to create very sophisticated email templates in Wild Apricot (or reuse templates you can find on the web). However we knew that this is beyond the technical know-how and budgets of many of our smaller non-profit clients. So in Version 4.4 we are working to add the following:
- At least 10 built-in email templates (click to enlarge screenshot)
- Changes in workflow - enabling you to see individual recipients and add/remove them individually or by lists. (click to enlarge screenshot)
It does not mean that we will stop improving emailing after that -- there are many other improvement ideas and wishlist suggestions -- but it does mean that after 4.4 we will be reallocating time and attention away from emailing-related features to other areas.
For the moment we only use https encryption (aka SSL) on a special secure site (payments.wildapricot.com) to ensure security of credit card processing for Wild Apricot clients, including compliance with PCI standards.There are other situations and scenarios where https encryption would be handy, for example:
- Members and, especially, administrators accessing the site when on unsecure WiFi networks, e.g. at a cafe.
- Security-conscious members and administrators wanting to make sure that all data submissions whatsoever (e.g. membership applications) are encrypted.
One complication is that Wild Apricot allows customers to use their own custom domains (e.g. abc.org) and it is not feasible for us (at least initially) to have encryption on custom domains. (Basically, encrypting with custom domain would require obtaining and installing their own security certificate and doing this is way too much hassle manual work from clients as well as from our support team). We believe we have found a good solution to address custom domain situations without doing that.
This setting will offer the following options:
- Optional https -- will use SSL only if the site is accessed via a special URL. Useful for security conscious admins and access over Wi-Fi
- Selective enforcement of https -- all WA pages with built-in forms (membership application, event registrations etc.) will be redirected and served via encrypted pages
- Full https enforcement -- this will always redirect all non-https requests to appropriate pages via https-secure URLs
To secure custom domains we will be generating special third-level domains on our own secure domain, for example http://abc.org in secure mode would be served via https://abc.org.wildapricot.org. Wild Apricot widgets (interactive chunks of WA web functionality intended for embedding into other sites) will also have an option to use https security.
This is just a glimpse of what is to come in 4.4 -- stay tuned for details on other planned enhancements in our next monthly post!