Make it easier to enter multiple values to fields allowing unlimited values

I like the proposed solution, but I'd also be interested in taking it a bit farther and use the paste event to look for newlines/pipes and parse the contents into multiple entries so pasting something into a single field that matches the old format will automatically create multiple entires. This could also be a followup since the current proposed solution is also an improvement that would not conflict with the expanded pasting functionality.

As far as the current proposed solution, there's a focus management question I'd want looked into. Were this implemented, pressing enter would focus the next empty item, but when the "add another item" button is pressed. This should probably be consistent, and my UX take is having the new empty field be focused in both cases, but this would require a bit more research to ensure that is not too opinionated/confusing, etc.

I like the proposed solution, but I'd also be interested in taking it a bit farther and use the paste event to look for newlines/pipes and parse the contents into multiple entries so pasting something into a single field that matches the old format will automatically create multiple entires. This could also be a followup since the current proposed solution is also an improvement that would not conflict with the expanded pasting functionality.

This is a great idea but I agree it should be a separate issue. What I proposed initially wouldn't necessarily have to be specific to the list options but could be useful for other uses of the same pattern.

This appeared to introduce an accessibility issue. When I tab to the machine name link and press enter it now skips to the next item but I can't edit the machine name now with just a keyboard.

As far as workflow goes though seems odd the machine name link is what generates the next line. Would expect it to be the main text field.

The latest commits resolves the problem mentioned in #7.So moving it back to needs review.

Still seeing accessibility issues

When I tab to the "edit" link I can't backtab anymore unless I hit enter to edit the machine name
Then when I do backtab back to the "Title" field and press enter it doesn't auto generate the field anymore.

I like the improvement, but in my local installation it was really slow to add the new item (~7sec) and it can be confusing. I’d say that showing the “Add another button” pressed is a really good indicator as a clue to what’s going on. I wish this "Please wait..." could be customized to something like "Please wait, a new item item is being created" to improve the context, but without tests I'd say the button is enough (what's done already).

Something that I do think would need some refinement though is the scroll/focus when you have a really long list: when you add a new item it scrolls up to the top, but it should stay right where you're working at the bottom. Here's an example:

https://www.drupal.org/docs/develop/user-interface-standards/interface-text → says to please not use please in UI copy :)

I'm wondering how would we rewrite that? Would that be just wait...?

Something that's probably worth noting is that the "Please wait..." text displayed in #14 is not something specifically added by this patch. It has been the default ajax loading text at least since 2009. Maybe we should open a follow-up to discuss changing that?

Looks like 📌 Remove "Please" from the codebase Fixed is proposing to change this to "Processing..."

I changed the UI text to Adding a new item....

I can't reproduce #14. I'm wondering if you had the most recent version of the MR and had cleared caches? There's even test coverage in the MR that should confirm the focus handling works.

Just reinstalled everything and I can't reproduce #14 anymore neither.

So +1 on a UX perspective, specially having replaced "Please wait..." with "Adding a new item...".

Verified the accessibility issue I was noticing before is resolved.

I'm able to tab though everything, back and forth
Also verified I can hit enter on the "Edit" link which opens the machine name field but pressing again adds a new line, which is a nice feature.

I'm assuming the last push will work so going to mark.

Manually tested this and it works well. However it's not clear that this is going to happen; I usually expect that pressing Enter submits the form and so avoid doing that. Should we add some indicator to the user that they can press Enter to add a new item, perhaps on the "Add another item" button?

The JavaScript approach is good, but I found some spots where we can reduce (possibly eliminate) the jQuery use.

omkar.podey → made their first commit to this issue’s fork.

For the open threads.

Really like the idea.

I did some manual testing and it worked when I used the enter key to add another item. But when I tabbed to "Add another item" button and then hit enter on that button it actually created 2 items instead of 1. I confirmed this does not happen in 11.x.

I assuming this is because the enter triggers the new behavior and the existing behavior. A current user who mainly uses keyboard navigation now would likely tab to "Add another item" like this. They would probably keep doing this because they would have no indication of the new "enter" method inside the option textbox.

Attaching screen recording to show this behavior

This probably means there is not a test for this using tab navigation like this or the test coverage is broken.

It would also be good if some manually tested this to see if the see the same thing I am seeing.

The latest code resolves the issue reported in #33 📌 Make it easier to enter multiple values to fields allowing unlimited values Fixed .I'm attaching the screen recording demonstrating that the issue is now resolved.

