Centre labels on the columns they're labeling to prevent overlap?

[julesjacobsen]

This shows how the lables overlap when the columns are of different sizes - can the labels be centred on the columns they're labeling?

see impc.html in commit: b2057baa4b548af7305e58738e15ecd1f4e5ee27 for example of the labels overlapping

[yuanzhou]

I noticed the same overlapping issue and got some suggestions from Harry a week ago:

1. calculate the x coordinate of the point where the angled red diving will hit the horizontal line containing the labels. Start the label there. In your picture below, this would have the impact of moving Group 2 to the right.
2. If the labels are still too long relative to the width of each group, we might try to stagger them in the y direction. if the y coordinate of label 1 is yVal, the y coordinate of the next group label would be yVal -10, followed by yVal and yVal -10 alternating.

I ended up going with the option 1, didn't stagger them in the y direction. And this only works if the group title is very short. If they are longer than the group columns width, we'll see overlaps again. I don't feel there's a perfect solution to this issue. If we only have couple of columns per group, there's really no much room to show the meaningful group title.

[harryhoch]

@yuanzhou, is there some reason why #2 wouldn't work?

[jmcmurry]

Is there a reason that we can't (or shouldn't) just hide text that doesn't fit, and have it expand when moused over?

[jmcmurry]

Another thought is that, regardless of approach, we could also abbreviate "abnormal" to "abn." as the majority of the phenotypes display as such?

[yuanzhou]

I'm also attaching a screenshot to assist this discussion.

@harryhoch the reason I didn't go with option 2 was because I was afraid if there's a long title, even after staggering them, it would still cause some vertical overlaps, still readable though, won't look very balanced. I also want to get some testing feedback from Jules to see if it's very common in his testings to have longer titles (longer than the columns width).

@jmcmurry I like the idea of mousing over to expand the full title. Abbreviating may work for some cases, and Phenogrid doesn't handle the abbreviation since those are IMPC/user provided data.

[harryhoch]

@yuanzhou, ok, but don't rule out vertical stagger. could still be useful.

[yuanzhou]

@harryhoch I won't. It will be useful.

Here is another example from Jules, which shows the overlapped group titles. There's only one column in either group 1 and group 3, showing the group titles can be challenging especially when they have more characters/words.

[julesjacobsen]

You could stagger them as @harryhoch suggested and truncate if they are too long. Implemeting a mouse-over as @jmcmurry suggested will catch any cases where the names are truncated if they are too long. I think that way we've got all the bases covered?

[harryhoch]

@julesjacobsen, yes. There are a couple of other tricks that one might use, including using alpha-blending and changing transparency on mouse-over, but that covers the basics

[yuanzhou]

I played with the mouse over idea, by only showing the first character of the group label. The reason why I only use one character is because it's very possible that we have multi groups, and all of them has only one column in the grid. Anything longer than one character or an icon will cause overlapping again.

But the one letter approach doesn't make too much sense in terms of describing the group. Staggering them works except after inverting the axis, which means we'll probably need to create more white spaces between the grid region and the options menu.

I almost feel we should just get rid of the group title/label. When we open the options menu, we can see the groups under the "Target Group(s)" section and turning on/off those groups will let us know clearly which group we are looking at. In the monarch use case, we can also mouse over the target item label and see the group title in the tooltip.

The full group title still looks better when there are enough space.

@harryhoch any suggestions?

[harryhoch]

@yuanzhou, how about we stagger if the usual view and don't display when inverted?

[yuanzhou]

Thanks @harryhoch, no group labels when inverted makes the UI look better. And normally users would expect the same group order after inverting, so as long as we have the group labels before inverting, it should be no problem.

I tried to stagger the group labels and it worked very well.

As we can see from the above screenshots, all group labels are staggered vertically. And don't be surprised by the second screenshot. Because we only have 1 column in group one, and the X of each group label is calculated based on

calculate the x coordinate of the point where the angled red diving will hit the horizontal line containing the labels. Start the label there.

