Should we change behavior on profile titles on Contribution/Event/etc pages?

[JonGold]

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.

[petednz]

Hi Jon - yes I have hit this issue - though the other way round - ie we want a slightly different profile in case X than case Y - but we want to have the same Label - mostly in cases where we are using multisite

If the profile is being used standalone then option 2 wont suffice will it - so you might actually need both 1 and 2

[Dave Greenberg]

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.

[xavier]

Hi Jon,

We did create  an issue about something similar I think http://issues.civicrm.org/jira/browse/CRM-9845

The suggested solution was like your 1)

I think your suggestion 2) is covering more grounds, but I am wondering if the title is the only field that the user will want to change between the same profile used in different places.
Ie. isn't it likely that the pre/post are as likely to be changed as the title for instance?

Moreover, it increases the risk of seeing a profile as "mine" and specific for an event or donation, even so it's shared with other events/donations....

ie if I can set as the title "what is the address to use for your donation receipt?" and it's the same profile as the one for the user registration, Joe admin will add/remove a field for the address donation without realizing it's used elsewhere.

Not saying the problem isn't already there, but I think it will exacerbate it.

I'm working on making it easier to update profiles (inline editing), and I'm inclined to think the main issue isn't having (almost) duplicates profiles, but more about not being able to easily have their context  info (ie. it has been created in 2008 by John Doe, it is used in event X and donation page Y and Z).  So you know what you impact if you decide to change it

Anyway, whatever way you want to go, either a new field on the profile or on the civicrm_uf_join is an improvement. The risk with the later is that it's becoming even harder to know how/where a given profile is used IMO.

Can I assign CRM-9845 to you or do you have already another issue and I'll mark it as duplicate?

X+

[JonGold]

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?

[xavier]

Re the second part.

Part of the problems we have is that for some use case (eg. survey) there is a 1-1 relationship between the survey and the profile, ie. you got a list of "sharable" profiles that will never be used by more than one.

Between being able to put a name that is different from the label (eg. so you can explicitly mention 'survey XY for our Montana constituents") without having it leaked to the end user that will see the clean "What are your main priorities for the elections this spring" and the new UI  that makes editing the profile part of the survey,  it isn't a problem anymore to have a lots of specific profiles.

Consider the hidden profile a rejected idea that solve a problem that isn't one anymore.

About sharing profiles, you might be luckier than I am, but on my side, unless you really put it on their face that they might be destroying another event/contrib... users will be super happy to put a new field and make it mandatory, without wondering who else might get their forms destroyed by the changes.

To their defense, it's really hard today to see which survey is used currently, or if it is used at all
X+

[jamie]

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

[Dave Greenberg]

+ 1 for showing users the places that a profile is being used - which we already do with Price Sets (see attached). HOWEVER this would probably be limited to showing profiles that are listed in the uf_join table which covers:
- profiles in event registration
- profiles in online contribution pages
- profiles in CMS user registration / my account forms

I doesn't include:
- profiles where html snippet has been copied and pasted into some web page
- "standalone" profile forms linked via CMS content / menus
- profiles used for batch update
- reserved profiles used for "system" screens (e.g. New Individual, Batch Contribution Entry etc.)

Not sure there is any way to "capture" those usages.

[reperry]

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.

[JonGold]

After hearing various folks' points, my thinking has changed on this.

I think that the folks saying that we shouldn't try to focus on profile re-use but rather on making it easier to manage a large number of profiles are correct.  I also think the point about over-abstraction and having too many places a single value could change are correct.  So I think this is the approach to take:
1) Add a "Description" field to the profile, which is for internal use.
2) Replicate the functionality dgg points out for price sets, where you can see where each one is used.

Thanks for everyone who's chimed in and given thoughts!  Xavier, you should feel free to reassign that ticket 9845 to me.

[xavier]

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+