navigation: cleanup less frequently used New items

[mlutfy]

Overview

The CiviCRM menu is overwhelming, with so many options. It can be useful to "save a click" for users who know exactly what they are doing, but for most people, it can be scary. More arguments under 'comments'.

This PR removes a few low-hanging fruit:

• Contacts > New Activity (based on years of working with users, I have never seen anyone use this directly, they always go to the Contact record first) not removed, see feedback below
• Contacts > New Email (same as above)
• Contacts > New Group (usually people go to Manage Group first, check if the group already exists, and it's not like we create new groups that often either)
• Contributions > New Contribution Page (not something used often, usually go to Manage Contribution Pages first)
• Contributions > New Price Set (same, rarely used, and there is Manage Price Sets)
• Events > New Event (go to Manage Events first)
• Events > New Price Set (Manage Price Sets)
• Membership > New Membership (go to the Contact record first, rarely used directly)
• Membership > New Price Set (Manage Price Sets)

Technical Details

I rarely fiddle around here, so not sure if it's the right way, and we might need to tweak the separators.

Comments

• A lot of partners have their own extensions to automatically hide most of these items.
• This PR only impacts new installations, right?

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[sluc23]

To be honest, I've never understood why menu entries Find "Entity" are duplicated in the main Search menu and in every Entity menu as well, this goes for Memberships, Contributions, Participants and Mailings.. Activities is the only one from main Search menu that is not duplicated.. maybe a good idea to unify those too...

[colemanw]

I think we'll be getting rid of a lot of those Search menu items in the future anyway, as Basic/Advanced/Component searches are all deprecated in favor of Search Kit. We've already removed the menu item for Search Builder... #22778

[mlutfy]

On that topic, places such as "Contribution Dashboard" should merge with "Find Contributions", and the Dashboard sections would have an Action menu, with things like "Import Contributions", "Manage Contribution Pages", etc.

maybe, as an incremental next change, personally I'd be up for that. Then we could remove menu items such as:

• Contributions > Import
• Contributions > Manage Pages
• maybe more

There could be an overlap period, to let people get used to the new navigation.

I'd also flatten things such as the Accounting Batches menu. (Mailings is also awkward for its lack of clear Dashboard)

Obviously, out of scope for this PR. I'm just throwing ideas of possible next steps.

[artfulrobot]

Yes.

[petednz]

Agree with the changes outlines in the Overview

[agileware-justin]

Sorry, but I am going to vote against removing these items. Because after years of running CiviCRM training sessions, people are trained to use these items and often comment that CiviCRM's menu is easy to use because it shows common actions in the menu.

Moving this out of sight onto a Dashboard would not be as obvious and would be particularly detrimental for experienced CiviCRM users (and I know this only impacts new sites).

Prefer to keep these menu items as is:

• Contacts > New Activity - We have users that regularly create an Activity for multiple contacts. They do not go to the individual Contact first.
• Contacts > New Email - We have users that regularly use this feature to email a small collection of contacts directly.
• Contacts > New Group - This is easier for users than having to navigate to Contacts > Manage Groups > Add Group
• Contributions > New Contribution Page
• Events > New Event
• Membership > New Membership - We have users that regularly add backend memberships for contacts

I do agree with removing the multiple New Price Set menu option.

Side note, bit bummed out to see that the menu item: "Manage Tags (Categories)" is still there even though we tried a few PRs ago to standardise the terminology.

If I'm in the minority, then that's cool - we will just unpatch this bit.

[colemanw]

Side note, bit bummed out to see that the menu item: "Manage Tags (Categories)" is still there even though we tried a few PRs ago to standardise the terminology.

@jusfreeman could you please link to the relevant PR?

[totten]

(A) Re:UX -- I agree that these items feel superfluous. But then again, if I'm testing something with "New Activity"... I prefer going to "Contacts => New Activity" (because it's fewer clicks). I'm not sure what that means. I don't think we have an empirical way to measure overall usage or trade-offs. Those aren't pro/con -- just acknowledging the ambiguity.

(B) Re:Implementation -- Instead of deleting civicrm_navigation items, it may be better to toggle them to is_active=0.

There is a distinction between:

• Visually removing the menu-item from the default menu.
• Removing support (code/testing/PR-review/etc) for the functionality that it references. (IIRC, screens like "New Activity" and "New Email" have some fiddly bits so that they work in different flows.)

There are certainly many systems which ship a library of actions that are visually-disabled by default -- but easy to enable. Example: PhpStorm and its list of actions/hotkeys/menus.

Completely removing the nav-item will create a pressure to remove the functional support - because the use-case is invisible/undiscoverable/non-runnable (and people enjoy deleting code that appears non-runnable).

I guess the real question is intent.

