CiviCRM Community Forums (archive)

Hey Matt,

Your proposition seems reasonable when it comes to custom fields extending Contacts, however, custom data groups extend all kinds of objects - Activities, Relationships, Contributions, Memberships, etc etc - you can create them for other purposes than just building profiles. Therefore, we cannot remove whole concept of custom field groups.

However, your reasoning on Profiles/Custom Data complexity makes sense. Could you try to discuss this further in this thread, taking above into consideration?

Thx,
m

@Michael,

I'm sure this needs further thought, but Profiles as they are now are not limited to Contact records either. They an be added to Event Registration, Membership sign-up, etc.

This may not be so much a change in architecture as a change in terminology & the admin interface. We add a 'Profile' to a Relationship, Activity, whatever, though in the background, it may function exactly as custom groups do now.

It might however, open the opportunity for allowing a custom field to be used across different objects, much like CCK allows a field to be used across different node types in Drupal. (Sometimes a field might have a slightly different meaning when associated with a different record type, but I bet there a performance advantage to sharing custom fields)

For example, an organization might want to track something called 'Initiation Date' on Contacts, Relationships, Memberships, and Groups, which is different from the built-in "Start Date" fields. (Maybe it marks the end of a Training period for new volunteers, for example, and would be tracked on the Contact record, and on the Activity Record for the training activity itself, and on  the relationship record for the Trainer-Trainee relationship.)

I realize the above is probably an outlaying use case, but it does demonstrate the usefulness of rethinking the way concepts in CiviCRM may be unnecessarily divided. I think numerous usability improvements can be made by mering concepts. Custom Group = Profile. Membership Organization = Domain Information. Membership = Group. Event = Activity.

To continue the general principle: Is it really useful to sharply divide Contacts into Individual, Organization, and Household? Another recent thread discussed the frequent blurring between Organization and Individual for some uses. Could one record represent both, if a user wanted it too? There are no Organization-Contacts per-se, there are just contacts who happen to have the Organization-Profile filled out. For most users, there would be no change in the way they work with or think about their data. They think "I need to look up an Organization" and the software knows, "Only look at contacts with at least one completed field in the Organization profile." But the removal of divisions in general opens up the possibility for innovation and more creative use of the tools CiviCRM provides.

(By the way, I'm not actually proposing the above change. I'm just brainstorming. Some actual usability testing would go a long way toward smashing my wacky abstract theories about usability.)

The general concern is simplifying the complex machine that CiviCRM has become over the years through the addition of new features. Sometimes less is more, and sometimes you can make it feel less overwhelming without actually taking away features. But I digress...


@Lobo,

1. Yes, but a profile can also be only custom fields, in which case it would function exactly like a custom group does now. In the case of displaying my profile-hybird in a contact record, I might suggest display redunant built-in fields when the profile-hybrid is displayed as a tab, but only showing the custom fields  of the profile when it is displayed as a fieldset along with built-in fields.

2. It still could be. I'm simply suggesting combining the steps of creating and custom field and adding it to it's first profile. Once it's been created, it appears in the selector for future profiles along with all built-in fields.

While this is under considering, I've been thinking or along time about the idea of build a flash or AJAX widget for a new drag-and-drop interface for building profiles, more like SugarCRM's UI, if I remember it correctly. Would there be demand for that sort of thing? Maybe that would be a better way to implement these ideas.

I'm reading this while on a "break" - so not fully absorbing etc. However it occurred to me that one approach to addressing some of the workflow / usability issues that Matt is addressing (prior to 3.0 and hence w/o a major architectural revamp) would be to allow folks to create custom fields in the context of building a Profile.

- Create Profile
- Add some existing fields
- Notice that I need a field for this Profile (form) that doesn't exist yet
- Click "create new (custom field)"
- Create the field (with the option inline to put it in an existing custom field group or start a new one)

Along these lines we could look at having default custom field groups (which are represented as tables in the current architecture) for each top-level record type. This would potentially allow folks to bypass thinking about creating custom field "groups" if they didn't need that level of complexity in their data.

Matt,

Seems like I missed quite some discussion over the offline weekend. :-) A few remarks without getting into the core of discussion:

First of all, thanks again for raising the issue and taking it further in the discussion. IMHO, it's really important for us (the team) to be able to think about such ideas, discuss over doubts and get constructive feedback, like yours.  :-)

The general concern is simplifying the complex machine that CiviCRM has become over the years through the addition of new features. Sometimes less is more, and sometimes you can make it feel less overwhelming without actually taking away features. But I digress...

Good kind of digression. :-) It seems like it's an important discussion to have - let's come back to it periodically. As Lobo stated, we really should spent some time ruminating over usability before 3.0 decisions are made.

While this is under considering, I've been thinking or along time about the idea of build a flash or AJAX widget for a new drag-and-drop interface for building profiles, more like SugarCRM's UI, if I remember it correctly. Would there be demand for that sort of thing? Maybe that would be a better way to implement these ideas.

I'm personally sure there would be demand.

Thx,
m

@Lobo

5.) Talk is indeed cheap. that's why I give it away for free. :-) Development, however, is not so cheap....

That said, here's a VERY rough UI mock-up of what I'm thinking for a new Profile-Builder widget:

http://www.ninjitsuhosting.com/profiledemo/index.html

I'm fairly confident I could build the back-end to this using the APIs as they are now.

How much demand is there for something like this? Is finding sponsorship for this a feasible goal?

@Michael,

Will do.

Well, I've got funded to do my own take on Phone banking, which I do intend to release in some form, so once that's done, I guess I'll start by hitting up my own client base for ProfileBuilder funding. :-)

By way of ballparking the cost, my initial thoughts are that my cost to develop this with my own team would be between $3k - $6, so it's not a HUGE undertaking, compared to what the core team might do.

My intention was to continue with lazslo, but I probably should spend some more time with views2 first. Although, that would would limit the functionality to Drupal users only. Not that I'm against that.... :-)

All feedback and input is welcome. But personally, I have zero experience with internationalization, so I'll be dependent upon whatever is built into CiviCRM for translations. I'll be pulling field labels, etc, by API, so as long as the API takes care of translations, field names will be translated. If anything more is needed, it will be dependent on the community.