Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Currently, the Views' module description says:
Create customized lists and queries from your database.
And Views UI adds to it:
Administrative interface for Views.
Now, given that large parts of the core UI have switched (and are continuing to switch) to using a view instead of hardcoded listings, without Views being enabled, users are losing an increasing amount of UI functionality, even if simple fallback listings remain in place.
However, Views' description sounds like this was a nice addon allowing to custom-tailor quite advanced listings.
Views UI's description adds some misunderstanding potential to it, because it could possibly be misread as "Administrative interface based on Views."
We should make sure users immediately understand Views' importance for the core UI, and understand that they want it to be installed even if they don't want to make specific use of it.
This is less of a Drupal WTF, because Views comes with the Standard profile. And given that disabling modules will be discontinued (yay, there really is a UI improvement aspect coming with this overall UI regression), it seems to be quite bothersome to uninstall a module. But once module uninstalling UI has been improved, it will become more of a WTF again.
So I'd say that core pretty much can't be released without a sensible rewording, however that should be revisited before release, if not fixed before.
Comments
Comment #1
PanchoFirst approach on a better description for Views module:
and for Views UI:
Arguments:
= all words suggesting you can configure anything with it (because people might think they don't need it then)
+ all words suggesting that it would do something sophisticated than normal things.
My first approach uses the word "compile" to still suggest that Views module does more than just "display" the listings. This is a compromise, as "compile" might be clearer from a DX perspective, while "display" might me more fool-proof from a UX perspective. But there might be an even better word.
While technically, that's true, on the surface, having Views installed exposes the system listings that even come with filters and sortings and everything. So users would say that this is already a UI.
So at the same time, in Views UI's description, we should avoid words like "administrative" in Views UI's description, because the average admin might associate it with the administration of content, not of the views themselves, and therefore think that Views UI was needed for administrative listings.
I'm using "advanced interface" here in order to signal that this is only for advanced uses.
Comment #2
PanchoWhile the first aspect (wording of Views description) is crucial, the second aspect (wording of Views UI description) is slightly less so. But we also don't want users to install Views UI on a regular install, if they don't specifically want to customize views at all.
This isn't completely secondary, though, because in order to avoid people uninstalling both modules at once, because Views UI adds to much complexity to all of the UI, it is really important that they really understand the difference between the two, from a UI perspective (not dev perspective).
A good wording of module descriptions and help texts would be of great value. But in order to really understand the UI difference between Views and Views UI, it would be very helpful to know the state of Views being installed, but Views UI not.
Besides complexity, this might also be another argument for removing Views UI from the standard profile. Only then they can figure out if they need Views UI at all, or not. But that's out of scope here.
Comment #3
dawehnerThanks for opening this issue!
I like the idea you had with mentioning content and administrative listings, though are you sure about the term "compiles"? Many people might have some kind of technical background and so will get really confused.
Why should this be an advanced interface ... it is the only interface to edit views. I would vote to not mention the term "views" but just refer to lists again.
While I agree that people should know the difference between views and views UI I would strongly vote against removing the UI from standard. Why should people explicit search for a UI, they don't know that it is changeable. The fact that there is an extra UI module is way less important then the realization that things like the frontpage is actually editable by default.
PS: I am not sure whether this can be considered as major bug, but well you decided to choose that :)
Comment #4
catchViews is enabled in the standard profile, this definitely isn't a major bug and could be updated at any time. Would be good to improve the description though.
Comment #5
Pancho#4: Convinced. Major might have been a bit overstated, given that it can be changed anytime.
Comment #5.0
Panchocorrect a wrong assumption
Comment #6
catchNot at all tied to beta, could happen whenever.
Comment #7
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #17
quietone CreditAttribution: quietone as a volunteer commentedThis work has moved into a later issue, #3060616: Update the module descriptions on the Extend page to fit the Help texts. Closing as a duplicate.