Suggestions for improving the Search API admin UI

use checkboxes instead of multiselect when creating an index

Completely Agree

if there are no bundle options, hide the configuration option when creating an index

Duh! Agreed ;-)

no server - should be selected by default when configuring an index.

If there is only 1 server, that one should be selected by default.

the enabled checkbox should be dependent on the server “- no server -” option via states & make sure to disable if no server is selected.

Agreed

when configuring aggregated fields, the new fields dialog has little vertical space & scrollbars might be hidden (test on mac). instead, probably try the views add/select field/filter modal.
in order to add a “related field” the user entity via “authored by” on a fields configuration, you first have to add authored by uid and only then can add :entity. this should be easier :)
column priorities for responsive tables would be helpful for all tables in the search api admin ui
currently the fields ui can be biiiiiig and no filters are available. 1) we could use views add/select dialogs, so that non-enabled fields aren’t displayed by default 2) we could add some quick filter like on the module admin page

This is duplicate of some other issues such as #2254749: Improvements for UI in fields tab of index configuration and #2247885: Improve UI for fields with multiple properties and/or references, #2230899: UX improvements for the "Fields" tab. Please continue that conversation about the fields UI there.
Thanks for the great suggestions, are you willing to patch some of them?

use checkboxes instead of multiselect when creating an index

Will change this to checkboxes. Will also put in an 'open' collapsible fieldset as this list could get quite long for some sites.

If there are no bundle options, hide the configuration option when creating an index

By bundles do you mean the 'data types'?

No server - should be selected by default when configuring an index.

Will look into this

The enabled checkbox should be dependent on the server “- no server -” option via states & make sure to disable if no server is selected.

Will look at this.

There are a couple of copy changes I will make (if you agree):

• Change index name description to: Enter a human-readable, display name for this index.
• Data type description to: Check one or more data types that will be stored in this index.

Will see if I come up with anything else

Thanks for working on this!

By bundles do you mean the 'data types'?

No. Once you click, e.g., "Comment" in the list of data types (we should really change that to "datasources", though), you get a new fieldset via AJAX containing options for that datasource. These contain the entity type's bundles. But if you have no comment bundles configured yet, it will still show the fieldset but with an empty list of bundle checkboxes.
(If an entity type doesn't support bundles at all, the whole form is already correctly hidden. We should do the same if a type supports bundles but doesn't have any yet.) (I'm not sure what we should do if there is only a single bundle, but I think we should err on the side of caution and display it then.)

Enter a human-readable, display name for this index.

I would remove the comma there.
The other suggestion is fine.

This is duplicate of some other issues such as …

I don't see the suggestion about responsive column priorities anywhere yet, and that would definitely make sense.
Also, it's true that we already have several issues outlining the (partially overlapping) UI reviews and recommendations of various people, but a glaring shortage of people actually implementing those suggestions.
So, I think working on them anywhere is fine. Optimally, of course, we'd go through them and bundle them either into a single one, or into one meta issue and linked child issues, and in any case close all the other ones. But as long as we don't do that, working in any of them doesn't really worsen the chaos.

Sorry to do this but I think I was a little 'over-ambitious' in trying to pick this up (being more of a front-ender). Got me into reading up on OOP and the D8 API's and stuff but think I've got quite a way to go before I'm able to decipher exactly what is going on in the module code.

What I can tell you is...

use checkboxes instead of multiselect when creating an index

This isn't as simple as changing the $form['datasources'] type to checkboxes. Although it does change it to using checkboxes, the Ajax doesn't work. I did quite a lot of tinkering to try get it working but no joy. Might be that Ajax on checkboxes doesn't work at the moment. See the very end of this post where he says Ajax is only working with Select element http://enzolutions.com/articles/2014/11/25/how-to-work-with-drupal-8-for...

For anyone looking into this it's in /src/Form/IndexForm.php around line 220

in order to add a “related field” the user entity via “authored by” on a fields configuration, you first have to add authored by uid and only then can add :entity. this should be easier :)

++ Just tested the current version, and I had to select nid or some other kind of field to have custom fields that I added appear as related fields...

column priorities for responsive tables would be helpful for all tables in the search api admin ui
currently the fields ui can be biiiiiig and no filters are available. 1) we could use views add/select dialogs, so that non-enabled fields aren’t displayed by default 2) we could add some quick filter like on the module admin page

++++ Perhaps some kind of grouping by content type would be great as well instead of dumping all the entity bundle fields... I would imagine most users work within the node entity and 3-4 content types can really elongate the list.

Change the "Index status" percentage to only show 1 digit after the decimal point.

The attached patch implements most of these suggestions. Please test and review!
Unfortunately, I currently don't have a web server at hand, so it's completely untested.

One thing I'm pretty sure will still be broken is the states of the index "status" checkbox. The code in states.js (around line 480) looks like it actually should work, but apparently it doesn't (according to the @todo comment).

the "No server" option is never selected by default – some bug in the code

Is this still a problem?

I also created #2863453: Use a modal dialog or some other user-friendly means of selecting aggregated fields, since that's a significantly more complicated task. Otherwise, all the suggestions here should be either implemented in my patch or out-dated (quite a few of them).

Maybe like this?
Otherwise, contains some debugging for IntegrationTest.

Perhaps like this?

there some updates for the first fail with the patch #16.
interdiff included.

It's about the missing anonymous value both from submission and configuration.
Also there is a user entity for the testing index.
+ there are some roles i can't figured out where they come from.

toDo: fix the second test failure.

Nice work, thanks for figuring that out!
However, as I tried to explain to you in person, the RenderedItemProperty should actually process the form values it receives and just save a numerically indexed array of roles, not the raw key-value data it gets from the checkboxes. The $expected field config should then also just contain the single array value, 'authenticated'. That would also solve the current processor integration test fail. (The additional roles are created by the test class when creating users with specific permissions.)

Regarding the other fail, in IntegrationTest, it would be great if someone could run the test and check which items are left in the tracking table at the point where it fails. Are they from some other index, for example?

Sorry, didn't mean to change the status.

Rebased.

Could one of the UI experts in here maybe take a look at this: #2939405: Better UI text on what is included in the index? Thanks!