You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is this feature? What is the problem that it is solving?
This feature is the last part of the existing, planned work for integrating search that uses metadata into Studio and Kolibri.
The initial work made it possible for metadata to be added in Studio, and from there, we added features that helped learners use this metadata to search and filter resources. For the self-directed learner in particular, discoverability was very important. This was a key part of 0.15's hybrid learning work, which focused on students learning at home, without a facilitator. Metadata search in Learn also supported adding the Kolibri App to the open testing track on the Play Store in 0.16. Kolibri 0.16 also focused on self-directed learning and enabled remote content browsing of the Kolibri Content Library (Studio) and neighboring Kolibris on the same LAN.
Now, we are turning our attention to the Coach experience, using this additional metadata to help with resource discoverability during both lesson and quiz planning.
On the user side - there should be a consistent, smooth user experience of metadata search that makes it easier for Coaches to quickly find relevant resources they need for lessons and quizzes, and explore potentially relevant resources they may not have considered before.
On the technical side - the feature abstracts the metadata search experience in Learn, moves it to kolibri-common, and then integrates these common elements (composables, components) into both Learn and Coach.
Community feedback that has helped shaped the problem definition and feature
Based on the three February 2018 content discoverability workshops in Kakuma and April/May 2018 testing and modification sessions on Studio, it seems apparent that users looking for materials on Kolibri (wherever a search interface appears) and Studio (when adding and browsing content) are missing content that could be potentially useful to them, as well as encountering content which does not meet their needs and becoming frustrated with the entire process. This inhibits their ability to move about the content library with ease, truly envision the wider possibilities of the heterogenous curriculum, and spend the time they have for lesson planning on creative pedagogical engagement with content rather than prosaic relevance-checking.
Specific observations included:
Preference to use category filters and free-browsing over keyword search, which was ranked as the fastest but not the most useful or educational search method.
Difficulty conceptualizing and iterating upon more creative keywords when one search did not yield desired results.
Becoming overwhelmed by the number of search results and choosing the first few content sources in sight.
Desire to know things about content at searching stage which platform does not convey, and which require too much user overhead to check oneself.
IDOC teachers named subject, language, and age range as metadata it was most important for them to see on Kolibri channel cards...the mixing of these diverse audience indicators within single channels and even single subtopics would make the browsing experience overwhelming and frustrating.
These categories have previously come up as the most critical for users in filtering and creating mental elimination schema to search for content
How do we know this feature is successful?
We know this feature is successful if we hear feedback about an improved experience for coaches regarding resource discoverability. This could be things like:
planning lessons and quizzes is faster than before
it is easier to find relevant resources
coaches experience of lesson and quiz creation and management is less frustrating and overwhelming
it's possible to discover relevant resources that the coach might have not previously thought to include (i.e. content from an available channel that the coach was less familiar with)
it's easier to mix and match resources from various sources to create a lesson or quiz
Are there any assumptions or constraints we are operating under?
In terms of the specific application in Coach, the main technical and design constraint is that we want to have the same experience as in Learn, reusing what we have to avoid (potentially confusing) parallel experiences and/or parallel implementations and tech debt.
Contextual metadata are high-value metadata. They’re more important than others in the discovery of content for curriculum, so less of them will suffice. The categories of contextual metadata we identified:
Classroom Constraints
Do I have the necessary resources to use it (ie need an overhead projector)?
Do I have enough time to use it?
Modality of Usage
What am I using it for?
What kind of learning objective do I have? (Not what is it!)
What are some ways in which I could use it?
Comprehensibility
Who can and can’t understand this?
Who could understand this and with what kind of work?
What are technical approaches, risks, or pitfalls that have already been discussed during planning?
Reuse, reuse, reuse existing code, components, designs, and patterns
Components for the Search/Filter UI should be as consistent as possible, although they may require some configurability (i.e. hiding the "Learning Activities" filter option when searching for quiz exercises)
Use the useSearch composable, as it exists in Learn, as much as possible. Deviating from this is probably either a specification error, or an implementation error! When in doubt, ask Richard for clarification around expected behavior as he was the original implementor on the composable and search experience in Learn.
Because the composable uses Provide/Inject to reduce prop drilling, the component hierarchy needs to be maintained (or if changed, this should be done with consideration and discussion - not just trying to make the components seem more "organized" or prettier). For example, <SearchFiltersPanel> uses injectSearch() and this requires useSearch() in the component ancestry
useSearch() is used (i.e. invoked in the setup function of the component) in LibraryPage/index.vue, which is not the same as places it is imported
The SearchFiltersPanel can be more rationally structured and somewhat refactored as part of this work, but it should be done with care. Right now the Category modals are children - we could consider them being moved out. The clearable Learning Activity Chips should also be migrated along with the other UI components.
useContentNodeProgress should be handled via dependency injection, as it is only relevant in Learn. Creating a Learn-specific composable to handle dependency injection would likely be a good strategy
The baseUrl is also only relevant in Learn (where we have remote browsing), because coaches should not be browsing remote libraries for potential resources and creating lessons and quizzes with remote resources that may not be available in the future.
The new KCard and KCardGrid should be used
The SidePanel component may need to be updated to be more flexible. Currently we are only using a few set widths, but we may continue to extend the possible widths of the component, and therefore, a small refactor to better accommodate variable widths may be useful if the component begins to feel unwieldy with the changes required for the updates in this project.
Acceptance criteria/definition of done for the feature
useSearch composables and related dependencies have been moved into kolibri-common
UX components have been moved into kolibri-common
Components that use a grid system, such as search results, should be refactored to use KCard and KGrid , and this should result in improved accessibility (n.b. KCard is not the end product for the card that will be used, but other cards may need to be built using it)
An updated "Coach Resource List Card" (name very tbd) should be created on top of KCard to reflect the updated layout, information architecture, and styles of the cards that are used in the spec
A coach can search and filter within channel resources within lesson creation/management and quiz creation/management
Stretch goals:
A coach can preview exercises/quizzes that they have selected in a full screen viewer
What is out of scope?
We are not refactoring logic in any significant way - we are just moving things
Tag search
What is the timeline of this project?
Some design work was scoped under 0.15
Finalizing design work, and community feedback sessions with Lewa and S2S will happen during Q1/Q2
Technical planning will begin during Q1 and continue into Q2
Dev work will take place during Q3 and Q4
Feature completion by end of Q4 2024
The content you are editing has changed. Please copy your edits and refresh the page.
What is this feature? What is the problem that it is solving?
This feature is the last part of the existing, planned work for integrating search that uses metadata into Studio and Kolibri.
The initial work made it possible for metadata to be added in Studio, and from there, we added features that helped learners use this metadata to search and filter resources. For the self-directed learner in particular, discoverability was very important. This was a key part of 0.15's hybrid learning work, which focused on students learning at home, without a facilitator. Metadata search in Learn also supported adding the Kolibri App to the open testing track on the Play Store in 0.16. Kolibri 0.16 also focused on self-directed learning and enabled remote content browsing of the Kolibri Content Library (Studio) and neighboring Kolibris on the same LAN.
Now, we are turning our attention to the Coach experience, using this additional metadata to help with resource discoverability during both lesson and quiz planning.
On the user side - there should be a consistent, smooth user experience of metadata search that makes it easier for Coaches to quickly find relevant resources they need for lessons and quizzes, and explore potentially relevant resources they may not have considered before.
On the technical side - the feature abstracts the metadata search experience in Learn, moves it to
kolibri-common
, and then integrates these common elements (composables, components) into both Learn and Coach.Community feedback that has helped shaped the problem definition and feature
How do we know this feature is successful?
We know this feature is successful if we hear feedback about an improved experience for coaches regarding resource discoverability. This could be things like:
Are there any assumptions or constraints we are operating under?
In terms of the specific application in Coach, the main technical and design constraint is that we want to have the same experience as in Learn, reusing what we have to avoid (potentially confusing) parallel experiences and/or parallel implementations and tech debt.
Assumptions, constraints, and decisions that shaped this work overall (the approach to metadata search, rather than the specific implementation in coach), include the following description of metadata value that came out of an early design sprint related to this work:
What are technical approaches, risks, or pitfalls that have already been discussed during planning?
useSearch
composable, as it exists in Learn, as much as possible. Deviating from this is probably either a specification error, or an implementation error! When in doubt, ask Richard for clarification around expected behavior as he was the original implementor on the composable and search experience in Learn.Provide/Inject
to reduce prop drilling, the component hierarchy needs to be maintained (or if changed, this should be done with consideration and discussion - not just trying to make the components seem more "organized" or prettier). For example,<SearchFiltersPanel>
usesinjectSearch()
and this requiresuseSearch()
in the component ancestryuseSearch()
is used (i.e. invoked in the setup function of the component) inLibraryPage/index.vue
, which is not the same as places it isimport
edSearchFiltersPanel
can be more rationally structured and somewhat refactored as part of this work, but it should be done with care. Right now the Category modals are children - we could consider them being moved out. The clearable Learning Activity Chips should also be migrated along with the other UI components.useContentNodeProgress
should be handled via dependency injection, as it is only relevant in Learn. Creating a Learn-specific composable to handle dependency injection would likely be a good strategybaseUrl
is also only relevant in Learn (where we have remote browsing), because coaches should not be browsing remote libraries for potential resources and creating lessons and quizzes with remote resources that may not be available in the future.SidePanel
component may need to be updated to be more flexible. Currently we are only using a few set widths, but we may continue to extend the possible widths of the component, and therefore, a small refactor to better accommodate variable widths may be useful if the component begins to feel unwieldy with the changes required for the updates in this project.Acceptance criteria/definition of done for the feature
useSearch
composables and related dependencies have been moved intokolibri-common
kolibri-common
KCard
andKGrid
, and this should result in improved accessibility (n.b.KCard
is not the end product for the card that will be used, but other cards may need to be built using it)Stretch goals:
What is out of scope?
What is the timeline of this project?
Product Issues
Prerequisites
Migration of
useSearch()
tokolibri-common
, composables refactoruseSearch()
intokolibri-common
asbaseUseSearch()
#12516useSearch()
to extendbaseUseSearch()
#12517kolibri-common
components, and delete Learn-specific components #12518Learn and Search component updates: refactors and migrations
<SearchFiltersPanel>
and children intokolibri-common
#12519<SearchResultsGrid>
intokolibri-common
and move relevant related components (such as<LearningActivityChip>
) #12520<SearchFiltersPanel>
to accomodate differences in display between Learn and Coach, and within Coach, to manage quizzes (i.e. no Learning Activity types) vs. lesson resources #12521Cards and Grids
<SearchResultsGrid>
to use new<KCardGrid>
and updated card built on<KCard>
#12695<KCard>
to use in the resource management side panel #12528KCard
from beta to its final API #12688KCardGrid
andKCard
#12873Quizzes - updates to 0.17 EQM question replacement workflow
kolibri-common
useBaseSearch()
#12624Lessons - integration of useSearch and alignment to quiz UI
ContentCardList
to use the newKCardGrid
and theAccessibleResourceCard
andAccessibleFolderCard
#12732<ResourceSelection />
so that can it can be used in lessons, without breaking the current quiz workflow #12790Information Architecture - new coach page structure
Additional design fixes and improvements
Resources
Previously existing bugs that should be resolved by this work
The text was updated successfully, but these errors were encountered: