Improve details on the Views listing page

This idea is great!

I totally agree that it makes sense to describe it for attachments/feeds to which display they have been attached to.
Regarding blocks: It doesn't seem to be obvious how to handle multiple themes/layouts (in the future)
but lisa promised to bring some ideas down.

Should modules page redesign make it in I would love to see the same pattern applied here and collapse most of this noise away from the initial view :)

To clarify: I think it's a *good thing* to show a list of all displays per view. But it will also make for horrible layouts in the 5+ displays per view use cases. Hence the suggestion to look into making each row expandable, starting with the basic info that lets you identify the right view, then to expand it and get all the details.

The exposed filters on the view page are dependent on an issue like #1846454: Add Entity query to Config entities, because we currently have no way to filter config entities.

Once we have a view we can make the fieldset closed by default but make it changable, yeah!
Regarding the filtering, I fear we are limited to either name or description based on the other issue linked by tim.
It seems to be that description might be a better fit, as it contains all the information of the name + some additional.

Regarding (3) The primary action here is for sure edit not enable a view, so using the operations pattern is fine.

Once we use views we need a dropbutton implementation in views: #1826604: Add a dropbutton field handler to Views

@lisarex I am wondering, isn't where it is at the really important information? I guess right now its a lot, making it hard to scan, but I dont think hiding it makes a lot of sense.

With absolutely no scientific reasoning to back it up, I vastly prefer 2a, where the arrow is closer to the extra information you are revealing.

@tim.plunkett I welcome you the Gestalt principle of proximity and the scientific research that accompanies it https://lirias.kuleuven.be/bitstream/123456789/128662/1/Kubovy%20et%20al.... .

I actually like 2b since it's very similar to a UX pattern we used for Meta tag admin UI and looks like the new modules page for D8.

I'd recommend expanding this UX pattern to cover all content lists where a portion of each line is hidden behind an expandable space, not just Views. If there's an existing pattern for this interface then it should be used, and then improve upon the general pattern, rather than taking each instance individually.

From a personal perspective, having it beside the field that is to expand makes a certain amount of sense, having it per row suggests that more than one cell may be hiding further information, which it does (type/tags are on the left in 2b).

At a general level, for 2a what would be the intended UX pattern were more than one cell per row to need to be collapsed - more arrows? What if the title wrapped onto two lines, how would the UX adjust?

Just wondering, do we really need type and tag? Tag should only be exposed if you have a custom one?

I think now that views in in core, we should be using tags to differentiate between front end views and admin views. We could keep the ‘default’ tag to signify views that come bundled with core, if we think that is useful information.

I think a "core" tag makes more sense than "default" that is too vague.

So core_admin and core_default?

In my mind it makes more sense to have more tags rather than concatenating them, so other Views could use the same tags.

This would mean:

1. core
2. admin
3. default

I'd much rather replace default with something that signifies Views that are used on the front-end instead of admin facing. I don't think front-end is the correct term.

I have never really believed in using tags for this, it seems like a tool to handle a usecase better solved by advanced filtering - given that this is an expert use case. However its clear we are down this road.

I would avoid using three tags, they all kinda have the same meaning to many users, default - to me doesn't mean anything. If I change that view, its not default anymore - standard provides a tag taxonomy, do we need to label that as default? It seems like something that was introduced by Views, but not a pattern across core, for that reason I would remove it. For lewis his usecase, the only thing I would opt for is adding "admin" as a tag to views used in /admin/*.

The point is that -at least from my personal experience- more and more sites rely on views to display most of their content. Now with views in D8 core and the conversion of the admin listing pages to views, there'll be a growing number of views in the views listing page.

I believe that soon we'll be facing more or less the same issues of the overwhelming modules page and we need to provide ways for people to quickly find the view they are looking for. A filter-as-you-type search field would be most welcome (#1475204: [META] Provide a generic search/filter UI interface pattern for listing pages / #1757618: Add Instant filter functionality in D8 core. anybody?) as well as a way to filter the views based on very basic criteria, for example whether they provide admin listings or content listings. The only relatively easy way I see this being done at the moment is using tags.

I think having a tag to explain that this view is provided by Drupal itself, feels helpful, just to be quickly scan the list.

Instead of discussing the usefulness of tags are, we should be reviewing the design proposal as a whole:

- I think this design could work well even when not collapsing things.
- The info for where blocks are used I'm not so sure of, reads a bit abstract. Maybe just the number of blocks created for this view would be enough here?
- Maybe the type can be used as the prefix for the description: "Content: list of all products on the site" ?

There is nothing to review here.

I think we took care of this in #2574767: Views listing page displays too few items on a page