-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resource discovery: Implement folder and resource card #12418
Resource discovery: Implement folder and resource card #12418
Conversation
Build Artifacts
|
d4b1a45
to
9bba53c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Allan, thanks :) I appreciate clarity in the PR description in regard to review and also what's done and what's coming, helpful. I hope to have all issues I promised to open ready soon. Cards look very good, and their API interface makes sense to me. I am leaving a couple of comments from the first code walkthrough.
@@ -37,7 +37,13 @@ | |||
disabled, tabindex, is-leaf class set here to hack making the card not clickable | |||
if you're trying to make the card clickable remove these properties | |||
--> | |||
<AccessibleFolderCard | |||
v-if="content.kind === 'topic'" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not so important as it's temporary change, rather just fyi for future work there's constants available here
kolibri/kolibri/core/assets/src/constants.js
Lines 28 to 42 in df0c4ee
export const ContentNodeKinds = { | |
AUDIO: 'audio', | |
DOCUMENT: 'document', | |
VIDEO: 'video', | |
EXERCISE: 'exercise', | |
TOPIC: 'topic', | |
HTML5: 'html5', | |
CHANNEL: 'channel', // e.g. a root topic | |
EXAM: 'exam', | |
LESSON: 'lesson', | |
CLASSROOM: 'CLASSROOM', | |
ACTIVITY: 'ACTIVITY', | |
SLIDESHOW: 'slideshow', | |
BOOKMARK: 'bookmark', | |
}; |
kolibri/plugins/coach/assets/src/views/plan/LessonResourceSelectionPage/ContentCardList.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
<KCard | ||
class="card" | ||
:to="to" | ||
:headingLevel="2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[required] I'd suggest that <AccessibleFolderCard>
has a headingLevel
prop and just passes its value to KCard
via the same prop. Reason being that <AccessibleFolderCard>
will be used from more pages in Kolibri, and on each page it can be a member of a different level. This will ensure that devs always make sure to configure it explicitly and correctly in the context of a given page.
> | ||
<template #thumbnailPlaceholder> | ||
<div> | ||
<CardThumbnail |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[required] Regarding the usage of <CardThumbnail>
here, KCard
doesn't need to use another component to re-implement the whole thumbnail area because it already provides it. If we used <CardThumbnail>
here, that would override everything in unintended ways, and it's also unnecessary extra work. Let's leave KCard
to do everything it can and only put folder icon into the #thumbnailPlaceholder
slot. I realize that the slot's name is not intuitive in this regard - can you think of a better name?
(side note for context, ultimately, a big future goal is to get rid of all current card components in Kolibri, <CardThumbnail>
included, in favor of KCard
)
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @AllanOXDi! Its super exciting to see KCard already being used in our codebase!! 🎉, and see that the initial implementation has covered the most usecases we had. I left just a couple of thoughts, mostly regarding the html semantic structure 🤗.
kolibri/plugins/coach/assets/src/views/plan/LessonResourceSelectionPage/ContentCardList.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/coach/assets/src/views/plan/LessonResourceSelectionPage/ContentCardList.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @AllanOXDi thanks for the great work on this!
My main suggestion here is for this PR but also helps us with the "how do we move past a working branch into the 'mainline' work for 0.18 question".
We should move both the ResourceCard and the FolderCard to kolibri-common
. This allows the work to be merged into develop with minimal additional changes, provides the cards for shared use, and also prevents cross-plugin imports (totally fine for this working branch and testing, but not something we want to merge into production. Why no cross-plugin imports? Since it's a plugin architecture, we cannot merge code that assumes the existence of another plugin. Each plugin shouldn't "know" about other plugins that exist, or depend on them. More questions? Richard would love to tell you about it).
Having this implementation as it is, and using the updated version in the content card list is very helpful for manual QA. So, after moving these new components into kolibri-common
, please update the reference for the import in the ContentCardList
for final QA and feedback, so we can make sure everything moved over well.
Once all of the feedback on the cards themselves is resolved, and we confirm with QA that the new cards work as expected in Coach in the ContentCardList
with no regressions, I think we can retarget this PR to develop and merge it directly there. I will then update the related issues in the milestone to be follow up issues that build on top of this foundation. I'm going to think about whether or not we want to include the ContentCardList
update, or if we just want to include the cards being available in kolibri-common
with no actual "placement" of them yet. If anyone has pros/cons, please share.
Also, a bit of a nitpick, but let's have a consistent name for the new cards -- I think making sure it's Accessible_____Card
for each makes sense, so update AccessibilityResourceCard
to be AccessibleResourceCard
.
Great work! I'm so excited that finally KCard
in Kolibri is coming to life!!!! 🎉 🎉 🎉 🎉 🎉 It's been a long time coming, and past Marcella, who struggled through 0.15 card refactoring (and many patch release "fixes" on the card UI ever since), is very grateful!
kolibri/plugins/coach/assets/src/views/plan/LessonResourceSelectionPage/ContentCardList.vue
Outdated
Show resolved
Hide resolved
@AllanOXDi After all feedback here is resolved, and also learningequality/kolibri-design-system#752 finished and linked here, please ping me here - will do one final read through and then we should be ready to |
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibilityResourceCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/learn/assets/src/views/LibraryPage/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
4a33906
to
50a4013
Compare
Hi @MisRob @AllanOXDi - I have started my review here and have a few thoughts. I'll add some comments and questions tomorrow. Some of them are probably for follow up and some are more general questions as I get more familiar with the relationships between these cards and KCard. Overall it's looking really nice Allan, thanks for all of your hard work! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @AllanOXDi Thank you for the great work on this. I can really see your increased comfort with all thing Vue components and navigating between KDS components and custom components in our products! I added a couple of comments but they're small.
Aside from the comments, I wanted to raise a little feedback that is outside of the scope of this PR but is interesting for the sake of learning and planning around the mobile view of the cards and this project.
On mobile view of the Folder card, the layout is technically responsive, which is great, but you can see it's a bit crowded.
I realize that the screenshot included in the issue only had more of a "list" view and didn't clearly state that there would be different sizes on mobile. And the image preview in the issue didn't include the mobile level responsiveness specifically. When we actually use this card (beyond just what you have here for the demo), I think we'll want to make sure we use the version of KCard
that is aligned with the spec..
From my understanding talking to @MisRob, it will be simple to do this with a different layout that exists, to be vertical vs. horizontal, which is already supported in KCard
You could try out doing this conditionally where the card is called
<Accessible...Card layout=breakpointLevel === 0 ? "'vertical" : "'horizontal">
but only if you're curious to test it out and see for yourself, as this isn't the final usage and you will be removing that code before merge anyways :)
In upcoming work I'd also encourage you to use a critical/reflective eye when are playing around with testing, and raise questions like "does this look right? did we overlook a mobile display? does this seem like what the designer intended?" Again, this isn't strictly in scope for this PR as the current "use" of the card is for manual QA only. And it's not a criticism of the implementation, but rather some thoughts to help with broader context thinking beyond the checklist of acceptance criteria. Noticing and sharing your perspective on things early, even if it seems like something a bit outside of your task list, is always helpful, and it helps you continue to build those reflective/questioning skills 🙂 And practically speaking, it will also help us make sure we do things like share with the team some of these features of the new KCard
and helps me remember to include these details in upcoming issues I'm writing.
@@ -225,4 +237,9 @@ | |||
margin-left: $checkbox-offset; | |||
} | |||
|
|||
/deep/ .horizontal-with-large-thumbnail { | |||
height: 141px; | |||
margin: 0 0 16px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering why there's a need to use /deep/
here, and if this is because this is more of an MVP, rather than the full implementation, or if there's something that we're missing with the KCard API. To me this is a small thing but an indicator that something is not quite as flexible as it needs to be, or like we've missed a detail and now are overriding something where there might be a better approach.
This is a bit of a nitpick, but I'm also confused about why the height is 141
px specifically. Was it this in the spec? We usually stick with 4 or 8px increments, or at the very least an even number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
currently, KCard has no set hight and and width- it's something that will be implemented in the gird. So I was just trying to play around with the number to make sure I'm close tot the the design
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked @AllanOXDi to not worry too much about these temporary files :) As mentioned this won't be configured on KCard
at all and this whole file will be removed before we merge.
However, it's definitely relevant notes and good guidance. @AllanOXDi it may be be helpful to comment on things like this in the PR comments or code comments so reviewers who don't have context (or just people like me with bad memory :-) can understand things like this.
@@ -25,6 +25,18 @@ | |||
</template> | |||
</component> | |||
</component> | |||
|
|||
<h2>AccessibleResourceCard preview</h2> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just make sure to remove this before merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. Once It's approve, I will remove it before merge. I wish I had added a comment
@AllanOXDi I think the last thing here is just to clean up any code that was used only for QA, and then we can go ahead and merge! Thank you for all the hard work managing this in connection with the KCard updates |
Okay thanks @marcellamaki. @MisRob is there something still missing? |
packages/kolibri-common/components/Cards/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
packages/kolibri-common/components/Cards/AccessibleResourceCard.vue
Outdated
Show resolved
Hide resolved
@AllanOXDi I will give it a final look after QA related code is cleaned up |
@AllanOXDi I'm sorry there's still some changes that shouldn't be here before merge. Would you always preview "Files changed" tab? I'm not particularly concerned about added/removed empty lines etc. but for example the extra condition in the |
The |
I don't think you pushed it then @AllanOXDi or perhaps internet connection troubles? See here https://github.com/learningequality/kolibri/pull/12418/files |
f87f210
to
f77aacb
Compare
Sorry I think It should be okay now. |
Thanks @AllanOXDi |
packages/kolibri-common/components/Cards/AccessibleFolderCard.vue
Outdated
Show resolved
Hide resolved
packages/kolibri-common/components/Cards/AccessibleResourceCard.vue
Outdated
Show resolved
Hide resolved
Please clean up the last two places I spotted and then you can merge. |
Not that it'd be wrong in the scope of this PR - it will just make work easier for those to come because it'd break the grid behavior unexpectedly otherwise. Thanks |
Okay, nice. I think as soon as checks pass, this is ready. Thanks for following-up @AllanOXDi, I will leave joy of hitting the merge button for you ;) |
Summary
The PR introduces a new folder card to Kolibri to support of coach resource discovery . See #12318
Screen.Recording.2024-07-25.at.19.53.42.mov
closes #12318
References
#12318
Reviewer guidance
While reviewing this PR, please note that I have decided to leave out a few acceptance criteria requirements, namely support for RTL.
Please note that this was built on top of the KCard, which supports two layouts (i.e., vertical and horizontal) with their respective thumbnail display options and for folder cards, the thumbnail display area is currently shown on the left when the display is large. but it require it to be on the right when the thumbnailDisplay prop is set to 'large', in addition to the title prop taking up the position of the above title slot in these kinds of layouts. This is currently not covered by KCard.
Vs the design spec
After discussing with @MisRob, we decided to work with what KCard supports for this issue and file a follow-up issue on KDS to handle these edge cases.
I have made a minor stying adjustment to the below title slot on KCard . To test this PR you would need to work with this KDS PR learningequality/kolibri-design-system#688
Here are a few things to look at:
Testing checklist
PR process
Reviewer checklist
yarn
andpip
)