[UX] Views UI: Views tags: fix the UI and use them or loose them.

[klonos]

As it is now, all new views get the "default" tag (#2074). There is no way to edit/remove this default tag or add more tags while creating a view. The UI to do that is accessible only via the "Change view name/description" action within the view edit form which is several clicks away. On top of that, are we expecting the user to guess that they can change the tags from an action that mentions only name and description?

Also notice how the tag field label uses singular ("View tag") despite the fact that you can add more tags:

...we also use the singular "Tag:" as a prefix when displaying tags in the views list:

...and in code, we have $view->tag that prints all the tags. Shouldn't that be $view->tags instead?

We could expose the tags in the view create form. We group the tags with the description in the views list, so I guess it would make sense have it be shown/hidden using #states along with the description field when the "Description" checkbox is ticked.

We could also have the "Change view name/description" be an option in the operations dropbutton that opens the same modal as the one that opens in the view edit form.

The point is though, is this a feature that most people use? Is it worth fixing things or should we just remove this? I mean, we do not even provide a way for people to filter the views list by tags. D7 had a separate column for views tags, so at least you could sort by it and in D8 the "Filter by view name or description" instant filter does work with tags:

[klonos]

PR addresses the use of singular "tag" in the UI labels.

[quicksketch]

Thanks @klonos! Great suggestions all. I completely agree that at the very least we should delete the "default" tag from being added. I can't see any useful purpose for it.

Personally, I've also never used tags at all, but I'm sure someone has for one reason or another. What's so odd about them however is that we don't have tags on any other kinds of configuration (blocks, image styles, layouts, etc.) I would be in favor of dropping them entirely.

[quicksketch]

Also I merged the small fix at backdrop/backdrop@ff6f246. Thanks!

[klonos]

...at the very least we should delete the "default" tag from being added. I can't see any useful purpose for it. ...I would be in favor of dropping them entirely.

Yeah, I generally am not in favor of removing broken things if we can fix them but this one begs for it. Perhaps we could hardcode a "core" tag for views provided by core and implement an instant filter in the list with a search field (like D8) + a toggle so that the user can switch between core/non-core/all views.

The singular tag label commit fixed a minor annoyance, but the main thing is that we are not using these anywhere. Then its the usability issue that I guess can be sorted with minor UI adjustments. Unfortunately, I have not yet reached the level where I can successfully edit forms so I cannot implement the addition of the tag field in the view add form.

Speaking of UI improvements... how do you feel about in-place editing? We could add ✏️ icons that open modals next to tag and description right in the views list page. UI clutter? ...even so, better than having people edit the view, then have them guess that they can edit the tags from the "Change view name/description" action. Alternatively, we could expose the "Change view name/description" form at the top of the edit view form, OR...

[quicksketch]

Speaking of UI improvements... how do you feel about in-place editing?

The difficulty of inline editing (and doing it consistently in our UIs) makes me think it wouldn't be appropriate in this case.

[klonos]

Yes, I expected that. Wait for the "OR" from my previous comment. Mockups coming up 😄 ...

[Bojhan]

@quicksketch I think it makes sense to drop it. Its a complete one-off aimed at making the UX of the views listing experience better. I've never really understood why its there, I think its just a relic from the past when someone thought it was a good idea - not necessarily a often used feature.

[klonos]

I never got to this, but will most likely have some time throughout the coming weekend.

If we implemented an instant filter that also searches on tags (even though not shown in the views list as an actual column), it would be useful. That's how it works on D8 (see screencast in issue summary). For example, say the site builder has created multiple (and many) views. Some are for the admin UI while others front facing. If we remove the tags, what options do they have to filter the list by? It could work if instead of the tags they used the description field.

Last thought is that I'd hate to break existing site functionality, so if we do end up dropping them, can we at least copy/append any existing tags to the description fields?

[yorkshire-pudding]

Don't lose them. They are used to great effect by Admin Bar Views Grouping and could have much better use of them made in the UI. I would love to see tag based filtering in the views listing

[kiamlaluno]

If there is a module that uses tags, I would not remove them. I would like to be able to filter by tags in the list of views too.