Fair warning, this post is intended to the technical part of our community, if you don't care about the architecture of civi, please skip this one, I'll come back to you soon with awesome datavisualisation and an interview of Micah about security and privacy (you'll like it).
And if you read anyway, I'm a bit of a drama queen and some of the mountains I describes are probably hills, at best.
As part of the Bristol Civi Sprint a proposed new layout has been suggested for the existing Find and Merge Duplicates page. The page is used to add / edit Duplicate Matching Rules for the individual, organisation and household contact types. This wouldn't involve changes to the way the Merge Rules work but the changes will make the page easier to use and understand.
This would include changing the use of the confusing terms 'Strict' and 'Fuzzy' to 'Front End' and 'Back End' respectively. On-screen help text will explain what the terms mean and how to use the page features. The names of the Rules would also be altered so they reflect the fields used to identify a matching contact.
A mockup of the proposed changes can be found here;
At our last big sprint there was some good discussion about ways to clarify the filtering conventions used on many of the search forms. One specific area that seemed to need "help" is the set of checkboxes for filtering on Pay Later, Recurring and Test contributions. Here's the current version of that section of the form:
With the checkbox interface, it's not obvious what effect checking the box has. Does it cause the search to ALSO include Test contributions (for example), or to ONLY include Test contributions?
Samuel Vanhove from Koumbit followed up by posting a suggested set of changes to the Find Contributions form recently here. Coleman and I discussed the proposed changes and came up with a few alternative approaches. Coleman also pointed at that the use of the word " - select - " on the dropdown filters was not...Read more
Brian Shaughnessy (lcdweb), who has been working with the New York State Senate's CiviCRM project, recently raised the issue of simultaneous editing: What happens when two users simultaneously make changes to same contact record? We've held a few discussions on IRC to examine the issue and draft some solutions. We would appreciate further feedback and ideas on how to address the issue.
As described by Brian:
The issue is that if you and I get into the same record around the same time, and you save the record first, when I save, it will overwrite your changes. So let’s say you add a middle name, and I get in and add a birthdate. The data is not in conflict, and both changes should be preserved, but they aren’t -- when you save the birthdate (where the edit form was loaded before I saved the middle name), the empty middle name overwrites the value I had saved.
We are currently working with an organisation that has a staff member that accesses their machine using a screen reader only (he uses Jaws). He has been working hard to see which core bits of CiviCRM (4.1.x on Drupal 7) he can access and has fantastically been working with us to feedback. In some instances we have been able to hardcode in menu links etc to increase his level of access.
This is real feedback from a user with genuine access requirements. Hopefully his experiences can lead to core code changes which will increase the accessibility of the system in the longer term for other users. We are also looking for ways in which we can increase his access levels in the short term. Please comment if you have any thoughts on core code changes that would make a difference, if you would like to get involved or if you know of users that have had similar experiences.
Generally he can navigate round a contacts summary screen, edit users, search via the basic Find...Read more
A member sends several separate payments to cover outstanding dues on a single purchase, like an expensive membership or a table at an event. How are you going to record this?
A conference participant selects “Pay Later” on several different event registrations, and later wants to pay them all in a single credit card transaction. How are you going to support this?
Current versions of CiviCRM don't offer a way to record multiple payments against a single obligation, or to split one payment among multiple obligations, but the CiviAccounts project is working to allow this flexibility. Work on data structure improvements has been going on for some time; it's part of a broad effort to help CiviCRM's financial data to be more compatible with QuickBooks and other accounting software packages, and it lays the groundwork for lots of possibilities, including more flexible payment processing.... Read more
The code sprint in London has finished yesterday. It's always a pleasure to see old civi friends and meet new ones. Thanks to Michael and Katy to have organized it. Time for a quick update of what I've been working on with the most obscure title I could find. My focus has been on usuability to make civicrm easier and faster to use.
To make our crm more user friendly, we need to make the pages more "application like", where you can add, edit remove and reorder from the same page without having to switch and go to more pages with forms to fill and save. And load. And wait. And save, and load and wait more...
For instance -and that will be a make it happen that we launch next week to improve- creating a survey today means you have to go to visit a different page to create the survey, the profile, for each field you add in the profile, for each custom field you need to...Read more
Batch entry of gifts (checks, cash, etc.) is a much requested "missing feature" in CiviCRM. Thanks to a generous sponsorship commitment from the Electronic Frontier Foundation, we are about to launch a Make-it-Happen campaign to implement this feature for the next release (4.2). We've spent some time discussing requirements with folks at EFF and several other organizations, and we've reviewed analogous functionality offered by several of the proprietary donor management products. The purpose of this post is to share the draft specifications for the feature and solicit feedback from others in the community.
The goal is to provide a streamlined interface for data entry of batches of contributions and membership payments. A simple batching concept will be introduced to provide verification of count and totals. The feature will use a grid-style input form with the columns controlled by a selected profile. This...Read more
Over the past few years the administration menu has grown quite a bit. Although I use it quite often, I find that I'm sometimes unsure where to look for a particular configuration option. We've heard the same comments from both experienced and new users - so Xavier Dutoit and I thought it would be a good idea to take a stab at re-working the menu structure. The goals of the re-organization are:
- reduce confusion - especially understanding the differences between Customize, Configure and Manage
- reduce the # of clicks to get to any admin option
- clarify language a bit
During the recent code sprint in the UK, we had a chance to do a "card sort" on the admin menu with Jamie McClelland from Progressive Technology Project. We came up with a proposed re-organization, and then tested it with the book sprint team by presenting the top level categories and asking each person to note down the category where they would expect a...