Problem/Motivation

During the usability study, some participants, once they realised they had chosen the wrong field settings, deleted the field. They did not realise they could move back to a previous step in the workflow.

Proposed resolution

Redesign the 'wizard-style' process of creating and configuring a field.

Remaining tasks

Design the wizard workflow indicators, bearing mind the wizard indicators on the installation screen.

User interface changes

Clearer signposting for the field creation workflow

API changes

None.

Data model changes

None.

CommentFileSizeAuthor
#55 2524322-55.patch4.98 KB_utsavsharma
#55 interdiff_37-55.txt4.98 KB_utsavsharma
#43 users_deleted_a_field-2524322-37.patch-before_after_screenshot.png54.43 KBfrederickjh
#37 users_deleted_a_field-2524322-37.patch14.03 KBscott_euser
#37 interdiff-2524322-35-37.txt653 bytesscott_euser
#35 interdiff-2524322-33-35.txt3.06 KBscott_euser
#35 users_deleted_a_field-2524322-35.patch13.67 KBscott_euser
#33 interdiff-2524322-20-33.txt2.56 KBscott_euser
#33 users_deleted_a_field-2524322-33.patch10.63 KBscott_euser
#23 2524322_20_previous_button_test_result.png80.62 KBjlopezg88
#20 interdiff-2524322-12-20.txt827 bytesscott_euser
#20 drupal-core-field-settings-previous-2524322-20-D8.patch8.92 KBscott_euser
#18 users_deleted_a_field-2524322-18.patch8.95 KBpenyaskito
#18 interdiff.17-18.txt1.3 KBpenyaskito
#17 interdiff-2524322-12-17.txt778 bytesscott_euser
#17 drupal-core-field-settings-previous-2524322-17-D8.patch8.95 KBscott_euser
#14 interdiff-2524322-12-14.txt2 KBscott_euser
#14 drupal-core-field-settings-previous-2524322-14-D8.patch8.93 KBscott_euser
#12 interdiff-2524322-9-12.txt1.87 KBscott_euser
#12 drupal-core-field-settings-previous-2524322-12-D8.patch8.64 KBscott_euser
#9 drupal-core-field-settings-previous-2524322-9-D8.patch6.65 KBscott_euser
#9 field-settings-wizard.gif2.57 MBscott_euser
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tkoleary’s picture

Priority: Normal » Minor

This is minor, I think, since the result is a loss of time but the task itself is still successfully completed. We have *many* tasks where that is not the case.

yoroy’s picture

Issue tags: +Novice, +Needs design
rakesh_verma’s picture

Being a newbie, I would love to contribute. Any assistance on this issue would be admired. Please guide me a little on this one.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hitesh-jain’s picture

Assigned: Unassigned » hitesh-jain

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Sutharsan’s picture

Assigned: hitesh-jain » Unassigned
Issue tags: +Dublin2016

Unnasigning hitesh-jain, no activity for 3 month.

larskhansen’s picture

When I try an go back, to change the field type I get an error:
The machine-readable name is already in use. It must be unique.

The system needs to be able to handle this if the user is supposed to go back and change it.

scott_euser’s picture

I am not sure the installation wizard is the best idea as that has a more unique UI which custom admin themes may not have styled. I propose a simple 'Previous' button to allow the user to go back and forth between the field storage settings and field settings like in the attached gif.

I have attached a patch that does that in case you want to try it yourself. I would appreciate any feedback on the patch.

tkoleary’s picture

Status: Active » Needs review

@scott_euser

As far as I'm concerned this passes usability review. This pattern has already been used elsewhere (views modals) without confusion and seems to me to be the simplest and most direct approach.

Marked as needs review so someone will hopefully review the code.

scott_euser’s picture

Great thanks for the feedback; glad you're happy with the approach!

scott_euser’s picture

Added new test. Haven't managed to successfully run Field UI unit tests even without this change, must be something wrong with my docker setup, but hopefully testbot runs successfully. Attached updated patch with unit test and interdiff.

Status: Needs review » Needs work

The last submitted patch, 12: drupal-core-field-settings-previous-2524322-12-D8.patch, failed testing.

scott_euser’s picture

darius.restivan’s picture

Status: Needs review » Reviewed & tested by the community

Great idea, works well.

penyaskito’s picture

Great job!

