Improve the readability of module cards in grid view

thanks for the patch @Utkarsh_33 and also thanks to @ressa for the screenshots. the only detail i am uncertain about is if it is ok from a design perspective to have centered headings with left or right aligned descriptions for the grid view? as far as i know that isn't a recommended pattern?! i've also found a blog post in that regard here: https://uxmovement.com/content/why-you-should-never-center-align-paragra...

One other mistake you should never make is to combine centered text with left aligned text. For example, a centered headline should not go with a left aligned paragraph. This is because the unsymmetrical line lengths of the paragraph can give the headline the appearance that it’s slightly off-center.

and on a second look i've noticed that in the RTL Grid screenshot the icon and the download button are next to each other in contrast to LTR. it is missing the spacing to push the button the left like it is done for LTR to the right. a follow up issue might be a good idea?

thank you @ressa! happy to help, in particular if it helps.

in regards of the mix of centered title and aligned descriptions you are probably right. the "anchor" function of the icon is an interesting and good point. looked little unusual at the beginning and i had the rule of thumb of not to mix centered headlines with aligned paragraphs in the back of my head. ;)

but take a quick look at the project browser figma file. https://www.figma.com/file/1Z8xrcP2zgnO6BXlu9ZeQ5/Project-browser?node-i... in the updated MVP from 2022 @saschaeggi has one screen where he also uses left aligend description but also left aligned titles as well as left aligned action buttons. one of the screens has a full screen logo while the other screen has a a left aligned icon as well. the problem with the project browser design system is that the designs are missing a few of the components project browser has added over the course of the last few weeks and months like the filter component.

and on the other hand for example the card design is also not exactly in line with the card design in the drupal design system https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/💧-Drupal-Design-system?node-id=553%3A0 (found in the group at the bottom). mainly the spacing to the card border of elements like buttons is out of line. i wanted to open an issue for that as well but i am drawn. on one hand it is important but on the other hand it would be rebuilding the design in svelt. there is an issue in regards of the svelt themeability #3285889: [meta] Svelte app themability.

and about RTL you were right there is more:

• not only more margin but the button has to be moved towards the left card border. the margins see my point about the spacing in the context of the drupal design system. the spacing part applies to ltr as well
• yep the categories definitely need a spacing/margin between label and checkbox. there is a general issue about the checkbox styling #3300262: Adjust the checkbox design for the categories sidebar to the Drupal Design system
• the magnifying glass has to be moved to the left border of the search box correct i agree
• in the filter component title the results count needs a padding. it is too close to the border (but that result count will probably be moved out of the filter component #3310896: Improve UI of results count). if you compare the spacing between the results count and the chips the spacing between the two is smaller in ltr than rtl. also the spacing between the sort by select and filters button is smaller in ltr than rtl while the filters buttons is missing a spacing to the left border.
• the radio button labels in the expanded filters component are totally confusing. buttons are on the left instead of the right of the label. and also have a lot of spacing.
• the list button is right aligned and should be moved to the left over to the grid button.

it would probably make sense to open up a separate follow up issue i suppose? cuz all those changes are out of the scope of the issue here.

apologies for the late reply. but too many different issues stacked up the last few days so i never was able to finish an answer for this one here.

I agree that having everything left aligned could work. the cognitive load is definitely lower even though personally I have the reflex wanting to see the icon centered. ;) but i agree with @ressa that things look fine and orderly left aligned. the only potential problem i see is if you have modules that don't use the default logo dimensions but something wider. examples are field group, CKEditor 4 - WYSIWYG HTML editor, blazy and so on. those cards are left-heavy that way. ideally all modules should have the default dimensions. otherwise things might look off? for example in the list view if you take a look at the aforementioned module the modules respect the overall width for logos in list view in contrast to grid view but that way the logos look tiny and hard to recognize (happens that those are mostly screenshots which makes the recognizability even worse).

in regards of the layout of the cards. the asciidocs examples are a really good way to discuss how things are arranged. good idea thanks for that @ressa! but to get to a final solution i think it would be helpful to agree on a final set of information module cards should communicate aka which components should be added first. the current set of components is:

• logo
• description
• categories
• active installs
• security icon (in case the module has security coverage)
• add/install button

but there are more components discussed to being added and the question is if those should be reflected in the card with a label and or icon as well. for one you have #3315859: Communicate the status/state of a project in the button accesibly which intents to add to illustrate the state a module is in in the upper corner of the module card. then is the question if the release status should be communicated as well on the cards. the issue for adding the release status as a filter type could be found here #3315864: Add a filter type for the release status. in regards of the install count #310877: possible multiple bio node bug it could be questioned if the icon is necessary at all. plain text might be enough. cuz the icon doesn't add any significant value at all. and then there is the question if the category chips add value to the card. one could argue you are already filtering by categories and that way those chips would be redundant. the only case chips definitely make sense is if no category filter type is applied. but to finally settle on the information communicated on the cards would be an important and probably mandatory step.

and it might be worth a thought after agreeing on the components being used on the card to get some design input. for example the padding between card borders and its components like the buttons, logo and so forth have a different padding in the drupal design system. but a few of the potential elements aren't available in the design system layouts. the cards there are in the context of cards used on the appearance page for example.

and a potential slight different card proposal in grid view to yours:

LOGO                    SEC ICON & INSTALL STATE ICO

DESCRIPTION

CATEGORIES
                   
ACTIVE INSTALLS         BUTTON

moving the security icon to the upper right for LTR and add the install state there as well. and use the active installs without the icon in the bottom left in plain text xxx active installs. but instead of using an icon to communicate the install state, the state might also be communicated via the install button instead somehow. #3312289: Svelte UI for install controllers replaces the button with a drop button. the current view commands default action was the motivation for #3315859: Communicate the status/state of a project in the button accesibly cuz it is currently hard to asses in a glimpse of an eye the state a module currently is in. but if it could be solved with the button the icon would be redundant and the icon could be spared and just the security icon could be placed in the upper right corner (for LTR).

tricky overall. but as i said the best would be to come to a conclusion which components should be available in a card. and then there should be also work on the cards in the list view. they are still high in vertical extent compared to the grid view and could be way more compact so you get more cards in one viewport height.