The 'Edit', 'Manage display' and 'Manage form display' tabs were hard to understand

+1 for merging "Edit" and "Manage fields".

The tabs could then have these labels:

• Fields and settings
• Form display
• Data display

"content display" would be more universally accessible

We could clarify Form display by making it "Edit-form display"

Sounds good to me.

Have we now decided on only renaming the tabs? An which text, the one from the issue description?

I think the labels on the tabs should be made consistent with the rest of the admin UI - specifically:

• "Manage display should be "Manage view modes".
• "Manage form display" should be "Manage form modes".

With the inclusion of "Structure | Display modes" in core, and the fact that "view modes" and "form modes" are types of "display modes", we should ensure that the admin UI is consistent with this nomenclature.

Not to open a can of worms, but I'd love to see this extend into the Views UI - "Show: Content" really should be "Show: View mode"...

I appreciate the discussion above to use "Form display" and "Data display" - but if we change it in one place, it really needs to be consistent across the admin UI.

-mike

@ultimike

"Manage display should be "Manage view modes".
"Manage form display" should be "Manage form modes".

+1 one to that. Using the same language allows users to connect the dots. The only thing I'd add would be why not remove "manage" altogether since it's really redundant and just adds cruft (what else are you going to do? Just look at them?) but that might need to be another issue since "manage' is used elsewhere.

Created child issue: #2677102: Word Manage at beginning of multiple admin page names make them hard to distinguish.

Why do we have the whole "modes" part? Seems kinda useless information.

Would this be too sparse?

@yoroy

Not at all. I think that's a huge improvement

I think @yoroy's suggestion is definitely better than what we currently have.

But, I also really like the idea of "linking" the nomenclature between the tabs and "Structure | Display modes"...

-mike

@yoroy This would be amazing!

@ultimike

Really there should not be a display modes menu item in Structure at all, display modes are a sub-category of content types and it's through the content type that the user should go to edit them.

I understand that changing that is a different issue but let's not use one bad pattern to reinforce another.

thanks @tkoleary for saying what I wanted to say as well :)

@yoroy

No problem :)

I like this, less is more.

Should we extend this to the Operations links? I think it is clear what each links means but the word 'Operations' now makes little sense.

Another note: When this is implemented we should check if these strings require a context.

Several hook_help texts for core modules refer to the tabs "Edit", "Manage display" and "Manage form display" and need to be changed as part of these changes as well.

This includes in any case the Field UI module and all the modules providing fields.

@Sutharsan

Yes, in this context operations doesn't make sense. It should be something like "configure", "configuration pages", or "configuration links"

Personally I prefer simply "configure", mentally the user will complete the phrase eg. "configure fields", "configure form" etc.

Wow - less is more. I really like "Fields", "Form", and "Display".

That being said, one of the other things that we can accomplish here is bringing consistency across various parts of the admin UI. One issue is that core currently uses:

• Display modes
• Form modes
• View modes

According to that logic, we should be using "Fields", "Form", and "View" - which doesn't feel exactly proper... (but I don't have anything better to offer at the moment...)

One other part that sticks out to me is in Views - as I mentioned in comment 5 above, "Show: content" should be changed to be consistent with these changes ("Show: view mode").

This is turning into a can of worms, but the consistency it will bring will be welcome.

-mike

I'm also very much in favour of consistency, and therefore sticking to to "Fields", "Form", and "View" makes sense.

"Fields" is also what the user is adding, so it would be confusing if that tab is called something else.
And calling the Views tab "Content" might be clearer if you look at a content type - but these tabs are used for all fieldable entity including taxonomy terms, users and contact forms. Using "Content" to describe the display of a user account for example would again be confusing.

Would it be clearer if "Edit" would be a noun instead of a verb as well, so that the tab titles would not require "manage"?
Especially using "Edit" and "Display" together makes it unclear on whether "display" is about displaying the entity or managing its display.

@ifrik

I'm also very much in favour of consistency, and therefore sticking to to "Fields", "Form", and "View" makes sense.

I think we're confusing the tactics and constraints with goals. The problem here is disambiguating the content type UI tabs so they can be more clearly differentiated, quickly scanned and easily remembered. The tactic we are proposing is shortening tab names by removing repeated words (manage and display).

Maintaining consistency is a constraint. The solution proposed by Yoroy does not introduce any new inconsistencies so we've met that constraint. The fact that there are existing naming inconsistencies—while it may offend our aesthetic sensibilities—is only a bug if it has caused confusion in usability tests.

