CiviCRM Community Forums (archive)

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?

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.

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.

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."

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.

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.

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