Consultants Conference Call - Jan 28, 2009

Assuming SanFran is PST then 9 am makes it 6 am NZ time. I will do my best. An hour later would seriously improve my chances but realise it may knock others off at the other end of the planet.

I had been thinking of asking among other implementers whether we could organise some 'show and tell' sessions to demo how each of us is bending civiCRM to meet various client needs.

I want to be on the call, but fear I will not be able to make it. Here are some notes from Trellon:

1) Feedback on What is Missing: some notes from the front

- accounts payable integration with external systems (Peachtree, Great Plains, Quickbooks)

- direct webservices integration (only available through Drupal)

- direct integration with external reporting tools, or a simple release for those tools (BIRT and Jasper)

- list segmentation on advanced search: exclude criteria

2) What Does Not Work

- Civimail: rich text editor often does not load for users in Firefox

M

Hmmm - that is about 4am here in Sydney.... I will try to wake up then!

Hi there,

Some quick thoughts on the agenda

What can be improved in the ecosystem + Feedback on whats missing in CiviCRM and should be high priority for a future release

Better talk and discussion around future releases and longer term - a Roadmap blog series might be useful to guide disscusion and feedback.  It's hard to get a sense priorities, difficulties, options, etc. from the current 'bulk bin of useful issues'.

How can we help you

Some pages on best practice on development environments to help people understand most efficient ways to customise code, ease upgrades with custom code, get contributions in core, etc.

How you can help us

More talk / co-ordination in the layer between core team and end users

Bad timing.  We will be kicking off a new CiviCRM project for a customer right then.  I will try and have one of my associates on the call, though.  Our biggest focus has been developing the API for CiviCRM (which we have done a lot of at this point).  OUr biggest need is to integrate Civi (primarily in stand alone configuration) to a number of other open source packages and custom web applications written in RoR.

So with the rescheduling, this will now be 11am PST, 2pm EST, I believe.

Most of my work in the past year has been with 2.0, I've just started working with 2.1. It has a number of great new features that clients like, and being able to use Drupal 6 is marvelous. The only big issue that has arisen is around OS requirements - for any current CentOS or RHEL, it's a real hassle because of CiviCRM 2.1 PCRE and PHP 5.2 requirements. I think neither of these requirements is actually essential to CiviCRM 2.1, so I'd like to see if they can be dropped.

Looking forward to it...

• Feedback on whats missing in CiviCRM and should be high priority for a future release

CiviCanvasser, including both offline and online canvassing. Farther down the road: VoIP integration.

Analytics of some kind to assist in cluster analysis. Maybe start with A/B analysis for mailings and Contribution pages.

High performance (large DBs, many concurrent users). Potential partial implementation: keeping 'memcache' code version current in a parallel release stream.

• What does not work in current releases of CiviCRM

Perhaps this is just me or a documentation issue, but I'm not clear on the best way to make changes to CiviCRM in a multi-site installation, when the modifications are to more than the .tpl files.

• What can be improved in the ecosystem

An organization with core mandate to provide CiviSMTP-like service.

I plan to be on the conference call. Here are some of my thoughts/comments in advance. They don't fit neatly into the predefined topics, so I'll just list them as is.

Development Cycle: From a developer/implementor standpoint, I think there are several ways I'd like to see the development cycle changed.