• If the intent is to remove the functionality, then we should state that intent.
• But my read on the PR is that it only intends to change the default visual. In that case, flip is_active=0. That'll make it easier for folks like Justin and his users (who want the nav-item) and more feasible to maintain (since we can still grep/see/use the hyperlink). It would be like a PhpStorm/default-off item.

[agileware-justin]

Thanks @totten agree with your recommendation

@colemanw see #20268 - Remove the confusing mixed terminology used to describe Tags: "Tags (Categories)" and "Tag (Category)"

[demeritcowboy]

For #20268, that was just for new installs. It looks right on dmaster.demo.

[mlutfy]

Sounds good. I updated the PR to disable the menu items by default, instead of removing them. I'll have to rebase again probably for the generated SQL, but will do when the PR gets towards approval to merge.

For stats, I checked 3 weeks of data from Spark. For context, most users are not power users, and many do not use email Here are some quick numbers:

• New Activity: 10 clicks
• Advanced Search: 170 clicks
• Basic Search: 894 clicks (that's surprising me honestly, considering it's barely more useful than quicksearch, but I did notice that very few people discover quicksearch on their own).
• Manage Groups: 110 clicks
• New Group: 20 clicks

[agileware-justin]

Thanks @mlutfy

Full-text Search is one menu item we disable by default. Did you consider that one?
Custom Searches is only used as a means to access the Include/Exclude Search, which is very useful. But otherwise, this item can be disabled.

I still think that the New Activity and New Email should remain enabled, by default as they provide access to the workflow for bulk recording Activities and direct emails. A feature definitely used more than 10 times in 3 weeks across our user base.

This is one of those areas where re-thinking the entire menu system and applying those changes to both new and existing CiviCRM site would be good to keep the system and user experience consistent. This then avoids the situation whereby older sites and their users have one set of menu options and new site and their users have a different set. Providing training for CiviCRM users and trying to explain why some menu items are not available for some students, but available for others is not ideal. Documentation covering the old and new menus items, also not ideal.

I'm a big fan of consistency, standards and improving user experience.

Anyway, just my 2c.

[mlutfy]

@agileware-justin OK sounds like a good compromise (re-enable New Activity/Email).

Regarding existing sites, I'm ambivalent. Agree on consistency, and while some would no doubt welcome the cleanup, I know how small UI changes can really rattle people (I remember when the colour of the menu was changed, or some time ago when some items on the Advanced Search were shifted around, that tiny change really caused chaos with my clients).

How about:

• we merge this change for new sites only
• blog about the upcoming change
• in a few releases, if feedback is good, then we also do an upgrade function to disable the menu items on existing sites.

Edit: about the Search items, I have to admit I don't have good data about. Personally, I'd remove the Search menu completely, but that might be a bit radical.

Edit: PR updated to not disable New Activity/Email.

[agileware-justin]

@mlutfy thanks very much for listening. I am acutely aware I may be the only user voice asking for changes.

To save some time and deal with this change in a single PR, can I suggest that you include a Status Check which includes an Action Button that applies the new CiviCRM menu to the existing site - that way, a user can opt-in. Similar to how the Stripe, Status Check provides an Action Button to resolve Stripe integration issues. And I think there's at least one or two other Status Checks that do similar.

Taking this approach, then there is less need for a Blog post and no need for a follow-up PR. The other advantage is that if an existing CiviCRM site does not want to implement this change, then they can suppress the Status Check and effectively opt-out.

Whereas, if this was an upgrade step for existing sites then there is no opt-out apart from patching prior to update.

How does that sound?

[lcdservices]

Chiming in on the topic of new vs. existing --
I'd vote for not touching existing sites. Admins can (and in many case have already) tweaked the navigation bar and users are accustomed to the options present. I don't think an upgrade should forcibly modify this (except when adding a new item per new functionality). The argument for consistency is largely irrelevant -- most users have and will only touch a single CiviCRM site; they don't care that the experience might be slightly different if they use a different site.

I think these changes should only impact new installs.

[mattwire]

Just to note that I think @agileware-justin idea of an opt-in (for existing installs) via a status check is a great idea. The status checks with Stripe have worked wonders with awareness/support and informing users.

[mlutfy]

I'm reluctant about a Status Check for this. Warnings cause fatigue, and I don't think this important enough. It will be confusing too.

I mean, I've rarely seen software ask my opinion for small UI changes. Worst case, a tutorial bubble when I login (and they're annoying), but we can also do a post-upgrade message.

If removing the menu items at a later version causes concerns (I agree with Brian), I'd rather just keep the PR as-is, and just leave existing sites alone. This is super easy to manage for admins in the menu management interface.

[totten]

I agree with the current scope. Leaving existing sites as-is is easy and valid.

Some post-upgrade/transitional advice would be a value-add, but there is another little rabbit-hole on the mechanics (eg workflow on status-checks is close-but-not-quite-right for transitional advice). It's fine to go down that path, but we don't need block on it.

I'm doing a little more r-run (and will then merge).