Current multi-step behaviour is confusing for users

In general, the issue is that there is no representation of what is selected, specifically when you have a pager and/or a huge list of assets. Awhile back I created a mockup that showed the thumbnails in the footer of the modal, so you know exactly how many things are being added. There should be no need for a "select" button and then an "insert" button.

gif of prototype: https://dl.dropboxusercontent.com/u/8476966/preview-files.gif

In the short term, for File Browser, I think we could display the selection by default but also add a "Quick Add" behavior. So if I'm in the View widget and I select two entities, I should be able to click one button to finish my selection. Currently I have to queue the selection up and then confirm it, which takes too long for simple use cases.

In the long term something like the GIF in #3 would be great - although we would need to make mockups of a full Upload -> View -> Finish selection workflow to see how that would work. If I change widgets in the widget selector, does that mean that I confirmed what was uploaded/selected? DropzoneJS already shows thumbnails your selection, how would we sync the inline thumbnails from the GIF with that?

Here's a patch which addresses some of my notes from #3. Specifically:

1. The "use_selected" button is always available, which means that users can use the current selection in one step instead of queueing it first.
2. The main submit button's label is now "Queue selected", which I think more accurately describes what it does.
3. The selection is no longer hidden by default.

Let me know what you think.

+++ b/file_browser.module
@@ -47,11 +47,14 @@ function file_browser_form_alter(&$form, FormStateInterface &$form_state) {
+        $form['widget']['actions']['submit']['#value'] = 'Queue selected';

Does this works if this string is translated?

@dagmar I should have used translations, oops! Thanks for the catch.

I was trying this out today.
I totally agree that there are too many clicks for normal "I just wanna attach this image now" use, and I also find the wording (or ordering of the buttons or the steps or something) very unintuative right now.
We (our use-case) really want to make re-using an image from the library *easier* than just uploading another copy like last time, and that's not true yet.

The #3 gif is sexy, and at least explains the difference between 'select' and 'use' (and 'submit' and 'apply' - which are all very similar meanings to fresh eyes).
I tried the patch, and I'm not finding the wording "Queue selected" any nicer for users in this respect :-/ . It may be more technically accurate, but it's not the call-to-action that (I think) will stand out to an everyday user.

I have no suggestions right now - just a little bit of gut UX feedback.

Oh, and patch #7 is at least good today.

Tested this today and it works well. Great improvement!

I think the "Queue Selected" label isn't quite right, but I'm not sure what would be a better choice. This should work differently if the field only allows one value vs. when it allows multiple values. If there is only one value allowed, the "Queue Selected" option should not be available and the user should not be able to select more than one item. It's confusing when you know you should only be able to select one item, but the file browser seems to be letting you choose more than one. Then it gives you an error only after you try to submit it.

In the case where multiple values are allowed, I think just "add" would be fine as a label for the "Queue Selected" button. Or "Add to Selected", which would make the options "Add to Selected" and "Show Selected". If there is a limit on the number of items allowed, it could give some feedback on how many you have left to select.

@mmcdermott Taking cardinality into account when displaying the "Queue Selected"/"Add" button is a great note, I think an easy solution would be to hide the button on single-cardinality fields, and show it on everything higher than that. Actually preventing selection of more than one item is kind of hard, especially in the Views widget, so I would probably want to do that in a new issue.

We hit the single-cardinality issue too - being encouraged to select several was confusing in the context where only one would ever make sense (a hero image), selecting several didn't complain (it just discarded the extras) and as the users expectations at that point were just "I wanna replace the existing one" - that never worked unless we remembered to delete the original also in another step.
So yeah, if we could pipe through the cardinality expectation to the browser, we could happily lose a lot of those buttons sometimes.

I have started some improvements regarding entity browser multistep display, to improve UX, you can take a look here: #2822009: Improved MultiStep selection display.

Interesting - thanks for the link @mtodor. I'll follow that issue and keep it on my radar for my next Entity Browser sprint.

Moving this back to needs work as I'll likely be doing some heavy styling once #2822009: Improved MultiStep selection display lands. The patch in #7 is not going to be the basis for newer work as the Entity Browser issue covers most of what I was trying to do here.

I have a new patch for testing, with multi step enabled! Please try it out and let me know what you think.

And as always, a GIF.

Where does all this stand right now? I agree that the current behavior is confusing. I had one user on a production site say that she felt she hadn't uploaded anything because it wasn't clear from the observed behavior.

Has anything been committed to dev that corrects this?

The behavior I was hoping for can be found in this video:

https://www.youtube.com/watch?v=wsFk1_t-bz0

@RKopacz Hi! You should be able to use the latest version of File Browser and the most recent patch (from #16) to see the proposed behavior. There are config changes, so make sure to update databases as well.

@samuel.mortenson thank you for the quick reply. I will give it a try. I have a project that is about to move to production, but I'd like to have the benefit of a better UX before launch!

I'll let you know what happens.

Anyone have a chance to review this? I'd love to get this committed.

Committing this to unblock adding test coverage. Please submit any feedback in additional issues. Thanks all!

hmmm because of this patch "selecting entities" stopped working.

Because these lines of code have been removed.

      $('.grid-item').once('bind-click-event').click(function () {
        var input = $(this).find('.views-field-entity-browser-select input');
        input.prop('checked', !input.prop('checked'));
        if (input.prop('checked')) {
          $(this).addClass('checked');
        }

@carstenG Could you post a new issue if you're running into problems after updating File Browser (and updating your databases)? It would be helpful to know what release you're updating from, and what errors you're running into. Screenshots are also welcome :-)

Fixed issues get closed automatically, so I don't want this to get lost, thanks!