+++ b/core/modules/field_ui/src/Form/FieldConfigEditForm.php
@@ -178,7 +192,25 @@ public function save(array $form, FormStateInterface $form_state) {
+    $button = $triggering_element['#value']->getUntranslatedString();
...
+    if ($button == 'Previous') {

Isn't there a better way for identifying it than the string itself? Looks hacky.

scott_euser’s picture

Thanks for the review darius.restivan and penyaskito!

I have attached a slight modification to the patch to get the form state bundle in a consistent way as the default redirect.

Regarding the string checking for 'Previous', I am not sure it is hacky. Consider the following in plain html:

<form method="post" action="">
  <select>
    <option value="optionval">Option Label</option>
  </select>
  <input type="submit" value="Previous" />
</form>

An input element like a select allows for a value and a string/label; however, the label for the submit button is both a string and a label at the same time.

I don't see a reliable way to set a fixed value yet keep the label translatable without switching from input type submit to the button element and I am not sure if that is going to work properly across all browsers and devices.

Alternatively, if I would instead use:

if ($request->get('op') == 'Previous') { }

That would work for an untranslated string. If the site translates Previous to something else, that might then fail as translating the label would be translating the value and the $request object contains the value only.

For that reason, I considered the getTriggeringElement method of $form_state as the most reliable method and the untranslated string from the triggering element as a way to be confident it wouldn't break if 'Previous' is translated to something else.

What do you think? Perhaps there is another way I am not thinking of.

penyaskito’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.3 KB
8.95 KB

We can assign an #id to the button element, this worked for me and I find it more clean.

penyaskito’s picture

Issue tags: +drupalironcamp2016

Tagging.

scott_euser’s picture

So simple! Nice one, thanks! Just removing the unneeded extra variable set, $triggering_element['#id'] == 'previous' will do fine there, more clear what the variable refers to than what I had before with the $button.

jlopezg88’s picture

Hi, I'm going to review it

scott_euser’s picture

Great, thank you!

jlopezg88’s picture

Hi, I've been testing the the patch provided at #20 against the branch 8.3.x and for me it works fine. I followed the steps below:

  • I created a new field for the Article content type.
  • At the second step I was able to see the "previous" buttton.
  • Clicking on the previous button I was redirected to the previous step successfully.
  • Editing the values and moving back again, works as well.
  • The button doesn't appear if we edit the field once that we created it.

I've attached screenshots with my test results.

I did this with @erchache2000 (https://www.drupal.org/u/erchache2000) at the #Global Sprint Weekend 2017 in Seville.

jlbellido’s picture

Issue tags: +SprintWeekend2017

Tagging this issue.

erchache2000’s picture

Status: Needs review » Reviewed & tested by the community

I revised this issue and it's ok for me.

gambry’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs usability review, +london_2017_january

I'm more than happy to RTBC this one.

However we are having a bit of discussion about the behaviour of 'Previous' button.
With the current patch if a user updates any of the "Field Settings" and click 'Previous', the changes are saved anyway.
To me this looks weird as the user didn't ask to 'Save settings' - like the other button says - but to go to the 'Previous' page, and so without saving.

Instead in a 'Previous' and 'Next' scenario it would make sense to save the settings at any step. But currently this is not the case.

I guess we need a usability review in here, to decide if:

  1. User clicks on the Previous button, form values are no changed (kept as they were when loading the step), user goes to the previous page.
  2. User clicks on the Previous button, form values are saved, including any change, user goes to the previous page.

We may also rename the 'Previous' button to something more meaningful notifying the user changes will be saved anyway, like in a Prevoius/Next multistep scenario.

Saphyel’s picture

What if we use the same that most apps does? save on field change rather than lying on click "save" button (I think this may be a big task).
So previous button can be renamed to Back...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

scott_euser’s picture

Found this stack exchange from the UX community which refers to Microsoft's UX guidelines where it says

Preserve user selections through navigation. For example, if the user makes changes, clicks Back and then Next, those changes should be preserved. Users don't expect to have to re-enter changes unless they explicitly chose to clear them.

If you are happy with that, perhaps this can go back to RTBC?

gambry’s picture

@scott_euser M$ guidelines seems to refer to a Back/Next scenario, where I do agree saving the changes after any step makes sense.
But we have Previous / Save Settings labels in here.

I'll discuss with my UX team and give you an answer today ASAP.

scott_euser’s picture

Sounds good, thank you! If need be, we can always rename it to 'Back' instead of 'Previous', but I think Microsoft is just giving 'Back' as an example.

gambry’s picture

@scott_euser the issue is not with the 'Back/Previous' label itself, the issue is it does the same action of the other one called 'Save settings' (+ switching to another page).

The response from the UX team was:

  • If both buttons save the form, they both should have (or should NOT have) the "Save *" label.
  • If the issue is with the users deleting the field instead of going back and edit, why don't we remove the 'Delete' CTA from the Edit page? It's not there on D7 and users can still delete the field from the general Manage fields board. Or may be just removing it while in wizard mode.
  • Together with the point above, another solution could be to rename the 'Save * settings' buttons to 'Next'/'Previous'/'Finish' while in wizard mode.

Thoughts?

scott_euser’s picture

Makes sense to me, updated with more clear button labels when in wizard mode & updated tests accordingly.

I think we should leave the discussion about 'Delete' in a new separate issue like 'The delete option in the create field wizard is unnecessary and confusing and should be removed' as I think it doesn't affect the problem trying to be solved in the initial issue.

Status: Needs review » Needs work

The last submitted patch, 33: users_deleted_a_field-2524322-33.patch, failed testing.

scott_euser’s picture

Status: Needs work » Needs review
FileSize
13.67 KB
3.06 KB

I'm not 100% sure about this direction; change the save button label during the wizard process has a lot of knock on effects. I think maybe #20 might still be the better way to go as it matches webform behaviour.

Status: Needs review » Needs work

The last submitted patch, 35: users_deleted_a_field-2524322-35.patch, failed testing.

scott_euser’s picture

Status: Needs work » Needs review
FileSize
653 bytes
14.03 KB

This should cover it all now, essentially a fair number of core modules create fields in wizard mode in their tests.

ifrik’s picture

Issue tags: +Needs screenshots
yoroy’s picture

Priority: Minor » Normal
Issue tags: -Needs usability review

- We couldn't find an example of this in the Views ui. We want to be sure that we have an existing example of this, otherwise we'd be introducing a whole new ui pattern, which likely needs more thought.
- How does this work when you are changing the settings of an existing field?
- And indeed, some updated before/after screenshots would be very useful

gambry’s picture

Whatever the final work is we are going to introduce a whole new ui pattern anyway. Even if this is only a simple 'Previous' button during the wizard or something bigger.

As the issue title says "Users deleted a field instead of going back to change their settings" I want to stress again the solution on #32.3:

If the issue is with the users deleting the field instead of going back and edit, why don't we remove the 'Delete' CTA from the Edit page? It's not there on D7 and users can still delete the field from the general Manage fields board. Or may be just removing it while in wizard mode.

  • We won't introduce any new UI pattern, we will actually make it more consistent with D7
  • For the user to delete the field he/she needs to go to the Manage Fields section and click on the field actions dropdown, where he/she can immediately see the ability to change the settings.
  • It is a 1 line change which does definitely fix the issue

If however the meaning of the issue is "User don't understand that is a wizard form so they can navigate back and forward to update settings" then this issue needs summary and title updates and we do need to expect a new UI pattern.

scott_euser’s picture

At the moment the latest patch makes it easy to do a find and replace to change all the wizard labels (out of wizard mode there is no change), so I think we need just a decision on what the final labels should be.

I am happy with Next/Previous/Finish for instance, or as it is now in the latest patch with Save and previous, Save and finish, but I am not a UXer.

Once a decision is made, I am happy to update the patch.

Re screenshots, please see the gif in #9: the same still applies (besides the labels).

scott_euser’s picture

The next / previous pattern is also used in Webform wizard (though I realise that is not D8 Core)

frederickjh’s picture

Before and After Patching Screenshot of the field edit page

frederickjh’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Version: 9.5.x-dev » 10.1.x-dev
Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs screenshots

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

At this time we will need a D10 version of this patch.

Also tagging for screenshots to be added to the issue summary.

_utsavsharma’s picture

Patch for 10.1.x.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

lauriii’s picture

Status: Needs work » Closed (duplicate)

The problem reported here has been addressed with a different solution in #3347291: Combine field storage and field instance forms. Moved credits from this issue there.