create new KContentCard component

[marcellamaki]

Product

Definitely Kolibri, but likely KDP and/or Studio in the future

Desired behavior

I think having a KContentCard component would be very helpful, especially as we move into the new 0.15 launch. (This does not need to be for the launch, but I think having a KComponent to refactor with would be a good idea.

Current behavior

There are many different Content Cards and content grids that are used across kolibri. It's not ideal 😄

The Value Add

Having one flexible, abstracted card would be very useful for future dev work on Kolibri if we are going to continue to use cards. It would reduce the overhead for page changes, and it would also be easier to learn how one KComponent works, rather than mentally switching back and forth between getting multiple different cards to work. It would also ensure a consistent responsive experience.

While I am not very well-versed in the accessibility concerns, I also think that there is quite a bit of material available about how to make card elements accessible (the short version is, making the experience anything more than the bare minimum is actually quite nuanced), and I while I think the team will be working to make sure the cards meet some basic level of accessibility for the 0.15 launch, I think that investing the time in making this card a great experience for learner who use assistive technologies is very worthwhile. (I have some bookmarked resources I can share if anyone is interested.)

Finally, I wonder about the value of having some "design patterns" for possible card layouts - which might also make this easier on the design side for new work as well - flexible, but with some constraints. Like... a handful of legos - arrange them however you want, in code of in design, but these are the legos we are working with. (I am open to other opinions on this!)

(Optional) Possible Tradeoffs

• it might lock us into card designs we don't want, or might be too constraining
• now that we have done 0.15, is refactoring this a good use of (very limited) developer hours?
• I don't actually know what the criteria are for "qualification to enter into the code library" so maybe this does not meet that standard!

[rtibbles]

Maybe the more general 'component-library' like ask here is a KCard component, rather than one specific to content cards?

This would also let it be generalized to display of channels, 'quasi-content' like coach generated quizzes and lessons, and card based listings of classrooms, groups, etc.

[MisRob]

I'd say too that it'd be more useful to have a general card component KCard since there are lots of specifics in regards to the layout and content of cards in Kolibri.

It could be a simple component with some basic styling similarly to Kolibri's CardLink. As you can see in cards (containing new hybrid learning cards), channel cards use a different component than lessons/quizzes/resources cards, but all of them are built around CardLink so I feel confident about having a general component inspired by CardLink. This is cards hierarchy:

CardLink

• --> BaseChannelCard
• --> BaseCard
  • --> LessonCard
  • --> QuizCard
  • --> ResourceCard

There's no card component for a class yet, but here you can see that CardLink is used for that purpose too.

It'd be also good to ensure that KCard works well when used within KGrid and KFixedGrid.

[MisRob]

Also noting that in Kolibri CardLink is often used within CardGrid. I assume that it has no implications for the implementation of the card component itself, but may be good to be aware of this background. You can see #267 for more information.

[indirectlylit]

We have some other precedent for clusters of components that are always used together, for example button-related and grid-related components.

When we write docs, it's best to cross-link between them.

[MisRob]

Related #264

[AlexVelezLl]

Closing in favor of #445