Follow up for #552604: Adding new fields leads to a confusing "Field settings" form

Problem/Motivation

As shown in that issue, the field settings tab (aka global settings tab) has only the global settings.
See #552604-66: Adding new fields leads to a confusing "Field settings" form point 4.
See #552604-73: Adding new fields leads to a confusing "Field settings" form

confusing-s07-fieldsettingswithcontentexisting-2012-11-27_1016.png

Proposed resolution

Make the tab name accurate.
Change field settings to Global Settings.

Remaining tasks

Discuss should "Edit" be changed also to "Field Settings" or "Instance Settings"?
Implement the change, provide patch
review patch
A screenshot with the fix would be nice.

User interface changes

Yes, renaming tabs.

API changes

No api changes anticipated.

Files: 
CommentFileSizeAuthor
#44 1855002-44.patch1.56 KBscor
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,896 pass(es).
[ View ]
#31 1855002-31.patch1.51 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,593 pass(es).
[ View ]
#25 drupal8.field-ui.module.1855002-25.patch19.17 KBAlbert Volkman
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,352 pass(es), 371 fail(s), and 11 exception(s).
[ View ]
#14 drupal-rename-field-settings-1855002-14.png61.88 KBdbazuin
#13 drupal-rename_field_settings-1855002-13.patch9.71 KBdbazuin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-rename_field_settings-1855002-13.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#9 drupal-rename_field_settings-1855002-9.patch9.56 KBAlbert Volkman
FAILED: [[SimpleTest]]: [MySQL] 57,932 pass(es), 135 fail(s), and 4 exception(s).
[ View ]
#4 drupal-rename_field_settings-1855002-4.patch14.7 KBYesCT
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-rename_field_settings-1855002-4.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#4 interdiff-1-4.txt3.66 KBYesCT
#1 drupal-rename_field_settings-1855002-1.patch13.06 KBYesCT
FAILED: [[SimpleTest]]: [MySQL] 50,026 pass(es), 36 fail(s), and 5 exception(s).
[ View ]
#1 globalsettings-s01-2012-12-29_0334.png105.66 KBYesCT

Comments

YesCT’s picture

Status:Active» Needs review
Issue tags:-Needs issue summary update
StatusFileSize
new105.66 KB
new13.06 KB
FAILED: [[SimpleTest]]: [MySQL] 50,026 pass(es), 36 fail(s), and 5 exception(s).
[ View ]

changes name of tag from Field settings to Global settings, and the url from field-settings to global-settings. Also updates tests.

There are some failures I think. Lets see exactly which ones.

globalsettings-s01-2012-12-29_0334.png

Status:Needs review» Needs work

The last submitted patch, drupal-rename_field_settings-1855002-1.patch, failed testing.

YesCT’s picture

Issue tags:-API change
YesCT’s picture

Status:Needs work» Needs review
StatusFileSize
new3.66 KB
new14.7 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-rename_field_settings-1855002-4.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

fix tests. Not sure why the Body assert needed to be changed.

Probably can change the name of the button to something more simple like "Save" eventually.

Status:Needs review» Needs work
Issue tags:-Usability, -Fields in Core, -string freeze, -D8MI

The last submitted patch, drupal-rename_field_settings-1855002-4.patch, failed testing.

YesCT’s picture

Status:Needs work» Needs review

Status:Needs review» Needs work
Issue tags:+Usability, +Fields in Core, +string freeze, +D8MI

The last submitted patch, drupal-rename_field_settings-1855002-4.patch, failed testing.

jair’s picture

Issue tags:+Needs reroll
Albert Volkman’s picture

Status:Needs work» Needs review
StatusFileSize
new9.56 KB
FAILED: [[SimpleTest]]: [MySQL] 57,932 pass(es), 135 fail(s), and 4 exception(s).
[ View ]

Re-roll.

Status:Needs review» Needs work

The last submitted patch, drupal-rename_field_settings-1855002-9.patch, failed testing.

YesCT’s picture

dbazuin’s picture

Assigned:Unassigned» dbazuin
dbazuin’s picture

Status:Needs work» Needs review
Issue tags:-Usability, -Needs reroll
StatusFileSize
new9.71 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-rename_field_settings-1855002-13.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-roll

dbazuin’s picture

StatusFileSize
new61.88 KB

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

drupal-rename-field-settings-1855002-14

dbazuin’s picture

Assigned:dbazuin» Unassigned
Status:Needs review» Needs work
Fabianx’s picture

Status:Needs work» Needs review
Issue tags:-Fields in Core, -string freeze, -D8MI

Status:Needs review» Needs work
Issue tags:+Fields in Core, +string freeze, +D8MI

The last submitted patch, drupal-rename_field_settings-1855002-13.patch, failed testing.

Albert Volkman’s picture

Status:Needs work» Needs review
StatusFileSize
new43.31 KB
new9.71 KB
FAILED: [[SimpleTest]]: [MySQL] 58,444 pass(es), 190 fail(s), and 58 exception(s).
[ View ]

Re-roll.

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

Screen Shot 2013-10-01 at 11.29.05 AM.png

Status:Needs review» Needs work

The last submitted patch, drupal8.field-ui.module.1855002-18.patch, failed testing.

Albert Volkman’s picture

Status:Needs work» Needs review
StatusFileSize
new14.47 KB
FAILED: [[SimpleTest]]: [MySQL] 58,647 pass(es), 49 fail(s), and 51 exception(s).
[ View ]

Updated the tests that were failing with the new string.

Status:Needs review» Needs work

The last submitted patch, drupal8.field-ui.module.1855002-20.patch, failed testing.

Albert Volkman’s picture

Status:Needs work» Needs review
StatusFileSize
new6.63 KB
new14.42 KB
PASSED: [[SimpleTest]]: [MySQL] 58,328 pass(es).
[ View ]

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

Albert Volkman’s picture

Ahh... green makes me happy :)

jhedstrom’s picture

Issue summary:View changes
Status:Needs review» Needs work
Issue tags:+Needs reroll

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

Albert Volkman’s picture

StatusFileSize
new19.17 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,352 pass(es), 371 fail(s), and 11 exception(s).
[ View ]

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

Albert Volkman’s picture

Status:Needs work» Needs review
Berdir’s picture

"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.

Status:Needs review» Needs work

The last submitted patch, 25: drupal8.field-ui.module.1855002-25.patch, failed testing.

amateescu’s picture

Title:Field Settings tab needs renaming to Global Settings (follow-up to Adding new fields leads to a confusing "Field settings" form)» "Field settings" tab needs renaming to "Field storage settings"
Issue tags:-Fields in Core, -string freeze

@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.

Berdir’s picture

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.

amateescu’s picture

Status:Needs work» Needs review
Issue tags:-Needs reroll
StatusFileSize
new1.51 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,593 pass(es).
[ View ]

I agree :)

Gábor Hojtsy’s picture

Status:Needs review» Reviewed & tested by the community
Issue tags:-D8MI

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

webchick’s picture

Status:Reviewed & tested by the community» Needs review
Issue tags:+Usability

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.

Berdir’s picture

@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.

webchick’s picture

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.

Gábor Hojtsy’s picture

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

webchick’s picture

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).

amateescu’s picture

@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 :)

amateescu’s picture

Assigned:Unassigned» yched

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 :)

webchick’s picture

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.

Berdir’s picture

@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.

yched’s picture

Assigned:yched» Unassigned

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.

Pierre_M’s picture

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.

scor’s picture

Status:Needs review» Needs work
StatusFileSize
new1.56 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,896 pass(es).
[ View ]

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".

dawehner’s picture

Status:Needs work» Needs review

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.