A different concept for CiviReport

[narayanis]

I hope this is the right thread for this... I've been thinking a lot about reports, and came up with a concept for report UI and architecture that takes a different approach from the current top-menu-driven UI. It's a bit more similar to the popular, proprietary nonprofit CRM systems and focuses the experience toward ease-of-use for a non-technical user.

Should I put the spec, user stories, and HTML mock up directly in a post here, or attach them? Or would this even be useful to the devs?

[lcdweb]

definitely would be helpful.
but could you create a wiki page for it and then link to that from the forum? that's a better venue to track specs.

[narayanis]

Done: http://wiki.civicrm.org/confluence/display/CRM/A+different+CiviReport+architecture+concept

I hope this is helpful in providing another way to think about the architecture of using, storing, and organizing reports. It's not uncommon for nonprofit CRM systems to have 120-200 reports, and the current menu concept wouldn't support that without becoming a usability problem.

[lcdweb]

on a very cursory glance, I don't see how this is much different than the existing structure.

report templates (your "report definitions") can be view here:
http://drupal.demo.civicrm.org/civicrm/admin/report/template/list?reset=1
-- which provides access to existing reports (grouped by type) associated with a template as well as the ability to create new ones

a full listing of existing reports is found here:
http://drupal.demo.civicrm.org/civicrm/report/list?reset=1
-- which is grouped by the type of report

your UI is different for the selection, and probably does a better job of navigating through a really large list. but the structure is basically the same, isn't it?

[narayanis]

On the surface, there are a few similarities, but here are some key differences:

• Organization of reports into categories is relegated to the database. This means you don't have to manage more report-organizing code when CiviVolunteer, CiviTicket, or CiviFoo is added to the program
• Ability to visit a My Reports folder for easy access
• Ability for a user to discern between canned and custom reports
• Ability to view who created a report and when it was last changed
• Ability to differentiate between updating/saving an existing report instance, and creating/saving a new report instance based on the existing instance

It's not a completed spec, but there are some other things to change if it's worthwhile for me to keep working on it

• Ability to restrict permission by ACL to entire report folders
• Eliminate "Include report in navigation menu"
• Eliminate "Reserved report". Let ACL handle this
• Eliminate "Available for dashboard". If a user has access to view a report, hiding it from his dashboard seems arbitrary and just adds complication and more clicks to his day
• The combination of Permission and ACL Group is confusing. Eliminate the Permission input and let "access CiviReport" do what it says.
• If "Everyone can view" and "Everyone can edit" options are too simple, then use multi-select lists for View and Edit, displaying the ACL Group list for each. The first entry displayed in each list should be "Everyone" and be pre-selected, since that's the most common use case

I just wanted to get the beginning of the idea out there for review from folks who work directly in the codebase. If this doesn't seem like a useful spec, I can stop now.

[lcdweb]

hmmm....
just commenting on your second list briefly:

• right now the reports are tied to (and organized into groups based on) the major system components. so ACL for a component determines ACL for the report. and those are handled by the class structure, so there's minimal additional work that would need to be done for new components. I think what you're suggesting is the ability for the user to create custom "folders" and reorganize the reports? interesting idea, but I think we'd also want to retain a way to maintain the component-based structure. maybe a toggle for viewing the listing in different ways?
• why would you remove including the report in the navigation? that's a really useful feature. you may not rely on it for large lists of reports, but that doesn't mean it should be removed. view proposed changes as in addition to the existing structures.
• the reserved report flag IS for the purpose of ACL. it allows admins with that permission to lock certain reports so they can't be modified by those who lack the permission. it's a very important option.
• available for dashboard is also important. not all reports are sensible for the dashboard. having that flag keeps your list of available dashlets limited to only those that are appropriate/useful for that purpose. if hundreds of dashlets are available, it makes the tool less useful
• the permission and ACL group/role was added for a purpose. it allows much more fine grained control over who can view and work with specific reports, which is critical for larger organizations. the single access civireport permission is much too general for any organization of size.

[narayanis]

the reserved report flag IS for the purpose of ACL. it allows admins with that permission to lock certain reports so they can't be modified by those who lack the permission. it's a very important option.

This seems to go against the fine-grained control you mention. Wouldn't two ACL lists on a report instance (one for View and one for Edit) provide better control?

the permission and ACL group/role was added for a purpose. it allows much more fine grained control over who can view and work with specific reports, which is critical for larger organizations. the single access civireport permission is much too general for any organization of size.

