Problem displaying genes with many isoforms on smaller screens

[mpoelchau]

Hi there,

Our annotators have noticed that there is no way to view many isoforms in the user-created annotations track at a normal zoom level if the number of isoforms exceeds the dimensions of your screen. For example, on my 13" laptop I can see 18 isoforms at normal zoom level, but I can't scroll up and down in the user-created annotations track in order to see the remainder (firefox; zooming out works, but that makes it harder to curate).

Is there a simple way to fix this?

Thanks,

Monica

[alpapan]

Basically if we have an overflow Y-scroll bar, that would be great :-)

[nathandunn]

Was able to reproduce pretty easily. I’ll schedule it for the 1.0.4 release, but you should be able to back port the patch pretty easily. Will look at more on Friday or early next week.

Nathan

On Dec 30, 2014, at 4:20 AM, Alexie Papanicolaou notifications@github.com wrote:

Basically if we have an overflow Y-scroll bar, that would be great :-)

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/124#issuecomment-68352217.

[cmdcolin]

I think this is a consequence of the fact that the User-created annotations track is a "pinned track". Normal tracks are factored into the "overall height of the genome view" which allows easy scrolling. However, when a pinned track becomes very "tall" it causes issues.

Some options: 1) Having scroll bars for individual tracks is one option mentioned but i'm not sure how this would be implemented or the difficulty involved. Also mentioned here https://github.com/GMOD/jbrowse/issues/71

2) Simply unpin the user created annotation track which allows for the global scrollbar...but this has some other issues...for example, the reason it is pinned is so that you can have lots of evidence tracks and always have the annotation track visible.

3) Have more "compact" annotation track, one that is more intelligent about showing/hiding labels (which is normally calculated based on feature density)

[nathandunn]

Colin,

I think that the problem here is that even if I do get Y-bars, but you are still unable to scroll. I don’t think we want #1. I think that #2 (temporarily unpinning) would make sense, but like you said, it screws up the display when I’ve tried it.

For #3, a temporary fix is to remove the labels when editing the config for the annotation track when editing the track config ( "showLabels": false).

Nathan

On Dec 31, 2014, at 9:17 AM, Colin Diesh notifications@github.com wrote:

I think this is a consequence of the fact that User-created annotations track is a "pinned track". Normal tracks are factored into the "overall height of the genome view" which allows easy scrolling. However, when a pinned track becomes very "tall" it causes issues.

Some options: 1) Having scroll bars for individual tracks is one option mentioned but i'm not sure how this would be implemented or the difficulty involved. Also mentioned here GMOD/jbrowse#71 https://github.com/GMOD/jbrowse/issues/71 2) Simply unpin the user created annotation track which allows for the global scrollbar...but this has some other issues...for example, the reason it is pinned is so that you can have lots of evidence tracks and always have the annotation track visible.

3) Have more "compact" annotation track, one that is more intelligent about showing/hiding labels (which is normally calculated based on feature density)

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/124#issuecomment-68455406.

[nathandunn]

in milestone 2.0 we can use the collapse option

[monicacecilia]

Proposed solutions to address this issue:

1. vertical height of a track should become configurable
2. a scroll bar should allow users to navigate this
3. add a collapse ability: everything in the track has the same Y coordinate - which could be useful at times -- so allow it to be on-off
4. set a cap on the max number of elements shown on a track at the same time. indicate that there are more elements, but at not being shown at that moment

[alpapan]

Seems only 2. can be useful to curators who don't know how to edit the config On 23/01/2015 4:49 am, "Monica Munoz-Torres" notifications@github.com wrote:

Proposed solutions to address this issue:

1. vertical height of a track should become configurable
2. a scroll bar should allow users to navigate this
3. add a collapse ability: everything in the track has the same Y coordinate - which could be useful at times -- so allow it to be on-off
4. set a cap on the max number of elements shown on a track at the same time. indicate that there are more elements, but at not being shown at that moment

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/124#issuecomment-71064369.

[nathandunn]

Alexie, I think editing the config and setting ( "showLabels": false) is the quickest workaround right now that helps (doubles the amount you can see), but does not fix the problem. They will unfortunately have to edit the config JSON.

With 2.0, you should see a non-JSON editing of tracks.

[selewis]

We truly need both #1 and #3 to be implemented. We had both in desktop Apollo (remember expand/collapse) and both are useful in many situations.

In addition #2 & #4 are alternate choices for the same thing (i.e. we need

1 & #3 & 2/4). I prefer #2, a scroll bar that only appears as needed

(which in effect is the visual indicator of #4)

On Thu, Jan 22, 2015 at 9:49 AM, Monica Munoz-Torres < notifications@github.com> wrote:

Proposed solutions to address this issue:

1. vertical height of a track should become configurable
2. a scroll bar should allow users to navigate this
3. add a collapse ability: everything in the track has the same Y coordinate - which could be useful at times -- so allow it to be on-off
4. set a cap on the max number of elements shown on a track at the same time. indicate that there are more elements, but at not being shown at that moment

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/124#issuecomment-71064369.

[cmdcolin]

For option 1, there is a configuration variable maxHeight, and this is simply a cutoff with a warning (see http://i.imgur.com/fPOB14v.png). Interestingly...the default maxHeight on CanvasFeatures is about 600 whereas the default maxHeight on HTMLFeatures is 1000, which is actually very tall (probably higher than most screens). If we set it to be a more reasonable value, then at least the user would know they have reached a maxHeight without it going off of their screen.

For option 3, I have demoed the collapsed track mode (as in, all features on one line) in HTMLFeatures style tracks (webapollo hackathon 2014)

So, perhaps both 1 and 3 can be achieved?

[selewis]

That would go a long way towards helping. Is there a toggle for the user (e.g. perhaps a checkbox menu item on the track) to collapse/expand?

But we will still need the #2+#4 combo eventually.

On Fri, Jan 30, 2015 at 1:21 PM, Colin Diesh notifications@github.com wrote:

For #1 https://github.com/GMOD/Apollo/issues/1 there is a configuration variable maxHeight, and this is simply a cutoff with a warning (see http://i.imgur.com/fPOB14v.png). Interestingly...the default maxHeight on CanvasFeatures is about 600 whereas the default maxHeight on HTMLFeatures is 1000, which is actually very tall (probably higher than most screens). If we set it to be a more reasonable value, then at least the user would know they have reached a maxHeight without it going off of their screen.

For #3 https://github.com/GMOD/Apollo/issues/3, I have demoed the collapsed track mode (as in, all features on one line) in HTMLFeatures style tracks (webapollo hackathon 2014)

So, perhaps both 1 and 3 can be achieved?

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/124#issuecomment-72272390.

[cmdcolin]

Should be ready in 2.0

[nathandunn]

@monicacecilia we have the sort of "quick" fixes for 2.0 . . . still scheduled for a real fix for 2.2