Roadmap: Reporting

Reporting is something we've been dialoguing about, and this page is a place to have those discussions. Comments, questions and ideas are most welcome.

---

User Personas

(These are just some personas to help us understand typical reporting requirements. They may, or may not, exist in your church.)

Persona	What they might need, or want
Anna Admin	Runs daily transactional reports, such as name and address listings.
Pete Pastor	Probably gets Anna to run and compile special reports for him. Unlikely to be interested in transactional reports. More interested in trends and patterns.
Sally Small-Groups	wants to know about attendance in her groups; summary and detailed listings of who has attended when. Collates and feeds information to Pete the Pastor on small group attendance.
Petunia Pastoral-Care	Would like to get a schedule of her upcoming visits and appointments so she can plan for the week.
Eugene Event-Manager	Hey, we've got an event coming up and we'll need someone who can take good photos for the church.io post. Can you find me those people who have said they're into photography, please?
Kathy Kids-Worker	I'd like to know how many kids attended last weekends am service to see if we need to put another room on for JC Crew class. They were saying the area is getting too small.
Ian Interns	Can you tell me all of those people that have expressed an interest in our internship programme next year? I'd like to follow up with them personally to talk through details of the internship changes for next year.
Igor IT-Admin	Give me SQL and a text editor, and I'll get my own information. :)

From the personas outlined above, you can see there is a wide range of requirements, and different levels of ability with a reporting tool.

Different levels of ability are:

1. Run a report
2. Create a simple report (perhaps just report on one table and simple filtering critieria)
3. Create a complex report (eg multiple tables, aggregation, joins and multiple filtering criteria)
4. Create a report beyond the limits of an "in-solution" reporting tool (i'm so cool, I've got my own tools :)

Basic Requirements

• We'd need to support different levels of ability (as outlined in the table above)
• Certain data might be classified as sensitive. We might want to omit this from reporting tools.
• People love Excel (or csv-to-Excel) for manipulating extracted data, so we should consider this. Then the end user can get lovely user-defined graphs and time-series and financial analysis and all sorts of stuff that a rails app shouldn't be expected to do in its internals.
• If we've got long running reports, we should consider moving them to another process/background worker so they don't impact front-end performance.
• We'd need to support the [custom fields] (https://github.com/churchio/onebody/issues/179) specification.

What's already there?

Reporting seems to me like a "universal" requirement of an information system. There are probably enough reporting "tools" out there that we don't need to create our own. Here's a few we might consider:

Tool	A brief description	Last Activity
[Active Admin] (http://activeadmin.info)	Active Admin is a framework for creating administration style interfaces. [axlsx] (https://github.com/randym/activeadmin-axlsx) provides an excel download feature.	August 2014
[Ruport] (https://github.com/ruport/ruport)	Ruby Reports (Ruport) is an extensible reporting system, own DSL	about a year ago
[Munger] (https://github.com/schacon/munger/wiki)	A data munge + format + output tool	5 years ago
[dossier] (https://github.com/adamhunter/dossier)	Ruby-based report generation/presentation Rails engine.	June 2014
[Thin Reports] (www.thinreports.org)	ThinReports is Open Source Reporting Solution for Ruby. It provides a GUI Designer and a Library for Ruby. (Japanese)	August 2014

An approach to OneBody reporting

Phase	A brief description	Status
One	Provide some bulk-standard reports that most congregations would find useful (like printed directory, maybe attendance tracking, kids check in type listing). We'd use a pre-existing report generation tool for this.	Underway as #189
Two	Implement something to allow reporting and filtering for simple report creation.	To be considered
Three	For those that require database level access, recommend a SQL tool that can be acquired separately to OneBody	To be considered
Four	Do something about "complex end user reporting	To be considered

For the future

• Poll OneBody user base to see what custom reports they might have created
• When looking at a new feature, make sure to include any relevant reports (if any) in the feature
• Is it worth us trying to create a "report creator" ie, something that reads a set of config tables and produces an output based on that? too complex?

Other Notes:

• I've noticed that lots of websites make use of profile search type reporting, eg punch in the criteria you are looking for, (eg. doctor) and out spits a web page of all those who have nominated the criteria, plus their names and contact details, and their photograph(s)
• Do we care about performance, ie reporting on a transactional table in "office" hours
• Do we care about providing SQL access... probably read-only for this purpose, perhaps that's just a recommendation we make to users.
• Heres another [take] (http://railsblog.kieser.net/2013/02/how-to-create-beautiful-reports-in-ruby.html) on the presentation layer.