[UX] Standardize Label and machine name usage in admin listings

[laryn]

Describe your issue or idea

In #3395 the machine name value was moved into the View name column:

I've followed that pattern in recent changes in the Paragraphs module in contrib, and I propose it would be good to use it more broadly in core and make things consistent. We'd first need to get a list of all the pages that list machine name as a separate column, but for starters here are some suggestions/questions:

• all the Manage fields pages have separate columns (on content types, user account fields, taxonomy vocabulary fields)
  

• Content types list machine name after the label but include the words "Machine name: " which could maybe be removed:
  

• On the other hand, Taxonomy vocabularies don't list the machine name at all (although it can be useful to have):
  

---

Final interfaces after the PR:

Content types list:

Taxonomy vocabularies:

Custom blocks:

Manage displays:

File types:

[klonos]

I think that this is a good idea 👍

[docwilmot]

I'm not sure we need to expose the machine name at all, myself. It makes the admin pages just a bit more techie, and I'm not sure thats a good thing. How likely are you to need to know machine names if youre not a dev writing code?

But if we're going to, I'd agree with standardizing how we do it.

[klonos]

@docwilmot the machine names are there to help devs. In most places we have them being rendered in a smaller font, which decreases prominence. IMO, the views listing does a great job at achieving that by making the actual name (admin label) bold as well.

[jenlampton]

I'm not sure we need to expose the machine name at all

Even as a non-developer, there are places where you need to know the machine name. I'd love it if this wasn't the case, but we're not quite there yet :)

It makes the admin pages just a bit more techie, and I'm not sure thats a good thing

This is a good point...

In most places we have them being rendered in a smaller font, which decreases prominence.

I was going to say that we should leave the machine name column where we have the room for it, but now that I've read this thread, I don't feel that way anymore. I think by moving it out of it's own column and into the Name/Label/Whatever column, we might make the admin interfaces more friendly (and less techie).

name (admin label) ...

@klonos you just brought to my attention that we call the Name / Title / Label / Admin Label different things in different interfaces. Is it worth cleaning that up too? (edit: see #5192)

[jenlampton]

we call the Name / Title / Label / Admin Label different things in different interfaces. Is it worth cleaning that up too?

in https://github.com/backdrop/backdrop/pull/2394/files I noticed the function theme_views_ui_view_name().

We might want to re-purpose that into a more general (system module) name + machine name theme function, and use it universally.

[klonos]

@jenlampton I know that as you mentioned in the latest design meeting, as well as previous meetings, you are in favor of modeling this after the Content type listing (/admin/structure/types), but I find the style in the Views listing page (/admin/structure/views) much more readable/scannable, as it focuses on the human name, and lowers the emphasis of the detail (machine name):

We are using the same pattern in the Layouts listing (/admin/structure/layouts), where we need to focus on the layout name, and then also provide the template used as a detail:

This pattern also works nicely in the Paragraphs listing:

[klonos]

@klonos you just brought to my attention that we call the Name / Title / Label / Admin Label different things in different interfaces. Is it worth cleaning that up too?

Yup, I think that we could squeeze that in too 😄

(edit: see #5192)

[jenlampton]

it focuses on the human name, and lowers the emphasis of the detail (machine name):

Hm, that is the same thing I was trying to achieve. The only difference between the content types table and the other tables is hat the content type page has it all in one line, and these other pages have it in two.

We could solve that problem with a class on the outer wrapper, the markup within can be identical :)

[jenlampton]

Photos below!

I've filed a PR for this that adds a new universal theme function theme_admin_info() that will display the name, machine name, and description (if provided). By incorporating all 3, I was able to update eight (8) different admin interfaces to all use the same function, and the end result makes me really happy :)

Other places to consider?

• Node types listing
• Layout listing
• File types listing
• Taxonomy vocabulary listing
• The menu listing
• The image style listing
• The text format listing
• The date format listing

Deprecated functions:

• The function theme_node_admin_overview() is marked as deprecated.
• The function theme_file_type_overview is marked as deprecated.
• The function `theme_menu_admin_overview()' is marked as deprecated.

I think we could also use this improve the views UI, but I thought that was too big of a can of worms to tackle as part of this issue.

Node types listing

Layout listing

File types listing

Taxonomy vocabulary listing

The menu listing

The image style listing

The text format listing

The date format listing

[docwilmot]

3 thumbs up. Nice.

[laryn]

Also trivial, but this issue started as a CSS/style standardization task, but has evolved to introduce a new theme function (although updating all listings to use it still sounds like a task). Should we change the label to type - feature, and move it to the 1.20 milestone?

It's not a new feature, just happens to include a new function, but if a core committer wants to add it to 1.20 instead of 1.19.4 that's fine :)

It's a bit of a grey area but I think since we're so close to 1.20 this feels like a good feature to add there: 77 comments later, I've merged into 1.x using backdrop/backdrop#3710 in backdrop/backdrop@1d2996c. Thanks for all the iterations, feedback, testing, and code review! I've tried it out in the sandbox and really like the visual consistency -- great work @klonos, @jenlampton, @BWPanda, @quicksketch, @docwilmot, and @herbdool.

[laryn]

Opening again -- where does this need to be documented?

[jenlampton]

We should add a new change record on docs.b.org announcing the addition of the theme function.

[jenlampton]

Change record is here: https://docs.backdropcms.org/change-records/theme_file_type_overview-deprecated-in-favor-of-theme_label_machine_name

[indigoxela]

Unfortunately a typo in this PR seems to cause a test regression. See #5293 for details.

[quicksketch]

Thanks for cross-referencing these issues! At this point I don't think we can revert the related PR entirely, since it's already included in 1.20.0. Let's use the new issue at #5293 to work on remedies.

[klonos]

With #5293 now merged, closing this again.