CiviCRM Integration Specification & New Features

This feature request is a working draft of the specification for integration of EventFinder with CiviCRM and a couple of other modules. I am posting it here to solicit comments on the exact features that would be most useful, ways of doing things, etc. I would like to get people's opinions on the specification collected in one place, positive or negative comments are appreciated.

I am going to preface this by saying the bulk of the work is already done (i.e. I am preparing to release these features and each one is in some form of completion), but that there is still some API work going into CiviCRM that will make some of this obsolete. Also, especially with the massmailer, there is no CiviCRM interface and the one I have hacked together might be replaced with a better one at some point in the future.

Anyways, here goes:

1) CiviCRM Registration Page - In addition to being able to use the contact_manager module to store registration details for an event, EventFinder would be able to use CiviCRM as an event repository. Since there is no generic means of generating a contact form in CiviCRM (as there is in contact_manager), this would involve building a separate module that automatically generates a contact form based on the fields in CiviCRM.

2) Announce Events / EventFinder Groups - Users would be able to create groups of individuals in CiviCRM that would represent a personal contact list. When a user enters an event, that person would be able to send an announcement of the event. EventFinder would generate a unique URL to visit to find out about the event, that would be used to track who has click through to see the event details. Event hosts would have a new option, to view their event announcements, see who has viewed the event, and who has registered. Users can automatically register their contact lists for events.

3) CiviCRM Event Tracking - Really just a fancy way to say we would be storing event registration details in CiviCRM.

4) Post Event Reporting / Attendance - EventFinder would be able to interact with CiviCRM to store details of who actually attended an event. Event hosts would be able to write up details of how an event came off, and publish them in an event archive. Possible integration targets include the galleries module, which would create galleries specific to each event (if someone wants to have a set of photos in the wrap-up).

5) Private Events - Users would be able to enter invitation-only events in EventFinder and use the system for event management. Event searches would ignore private events, and the only means of accessing them is through a unique URL sent to invited guests. This would interact with the Announce Events functionality listed above.

6) Bulk Mailer Integration - EventFinder would have a native interface for interacting with bulk mailing systems to accomodate the needs of high-volume Web sites. Event announcements and saved searches would be sent through the bulk mailer, registration and event creation emails would continue to be generated on the Web server (since these are one-offs anyways). Target platforms for integration include the massmailer module and Trellon's CivicMail module (disclosure: I am a partner in Trellon).

7) Registration Fee API - Users would be able to attach registration fees to events. Users registering for events would go through the normal registration process, but registration would not be complete until the user has paid to attend. Would provide a native interface into PayPal and possibly VeriSign based on the ecommerce module. Would include a generic payment form that could be customized to site-specific needs.

8) Search By Date - EventFinder would now allow users to search for events by date, for example, only the events occuring in the next 30 days.

9) Host Update Emails - EventFinder would send update emails to event hosts at an interval they determine at the time an event is entered. Intervals include: 1) every time someone registers for an event, 2) every n days, 3) weekly, and 4) monthly. The host update email would automatically include the event title, the date, the location, and the number of people who have registered for the event. The host update email could be configured (if other modules are installed) to include information on the number of people who have responded to an event announcement, the number of times people have viewed an event, and other figures specified. Host updates could be cumulative, covering multiple events hosted by individual users.

10) Host Overview page - Users who are hosting events will have access to the event host page, which will include some quick statistics on all the events they are hosting, including the number of people who have registered for the event, the number of page views, the amount of money collected in registration fees, and a qualitative score showing how often their events were viewed in searches / sent out in saved searches. Administrators will have access to this page in the aggregate, allowing them to see host overview statistics for all events kept in the system. The tool will be sortable on all the different columns and include links to events themselves.

11) Migration Tool - backend tool for administrators to switch between various registration repositories. Would gracefully migrate contacts from the contact_manager module to CiviCRM (and vice versa), from contact_manager to one click registration, and from one click registration to either of the repositories. Would include a flat file output for contacts which were unable to be migrated including all fields from the original respository.

12) EventFinder Blocks - several block recommendations have been sent to me. First, a top events block, showing the top events by the most users registered. Secondly, custom event blocks, where users could specify the criteria for events they want to appear in this block using the standard search controls.

13) Event Serialization - This is the one thing I have not done any work on. Several people have contacted me looking for a way to serialize events and registration information over several sites. I have given some thought to the issue, and think there may be a way involving flexinode and RSS. First, any node type can be an event, so the idea of having a standard set of fields used by eventfinder is out. Instead, EventFinder would be able to generate and import a spec file containing all of the fields used by an event. This event type import tool would be able to create a flexinode node that would be used to capture events of that type. It would also be able to replicate things like event types and event categories, fields used specifically by the event module. Secondly, EventFinder would be able to generate an RSS document that could be continually imported to bring in new event information. Third, separate EventFinder installation would be able to communicate registration details between installations.

Permissions would be set so that only administrative users could generate the event spec file, the serialization could be limited by IP, and registration details could be de-duped at registration time (like, if someone signs up at site xyz.com for an event and again at abc.com, that person only signs up once based on email address and other fields specified by the admin). This could also integrate into the host overview page, which would display the number of sites where a particular event is appearing.

The more I think about it, the easier this sounds. The only hitch is with registration numbers, there would need to be some way to get the current registration numbers from the originating site. Because of the possibility an event could be serialized over n number of sites, I am hesitant to want to do this in real time. I am leaning towards an intelligent home base design, where the original event would track which sites are hosting a copy of it and send a message with the current registration level each time someone registers for an event. So ideas about keeping the registration info current would be appreciated.

14) Mapping - I have been doing some work with EventFinder and Mapserver. Some people noticed the eventfinder installation at Trellon.com had full mapping capabilities for about a week. The way I was doing this was to provide mapserver with an array of geocoded addresses that were fed into it on each page load. The way I got it to work was by using iframes and javascript to control what addresses appeared in the map.

That said, it is really difficult to come up with a way to do this that would work for all users, browsers and installations of mapserver. I am giving a lot of thought to how to pull this off in a way where it can be distributed easily and supported within the community. A lot of people would want to just plug it in and have it go. To that end, I am considering launching a web service that just does EventFinder maps in mapserver. It would be available for free up to a certain number of page loads, then we would start charging for access as a service.

Other ideas would be appreciated, people start getting wierd when I start talking about a service based model for this. The maiin job is to get something done that would be reliable and up to date.

This is a pretty comprehensive list of all the feature requests I have received. The more feedback I get, the better the ultimate module will be. Please post all comments here, I would like to have this be a public discussion about what EventFinder should be able to do.

M