@ultimike While I agree that "view modes" is inconsistent with the proposed "display" tab (not to mention causing confusion with "views") and I would definitely agree with changing it to "display modes" but you need to open another issue for that, provided it's a known usability problem.

On the question of Views, that also probably needs to be another issue because as soon as you change "view modes" to "display modes" now you have a configuration option in views to choose a "display mode" but what you are looking at is a Views "display", yet another ambiguity. I suppose we could differentiate them by changing "Displays" in views to "Views modes" :/ and again, this needs another issue.

@ifrik

using "Edit" and "Display" together makes it unclear on whether "display" is about displaying the entity or managing its display.

This has also bothered and at times confused me but I'm only one data point and I'd want to see evidence that it's a problem for others.

By pure logic it would be: "type", "fields", "form", "display", all nouns referring to the object being edited, but that seems wrong since "type" really adds no meaning. Other possibilities would be "settings" the generic noun describing the options, or "Information", but the one I prefer would be "Defaults" which would make it:

Defaults | Fields | Form | Display | Translation

"Defaults" provides much more "link scent" to the name than "edit" or the others because what you mainly do in this tab is change the default options for content of this type. But again we'd need to test it.

I'd love to see us scope this a bit better and move it forward. It would be such a nice cleanup and showcase of how we *can* simplify our language without losing meaning.

An initial patch to try it out and see where it might break would be a good next step.

Maybe somebody could look at this during DevDays Milan?

I will have a go at implementing @tkoleary's suggestions at the end of #23.

First pass at a patch, to see if it passes the tests. Changing 'Edit' to 'Defaults' was the one that required the most judgement calls, since 'Edit' appears in so many other contexts... Even if the chosen label texts are ultimately changed again, hopefully this will save the need to look through all the occurrences of 'Edit' and "Edit" in core again...?

Re-rolled.

I think the short "Fields", "Form" and "Display" as tabs and operations work well. Shortening the tabs and operation but leaving the page title long also gives us both an short label to click, and a longer phrase with a verb, without duplication.

However "Defaults" confuses me. If there are Defaults then I expect that there is some variation of it somewhere as well.
What that page contains is usually some configuration related to the entity (a content type, a vocabulary, user accounts), starting with simply a name and description, to language settings, publication settings etc.
Maybe we can simply call that tab "Configuration"?

In all honesty; I preferred 'Configuration' too! For vocabularies, and dates, I didn't change the word 'Edit' for that kind of reasoning. So, if we make it 'Configuration', I've got a few more places to change...

@martin_q

Quoting myself with emphasis

"Defaults" provides much more "link scent" to the name than "edit" or the others because what you mainly do in this tab is change the default options for content of this type. But again we'd need to test it.

This patch should not go forward until someone tests it on actual users. If we continue bikeshedding text all we are doing is making guesses and assumptions.

For example in some quick hallway testing on users with little prior Drupal experience trying to understand "form" it became clear that users did not understand that they are using this interface to build the content creation interface. When explained the answer was "Wow, I didn't know you could do that". This is a classic curse of knowledge effect problem. We know that this is possible and therefore we assume others do as well.

In this case users thought that "form" was for creating a webform as part of the content type. Alternates suggested when the actual meaning was explained were: "Interface", "Editing page","Content editing page","Backend interface" or "Admin page"

Defaults was also not clear to users who confused them with default content. When explained alternate suggestions were "settings","default settings" and "Basic settings"

@tkoleary

This patch should not go forward until someone tests it on actual users. If we continue bikeshedding text all we are doing is making guesses and assumptions.

You make excellent points. Seems my work here for the moment is done, as here at DevDaysMilan I don't have access to the kind of users you need to test the results on. I hope the patch is of use to save someone doing all the legwork again of identifying all the places that need a change - with the caveat that I left a couple of entity types' 'Edit' text unchanged because 'Defaults' definitely seemed wrong. I can add them back in for completeness if required?

Great discussion, so glad this is moving forward.

I agree that some real user testing is necessary (as a next step), but for this user (pointing at myself), I much prefer either "Settings" or "Configuration" over "Defaults"...

-mike

The issue reportst that usability testing has shown that the labels for tabs B, C and D are unclear and now we're argueing over the label for tab A…

We could also decide to not change that one tab and leave it to "Edit", it's not like that was the one that needed to change anyway.

@yoroy

