DRAFT: Organize Favorites into Collections

[carddev81]

Description

This feature aims to enhance the current Favorites functionality by allowing residents to organize their favorites into custom collections. This implementation will unify all open content types under a "Favorites" feature within organized collections, supporting more flexibility and scalability. This issue was created based on research completed from #560.

Question: Can a resident have the option to favorite a content item in more than one way? Discuss?

Proposed Implementation

Backend

• Database Changes:
  • Create a new table: favorite_type_codes with at least the following columns:
    • code (2-3 character code, e.g., "IMP", "LOT")
    • description (Label shown to the user, e.g., "Important", "Love It")
    • Modify open_content_favorites to include a favorite_type_cd column, establishing a relationship with favorite_type_codes.
  • Category Examples (Discussion/Brainstorm):
    • Default: Libraries, Videos, Helpful Links
    • Custom-defined: Fun, Inspiring, Important, Love It, Most Important, New Finds, Follow Up...
    • Colored Dots if wanted?
  • Behavior:
    • When favoriting content, users will be able to assign it to a specific category.

Frontend:

• UI Design Options:
  • Option 1: Keep the star icon for favoriting. Add a vertical ellipsis next to it to display a pop-out window where users can assign categories.
  • Option 2: Clicking the star icon opens a pop-out window to assign categories directly. Users can also manage existing categories here.
  • Pop-out window will allow:
    • Adding content to one or...to another category?. (maybe have a check mark next to selections)
    • Removing content from a category.
  • Dashboard Display:
    • Limit displayed favorites per category to a maximum of 10 items (most recent) for better performance and usability.

Risks and Challenges:

1. Data Migration: Add new columns and populate data for existing favorites without disrupting current functionality.
2. Performance: Limit collection sizes to a reasonable number and optimize queries for large-scale use cases.
3. Dependencies: Database scripts must be executed before implementing frontend and backend changes. (A create/insert/alter script)

Outstanding Questions:

1. How should deletions or changes in the original content impact its associated favorite and category?
   • Logic already exists to handle visibility changes; no additional logic is required. Currently the favorited item will not display in these scenarios.
2. How should performance be addressed for thousands of favorites?
   • Limit displayed favorites to 10 or a reasonable number. These would be most recent items per category.
3. Are there concerns about persisting collection names in open text?
   • No, the text will be managed by the favorite_type_codes table.
4. Should we include user flows to guide developers?
   • Yes, once a draft is finalized we can come up with a user flow for the developer?

[jtucholski]

Some ideas that I have after reading this.

• It's written as "When favoriting content users will be able to assign it..." and I want to clear that we'd probably get rid of the generic favorite as it is today and everything would go into some collection.
• After seeing the Important, Love It, etc. it reminded me that YouTube has a "Watch Later" category. We could consider:
  • Read/Watch Later
  • Favorites
  • Archive (this could be where you put things you have read/watched).
  • I'd like to explore other useful categories. I like the ideas proposed (Inspiring, School)
• We should have the pop-up include the proposed checkbox.