CiviCRM Community Forums (archive)

I had a meeting w/ the online organizer for Progressive Future who's
been using CiviCRM to do online organizing w/ her group for several
months now. Our supervisor was there also. We discussed reporting
needs for the next version of CiviCRM and I think reached some
interesting conclusions. I'll try to summarize things here.

We started out the meeting looking at the list of reports defined in
the wiki here: http://wiki.civicrm.org/confluence/display/CRM/CiviReport+-+The+Return

We wanted to sketch out one of those reports complete with charts and
graphs to get a better idea of what we wanted a polished report to
look like. However, we quickly realized that the "define a set of
reports we'll need" approach was too limiting and not the right fit
for us. For instance, the Activity Report and the Mailings Report that
I worked on in the wiki won't actually be useful to us. That's because
we rarely if ever need a report on activity or mailings in a vacuum.
We need to combine these data with other data (contact-related,
membership-related, activity-related, etc. etc.) using various
criteria to answer more complex questions (such as "the number of new
people recruited by this action" or "the average response rate for all
actions over a time period").

So what we need is a flexible way to create and save custom reports.
We decided that the existing search tool would work very well for this
with a few (hopefully simple) additions:

1. Reports would become a collection of smart groups or saved searches
that defined the searches / criteria needed to generate that report.
2. Smart groups would need to be parameterized (e.g. you could define
a smart group based on, among other things, which state people lived
in, but supply the state or list of states when you ran the report;
that way you just need one report rather than dozens).
3. Add a new "Reporting" group type in addition to the Mailing list
and Access control types. Only Reporting groups will be displayed in
the reporting tool. This helps keep the interface sane.
4. Should default to generating counts instead of lists. In fact, if
the first version of this just generated a chart containing the total
counts for each smart group / saved search's result set, that would
cover 90% of our use cases right there.

Some of this may even be the plan for 2.3. But I wanted to make sure I
got this feedback to everyone. It turns out I was being overly
simplistic in assuming that my report descriptions in the wiki would
be useful to my users. And the tricky part of any custom reporting
tool is how do you let users define their search criteria and save it
as a reusable report? But it seems like we already have that w/ the
saved search functionality already built-in.

What do you all think?

Didn't somebody mention an effort to integrate one of the BIRT tools with the CiviCRM database?  That would seem to me like a possibly fruitful approach.  I hate reinventing wheels 

-- Walt

No, we're abandoning that approach. BIRT is too complicated and yet another platform (Java) and yet another dev environment (Eclipse). The best wheel to not reinvent here is the existing search mechanism. A very robust reporting system can be built on top of that. Beyond that there are plenty of PHP charting libraries and we've already got one integrated into CiviCRM 2.3.

Well, like I said, the BIRT approach has been tried, deemed a failure, and abandoned. We're well down the path towards another, better solution (as you saw at the San Francisco Dev Camp), so let's steer the discussion back in that direction.