This section provides guidance on the elements of a card. Cards represent a gateway to more detailed information. Use Cards to provide information, detail about the service or to represent data with which your users can interact.
Block links are a must! They make more of the target clickable, they should be better for accessibility since you don’t have multiple links sometimes with the same text (“link $heading link graphic $heading”), and they make the management heaps easier since you only have one link.
One thing we’ve run into is WYSIWYG editors don’t play nicely with block links. Specifically CKEditor in govCMS mangles them. We ended up with a ‘pseudo block link’ where the elements inside are mostly <span>s with classes that add display: block.
We ended up with a few variations, but the most common one seemed to be title+image+(optional text).
The way I imagine the cards working is they are broken into sub components with one wrapper component.
On the wrapper component the user can choose if the whole component is a link. If it is then they won’t add a link inside the wrapper. If the wrapper isn’t a link then they can add links inside the component. The wrapper component would also allow the user to add variations to the appearance of the card such as a shadow or a border.
Sub components would have the ability to be full width, potentially have links or all kinds of content inside them. They can also be ordered in any order to suit the needs of the users.
Thanks for the write up Chris. We based our newest cards on the Digital Guides cards. Its not a one to one adaption, and we haven’t gone back and updated all our old cards yet, but it seemed like a solid implementation and is the direction we’re heading in.
I have been thinking about the card component a lot. After a lot of deliberation I think that an extremely simple card component copying something like material designs would be best. The card would literally be a container that gives whatever element it is applied to a shadow and nothing else.
This would allow maximum flexibility and users could use the au-body and headings to do their necessary additional styles inside the card. It would allow them to insert callouts, call to actions and keyword lists without any restrictions.
On the flip-side we could be prescriptive about the elements that go inside cards. I previously mentioned a large list of things that could go into a card component. These would be class names and react components that allow users to style the card in a precise way.
You can see our prescriptive component code here:
My problem with telling people what goes into a card is that we have no idea what will go inside or how it will scale in the future. For example an event listing may use the card appearance for each item that may contain a date. Do we now allow users to add dates into the card component, how does that work?
If we tell people what goes into a card we can better provide accessibility guidance, however this comes at a cost to customisation ( this problem comes up often when building components ). If anyone has any feedback on how prescriptive or flexible cards should be I’m all ears.
Perhaps a simple card component and a few common example implementations? It isn’t possible to outline all possible uses, but there are a handful of common uses that could be really useful as templates to work from.
Thanks @podgkin this gets me thinking-- perhaps a blank or simple card is a useful thing, as the container (block anchor link) styles were the hardest thing to get right.
The second complex piece of CSS is the flexbox that puts the cards in a grid.
@alex.page maybe for generic-use the CSS classes are the most useful thing for front-end devs as the card content is going to be unique for every use case, but the containers can be standardised in a system?
Heading type information would be better in a H# tag instead of strong and other text is generally better in a p tag than a div. That way the content gets handled better when machines parse it, for example screen readers or other non-browser reader applications.
On a slightly different note, in some cases cards might also be best wrapped in an article or aside tag, so the solution needs to be flexible in relation to which element wraps it.