Increase the fading area for whizzing labels

[Anastasia Baryshnikova]

USE CASE: WHAT DO YOU WANT TO DO?

Make it more clear that only a subset of labels is shown

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

Load any test file (e.g., small_133x133.txt)

CURRENT BEHAVIOR

Currently, only the indicator bar and the first and last labels are somewhat faded to indicate that what you see on the screen is an incomplete list.

EXPECTED BEHAVIOR

I think it would be best if a much larger portion of labels was faded out. E.g., 5 labels at the very extremes should be completely transparent (0% visibility), then 10 labels should be somewhat visible (25%-75% visibility) and then the rest should be 100% visible. Maybe that's too much but you get what i mean, right? Make the boundaries a bit more clearly faded out.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

FILES AFFECTED (where the changes will be implemented) - developers only

LEVEL OF EFFORT - developers only

major

COMMENTS

[Robert Leach]

Setting label number minimums doesn't necessarily scale well when label size is increased. Probably should set a percentage of pixels inside which there are "faded" labels.

Setting a variable fade BTW, is much more difficult than setting a value. I'm not sure the effort is worth it. Doesn't the fact that they move tell you that you're looking at not all the labels? We might also consider seeing if people have feedback about it in alpha03.

[Anastasia Baryshnikova]

For some reason, the fact that the labels move doesn't tell me immediately what it means. It takes some thought (for me) to remind myself what I am looking at and to remember that only 1 of the labels is aligned with the data (the middle one).

How is the fading set up now? Is it just a constant pixel value? Can we increase that and see how it looks like? I can come & check it out on your computer.

[Robert Leach]

The faded labels have a 50% transparency. Labels are drawn from the row/col currently hovered over to the left/down and then to the right/up. Once there is not enough space available to draw an entirely visible label, the transparency is set to 50% and the data index of the corresponding tile to the label previously drawn is saved as the visible label boundary, which is used to draw the blue indicator showing the range in the matrix that the visible labels represent and it's used to draw the light blue background on the tree also indicating the same thing. I used to also use it to draw a blue border around the portion of the matrix corresponding to the visible labels.

I admit that we don't currently have a perfect solution. I see merit to the continuously fading edge labels. I simply have reservations that it's the best solution to solve the problem, or necessarily agree on the degree of significance of the problem. I understand the concern. The concern is that a user will hover over a column, see the label, and look left and right and then look down at what's directly beneath that label (without having moved the mouse) and incorrectly assume that the label they are looking at corresponds to the column of data below it. How common of a mistake would that be for a user to make? I don't know.

And I think that's why we have testers. I think that having the alpha03 testers provide feedback on it could determine answers these questions. It could even result in a brilliant suggestion - which would be something we'd feel obliged to implement, meaning time spent on a continuous fade would have been wasted. So I think that there are so many directions one could go to solve the problem with varying degrees of efficacy, that it's a good place at which to consult the users. And I think when we provide alpha03, I don't think we should ask a question about this for them to evaluate, because I think the question would influence the outcome. The feedback we've received thus far leads me to believe that the testers are very astute, so if this is an issue, we'll hear about it. Perhaps after they have had a chance to play with it, we could even solicit users to fill out a survey that addresses this and other issues, like the search functionality.

BTW, I realized when working on the search, that I could make the popup show the first match, including considering the wildcard characters. But unfortunately, you can't cull the contents of the popup to only show matches. Nor can you prevent the autofill from occurring. They're too closely tied together. Later versions of java interfaces would behave in a more modern fashion. We're limited by swing and java 1.7.

[Robert Leach]

One thought I just had would be to make the bar indicator region a little thicker and instead of drawing a bar, draw slanted tick marks every so many pixels or something. Not sure how good that would look though.

Another possibility would be to use that darkened matrix ability Chris developed last year on hover which could serve to highlight the region corresponding to the labels... not sure I prefer this idea either, but I'm just brainstorming.

A fish-eye effect on label font size might be more effective than fading. The variable font size would certainly convey the visual disconnect between labels and the data. The user could even change this behavior with the min/max label size settings and turn it off with the fixed label setting. It's perhaps equally as hard as doing a continuous fade simply because with a single size, the calculation of font overlap would be touchy and I know there are some calculations that multiple font pixel size by number of labels to calculate the boundary offset. The downside of this would be one thing I've observed - fonts only draw at certain static arbitrary sizes, so instead of looking like a smooth font size change, it would probably end up looking tiered, which would make it difficult to display optimally at an arbitrary font size range...

[Anastasia Baryshnikova]

I think the fish-eye effect would be too much. We have to keep it simple.

