Still to implement:

  • Unify redirects when enabling/disabling servers and indexes: redirect to overview only if the action was started there.
  • Clean up styling of disabled servers/indexes in overview: no italics, no symbols, maybe gray out the row or something.

Comments

lewisnyman’s picture

View server

  1. Should the “Delete all data” be a danger button type? It sounds dangerous.
  2. I'm not sure how much data would normally appear in this table but maybe the button is better off appearing above the table?
  3. The status table looks weird but I think it actually a problem with the styling. Issue created here: #2252713: Table headers inside of status reports look strange.

Enabling a disabled server

When I enable a server it directs me to the edit form? When I disable a server it redirects me back to the listing page, is this intentional?

Server listing

  1. I'm not sure if using the icons to represent the state of the server is consistent with how we use them. The red cross definitely signifies 'danger' which is not the case here. To be fair we don't have documentation on the semantics of the icons yet. Issue created: #2252721: [policy] Document Libricon semantics, including examples
  2. I noticed that disabled servers get italic font styling. This implies some kind of emphasis when I assume we we really want to do is deemphasise them because they are not being used. If you guys want to propose a greyed out styling as a new table row style then I would make sense to pull this into core so others can use it. You probably wouldn't need the status icons then either, assuming you only have two states.

Manage search index filters

Should all the processors be inside of a fieldset? It seems redundant if they are the only items on the form.

That's all the time I have right now. I'll look around some more this week. I can create each of these as separate issue later if you want.

drunken monkey’s picture

Should the “Delete all data” be a danger button type? It sounds dangerous.

Yes, definitely. Probably the same for the "Reindex" and "Clear" buttons on the index View tab.

I'm not sure how much data would normally appear in this table but maybe the button is better off appearing above the table?

It's a very rare action, so I think having it at the top would make it look too important.
Also, usually the table will be small enough to let everything fit on one page, I think.

When I enable a server it directs me to the edit form? When I disable a server it redirects me back to the listing page, is this intentional?

No, probably just a mess. If doing this from the listing, probably both should redirect back there. And from the edit form, both should redirect to the View tab (but I think that's currently the case anyways).

I'm not sure if using the icons to represent the state of the server is consistent with how we use them. The red cross definitely signifies 'danger' which is not the case here. To be fair we don't have documentation on the semantics of the icons yet. Issue created: #2252721: Document Libricon semantics with examples

I noticed that disabled servers get italic font styling. This implies some kind of emphasis when I assume we we really want to do is deemphasise them because they are not being used. If you guys want to propose a greyed out styling as a new table row style then I would make sense to pull this into core so others can use it. You probably wouldn't need the status icons then either, assuming you only have two states.

You are right, that all doesn't make much sense. We should probably completely redesign this at one point.
One thing that would help, which is planned (more or less) for later, is #2134799: Allow backend plugins to provide more specific feedback/information. If we have a dedicated method on the server to check, whether everything is OK for it, then we can use the icons for those. Disabled servers should really be de-emphasized in some way to hide them more. Greying out sounds like a good option, but maybe we also want to re-activate the "Disabled" category on this page.

Should all the processors be inside of a fieldset? It seems redundant if they are the only items on the form.

You're right, of course, that's just a remnant of D7. We should get rid of that, and probably either rename the tab to "Processors" or refer to them always as "Filters".

amateescu’s picture

draganeror’s picture

Issue summary: View changes
draganeror’s picture

Issue summary: View changes

Added new related issue to description.

draganeror’s picture

Issue summary: View changes

More related issues...

drunken monkey’s picture

Project: Search API (8.x) » Search API
Version: » 8.x-1.x-dev
Assigned: lewisnyman » Unassigned
drunken monkey’s picture

Issue summary: View changes
Issue tags: +release target
cedric_a’s picture

Status: Active » Closed (outdated)
StatusFileSize
new209.68 KB

A lot of these initial remarks are no more relevant, here is my analysis (from tests over the git branch 8.x-1.x today) :

  • View server : the UI has changed a lot since the screenshot was made. I attached the current UI (view-server-20191101.png). The remarks are no more relevant -- FIXED
  • Enabling a disabled server : the weird redirects don't happen anymore : enabling and disabling a server (or an index) keeps you on the list page (/admin/config/search/search-api). -- FIXED
  • Server listing : disabled server/index appears in italic with a red cross -- this part is still relevant and should be discussed in its own issue -- I'm going to close this one and make a new issue for this topic
  • Manage search index filters : the form has changed, there is more than just processors so wrapping them in a fieldset is now relevant. -- FIXED