specify category-select component

[surchs]

Purpose: Select a current category for linking to columns represented in the column linking table

Actions / User flows:

• Select a category
• Add a new category (assessment tool group for now)
  • click on a plus icon to start the process
  • new UI element appears with a default name, I can click on it to enter / change its name
  • I can click an "x" icon (or similar) to delete the category (assessment tool group) again.
  • clicking on the new category makes it the selected category (i.e. I can now "tag" columns with this category)

Required input:

• list categories for selection
  • has some way of knowing whether a category is user-defined / editable / deleteable.
  • This will control whether user can change name / delete the category and whether the corresponding UI elements exist
• css classes for each category - for opacity and color

Generated output:

• currently selected category (sent up to categorization page)
• created (new) category (assessment tool group)
• deleted category (assessment tool group)

Internal state:

• currently selected category (name of the current category as string)
• category table (array of objects where key is column name and value is category name - to be displayed in coponent)

[jarmoza]

Purpose: Select a current category for linking to columns represented in the column linking table

Actions / User flows:

• Select a category

Required input:

• categories for selection
• css classes for each category - for opacity and color
• instructions text
• title

Generated output:

• currently selected category (sent up to categorization page)

Internal state:

• currently selected category (name of the current category as string)
• category table (array of objects where key is column name and value is category name - to be displayed in coponent)

[surchs]

We will put the instructions and title in a separate layout element on the categorization page. The category-select component will just handle the components

[jarmoza]

Add a new category (assessment tool group for now)

• click on a plus icon to start the process
• new UI element appears with a default name, I can click on it to enter / change its name
• I can click an "x" icon (or similar) to delete the category (assessment tool group) again.
• clicking on the new category makes it the selected category (i.e. I can now "tag" columns with this category)

This particular addition has a few ins and outs that I will document here.

1. The plus icon should be set at the bottom of the category select table and move down as categories are added
2. The UI element to appear for name addition can either be an editable row or a separate component. The problem with the former is that editing vs selecting may be incompatible (either to b-table or just in general from a UX perspective
3. Clicking the 'X' icon deletes only custom categories. Presumably we don't want the user to have the ability to delete original categories (as defined now in the store, and in the future, as defined in the app config file. So X's will only appear next to custom categories.
4. Deleting a category necessarily de-links the columns of the data table with that category
5. Additional categories will need to choose colors from a palette. For now they will all be the same color
6. There's the question of whether or not these new, custom categories behave like (or replace) the "Assessment Tool" category

[jarmoza]

Open question: Given that there will have to be code to generate a new color for each new category, is there a limit to the number of custom categories that we want to set?

[jarmoza]

Design notes for editable custom category name feature:

1. Editable textbox featuring name of currently selected category (grey for original categories)
2. Editing name searches through columnToCategoryMap in store and edits name of category assigned to each column

[jarmoza]

Since the creation of custom categories necessitates the selection of new colors, I am introducing a new component: a color picker.

This utilizes the vue-color plugin and is based off this example of a picker (sans hex code input box) in which a limited palette of m x n (m, n of our own designation) is made available to the user to choose the color of the new category.

See vue-color's README.md for an example of what a 'compact' picker looks like.

Since we are looking toward a (potentially) cyclical workflow for annotation, I will build into the store now a place to store these custom category colors.

New output: Custom category colors

[jarmoza]

Since specification and refactoring of this component (as well as the categorization page and column-linking-table component) had been developed with the idea of maintaining working code between components, page, and store, I am re-summarizing the work to be done for the refactor of just the category-select-table solely for the purpose of streamlining and shaping its inputs/outputs for a new data dictionary driven store. Store functionality will be mocked as necessary.

• Input: pre-defined categories for selection, css class for category
• Output: currently selected category (name of the current category as string)
• Internal state: category table (array of objects where key is column name and value is category name - to be displayed in component)

This refactor work will be done in a new branch off of the dev branch (dev_components_talk_to_store_directly).

As per today's discussion with @surchs, I am also splitting off the task of creation of new categories into its own issue as well as the need for a means of choosing/saving the color of a new category.

• [ ] Ability to add new categories
• [ ] Colors for custom categories

[surchs]

@jarmoza, sorry, I think I lost track here. Is this issue now tracking three issues (1 - refactor of component, 2 - new categories, 3 - colors)? Since https://github.com/neurobagel/annotation_tool/pull/229 is closed now, I was expecting that we can also close this issue. But if you want to use it for the whole epic, then let's keep it open and update the description.

[jarmoza]

@surchs No, this can now be closed with #229 as we don't currently have a timeline for the other two issues work/completion. Though I'm guessing they will be addressed sooner than later.