"Field settings" tab needs renaming to "Field storage settings"

Re-roll.

Re-roll

The save button is renamed but the tab still got the old name.

#13: drupal-rename_field_settings-1855002-13.patch queued for re-testing.

Re-roll.

Also, to #14, I'm seeing the tab correctly.

Updated the tests that were failing with the new string.

I'm not sure why some form tests got switched to "drupalPost" vs "drupalPostForm", switching them back.

Ahh... green makes me happy :)

Patch no longer applies. I'm uncertain if this is allowed under beta--it might have to wait for 8.1?

Here is a re-rolled and updated patch. I'll defer to @YesCT for comment as to inclusion within 8.0.x.

"global field" is not a term that is used anywhere..

What we have is field and field storage, so maybe "storage settings" or something like that?

Make sure to get @yched in here for his opinion.

@Berdir is right, the most accurate name for that local task is "Field storage settings" :)

UIs and strings are not frozen in the beta phase so we are good to go here in that regard.

I didn't look closely but it looked like the patch was renaming a lot more. I would suggest to start again, and just rename the local task. The other parts of the form have been refactored since the last patch anyway and is not done yet.

I agree :)

Looks good. Not sure why was it a D8MI issue, removing that tag.

Hm. This feels like exposing a bit too much about how the sausage is made to end-users, to me. Marking for UX team to provide feedback on.

@webchick: We already have "Storage settings" on admin/structure/types/manage/article/fields, it's not like we're introducing something new. If we would want to rename it, we'd have to rename both places.

Right, I realize these are inconsistently named now, but the solution might be to rename the link to match the tab, rather than rename the tab to match the link. Renaming a tab is a much bigger deal because docs need to be updated, screenshots retaken, etc.

Well the UI is unfrozen according to https://www.drupal.org/contribute/core/beta-changes so screenshots are not yet a concern?

Yes, but we don't want to introduce UX changes simply because the UX is unfrozen. The claim seems to be that users will find this confusing if we don't rename the tab, because the under-the-hood behaviour in D8 has changed. I'm simply asking for UX confirmation on that hypothesis before we force everyone to update their docs/screenshots (when the time is appropriate to do that).

@webchick, we need to keep in mind that the terminology actually changed compared to D7. Back then we had the concepts of "Field" and "Field instance" and now we have "Field storage" and "Field" instead, which means that all the docs/screenshots have to be updated anyway.

This patch is just a small step towards that :)

Let's see if @yched can better describe the reasons why this tab should be renamed. But that shouldn't stop anyone from the usability team from chiming in :)

So amateescu pinged me about this issue in IRC to talk through it.

Basically, from a user perspective (leaving out concepts like "Field vs. Field Instance" which are for developers) the thing you're trying to communicate is that in Drupal 7, changing settings on this tab would affect the field across the entire site, whether it was placed on a user or term or node. And in Drupal 8, changes only apply to the field within the current type.

The problem is, "Field storage settings" does not communicate that change. I can attest that it's a more accurate name for the tab, since that is in fact what you're setting here, but I don't personally see how the "impact vs. disruption" balances out (remember that we're talking about a 90%+ site builder UI here).

If that's what you want to communicate, really all you need to do (and actually needs to be done, since it's a bug currently) is change the following text at e.g. admin/structure/types/manage/article/fields/node.article.body/storage:

"These settings apply to the Body field everywhere it is used."

to:

"These settings apply to the Body field on any content type that it is used."

...or whatever.

Happy to hear yched's thoughts on it, but I don't feel I'm being unreasonable asking for UX review on a change that almost every site builder is going to be interacting with as a primary UI.

@webchick: I think the more important distinction than global vs not is that those settings are about how the field values are stored and can often not be changed when you already have content. For example, the length of a text field, the structure of date strings, the allowed values (you can add more, but you can not remove something that is in use), etc.

That's why it is now called field storage in the API and why we think that it is also better for the UI (conceptually, maybe we can find a better word that explains this better).

Maybe we should also rename "Edit", I don't know.

I understand the concern about the relevancy of exposing internal concepts in that UI. Always been a tough question in Field UI :-/

I think I agree with @Berdir #41 about why "storage" is relevant IMO. The fact that it's about defining a storage is the reason why some of those settings can't change after creation. It also incurs that those settings apply everywhere the field appears.

Thus "Storage settings" + the "help" text mentioning that these apply everywhere the field is used makes sense IMO.

Also agreed with @Berdir that the other tab, that contains the settings specific to that field in that bundle, currently named just "Edit", could use a rename too. "Field settings" would be fine IMO.

As part of the #SprintWeekend we at the Toronto Drupal User Group has collective agreed that this is more a UX issue and we could leave it as is since there are more pressing issues to work on.

I agree with the renaming to Storage settings here. The patch #31 no longer applies, here is a reroll.

Like @webchick said, we should emphasized in the text that the storage settings only apply to one particular entity type.

"These settings apply to the Body field on any content type that it is used."

We need a more generic sentence that works for any entity type. What about:
"These settings apply to the Body field everywhere it is used on the Foo entity type."

We will have to make a special case for nodes though, since we don't say "Node entity type" but "Content type".

I just ran into the problems and got confused by not finding storage related settings.

Honestly, "storage" is IMHO much easier to understand than "field settings", as at the end of the day the user will need to know that these are storage related settings.
Just deferring that information is a bad site builder experience.

Set to needs review again.

Field Settings is changed to Field Storage Settings, but inconsistency in the tab and button name.

Adding one more patch.

Re-rolling the patch.

This renames 'edit' to field settings as well - fixed a bunch of failures for the 'save storage settings' button. Probably new will pop up with the 'save settings' button, but will wait for the bot to com back on this.

Yay. RTBC if green

Mmm bot stuck again :/

Oops, actual fails it seems :-/

.

.

Yep, expected that, the patch in 64 was just fixing a fatal :)
Fixing the failures now

should be good *crossing fingers*

Should be fine now

damn it

#80 is green, lets do this

Looks good now, Ready to ship.

@swentel said this could immediately go back to RTBC once green.

Storage is a bit technical? If you are not familiar with the concept of "database storages" you have no idea what this is referring to.

I do definitely agree with renaming it, but I'd like us to explore alternatives. Angie is correct in stating, this is really using our internal labeling to site builders.

@Bohjan : This was already discussed above after @webchick raised the same concern 8 months ago.

@Berdir in #42, myself in #43, @scor in #45 and @dawehner in #45 all separately said basically "hmm, no better proposal, storage is really what this is about".

The current UI labels are *completely off* (as in : they lie) and thus widely confusing :-) Can we make them at least correct as a first step before RC, and then try to find better wording ? (because : finding a better wording for the current shape of the UI has been tried 8 months ago, and did not come up with anything, so do we really want to block the issue on that again ?)

Updated patch for 10.1.x address #104

interdiff 106

Fixed failed test cases issue.

interdiff with 1855002-107.patch(#109)

interdiff with #110

interdiff with 106, as #109, #110 and #111 test cases has failed.

Fixed failed test cases issue.

interdiff with #113