Make 'Add' buttons consistent across data views, simplify labels

[jameskoster]

• "Add new $post_type" is unnecessarily verbose. We can shorten this to "Add $post_type". Trac ticket: https://core.trac.wordpress.org/ticket/61219#ticket
• The add flow for Patterns should match other data views. IE a primary button in the page header. For now this button will open the same menu as the current + in the sidebar. The + button can be removed.

[afercia]

The labels are unnecessarily long. "Add new" would suffice in all cases rather than the verbose "Add New Template Part".

You may not be aware that recently in core all the 'Add new' strings have been expanded to include the what they refer to. This has been done for accessibility reasons and to be consistent with Gutenberg.

I'm not sure this should be changed. Please don't shorten to 'Add new'.

Cc @joedolson @alexsanford

[jameskoster]

@afercia couldn't we use aria labels like the action links in wp-admin tables?

[joedolson]

I'd really like to avoid using different logic in new interfaces from what we've decided to use in core. In core, we've agreed that these controls need to include context, so let's not just casually reverse that in a new interface.

Regarding the row actions, those use aria-label only because of the amount of repetition and the possible length. There are several row actions, and each one needs that context included, and the post titles could be quite a bit longer than a single word.

"Add New Template Part" is a nominal amount of text.

In row actions, we'd potentially be looking at Edit "You only live once: the history of frisbees in Wollongong" | Quick Edit "You only live once: the history of frisbees in Wollongong", etc. You get the point. Visually, that starts to take up an enormous amount of space and repetition.

Screen reader users don't necessarily have to experience that entire text; spoken text can be interrupted, unlike visual text. So a screen reader navigating through these same links only needs to hear enough to verify that the context is what they expected it to be. So that quantity of text is less of an interference for screen reader users than it is for sighted users.

[jameskoster]

At the least, now the the Patterns data view is stable, we should update the "Add new" UX there to match other data views. What do you think @oandregal @ntsekouras ?

[ntsekouras]

At the least, now the the Patterns data view is stable, we should update the "Add new" UX there to match other data views.

You mean a new add pattern + add template part button at the right top corner of the UI? Since in this page we can create two different things, should be a simple Add new(or Create new) button that opens the same dialog with the three options(including the import pattern)?

[jameskoster]

You mean a new add pattern + add template part button at the right top corner of the UI?

That's correct. A button that opens the same dialog is fine.

Since template parts and patterns are converging we should probably consolidate the template part / pattern creation modals into a single UX. Importing would be a secondary action. So in the future we'd end up with something like:

Until then perhaps the label can read "Create new..." with the ellipsis indicating subsequent action is required. What do you think?

[pablohoneyhoney]

I agree with @afercia on this #58198 (comment)

UX wise, it's better to advance the value created within the button itself.
I'm not sure how that applies across all logics and cases, since I also agree Add new template part is quite a long CTA. But maybe it's a better solution to remove new, since Add provides that additive context already.

[jameskoster]

I've updated the OP based on the discussion here to make the issue actionable.

[youknowriad]

I think the first part of this issue should be a trac ticket as it means changing the "add_new_item" label for all the core post types and the post type registration is maintained on Core.