We could also decide to not change that one tab and leave it to "Edit", it's not like that was the one that needed to change anyway.

Good point.

OK, I'll reroll without the changes to 'Edit'.

I've noticed that it's not only the tabs that get changed, but also the Page titles and the Operations.

The dropdown with operations are currently links that lead users to do something. These should certainly stay verbs - not a mix of 3 verbs (edit, delete, translate), 2 nouns (fields, form) and one that could be either (display).

Having the tab titles short is great. It just allows users to switch between the different pages fast, and that doesn't need to be a duplication of the field title. So Manage form as a title - and just Fields, Form, and Display would be a useful way of using both.

Shortening the page titles to just "Field", "Form" etc means that we have an ever growing number of pages with so generic page names that it becomes more and more difficult to understand where you are in the page.

Alternatively, there is also an issue on whether or not to mention the name of an entity bundle in the title again (such as Manage Article fields, or Manage Content type article fields) - I that case long page titles and short tab titles would work.

To cut it short: I don't think it makes sense to continue with this without user testing (both new users and site builders) to compare different options.

Alternatively, there is also an issue on whether or not to mention the name of an entity bundle in the title again (such as Manage Article fields, or Manage Content type article fields) - I that case long page titles and short tab titles would work.

This is a really good point and one that has also puzzled me. Tabs, as the user understands them, are for navigation around a "section" of the content, the fact that the page title changes as you switch tabs is an anti-pattern. The page title should always be "Edit (or perhaps 'configure') content type [name of the content type]"

To cut it short: I don't think it makes sense to continue with this without user testing (both new users and site builders) to compare different options.

I think that in order to be tested we might need to agree on a proposal, or a few different variants, and implement the corresponding patch or patches. And even if we don't need patches for testing, we would need something specific to test

Summarizing what I've read so far:

• The tabs would change to: Settings | Fields | Form | Display | Translation
• We should keep the same main title across tabs: Edit [name of the content type]
• As a consecuence of all the tab labels being nouns and not verbs, there would be a problem with the dropbox of Operations, which requires using verbs. We don't have a clear proposal for this yet.

In my opinion we already have "delete" as operation, so changing Operations to Configure wouldn't completely solve the problem. I would move forward by just converting the nouns to verbs options within the Operations context, adding "Edit" to the noun:

• Edit settings
• Edit fields
• Edit form
• Edit display
• Delete

Please let me know your thoughts on this to see if we can set a specific proposal or a few variants to move to the User testing phase.

+1 to #43.

-mike

@juanolalla

I would move forward by just converting the nouns to verbs options within the Operations context, adding "Edit" to the noun:

Good point but rather than having to deal with form altering and the incur the penalty of adding interface translation complexity, what if we signify 'edit' visually by prepending either pencil or gear icon to each drop-button link using the :before pseudo-element?

We don't do this anywhere else, lets avoid doing any repetitions as one-off.

The solution here should not be to add more nouns, but about using more clear labels for the functionality - in some cases that might just be removing the word "Manage" so the important parts standout more.

I've been looking at the verbs being used in the UI (in 8.3) in general to get a bigger picture.

For all the quick links the verb is either "Configure" or "Edit" - but no clear line of what is used when (Configure block, edit view).
As a non-native English speaker I would expect "Edit" to be editing content, while Configure refers to settings - anything that can be exported as configuration. (So it should be Configure view, but that's a different issue.)

So one thing we could do, is to get rid of "Manage" and use "Configure" instead, to make the UI text more consistent; giving users a better idea of what to expect based on experience with other parts of their website.
I don't think "manage" is used anywhere else besides in something like "Configuration management".

Secondly: If we have a longer page title (no matter whether that's "Manage form" or anything else) then the tab titles can - and should be - be shorter. Tab titles are for moving between different pages, not for explaining what the pages do.
Any multilingual form already ends up with 5 tabs, and in many languages the verb in the tab title is so much longer then the English, that you end up with collapsed tabs - which defeats the purpose of the tabs.
See for example the screenshot for the Manage fields page in German.

Tab titles are for moving between different pages, not for explaining what the pages do.

I do think tab titles should largely communicate what pages are, in this case they still do.

Should we just start this change?

Maybe we can think of having also an icon per tab?
I have no proposal for it but think this could help.

Sorry, didn't realise I still had this assigned to me, which I did temporarily at Dev Days Milan in 2016. I'm not able to work on it any more, even if it was still a live issue, which I suspect it is not... :-S