Explore different karyogram orientations

[ryan-williams]

There are 2 independent axes here: intra-contig orientation, and inter-contig orientation; each can be horizontal or vertical:

source ^^

horiz/horiz and vert/vert share several issues:

• super wide (resp. tall), skinny shape necessitates very-zoomed-out view, makes it very hard to interact with the karyogram / see any detail in the multi-contig view
• propagates the illusion that e.g. the end of chromosome 1 has anything to do with the start of chromosome 2.

Google image search for karyogram shows no examples of horiz/horiz or vert/vert, for good reason imho:

If we bring back the karyogram (and I would like to / believe we can find a way that makes sense, once we figure out exactly what purpose it would serve), we should think about the 2x2 matrix of possible orientations.

[ihodes]

cf. https://github.com/hammerlab/cycledash/issues/245#issuecomment-106850297

[ihodes]

Another datapoint; all the genome browsers use the horizontal/horizontal layout.

[ihodes]

Adding my points from slack discussion to save future rehashing:

propagates the illusion that e.g. the end of chromosome 1 has anything to do with the start of chromosome 2.

1) I don't think we should put much weight on disillusioning those unaware that there is not a natural ordering on chromosomes—this is a tool for people who already know that. 2) We place an ordering on the chromosomes already when sorting; maintaining that ordering (chr1 before chr2, etc) in the karyogram is logical.

super wide (resp. tall), skinny shape necessitates very-zoomed-out view, makes it very hard to interact with the karyogram / see any detail in the multi-contig view

We need to figure out why we want the karyogram before we can determine if it's difficult to interact with.

The purposes of the karyogram I'd envisioned are (and had been in use before):

1) Navigate the genome: i'm less interested in this use-case, as we have other ways of doing this (CQL, namely). 2) Seeing density of variants matching some CQL criteria or density of some other aggregate attribute in bins within the contigs.

Finally, my natural inclination is the horiz/horiz view, as

1) That has been shown to be useful and usable via IGV and all the genome browsers (in before "appeal to authority") 2) It does not take up column space from the variant table like horiz/vert would, nor does it take up nearly as much row space as vert/horiz would.

[hammer]

On HN front page right now is TremulaJS, a nice JS library for navigating image collections that may be useful for navigating chromosoms. Archiving here for posterity.

[ryan-williams]

Select inlines / points ported from Slack :)

2) We place an ordering on the chromosomes already when sorting; maintaining that ordering (chr1 before chr2, etc) in the karyogram is logical.

There's reusing the order of the chromosomes, and then there's reusing the same spatial dimension across the two relevant axes: {inter,intra}-chromosome.

vert/horiz and horiz/vert also preserve the ordering of the chromosomes, but without muddying the very-real intra-contig distance by {re,ab}using that spatial dimension to also mean inter-contig distance (the latter not even representing a proper "distance" metric; chr1 → chr20 is not meaningfully "further" than chr1 → chr2).

nor does [horiz/horiz] take up nearly as much row space as vert/horiz would.

Claim: the previous incarnation of horiz/horiz was so zoomed-out as to be not useful, which hastened its demise, so its space profile is not admissible independent of considerations of what we want from it. There are two views on it:

• We didn't know what we wanted from a karyogram so even a minimal space cost was not worthwhile, hence we removed it.
• Its (crunched, horiz/horiz) space profile caused it to be unusable.

I believe the latter: I think a karyogram could/would be useful for several things, but we should think carefully about the many ways that it could be laid out on the page, be visible / not-visible in different situations, etc. etc.

I've had to argue a lot just to get acknowledgment that there is a search space potentially worth exploring here. I'd like us to stop treating the horiz/horiz impl that we had as a default that is/was inherently sensible.

[ihodes]

For the record, the karyogram wasn't removed for any particular reason related to usability; when I rewrote the backend, supporting the karyogram became difficult and got pushed: it hasn't yet been reimplemented as no one has asked for it/it hasn't been shown to be needed.

Additionally, I acknowledge the use of assessing other options for the layout; know that before spending a long time implementing it the way I did, I did consider other choices (and for the reasons above, settled on the horizontal layout). That's not to say another layout wouldn't be better (given what I wrote above), or that we're stuck with horizontal layout.

[ihodes]

Closing this; can reopen if we decide to re-add the karyogram.