Suggestions for improving the Search API admin UI for the Add/Edit Index screen

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!

I know these issues are ancient, but I was trying to browse through the user interface related issues to see if there are any plans in place in general. We started leveraging Search API for the 'AI Search' sub-module of AI and have extended some form classes. Would be interested in contributing to modernising the 'Add fields' wizard/edit approaches to match Drupal Core more (also so things like Gin/Claro/etc all adapt nicely). Is this the best issue still to work from? Or start fresh with new issue and "Closed (outdated)" some of these old ones?

I think we can still work on this issue, or if we move to another issue we need to credit the people who helped already here. I think it's a safe move to reuse this issue.

I agreee, please feel free to keep working in these old issues.

Sounds good thanks both!

Okay I reviewed the options here. I think the Add/Edit fields screen needs more significant thought and rework to bring it more in line with drupal core forms to allow it to more easily feel at home in Claro/Gin so I am suggesting I create a separate issue for that (and work on it) and keep this limited to the original issue summary.

I have crossed out items that are no longer a problem (ie, over the last 7 years must have been fixed elsewhere) and I completed the ones that do exist.

Follow-up created here: #3484811: Improve the Search API admin UI for adding/editing fields

Thanks a lot, great job!

I just had some minor adjustments, the most relevant being that the #disabled setting on the “Enabled” checkbox makes even less sense now than before, so I removed it.

If you are fine with these changes then I can merge. In any case, thanks a lot again!
Reviews from others of course also welcome.

Thanks! Just gave your changes a quick run adding a new index again and all looks good. Code perspective, no concerns with the changes. And thanks for the quick review!

Haven't tested it out locally, but the code changes look great.

Great to hear, thanks for reviewing!
Merged.
Thanks again!

Thanks for the quick review & merge!

Re the comment on raising an issue in Core, I raised that here now and added test coverage to demonstrate: #3486574: Ajax cannot be triggered from within a table row. Should I create a new MR here to update that comment?

Ah whoops, cross posted on that last comment, was meant for #3484811: Improve the Search API admin UI for adding/editing fields sorry!