This makes sense, so 'all can view' and 'all can edit' are too generic. Wouldn't these be better served as 2 ACL lists, as mentioned above?

available for dashboard is also important. not all reports are sensible for the dashboard. having that flag keeps your list of available dashlets limited to only those that are appropriate/useful for that purpose. if hundreds of dashlets are available, it makes the tool less useful

Wouldn't it be less complex for the user to visit a report instance and select an option like "display on my dashboard", rather than having report instances displayed in the list of available dashlets? The dashlet can still be removed directly from the dashboard when the user no longer wants it.

From the perspective of an average user, navigating CiviReport is complicated. Even if you don't feel the underlying architecture needs change, or the My Reports and Custom Reports items are useful, the UI could still use improvement. The hardest mechanic is navigating the seeming overlap of Permission, ACL Group, and Reserved Report. The average user of fundraising CRM software may say "Which ones do I set and how? There are too many widgets, options, and checkboxes. I just want all Civi users to access my New Prospects report, so my solicitors stop calling every other week asking me to run them a copy." The second-most confusing mechanic is working with report/list and report/template/list. "These pages look the same except for that oddly-placed 'existing reports' link on one of them, and what is a template anyway? I just want to run a copy of the Weekly Contribution List report that Suzy made, but do it for all of last month."

[lcdweb]

re: reserved --
yes, there is arguably some overlap. but still enough difference for that option to be worthwhile. it allows admins the ability to lock certain reports across the site.

re: dashlets --
personally, I think the current model is a lot easier. people want to manage their dashboard while they are on their dashboard. to ask them to hunt down a report instance in order to add it to their dashboard is cumbersome.

further -- coupled with the reserved flag -- this allows an admin to construct a set of locked reports that may be dashlet enabled, thus facilitating staff by giving them a finite list of meaningful reports that could be useful on their dashboard.

[Eileen]

One thing I quite like in the spec is being able to see who created reports and the concept of 'my reports'. I can imagine in a busy organisation there could be lots of reports created and being able to see them all could be a bit cumbersome.

[xavier]

Hi,

Nowhere near as advanced as what's in your spec, but have you checked what's in trunk now?

IMO, Dave did a good job to put the list under control. I'm still not super convinced of the report menu and I think it'd work better as a sub menu under contact/contrib/case...

Anyway, things like "my" seems something that would be useful when you got a few 100 reports indeed. Wondering if the need isn't shared more broadly with "my" contacts or my groups or my tags.

X+

[The Next Wave]

There are two gems here:

Ability for a user to discern between canned and custom reports

This is something that needs a lot of clarity in CiviCRM- so that there is no confusion about what is system generated- general- and user generated - custom and ostensibly tested with the current configuration.

and:

From the perspective of an average user, navigating CiviReport is complicated. Even if you don't feel the underlying architecture needs change, or the My Reports and Custom Reports items are useful, the UI could still use improvement. The hardest mechanic is navigating the seeming overlap of Permission, ACL Group, and Reserved Report. The average user of fundraising CRM software may say "Which ones do I set and how? There are too many widgets, options, and checkboxes. I just want all Civi users to access my New Prospects report, so my solicitors stop calling every other week asking me to run them a copy." The second-most confusing mechanic is working with report/list and report/template/list. "These pages look the same except for that oddly-placed 'existing reports' link on one of them, and what is a template anyway? I just want to run a copy of the Weekly Contribution List report that Suzy made, but do it for all of last month."

While most of the people running this project have been with it for a long time- it's not easy or obvious like WordPress- and that should be a goal.
That ANYTHING shows up in multiple menus is confusing and part of a bad UI spec-
and- that terminology changes- "activity" needs to be the same across the board- and clearly defined. Either you do an activity- or you create an activity- but- you can't have menus using the same term- and expect people to understand.
Also- Maybe a solution for everyone that would start demystifying this is that fields that are custom- all come with a tinted entry field- all that are standard, plain- or vice versa.
Also- any field that appears on a form- should be hinted- with creation date, creator, reason why- that exposed to top level admins using ACL.
Just a thought.

[jaapjansma]

I like the idea of a my reports section. Also The my reports sections should be something like my group reports (e.g. so you can store a report in a group, rather than just me). In an organisation where lots of reporting happens users working on the same department share the same reports.

[jaapjansma]

Never mind this topic came up in my unread list of topics but I see the topic is quite old.