Following on Lobo's recent blog post about missing features in CiviCRM - we decided to take a closer look at what it would take to get basic "Pledge" functionality added to CiviContribute (and then evaluate how soon we could take that "leap").

The first step was reviewing the Pledge Requirements document / discussion which has been "evolving" on the wiki over the past year or so. Then I spent some time looking at some demos of Pledge functionality in other applications.

Thanks to the folks who expressed interest in attending a CiviCRM Boot Camp in Philadelphia this summer. Unfortunately we didn't get a sufficient number of signups to justify the expense of running the session (given that we'd be covering
airfare, housing expenses etc.) - so we are forced to cancel the session.

If you were thinking of participating in the proposed Philadelphia Boot Camp, tomorrow is your last day to let us know (by sending an email to me - dave at civicrm dot org). We are still a few folks short of the number we need to run the camp - so if we don't hear from you tomorrow - we'll have to cancel this session. We're still planning to hold another camp in the fall on the West Coast - details to follow - but feel free to drop me an email if you're interested in that session.

As part of the 2.1 release cycle, we are working hard to simplify and streamline the codebase wherever possible. The intent is to increase performance, reduce the number of bugs and make the code easier to understand and maintain.

As part of this effort, we are considering the elimination of two "features" which create (potentially) unnecessary complexity in the code, AND which we believe to be infrequently used...

Store Data for Multiple "Domains" in a Single Database

The current data model allows you to create and maintain separate "data silos" ("domains") in a single CiviCRM database. This concept was derived from Drupal's multi-site table-prefixing model - although it uses foreign keys instead to link each domain's dataset.

Over the past few releases, we have seen quite a few use cases where larger hierarchical organizations want to control access to subsets of their data - based on a user's departmental or regional affiliation and/or role. However - the current domain model does NOT address this issue - since data in each domain is completely separate and there is no concept of hierarchy, inheritance of permissions etc.

Two new CiviCRM-related articles just got posted on the NTEN.org website - and might be of interest to folks...

Michelle Murrain writes about Open Source CRMs - How Do They Stack Up.

... and John Kenyon posted an article where he "puts a human face" on open-source software, and features an interview with yours truly (blush). Open Source Software - Who Makes This Stuff.

Case management is a central activity for a large number of non-profits and NGO's who are current or prospective users of CiviCRM. Basic support for defining cases as a grouping of activities with a "client" was added to CiviCRM 2.0 through the sponsorship of Frontline Defenders. Subsequently, interest has been growing for adding more comprehensive case management support to CiviCRM. Earlier this year Michelle Murrain of NOSI organized a lively discussion list which allowed folks to share ideas about requirements and use cases.

Andrew Clarke, the Executive Director of The Physician Health Program of British Columbia (PHP-BC) was one of the participants in that discussion. PHP-BC provides "advocacy and support for physicians...who are experiencing problems related to personal and family emotional health issues..." They have been looking to replace their current data management system. Recognizing the potential of an open source solution that could both serve his organization's needs AND those of other human service organizations - Andrew advocated and obtained funding to partner with CiviCRM in designing and developing a CiviCase component.

I'm on my way back to San Francisco after an incredibly stimulating three weeks of collaborating (and co-habitating) with fellow "Civi's". There were lots of very long days (12 - 15 hours) of brainstorming , designing, hammering out code... intermingled with cooking and eating some lovely meals together, a few cool adventures in the natural beauty of New Zealand, and some excellent meetups with members of the community "down-under".

This was our fourth "international" team gathering. In planning for it we tried to build on the things that worked best in our prior meetups - and learn from things that didn't work as well. We decided to focus tightly on a few key goals / projects - and worked hard at staying on task. (This meant resisting the gravitational pulls of email, forums, team members not with us etc.) We set a schedule for moving through our projects and decided up front that it was ok to move on to the next task without completing 100% of the current one.

Lobo and I woke up at 5:30am (ouch) today to conduct the CiviCRM Webinar. A dark and stormy morning in New Zealand - but evidently a good time for the Webinar (11am PDT) - as we had an awesome turnout (40+ folks registered).

The session was billed as in introduction to CiviCRM - so we spent most of the time describing the key features and components (contributions, memberships, event registration, etc.). In order to give folks a better idea of CiviCRM in Action - I created a separate slide-show with screenshots of CiviCRM pages from a variety of live sites...

• User registration with CiviCRM profiles - from Amnesty International
• Multiple online contribution pages (campaign-specific) - from The Conservation Fund
• Membership signup - from NYAMA
• Event listing and registration - from The Foundation for Prader-Willi Research
• Searchable South African NGO eirectory - from SangoNet

Brian Shaughnessy is working on some layout improvements for a client - which may potentially result in some core code contributions. He posted this question on the forums today:

I notice there's some inconsistencies regarding how some of the forms are laid out. Specifically, I'm running into forms that use a mix of table/tr/td tags with dl/dt/dd tags to layout the form labels and fields. This makes it more difficult to have consistency laying out the page using css, because those tags are structured differently.

My personal preference is to use table tags exclusively. Because of the built-in structure of dl/dt/dd tags, I find them hard to layout on a consistent and growable/shrinkable manner. I know that in a strict-css-world we shouldn't use table tags for layout, but for a long list of form labels and fields, many of which have option contingencies, tables seem like the most logical way to handle layout.

Since this is an issue we've struggled with, and because we're looking at changes to some key screens and forms to improve usability - I'm posting my response here as a blog. Hopefully we'll grab a few more eyeballs and get some useful input from folks with expertise in this area...

UPDATE: You can review detailed implementation specifications here and here

----

• "We are an Association whose members are organizations. How can these organizations signup and renew their memberships online?"
• "We get contributions from companies as well as individuals. How can we configure our online contribution pages to handle this?"
• "How can we allow someone from an organization to update the organization's address and contact info?"

These are questions that have come up over the past year from users - most recently with Emily Frazier who works on Public-access media related sites, and participated in our New Orleans Boot Camp. Working through real use cases and options with Emily was very helpful - and we think we've come up with an approach that makes sense. If you're organization has requirements in this area - please take some time to think about how well this will meet your needs.