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.
Comment | File | Size | Author |
---|---|---|---|
#55 | 2524322-55.patch | 4.98 KB | _utsavsharma |
#55 | interdiff_37-55.txt | 4.98 KB | _utsavsharma |
#43 | users_deleted_a_field-2524322-37.patch-before_after_screenshot.png | 54.43 KB | frederickjh |
#37 | users_deleted_a_field-2524322-37.patch | 14.03 KB | scott_euser |
#37 | interdiff-2524322-35-37.txt | 653 bytes | scott_euser |
Comments
Comment #1
tkoleary CreditAttribution: tkoleary at Acquia commentedThis 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.
Comment #2
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #3
rakesh_verma CreditAttribution: rakesh_verma commentedBeing a newbie, I would love to contribute. Any assistance on this issue would be admired. Please guide me a little on this one.
Comment #5
hitesh-jain CreditAttribution: hitesh-jain at Acquia commentedComment #7
Sutharsan CreditAttribution: Sutharsan commentedUnnasigning hitesh-jain, no activity for 3 month.
Comment #8
larskhansen CreditAttribution: larskhansen at DBC commentedWhen 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.
Comment #9
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedI 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.
Comment #10
tkoleary CreditAttribution: tkoleary at Acquia commented@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.
Comment #11
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedGreat thanks for the feedback; glad you're happy with the approach!
Comment #12
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedAdded 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.
Comment #14
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedComment #15
darius.restivan CreditAttribution: darius.restivan as a volunteer commentedGreat idea, works well.
Comment #16
penyaskitoGreat job!
Isn't there a better way for identifying it than the string itself? Looks hacky.
Comment #17
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedThanks 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:
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:
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.
Comment #18
penyaskitoWe can assign an #id to the button element, this worked for me and I find it more clean.
Comment #19
penyaskitoTagging.
Comment #20
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedSo 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
.Comment #21
jlopezg88 CreditAttribution: jlopezg88 as a volunteer commentedHi, I'm going to review it
Comment #22
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedGreat, thank you!
Comment #23
jlopezg88 CreditAttribution: jlopezg88 as a volunteer commentedHi, 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'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.
Comment #24
jlbellidoTagging this issue.
Comment #25
erchache2000 CreditAttribution: erchache2000 as a volunteer commentedI revised this issue and it's ok for me.
Comment #26
gambryI'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:
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.
Comment #27
Saphyel CreditAttribution: Saphyel as a volunteer commentedWhat 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...
Comment #29
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedFound this stack exchange from the UX community which refers to Microsoft's UX guidelines where it says
If you are happy with that, perhaps this can go back to RTBC?
Comment #30
gambry@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.
Comment #31
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedSounds 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.
Comment #32
gambry@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:
Thoughts?
Comment #33
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedMakes 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.
Comment #35
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedI'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.
Comment #37
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedThis should cover it all now, essentially a fair number of core modules create fields in wizard mode in their tests.
Comment #38
ifrikComment #39
yoroy CreditAttribution: yoroy at Roy Scholten commented- 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
Comment #40
gambryWhatever 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 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.
Comment #41
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedAt 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).
Comment #42
scott_euser CreditAttribution: scott_euser as a volunteer and at Fat Beehive commentedThe next / previous pattern is also used in Webform wizard (though I realise that is not D8 Core)
Comment #43
frederickjhBefore and After Patching Screenshot of the field edit page
Comment #44
frederickjhComment #54
smustgrave CreditAttribution: smustgrave at Mobomo commentedThis 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.
Comment #55
_utsavsharma CreditAttribution: _utsavsharma at OpenSense Labs for DrupalFit commentedPatch for 10.1.x.
Comment #57
lauriiiThe 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.