So if each group has only one column, it will look like this:

So far I feel the staggered version works best regardless of the number of columns per group. It may look a little unbalanced in some cases, but that's the expected results based on the calculation of X position. May not be obvious to users though. My only concern is users may think there's something wrong in the labels positioning.

[harryhoch]

@yuanzhou, I think that looks good. It's never going to be perfect, and edges cases are always hard. Thanks for doing this.

@julesjacobsen, what do you think?

[yuanzhou]

@harryhoch I also encountered the same requirement when testing the fly and worm data in monarch. There are cases that there's only one match in fly but 10 matches in fish in the multi-group view. So get this issue addressed properly benefits both IMPC and monarch use cases.

[jmcmurry]

What about icons?

• Recognizable
• Work in both horizontal and vertical orientations
• Work even when densely packed

At least for the major species, this should work. For the (eventual) minor species, this can be assessed on an a per-species basis as to whether they get an icon or an abbreviation (eg. Mm).

Regardless, I do think that expansion on hover is where we want to be.

Note that these particular icons are not the best for use at this size; they just happened to be what I have already. However, I think a simplified version could work; if you think implementation would not be too painful.

ps also note that these particular pairings of species to data are completely made up to illustrate the possible representations.

They could also work well even when the span is large enough to accommodate lots of text; we just might need a way to visually span the columns.

eg.

[harryhoch]

@yuanzhou , do you think the current solution is sufficient?

@jmcmurry, the idea of icons is definitely worth exploring, but I think we need to put this to rest for now. If we are "close enough" with text, I suggest leaving it like that for the time being and making icons a possible enhancement...

[yuanzhou]

@jmcmurry Thanks for making the demo images with icons. Icons can be great if we only have different species. In the current data schema of Phenogrid, it allows multi groups and those groups can be from the same species but different models. In this common use case, all groups are from the same species, so using the same icon won't make good sense. Another reason that it's hard to use icons is all the group data is provided by users (IMPC use case for example), it's unpredictable of what group will need to be rendered in phenogrid, and the users can't send us those icons as part of their data input.

@harryhoch I think the current staggering approach works very well and covers all basics. I'm just waiting the final feedback from @julesjacobsen before we can go ahead merge to master.

[yuanzhou]

More examples of the staggered version with 4 groups:

[julesjacobsen]

I think the continued stagger looks weird. Wouldn't it be better to have an alternate stagger:

        Gr..
Group 1      Group 3
      /   / 
    _  _  _  

That way it can scale to any number of groups. There is still the potential of overlaps @yuanzhou can you try this for a list of groups 0 - n:

• Use a scalable cutoff for group label length based on the group size. e.g. Gr.., Grou..
• Left justify the label for group 0
• Centre justify the labels in the middle of the groups 1..n-1
• Right justify the label for group n
• Add a mouseover tooltip to display the entire label

This way it ought to look ok for different sized groups, small groups, lots of groups, large groups and any mixture of these cases.

          Group 2
Group 1            Group 3
      /          / 
   _  _  _  _  _  _

          Group 2         Group 4
Group 1             Gr..
      /           /     / 
    _  _  _  _  _  _  _  _  _

                    Group 2                            Group 4
     Group 1                          Group 3
               /              /                    / 
    _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _

Or you could go crazy and make the last case fit on a single line, but stagger things if they are too close to each other.

[yuanzhou]

@julesjacobsen I actually thought about this approach and gave it up. In your examples, there's one thing isn't quite close to what we have now, that's the X labels length. When we have a few columns per group, their labels usually a lot longer. Here is an example, we have 3 groups of 1-2-2 columns. As you mentioned, we can't avoid overlaps without shortening the labels, in this example, group 1 and 3 will overlap.

          Group 2 (2 coulmns)
Group 1 (1 column)Group 3 (2 coulmns)
          /     /
         /     /
        /     /
       /     /
      /     / 
   _  _  _  _  _

