spec : category system #15
Conversation
There was a problem hiding this comment.
Pull request overview
This PR translates the category system technical specification from another language into English. It provides a comprehensive design document for implementing a hierarchical category system that allows organizing objects (events, relationships, tasks, notes) with visual differentiation on a timeline interface.
Key Changes:
- Added complete English translation of the category system specification
- Documented data models, priority rules, timeline rendering logic, and API contracts
- Included migration strategy and UX considerations
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ## Risks and Limitations | ||
| - Deep trees may require UI pagination/virtualization; cap depth (e.g., 5 levels) or use lazy loading. | ||
| - With multi-category objects, clearly explain which category became the leading one and why (priority → depth → order). | ||
| - Moving/deleting a category can break styling; prefer archiving and mass reassignment. |
There was a problem hiding this comment.
The phrase "prefer archiving and mass reassignment" introduces "archiving" as a solution, but this functionality is not described elsewhere in the specification. Consider either adding a section about category archiving or clarifying what archiving means in this context.
| - Moving/deleting a category can break styling; prefer archiving and mass reassignment. | |
| - Moving/deleting a category can break styling; instead, mark categories as inactive ("archived") and mass-reassign affected objects before hiding them from standard views. |
| backgroundColor?: string, // HEX or rgba for fill/badge | ||
| opacity: number, // 0..1 | ||
| icon?: { text?: string, url?: string }, | ||
| pattern?: string, // e.g., hatching when combined |
There was a problem hiding this comment.
The comment about "hatching when combined" is unclear. Consider adding more detail about what "combined" means in this context and how the pattern is applied when multiple categories are present on an object.
| pattern?: string, // e.g., hatching when combined | |
| pattern?: string, // Optional fill pattern (e.g., diagonal hatching) applied on top of the base color when an object has multiple categories to indicate a combined state |
|
|
||
| ### Assigning categories to objects | ||
| - Update `objects.categories` during object create/edit. | ||
| - Limit assignment count (configurable, e.g., ≤10) for UX control. |
There was a problem hiding this comment.
The magic number "10" for the assignment count limit is mentioned without justification. Consider adding a brief explanation of why this limit was chosen or clarifying that it's an example value that should be configurable based on UX needs.
| - Limit assignment count (configurable, e.g., ≤10) for UX control. | |
| - Limit assignment count (configurable, e.g., ≤10) for UX control; **10 is an example default and the actual limit should be tuned per product/UX requirements**. |
| - Child priority may slightly decrease relative to parent, but explicit values always override inheritance. | ||
|
|
||
| ## UX Policies | ||
| - Limit simultaneously selected filters (e.g., ≤8) and show a counter. |
There was a problem hiding this comment.
The magic number "8" for simultaneously selected filters is mentioned without justification. Consider adding a brief explanation of why this limit was chosen or clarifying that it's an example value that should be configurable based on UX testing.
| - Limit simultaneously selected filters (e.g., ≤8) and show a counter. | |
| - Limit simultaneously selected filters (e.g., start with ≤8 to avoid clutter) and show a counter; treat this as a configurable UX value to be validated via user testing. |
| - In admin UI, flag conflicts (two categories with the same priority/order) and suggest fixes. | ||
|
|
||
| ## Risks and Limitations | ||
| - Deep trees may require UI pagination/virtualization; cap depth (e.g., 5 levels) or use lazy loading. |
There was a problem hiding this comment.
The magic number "5" for the depth cap is mentioned without justification. Consider adding a brief explanation of why this depth limit was chosen or whether it's based on performance considerations or UX research.
| - Deep trees may require UI pagination/virtualization; cap depth (e.g., 5 levels) or use lazy loading. | |
| - Deep trees may require UI pagination/virtualization; cap depth (e.g., 5 levels, based on typical screen real estate and breadcrumb usability) or use lazy loading, and revisit this limit based on UX/performance testing. |
skywinder
changed the title
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Summary
Testing
Codex Task