backdrop
UX: Display the display type more clearly on the view configure form
Description of the bug
I often struggle with determining the display type for the view I am configuring. The default pattern where the name of the displays are the types of displays does not hold up when you have many displays of the same type. This requires us to change the names of the displays to tell them apart, and then we loose the type of display.
Steps To Reproduce
To reproduce the behavior:
- Navigate to the views admin interface at
admin/structure/views - Configure the "Administer content" view at
admin/structure/views/view/node_admin_content - Clone the Page display as a block
- Rename the page display to
one - Clone the block display as Embed.
- rename the enbed display to
two. - Now try to figure out which one is the block, and which one is the embed.
Actual behavior
Once I have renamed my displays, the tools I use to determine the type are:
- the label of the section containing
Block settings, Page settings` etc (which is not available for all display types) - The URL for the link to change the
Display name:, which appears below the buttons to goggle display settings.
Both of these are cumbersome ways to get information that is readily available to views. Let's put it in the UI instead :)
Expected behavior
It should be easy to determine the display type.
I have two recommendations:
- Put the display type adjacent to the Display Name:
- Add the type on the views listing page, adjacent to the Display name, in parens:
Additional information
Add any other information that could help, such as:
- Backdrop CMS version:
- Web server and its version:
- PHP version:
- Database sever (MySQL or MariaDB?) and its version:
- Operating System and its version:
- Browser(s) and their versions:
I think I prefer the first image above, to decrease change for existing users.
I have made it so that the type only appears if the Name of the display is not identical to the type. If someone does have page / block / feed, those will still work identically to how they do now. But for more advanced users or those who like to organize things by renaming displays, the type also becomes easily available.
PR at https://github.com/backdrop/backdrop/pull/5179
I also often miss the option to identify the display type in the Views interface, and I like the idea to show the display type near the display name. That said, I don't like the capital letters notation. Instead of Display type: BLOCK, I would prefer Display type: Block. Apart from that, the PR works for me.
I've tested the PR, and it works, but like @olafgrabienski, I prefer "Block" versus "BLOCK".
I note that in the "+Add" button above the Display name/type bar, all of the item names are intrinsically title case (i.e., "Block", "Page", etc.), and then are themed to UPPERCASE in the dropbutton. So for consistency, I'd think that the display type should be output to be the same text as what the "+Add" button produces, and then themed appropriately. Instead of
<div class="views-display-setting views-ui-display-tab-type">Display type: PAGE</div>
Something like
<div class="views-display-setting views-ui-display-tab-type">Display type: <span class="display-type">Page</span></div>
And then CSS
.display-type { text-transform: uppercase; }
And that way, themers could put it in either title case or upper case, as they prefer, in both places.
Keeping it title case (i.e., no special theming) also is nicely consistent with how it is displayed in title case on the Views listing.
I note that in the "+Add" button above the Display name/type bar, all of the item names are intrinsically title case (i.e., "Block", "Page", etc.), and then are themed to UPPERCASE in the dropbutton.
Yes, this happens in Seven's (and Basis') style definition of the elements input.form-submit, button.form-submit, and a.button. So, the intention was not to explicetely style the display types under "+Add", those are only in uppercase because they happen to be input.form-submit elements. In contrast, the new display type element should just be text without any text-transform definition, and in my opinion they even don't need a separate span element to style them differently.
in my opinion they even don't need a separate span element to style them differently.
Sounds good to me.