RESEARCH: Technical Complexity of Implementing "Organize Favorites into Collections"

[chrissantillan]

Description:

This research explores the technical complexity of implementing the "Organize Favorites" feature. Currently, residents can favorite Libraries and Videos, but not Helpful Links.

An additional challenge is to consider that libraries and videos have their own association table. Trying to represent them in the same “organized collection” may require us to find a way to support unstructured data.

The research should address:

1. How to handle the organization of multiple content types under a unified "Favorites" feature using collections.
2. The changes required to support collections that contain different content types.
3. Backend and frontend implications for categorizing favorites and displaying them in the resident dashboard.
4. Potential challenges related to data migration, performance, and scalability.

The outcome of this research will be a draft issue outlining a proposed implementation approach, including task breakdowns for development.

Note: If the scope is large, the work may be divided across multiple issues.

Tasks:

Understand Current State:

• Assess how favorites are currently stored
  • Association table for Favorite Videos & Libraries.
  • Nothing for Favorite Helpful Links.
• Assess how favorites are currently fetched and displayed in the resident dashboard.
• Research what database changes are needed to mix favorites into collections.
• Identify all of the places in the application that favoriting might be impacted.

Identify Potential Challenges:

• Consider UI concerns for large collections (e.g., how would the UI react if there were 100 favorites in a single collection? 1000?)
  • Should we limit collection sizes?
• Handling edge cases such as a content item (that has been favorited) getting hidden from residents or deleted from the database.

Acceptance Criteria:

• A detailed draft GitHub issue is created, outlining the proposed approach for implementing "Organize Favorites into Collections" based on research findings.
• The draft issue includes:
  • Database changes to support multiple content types
  • Backend and frontend development tasks with clear objectives.
  • Any identified risks and challenges related to performance, scalability, or data migration.
• The research identifies potential dependencies that must be addressed before implementing this feature.

Outstanding Questions:

• How will deletions or changes in the original content (e.g., a removed video) impact its associated favorite and category?
• What performance considerations must be addressed for large-scale use cases (e.g., thousands of favorites across hundreds of residents)?
• Are there potential concerns that will get raised about persisting values in open text (collection names)?
• Should we add the user flows to this so that it can help guide the developer into thinking about how everything needs to be changed (e.g., where collections get named, how favorites are added to collections, etc.)

[jtucholski]

Known issues/dependencies to consider:

• This is dependent on being able to favorite a page. Limiting it to collections and libraries is acceptable for now.
• Main issue that comes up is allowing arbitrary user input introduces a surface area for risk.
• One potential idea could be to have pre-defined collections (names, colored dots like Mac OS).

[carddev81]

Created draft issue: #621

Also created gist with same info: https://gist.github.com/carddev81/c749705b0c7a64d6150d0ce4f145a427