1. @Utkarsh_33 sorry when I started to review this issue and the new test I didn't first take a look at the existing test coverage \Drupal\Tests\options\FunctionalJavascript\OptionsFieldUITest::testOptionsAllowedValues. I started to update that method and realized we could probably just add the test coverage there.

   I think this is better because if someone is in the future is trying to assess the test coverage or how this form is suppose to behave they will have one place to look. We should not break up the test coverage just by the order we added functionality but in how it makes logically if a developer were to look at the test and not be aware of this current issue. This method already had a data provider to test the 3 different types of list so I just add coverage for the new functionality there. I also add test coverage new functionality there. I also added test coverage for some of the existing functionality that was not covered to ensure we did break existing functionality.

   I don't think we need \Drupal\Tests\options\FunctionalJavascript\OptionsFieldUITest::testShiftFocusFeature any more but someone could double check and make it is not covering anything that testOptionsAllowedValues is not also covering. I have not removed it yet.

2. I tagged with Needs issue summary update because I think we need more in the "Proposed Solution". I doesn't completely detail how we want this feature to work.

   For instance if you have multiple options and you are focused on the first row and you press enter on the last input in the row it creates a new row at the end of the list and move your focus there. I am not sure if this was thought of intentionally from UX perspective or since the javascript just does "mousedown" event on the "Add another item" did it just happen to work this way.

   Previously in very long list if a user was on the first row they would have had to scroll or tab to the bottom to get to the "Add another item" so in that case it would probably make sense to see a new item show up at the end and be focused there.

   but of course if the user is just pressing enter while focused on the first row element they have no idea that behind the scenes the JS is clicking "Add another item" at the bottom of the list. they may just expect a new row to be added below the row they are currently(which is how behaves if you are at the end of the list.

3. Another thing we might want to consider is how we want this to behave if you press enter the but the items in current row are not actually filled out.

   for instance say on integer list in the first row:
   a. the user fills out the "name"
   b. presses "enter" and is moved to the "value" input
   c. the user accidently presses enter again before they fill out value
   d. Now they are on the new row on "name" but they still have to fill out "value" in previous row.
   e. If they are using keyboard navigation they have to back tab 3 times to get to "value" in the previous row.

   In this scenario what is the purpose of creating a new row and moving the user to it if they have not entered a needed value on the element they are currently on. It doesn't seem to be making things "easier" for them as is the intention of this issue.

   If the user is interacting with the "Add another item" button directly it is easier to decide we should just always create the new row if the user want create many empty rows that is up to them.

   but when they are focused on an empty element and the press "enter" we don't actually know their intention was create a new row and in this case it seems creating the new row when they have not filled the current element is not really making things easier for them as they now have to go back to fill it out.

   If we want to stick with the current functionality that is fine but I think this is the kind of stuff we should add to the summary so we are clear on how it is supposed to behave.

   Another option would be to just not make a new row if the currently focused element is empty and maybe not move focus if you are an empty name instead of moving to the key.

For the IS update and to address the fantastic review from #33

UPdated the summary

I totally agree with @tedbow with 33.2 and 33.3: if you are in the first row, with several unfilled rows below, and you click enter and go to the last row feels like an strange behaviour. It takes the focus away (it moves you to the new row created at the end) and it’s not what I would expect (which is jumping to the next unfilled row). Plus it might be all happenning outside your viewport.
And agree again that pressing enter in an empty row: if you go ahead and greate 5 empty rows (because for whatever reason you want to see all of the fields at the same time), when you press enter after filling the first one you will jump to a sixth row at the end leaving empty those previous rows.

Small recording of this:

So if had to assume here it would be that If I press enter a new row is NOT created if:


• I’m in an empty row
• There are already empty rows

Anyway, I feel this would be the classic place where a small user test would help. I'll try to add this to the 2 sidebar prototype user tests I'm doing next week.

Discussed with @ckrina and we are still aligned that the proposed solution is what we'd like to implement at this point. We think that the experience should be consistent regardless of whether the inputs have value or not.

I want to highlight that we don't have to address all of the keyboard navigation issues here, the main goal is to improve the experience of adding a pre-defined, potentially long list of options to a field configuration.

Moving back to needs work because the proposed solution is not currently implemented in the MR so we'll have to figure out how to get back the earlier behavior.

The remaining task on this issue is that we need to figure out that should we keep the test testShiftFocusFeature()because i think the test that @tedbow are sufficient to cover the testing of the features that we are including in this MR.

Tested the MR and the implementation is aligned with the intended behaviour described in the updated issue summary. Checked all use cases of adding a new row to the table and the functionality is consistent across all use cases. A new row is added regardless of whether the last input field is populated or not.
Also, if the the focus is on an empty row or if we have empty rows below, the focus shifts to next input element on hitting enter and does not add another row.
Looks good to me 👍🏼

lauriii → closed merge request !4284

Committed ded815f and pushed to 11.x. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.