So if use a scalable cutoff for group label length based on the group size, we'll have G.., Gr.., Gr.. and after left justify group 1, center grou 2, and right justify group 3, we'll have this:

          Gr..
 G..             Gr..
          /     /
         /     /
        /     /
       /     /
      /     / 
   _  _  _  _  _

Do you really think they'll work better than the current staggered version?

                    Group 3 (2 coulmns)
             Group 2 (2 coulmns)
         Group 1 (1 column)
          /     /
         /     /
        /     /
       /     /
      /     / 
   _  _  _  _  _

And when we left justify the first group label, and center the middle one, likely we'll encounter this if it's based on the vertical group boundaries instead of what @harryhoch suggested to use the angled divider as baseline:

calculate the x coordinate of the point where the angled red diving will hit the horizontal line containing the labels. Start the label there.

        Gr..         Gr.. 
G..           Gr..        Gr..
          /     /     /     /    
         /     /     /     /    
        /     /     /     /    
       /     /     /     /    
      /     /     /     /    
   _  _  _  _  _  _  _

At least this will cause confusions to users due to alignment issue. So even when we use the angled divider to position those shortened labels, it will look like this:

             Gr..        Gr.. 
G..               Gr..        Gr..
          /     /     /     /    
         /     /     /     /    
        /     /     /     /    
       /     /     /     /    
      /     /     /     /    
   _  _  _  _  _  _  _

[julesjacobsen]

What I meant was to have slightly different rules for groups 0 and N - these can be longer as there is a lot of whitespace to the left and right of these. You know what the maximum label length for column 0 is as this is a constant you've already predefined. Similarly for group N as you know what the available space is before you run of the right margin.

Your final example should only have the middle three group labels truncated:

        Gr..    Gr..
Group 1    Gr..     Group 5
      /   /   /   /   
    _  _  _  _  _  _  

I agree this isn't ideal, but that's what the mousover can cover. Plus maybe you can figure out a way of checking the length of the labels so that they don't overlap each other or figure out the optimum length before truncating for a given number of columns - e.g. for a non-terminal column the label length might be 5 characters per column which scales very well - 3 columns will get you Homo sapiens, Mus musculus, Danio rario, Drosophila me..

Plus the many single columns is an extreme case. It's possible to display the scientific names of all of those species in cases where there are 1, 2 or 3 columns only as you know the labels won't overlap:

       Drosophila melanogaster
Homo sapiens      Mus musculus
            /   /   
          _  _  _  

So no, I don't think it will look that bad.

Your point about the angled baseline makes sense - but just centre the labels on the midpoint of these rather than the column then.

The problem with your current proposal is that it will look really odd on the monarch site almost all of the time as there is plenty of space for the labels and there are 4-5 groups. For IMPC it will look OK, but we only have a maximum of two groups at the moment. Keeping columns 0 and N on the same level will make two group grids look nice and multi column grids nice too. The ever increasing stagger solution begins to look more and more odd the more groups you have and the more columns in those groups.

[harryhoch]

@julesjacobsen, your points are good, but we really need to wrap this up soon.

@yuanzhou, Iis it possible to try Jules' suggestion in some small amount of time (< 1 2-3 hours)?

[julesjacobsen]

@harryhoch Yes, I completely agree, this needs to be finished soon as it's taken a very long time. Nonetheless, it makes no sense to deliver something half-baked. We've come this far and might as well do a decent job. Once we've done this, we're done.

[harryhoch]

@julesjacobsen, agreed so long as this doesn't open up other problems. @yuanzhou , can you try it ?

[yuanzhou]

@harryhoch I'm making the changes now. Will post screenshots soon.

[yuanzhou]

First I want to post two rendered examples:

Example 1: only stagger up the group labels with even number in the list.

And when we have fewer columns:

Example 2: Left justify the first group label. It turned out that we don't need to right justify the last label since it's aligned with the last angled divider.

And when we have fewer columns:

My questions: which one looks better? Left justify or not? Are they better than the initial staggered version?

Once we can decide on which stagger version is better, we'll have a better idea of what to do next.

[julesjacobsen]