1. I'd actually like to see the release schedule slowed down a bit. I'm maintaining a number of CiviCRM sites, and I'm finding it more and more difficult to keep up with upgrades, especially since the process requires each version upgrade (i.e. you can't skip a version release, for example jumping from v2.0 to v2.2). By releasing just a little less frequently, more features could be included in each upgrade, which would provide more value and impetus for the upgrade. (Note -- I have mixed feelings about this suggestion, even as I type...)
2. I'm concerned that with each version release, the focus is largely on building *new* functionality, when there are remaining holes in previous functionality. I notice this most in areas where it seems a new function was included in a release, but the full implications or usefulness of the function have not really been fleshed out -- leaving a new function with limited usefulness. I would like to more emphasis on plugging holes and filling out existing functionality before new features are added. A few examples off the top of my head:
   1. The ability to set relationship authorizations (John Doe can change ACME Corp's contact details) was a much requested feature that was added to v2.1. But the usefulness is limited:
      1. there's no way to identify a contact as having such authorization without viewing/editing a relationship (some distinguishing element should be visible in the relationships tab)
      2. there's no way to search for such authorization via advanced search, etc.
      3. on the frontend, access to the contact editing for the related record is non-intuitive -- currently only available through the membership dashboard
      4. there's no way to control what fields are accessible to the contact who is authorized to edit the related record
   2. The ability to have inherited memberships has been a feature in Civi for quite some time. But it seems some of the functionality around using that capability is limited. For example, the CiviMember dashboard shows summary stats for ALL members (primary + inherited), with no way to refine the details to show only primary members. While the full stats may be useful at times, I suspect most orgs that use that functionality want to know the number of actual paying members (primary member) at times. There also is no way to search for just the primary contact via CiviMember Search or Advanced Search.
   3. Integration between an Event Registration or Membership and its corresponding contribution has come a long way in v2.1. But there is still room for improvement, particularly in how the search tools work (you're still not able to search contributions for a specific event or membership type; the contribution source can be searched, but because that field is editable, and is constructed differently for frontend v. backend pages, it is unreliable).
   4. Improved current employer functionality was included in v2.1 (ability to set the current employer on the main contact summary edit page). But it needs to be fleshed out more: the user should be able to set the CE from the relationships tab; when setting the CE on the summary tab, memberships are not inherited via relationship.
3. It seems that the current development process is such that once a release gets to Alpha stage, the *only* concern is with testing and removing bugs. That does not leave opportunity for functionality-filling, per the above. I realize that from a development standpoint, it may be problematic to allow that circling-back and reopening of feature considerations for a given release. But the community does not have opportunity to see and test functionality until a release goes Alpha, so there's no way at that point to help inform how the layout/functionality/workflow of given feature works. I'm sure we (community) could do a better job of creating screen mockups and outlining desired functionality through Jira, but there's still nothing quite like looking at a demo release, kicking the tires, and providing suggestions for improvements.

Upgrading: It would be useful if minor revisions were available as patch packages (only files changed from the immediate previous version included; file structure mimics the installed file structure). This would ease the upgrade process as the package could be uploaded and unpacked without going through the actual uninstallation/reinstallation process. It also would help developers quickly identify if any override files need to be updated to reflect changes in the core.

Interface: I really think interface issues need to take a higher priority. A clean, space-efficient, intuitive layout in the backend is critical for helping the administrative staff function efficiently and navigate easily through the various tools (it also reduces the need for extensive training). On the frontend, there are a lot of inconsistencies in how the template html and css is structured, which makes it challenging to customize the pages to fit an existing site design. I would also like to see more ability to customize the admin interface. The biggest single request I get is to modify the search result selector tables (for the standard search as well as component-specific search) -- people want some columns removed, others added, current employer listed, etc.  Some more specifics on my wishlist:

1. There should be a clear demarcation in the css applied to frontend pages vs. backend pages. This should be done by having distinct page wrapper ids for frontend and backend pages (currently all pages are wrapped in #crm-container), and perhaps a generic civicrm wrapper outside of the context-specific wrapper. The civicrm.css file should then distinguish betweem styles applied to all Civi pages, and those that are frontend or backend specific. As it stands, when I make modifications to the styles to make frontend pages match my site styles, those changes alter the backend pages as well, which may or may not be good. Likewise, alterations with the administrative pages in mind have impact on the frontend pages.
2. The out-of-the-box CiviCRM css should be more neutral in its color scheme and styling. Baby blue has got to go. Using more greys, tans, browns, would help people implement more quickly.
3. As noted above, many of the templates are inconsistent in their use of html and css. For example, you'll have table-based layout and dl/dt-based layout within the same template -- and those are very difficult to reconcile style-wise. Since just about everything displayed in a Civi page is data, I don't think it's problematic from an accessibility standpoint to retain the use of tables. But the primary issue is consistency.
4. The CiviCRM use of css is getting pretty bloated. I'd love to see more simplicity, consistency, and organization in the civicrm.css file and its use throughout the system.

On a related note --
I had indicated last year that I was working on a project and would be doing a fair amount of work on the interface and layout to improve space efficiency (tighten things up), etc. I had hoped to release that to the community as an alternative "theme" for Civi. Biggest problem I ran into was that by the time the project was at a stage where I'd caught up with enough theming elements to be worth releasing, the next version of Civi was about to be released. I'm more than willing to help out with the theming/layout piece, but I'm not sure how best to do that as part of the core teams development process.