11 June, 2010
By xavier
Relationship are a natural way of storing relations between contacts. However, it doesn't work so well if you have several hundreds of related contacts as the realationship tab becomes unreadable quite quickly. One of our client needed to associate each individual in their base to a local branch (we implemented a nice geo lookup based on the postal code to identify the local branch, but that's another story). It means that each local branch has 1000th of individuals. This could happen in other situations, for instance to keep a relationship between a "main teacher" and each pupil or who is the latest volunteer that contacted each person in a GOTV/ Canvassing campaign... We choose to store that relation as a custom field of the type "contact reference". Each individual has a new field "nearest local branch", that is a reference to an organisation (the local branch). It works fine and you have a nice autocomplete field, like the search field in the top left corner in the... Read more
22 February, 2010
Filed under Interface and design
DGG and I have been discussing a small modification to the Contact page that we think will have a nice impact on usability for people who spend a lot of time working inside of the contact record. After some thought, we decided that it makes sense to move the edit/dashboard/vCard and "Create activity" buttons up and outside of the Summary tab. We'd like to change the "Create Activity" dropdown into an "Add ..." dropdown that could include contributions, activities, cases, memberships, relationships and notes. This will have the effect of removing one click from the process of adding any of these (commonly used) entities to a contact, as well as surfacing many of the "jump-off" points that administrators use on the contact page. Additionally, it seems that the order of the buttons could be re-worked. Specifically, the "delete" button which is used least, should be moved away from the prime real estate of the top left. I've set it as the last item in the list, and have put the "Add... Read more
25 January, 2010
Filed under v3.1, Interface and design

This is a follow up to Refactoring CiviCRM's templating system (starting with CSS). It may be helpful to read that first, although it is certainly not necessary. We have made a lot of progress on CiviCRM 3.1's templating system, and I'm quite please to share some of the details of the work with you! In addition to a number of minor fixes and CSS cleanup, the main contribution page template has been re-worked and we have begun implementing many of the ideas outlined in the Layout Standards page. I've also created a new subsection in the Wiki, that deals specifically with templates & theming. I hope that this section will...

Read more
22 September, 2009

In the course of the recent NYC Developer camp, I had the opportunity to discuss the state of CiviCRM's templating system with members of the core team .  In the course of our work with CiviCRM we have done extensive theming and have discovered a number of opportunities for improvement over the current system. In this post I will outline a quick overview of the current state of affairs, and then I'll move on to a broad overview of the changes we would like to see and then specific goals for the 3.1 release.

Current state of affairs


The current templates make extensive use of tables when divs would be more appropriate. This is not in keeping with the Web Content Accessibility Guidelines, specifically, separating structure from presentation (refer to the difference between content, structure, and presentation).  While it may not be possible to follow the WCAG to...

Read more