search

GMOD / jbrowse-components

Source code for JBrowse 2, a modern React-based genome browser
https://jbrowse.org/jb2
Apache License 2.0
196 stars 60 forks source link

Rename "Synteny track" to "Homology map" #4370

Open ihh opened 2 months ago

ihh commented 2 months ago

Synteny "tracks" are different types of thing from annotation tracks - they are defined on 2 sequences not one - it's like the difference between a vector and a matrix. It's confusing having three "track selectors" in the pairwise synteny view, two of which are for annotation and one is for synteny.

I propose renaming "Synteny track" to either "Synteny map" or perhaps "Comparison map" or "Homology map".

cmdcolin commented 2 months ago

The term "synteny track" is not my favorite thing, but this would be a bit tricky to change.

There are sort of two things at stake

a) the term synteny b) the term track

I think the term track is not so bad and is not inaccurate either. A synteny track can be opened as a track in a plain old linear genome view. For example, a "synteny track" of mouse vs human can be opened as a track from the tracks selector on a plain old hg38 linear genome view, which shows "alignment type features" that users can right-click (and launch a synteny view from, or just click to get info). Similarly, a "track selector" is useful in the the dotplot and linear synteny views because multiple "synteny tracks" can be opened and displayed one over the other. I understand it is odd to have "three track selectors" and if there are ways to improve that UI, i am quite open to it.

As far as the term synteny, it is a bit troublesome, but i think it is understandable in a colloquial way that many people understand. In a abstract sense, it would be nice to just call them "alignments tracks", showing the alignment between two species for example, but we already have alignments tracks and not sure the term alignments tracks helps users understand the situation as well :)

Finally, it can also just be fairly difficult to change the names. It requires docs changes, UI changes in the app, and even internal code name changes, which can be difficult/dangerous because some of the internal type names are serialized into the sessions, and unless proper migration logic (which is tricky) is implemented, it can cause crashes when those sessions are loaded.