I think the new stagger but without the left justify look better - like in example 1. Just make it so that it can cope with really small columns and so that the group labels are centred on the space between the dividers marking each group so things look even. You can calculate this using the number of columns in the group. For example in examples 2 and 6 the Homo sapiens is too close to the divider, it would look better a bit further to the left.

[harryhoch]

Agreed. new stagger with no left justify. Thanks @yuanzhou

[yuanzhou]

Based on our agreement, I went ahead and first centered the 1st group label based on the group grid width, and all the rest of the group labels are centered at the angled divider tip. This makes the whole UI look more balanced for the majority of instances.

And then I added functionalities to adjust the group label length if its width is wider than the corresponding group grid width.

And below are screenshots of how it looks by changing the number of columns per group in Monarch use case:

Example 1: 2 columns per group

Example 2: 4 columns per group

Example 3: 6 columns per group

Example 4: 10 columns per group

So from all the above Monarch examples we can see it's working properly and looks better. Due to the different positioning methods used for the 1st label and other labels, the wider per group, the more balanced they look like. In order to achieve the ideal look, we'll need to config the number of columns per group to make the divider tip point looks like the center of that grid area.

I also tested with the IMPC example:

IMPC Example

Because we only have 1 column in the 1st group, its label gets shortened.

@julesjacobsen @harryhoch @jmcmurry I think so far this is the best result I can get.

[harryhoch]

@yuanzhou , looks great! Thanks for pushing through.

@julesjacobsen , I think we're done.

[julesjacobsen]

@yuanzhou You can't make the first column label longer? There is a lot of space available for it and was my main point I was trying to make above. Can't you replicate the example I gave:

       Drosophila melanogaster
Homo sapiens      Mus musculus
            /   /   
          _  _  _  

[yuanzhou]

@julesjacobsen I just tweaked the 1st group label.

When the label width is longer than the grid width, it's scaled based on the grid width + the angled divider line's projection on X coordinate. This way we can have a longer label. And since the angled divider line's projection on X coordinate is a fixed width, we don't have to care about the second group length.

When the label is not longer than the grid with, it's centered at the mid point of the 1st grid width. This keeps a balanced look when we have more columns per group.

Hope this addressed all the issues.

[julesjacobsen]

Much better - can you do the same with the final column and then we'll call it done.

[yuanzhou]

@julesjacobsen I don't think we should do the same with the final group label. The final label is anchored based on the last angled divider tip. There's no more divider on the right, and we can't just center the label based on the final group grid width, especially when there's only a few grid columns. And except the first group, all the rest of the groups has a divider on the left, it looks consistent of the current label positioning. Unless I missed something here.

[julesjacobsen]

I meant can you think of a way to just make the final label longer too? Here the final label says 'Phenodigm predicted'. There is a lot more white space available. Can you just shift the labels for groups 1-N (not group 0) to start from the anchor rather than centre on it, like you had 9 comments up where you started:

First I want to post two rendered examples:

Example 1: only stagger up the group labels with even number in the list.

I liked those examples and just wanted you to shift the first and final labels to enable them to be a bit longer. That was all!

[yuanzhou]

I shifted all the labels (1-N, not include the 1st group) to start from the divider tip instead of centering at it. And also adjusted the group width of the last group. Because we still need to set a fixed value of the width, I added the width of the Options box to the last group grid width, and subtracted the last divider's projection on X. This way the last label won't go beyond the right edge of the expanded Options box when that box is right after the grid.

And the Monarch use case is still fine.

[harryhoch]

@yuanzhou, awesome. It's done.

[julesjacobsen]

@yuanzhou - thank you., that's much better. So are you going to merge this into master now and release?

[yuanzhou]

@julesjacobsen Thank you as well. My plan is to merge it to master and I'll ask @harryhoch to review some code and help with testing. Then bump the npm version number and publish to npm registry. By then you should be able to just use the master branch code since I'll delete the impc-integration branch after merging. I can keep you posted once I got this done if you feel this is helpful.