Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Tag feature : Adding colors #483

Open
Rdornier opened this issue Jun 26, 2023 · 8 comments
Open

New Tag feature : Adding colors #483

Rdornier opened this issue Jun 26, 2023 · 8 comments

Comments

@Rdornier
Copy link

Having different colors for tags could be a very good option to make the webclient more user-friendly (like in Trello cards).
The colors could visually differenciate processes, categories, workflows... For example, blue tags could refer to the biological sample, green ones to the microscope acquisition and orange ones to proessing.

Forum thread : https://forum.image.sc/t/omero-tags-queries/82584

@imagesc-bot
Copy link

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/omero-tags-queries/82584/4

@will-moore
Copy link
Member

Items of work (if we decide to use LongAnnotations on a Tag to store a colour value)

  • Need some way to add a colour annotation to a Tag and make sure only 1 is added. This could be done in the right panel when the Tag is selected, since that will allow updating of the colour after creation. Users might expect to be able to do this in the Tag creation dialog but that will make the dialog more complex and the API end-points for Tag creation (which are already a bit complex with tags to add and remove) will also have to include colour for new Tags. So, simpler to only support editing of colour after creation. This will need a new URL endpoint. The Colour Annotations will need a custom namespace to indicate that they are "Colour annotations". Although OMERO permissions allow anyone in a read-annotate group to add Annotations to other's data, it might make sense to restrict this to the owner of the Tag.

  • When tags are loaded and we want to show colours, we'll also need to load the Colour annotations:

    • When loading Tags for right panel, which uses /webclient/api/annotations/?type=tag&image=1. This loads the Tags via
      def api_annotations(request, conn=None, **kwargs):
      and
      select oal from %sAnnotationLink as oal
      . That query will need another join/fetch etc to load Colour Annotations if we are loading Tags (but not when loading other annotations)
    • When loading Tags for the Tree (left panel). That is loaded with e.g. /webclient/api/tags/?orphaned=true&experimenter_id=-1 but uses the same OMERO query function as above.
    • Possibly also in the Tagging dialog.
    • When we are filtering a Dataset by Tag - uses same URL endpoint as for right panel
  • Maybe also in tagsearch and autotag plugins? cc @Tom-TBT

@jo-mueller
Copy link

Is this still being worked on? I'm a bit late to the party, but I think a really straightforward way would be to give every tagset its own color. The latter, for starters, could be randomly chosen, as adding a dialogue for the color setting would probably be a bit more work.

@will-moore
Copy link
Member

@jo-mueller it's not being worked on. I don't know if colour on Tagset would satisfy the requirements of most users (especially as many don't use Tagsets)? @Rdornier

What I proposed there was a possible approach to add colour support to Tags (without changing the underlying OMERO model). This has the advantage of not being a breaking change (wouldn't affect other clients or need a server upgrade etc) but still needs wider discussion and agreement before starting to work on it.

cc @knabar

@Rdornier
Copy link
Author

I agree with @will-moore ; tagset are not widely used and I personnaly don't use them. I would strongly prefer to assign the color directly to the tag.
I cannot really discuss on the implementation way. It will be better if the color can also be chosen at tag creation but if it is too complex to handle, then the proposed solution looks good to me as well

@Tom-TBT
Copy link
Contributor

Tom-TBT commented Jul 11, 2024

I side with @jo-mueller :D, I use tagsets a lot and recommend them too. Typically I use them for things like:
Condition

  • condition A
  • condition B
  • control

or

Genotype

  • wild type
  • ABC-/-

In those cases, I annotate datasets with one tag per category, so to me it makes a lot of sense to use one color for all tags of the same category.

But I don't see an issue having both colors on tags and tagsets (anyway, tagsets are just tags with a special namespace, right?) We can conciliate it like this:
If a tag has a color annotation, it's displayed with this color.
Else if it has no color annotation, it takes the color annotation of its tagset
(so if you move a tag to a tagset, you would have to delete its color annotation to let it take the color from the tagset)

About the random assignment of colors, I'm less in favor. I would rather choose from predefined palettes (also ok to randomly choose from predefined palettes).
We could propose two different palettes, one for the tagsets and one for the tags (could make it clear whether the tags are isolated or part of a set):

@jo-mueller
Copy link

Hi all,

thanks for the replies on that topic.

Maybe to motivate my idea regarding colors for taggroups a bit more: I basically started today with @zoccoler to create a set of standard tags for people who want to use our OMERO instance. For this we oriented ourselves along the REMBI metadata standards. Essentially, we turned every suggested metadata category into a set of tags for each category. In doing so, we found it quite helpful to organize things in taggroups, simply for the sake of better ordering a potentially large number of tags.

In that respect I don't have a strong opinion about the value of taggroups over just tags - giving all tags in a taggroup the same color would just be a nice feature to see possible redundancies in the used tags. For instance, the tags Confocal and SpinningDisk would (visually) belong in the same tag group. I don't think there is a collision of interests here.

On the implementation side, I think it would be helpful if the individual tag would inherit its color property from the respective taggroup to make the assignment of colors a bit handier. It doesn't prevent you from giving an individual tag an individual color, either.

@Rdornier
Copy link
Author

If a tag has a color annotation, it's displayed with this color.
Else if it has no color annotation, it takes the color annotation of its tagset
(so if you move a tag to a tagset, you would have to delete its color annotation to let it take the color from the tagset)

Ok, it sounds like a good compromise 👍

I would rather choose from predefined palettes

I agree

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants