CiviCRM Community Forums (archive)

When including profiles on a contribution or event page, the title of the profile is displayed on the page.  This causes a few problems:

• You may want a different label on the front end page than you do on the back end UI.  E.g. "Membership Fields" might be a good back-end name, but on the front end you might prefer, "Please fill out as much of this information as applies to you."
• It's difficult from a usability perspective.  I find that it's confusing to end users that the label must be changed on a profile page - especially since many users are comfortable with the "Manage Event Pages" feature, but not with creating/editing profiles.
• It inhibits reuse of profiles.  I have many installs where there are 3-4 copies of a profile, identical except for the title.
• Often, you don't want a profile label at all on the front end.

Does anyone else have these issues?  I have a few thoughts on solutions, but I wanted to throw it out to the community before I waded into it.

Possible solutions:

• Adding a "label" field on the profile itself, distinct from the profile title, would solve problems 1 and 2 and 4, but not 3.
• Adding a "label" field on the "Include Profiles" section of "manage contribution pages", "manage events", etc. would fix all the issues.

What do people think of the second solution?  I think one could best implement this simply by adding a "label" field to civicrm_uf_join.  I think that I could do this (if I find the time!) but wanted to get feedback on the approach, and whether other folks experience this as a problem.

Jon - this has come up in the past. You might want to pull folks from PTP into the conversation since they use profiles quite heavily with their organizations and are driving some other profile usability improvements forward for 4.3 (hopefully).

First thoughts on your suggested solutions ...
* We have "title" and "name" for profiles (uf_group table) - so I think adding "label" is a bit confusing semantically. Alternatively, adding a "description" field which is displayed to back-office folks in the Profiles listing might solve some of this problem. Then the "title" could really be the "default value" displayed when the profile is rendered.

* Continuing w/ "default title" concept, adding a "title" (or "label") field to uf_join seems like a good approach. The UI on Manage Events / Manage Contrib Pages could default to inserting the selected profile's title into that field when a profile is selected, but then allow user to override it (replace w/ another string) OR leave it blank if they don't want a title on that section of the form.

Thanks everyone for useful feedback!
@Dave - I agree that "label" is semantically confusing.  However, petednz brings up a good point I hadn't originally considered - sometimes you want the "label" to be non-unique across two profiles. 

Hmm.  If we implemented a new field `description`, would it be possible to allow non-unique titles?  Since it's the `name` field that gets called, I suppose we could.  Would we then disallow non-unique descriptions?  I think we'd have to.

Besides that, thanks to you and petednz for validating my thinking on both the general approach, and confirming that I'm not the only person who's considered this.

@Xavier - I thought about your comments about folks seeing a profile as "mine" for a long time before I understood your point.  I think that done correctly, it will actually reduce folks seeing a profile as theirs, since they can reuse an existing profile without changing it.  However, that depends on the language we use - if we make people think they're changing the profile (instead of giving it an alternate label), I think it will have the effect you described.

I don't have a good answer about folks wanting to change the pre/post - it's a good point, and since I almost never use them on a profile-wide basis, I hadn't considered it.  Maybe I'll bring it up with PTP and see what their thinking is.

CRM-9845 has two parts to it.  The first part is similar to what we're describing here, and I'd be willing to talk to Jamie at PTP and see if he'd be willing to give me a bit of help if I needed it toward completing that part.  However, the portion about hidden profiles is confusing to me - I've read previous discussions about the use cases, but I don't have a good handle on it.  So if you'd like, I can take part 1 on a new ticket, and leave part 2?

I don't want to add feature bloat to this forum post... but I think Xavier's suggestion to be able to see where existing profiles are being used would be extremely useful. It's something we've discussed informally at PTP. While listing the internal uses of a profile seems to be straight forward, I'm not sure how to track profiles that have been exported (as html) to other sites. If we can somehow solve this problem, than I think it affects how we would approach Jon's request.

I prefer option number 1 to add a new field to the profiles interface (along with Dave's suggestion of calling it description).

The reason I'm nervous about option 2 (adding a title via the event/contribution etc. interface) is because of the increasing level of abstraction that we are creating.

We already have custom data fields which are then displayed (often in a modified way) by profiles, which are then displayed (and with this feature, modifiable again) by an event or contribution page.

If a user sees how a profile is displayed on a contribution or event page, they might reasonable ask: how do I change that display? At this point, the answer could be: via the event UI, the profile UI or the custom field UI. It gets really confusing.

I'd prefer to have custom data fields be the re-usable piece (we don't want duplicate data) and then encourage people to create as many nearly identical profiles as they need. If we could clearly tell them which profiles are used where, then the head ache of maintaining a big list of profiles would be easier because people could more confidently delete profiles that they know are no longer in use.

jamie

Thanks for bringing up this discussion, Jon. Very important topic. I definitely agree that it should be possible to distinguish between front-end and back-end names for these. 

DGG: Yes, I love the price sets functionality that works this way. I second using this with profiles, even if it's limited to the uses you mentioned.

The profiles uses you mentioned that could be shown like the price set functionality are the most important to show, in my opinion.

Reserved profiles: The fact that they are reserved does add one layer of "protection" -- one is hesitant to make changes to them because of that status,  even as a newbie.

Html snippet profiles: aren't as big of a problem -- if you make a change to a profile being used on a website via html snippet, the snippet doesn't change with that profile, correct? It is frozen in time until you recopy and repaste it into your website, I think. Still a problem if you want to reuse it exactly as is, but not something that changes the moment someone changes the profile.

Batch update: Any profile can be used for batch updating that has the right fields (w/ membership fields, it will be available to make changes to membership data, and so forth).

I think the key ones are the ones used for events, contributions, and CiviCampaign stuff.

Done.

As an aside, this thread is a good example of the benefit of the open source approach, and we ended up with a solution that is better than any of us did have on their own.



X+