I got an eslint error for sorttable on run, but did not know how to fix that, so I left it for now.

Codecov Report

Merging #133 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #133   +/-   ##
=======================================
  Coverage   89.02%   89.02%           
=======================================
  Files          28       28           
  Lines         337      337           
=======================================
  Hits          300      300           
  Misses         37       37

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 638b05a...3a5f218. Read the comment docs.

.fa-level-up and fa-level-down make sense to me. Can you add tooltips or hover text to those buttons?

I'm not too comfortable merging this with only having a scale-up, and not the opposite. Can you do some more research there to figure out a solution?

I'll give it a shot. The main issue is the stop-gap, which is necessary to avoid Inf values. Take for example, the case where the biggest node is size 100,000 and I scale up until (say) 10 values have size 100,000. When I scale down again, the values that are 100,000 will be treated as the same, when originally they were not.

For the network I was working with, I did not see very much value in the scale down. It basically did the same thing, except it sized the smaller nodes more quickly. This could be different for graphs of larger size I imagine, but I'm not sure.

Maybe instead of "scale up" we could use "spline." Another option is to give up on this all together as a neat idea, but not really that helpful in the end.

Realized that I could try to make this happen using some form of state-like object like with ReactJS or a C struct so that "scale down" reverts to a previous state. Might be more trouble than it's worth though.

Agreed on scale-down - it would be nice to have, just in case somebody is clicking too fast and wants to go back.

A question. Here's a step in the 'scale-up,' where we lose the original label in favour of another one. What's going on here?

Step One:

Step Two:

Note that fmap.com disappears after clicking "scale up" despite being the most significant node earlier.

Might be more trouble than it's worth though.

I think it's worth trying to get this implemented FWIW – you're pretty close and have a few ideas of how to potentially resolve this problem.

Okay - if it's worth trying, then I'm willing to put in the time using some kind of state management. That'll take a bit of time to get set up.

The reason why fmap got lost probably has to do with the fact that the other values overtook the max value when they were squared and then became the max value. I thought I plugged that bug up, but it looks like I didn't.

Okay - if it's worth trying, then I'm willing to put in the time using some kind of state management. That'll take a bit of time to get set up.

Great, thanks Ryan – that sounds like a good approach to me.

The reason why fmap got lost probably has to do with the fact that the other values overtook the max value when they were squared and then became the max value. I thought I plugged that bug up, but it looks like I didn't.

👍

I applied a different logic and got the scale up and down to work.

🎉 that's great to hear @greebie. I'll give it a test!

For reference, the current format uses natural log transform or the current value if conducting the transform results in a non-finite value. Scale down uses x^e or the current value if the x^e is a non-finite value.

What's the status of hover text on the buttons?

I'm still noticing @ianmilligan1's issue with fmap appearing disappearing at different points of scale-up/down.

I'll add the hover text. Just got excited about being able to add the scale down button.

Going to try rounding to resolve the fmap error.

Okay - rounding just made it worse. There's just no getting around the floating point problems here unfortunately. Here are the options for this:

1. Accept the scaling as is with clear tooltips that they are simply transforms of the data (either x^e or nl(x)). There will be only very limited consistency for the up and downs.
2. Have only one form of scaling and a revert.
3. Leave this option out.

The state management option is overkill for this feature and could cause even worse problems down the road. There's no guarantee that managing state will scale for larger graphs either.

Accept the scaling as is with clear tooltips that they are simply transforms of the data (either x^e or nl(x)). There will be only very limited consistency for the up and downs.
Have only one form of scaling and a revert.
Leave this option out.

Let's have a think.. are there any collections that would benefit from a scale down out of the box, or will users be generally scaling up the collection.

My vote would be for either one or two, and I see pros and cons for both. Having both is very good, but we'd have to be very clear about what it's doing and some of the downsides. But if people are mostly scaling up and then hitting down to just sort of serve as an undo, that might be ok.

Having just scale up probably covers most but not all of the use cases, but it seems a bit unbalanced to have an up and not a down.

@machawk1 do you have thoughts, since this PR stems from #121?

Yes. Let's have a sit on this for a week. It seems like I could be mistaken about the reversion, but I have to see why it's acting so wonky. The biggest problem is if people scale down super far and then scale up. Scaling up and then scaling down is not a problem. I could just do a scale up and once scaled, add the scale down button until it's back to normal and then remove the button?

I could just do a scale up and once scaled, add the scale down button until it's back to normal and then remove the button

Thats' a very tempting option (or maybe have the scale down button greyed out or visibly inactive).

Giving the user the ability to upscale the nodes is helpful. I would argue to being able to undo this is useful as well after upscaling, as it allows for examining the visualization at a glance without the visual "loudness" of large but easily clickable nodes.

Also, I would recommend not adding new UI elements after a condition occurs. Make it present but greyed until it is activated by the user hitting the upscale button.

OK. I think with discussion, @greebie, why don't you implement the scale up button (I'd recommend with a step of +2) and grey the scale down button out until a scale up (and similarly grey it back out when the user has brought it back to the starting point too).

Sound good?

Just pinging this - sounds like we have rough consensus on the path forward. Now that the graphpass stuff is merged, could you implement @greebie?

Yes, I intend to implement the changes. I think I need the weekend to figure out how to manage state changes without overcomplicating things.

I think I have this fixed now. I established a basic increment/decrement state apparatus here. If we start wanting more, I suggest we move to Redux or a more comprehensive state management library.

Looks good on my end - thanks @greebie. We'll let @ruebot look at this once he's back from vacation!

Yeah - found a small discrepancy as the screen went from full to normal etc. I think I fixed that now.