Same thought for the tick bars at the bar indicator. Actually, at some point it was not very clear to me what the blue vertical bar was indicating. Can you remind me again? Is it supposed to link to the tree? When you hide the trees (or don't have them at all), we might consider hiding the bar.

@TreeView3Dev and @lance_parsons -- what do you guys think?

[Lance Parsons]

Perhaps we could get a screenshot of couple of different scenarios and then mock up some photo-shopped ideas... Might help to visualize a few options.

[Robert Leach]

No, the blue bar relates the visible labels to the corresponding portion of the matrix. Think of it like a scrollbar (only its motion is controlled by hover). The left most non-faded label corresponds to the left-most column under the blue bar.

I used to draw the label font blue to aid the visual association between the labels and the bar. I also used to draw a blue box on the matrix indicating the association. Plus, I used to draw a blue bracket around the labels that connected to the bar, but that was too busy-looking.

I think it naturally looks like a scrollbar, so I think people will intuitively get it.

It doesn't always correspond to the tree, but it happens to when the tree is drawn to scale to the matrix.

[Robert Leach]

One of my earlier ideas (which actually came after the original idea for the current whizzing labels) was to allow users to treat labels like a box on the matrix that you could move by scrolling. If you were zoomed in, you would end up scrolling the matrix once the blue box hit an edge.

This incorporated the blue "bracket" idea that visually linked the visible labels to the corresponding portion of the matrix.

A red hover indicator had a plumb line that went from the hovered matrix position to the corresponding labels.

While this idea proved to be too complex, I think that it was better at dissociating label position and matrix position. I'm not sure whether there's any element from this we could morph into a more elegant solution, but I just thought I'd highlight it to stimulate ideas.

Here's a screen capture and a reasonably working jar file link:

https://bitbucket.org/TreeView3Dev/treeview3/downloads/tv3_label_idea_refined.jar

[Robert Leach]

Another option which I've brought up before would be to, for example, draw every other label - whatever column is far enough away to have the label fit & not overlap with the previous labeled column. We could have tick-marks to indicate that the labels displayed do indeed align with the matrix (which ironically is the opposite problem).

This idea comes with some pretty big drawbacks in my opinion. If the data is dense enough, there are some labels you would never see while zoomed in. The space between labels would alternate a pixel length every so often with wouldn't look as neat. The biggest drawback is that you lose a lot of the advantage of context.

[Anastasia Baryshnikova]

Yeah, I think it would be a big loss: not knowing who is right next to the row/col I'm pointing at.

[Robert Leach]

I just had another idea inspired by the red plumb-line and the blue bracket in the image above would be to associate the edge of the current indicator bar with the edge label using a color and/or a plumb-line (probably not a plumb-line). I was comparing ideas with Lance - he has a few unique ideas of his own - and even realized that the tick-mark idea could be merged with this idea and make (e.g.) every so many labels a certain color that corresponds to a mark on the bar indicator. I'll do a quick mock-up of the idea.

[Robert Leach]

OK. I did a bunch of mock-ups. The ones that I think effectively solve the problem look inelegant. The ones that look elegant (including a faded label scheme, which I haven't mocked up) don't, in my opinion, effectively solve the problem.

The first idea did not turn out well at all, so I will skip it.

Idea 2 adds red (not bold) at the ends, which correspond to the red color at the ends of the indicator bar:

Idea 3 is the same thing with plumb-lines added:

Idea 4 uses a large indent of the start of the labels to draw a connecting wedge:

Idea 5 uses a growing indent to dissociate the labels from the matrix:

Idea 6 uses a floating box to dissociate the labels from the matrix with the aid of a dropshadow:

Idea 7 takes 6 a step further and adds a light blue background:

Idea 8 adds that light blue background to the divider (which would be a lot more work):

Ideas 9 & 10 turned out to be duds.

Idea 11 adds a wedge outline to connect the labels to the indicator bar:

Idea 12 eliminates the shadow from idea 8:

Lastly, idea 13 is idea 11 without the shadow since we realized the outline makes the shadow unnecessary:

[Anastasia Baryshnikova]

I like idea 4.

Also here's idea 14: with the fading (it's really ugly but you get the idea). Is it really so bad?

[Robert Leach]

I'm just not sure fading solves the problem. I think the problem is, a user will hover their mouse on a column of interest and look left over the labels and mistakenly think that a label corresponds to the column of data underneath it.

The floating box depicted in the later ideas was an inspiration from Lance and the more I think about it, the more I like it. It looks like an inset you would see in a published paper, especially with the blue angled lines connecting to the corners. So I think idea 13, or a variant of it that excludes the background on the divider gets my vote. Unfortunately, it's also more difficult. Still, I think it solves the problem better than a fade does.

[Robert Leach]

And I still think that this should at least be an alpha04 issue. I'm still not convinced people would make the mistake of misassociating a label and a column of data.

[Lance Parsons]

I agree that this should be an alpha04 issue. It's not really a bug, and it's fairly apparent in many situations what is going on. Only when the matrix is just a bit too small to fit the labels is this likely an issue.

I'm partial to the floating box idea. #4 is rather ugly and I'm not sure clear. #14 is much nicer looking, and in fact is a lot like the fisheye idea. However, I'm not sure it's all that clear what is going on and starts to obscure so many labels that perhaps we just show a single label at that point (that the user is hovered over). Just my $0.02.

[Robert Leach]

Had another idea, though still non-optimal. Similar to ideas 5 & 6 combined:

idea 16:

[Robert Leach]

I'll be interested to know if we get any feedback on this topic...

[Robert Leach]

Removing milestone: Labels (automated comment)