Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Scaling Design for SigmaJS -- partially address Issue 130 #133

Merged
merged 13 commits into from Jun 24, 2018

Conversation

@greebie
Copy link
Contributor

commented Jun 5, 2018

The title of this pull-request should be a brief description of what the pull-request fixes/improves/changes. Ideally 50 characters or less.


GitHub issue(s):

#130

What does this Pull Request do?

  • Add a scaling feature to enable showing of more labels on graph.
  • Make the transition from page to full screen more consistent (same graph shows in each place).
  • Move default settings to instance rather than library.

How should this be tested?

Spin up an instance with an account and use the "scale up" feature. What should happen is that the next-to-largest nodes will get larger and therefore start to show labels.
Switching back-and-forth from fullscreen should show the exact same graph.

Additional Notes:

The scale up checks whether each node is the same size as the largest node and if not, it squares the size value. Sigma takes care of the scaling and displaying.

I tried "scale down" using sqrt, but the max-value check means scale down does not restore back from scale up. I found that confusing, so just left "scale up" which can be restored to normal using refresh.

I'm sure there's a font-awesome icon for this feature instead of text, but I did not see it yet. Icon options for bootstrap 4 are here: https://fontawesome.bootstrapcheatsheets.com/

Interested parties

@ianmilligan1 @ruebot

Thanks in advance for your help with the Archives Unleashed Toolkit!

greebie added 3 commits Jun 5, 2018
Make modal and page sigma outputs match.
Move settings to instance rather than edit sigma library.
More consistent matching between page and fullscreen.
Linting fixes.
@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 5, 2018

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

@codecov

This comment has been minimized.

Copy link

commented Jun 5, 2018

Codecov Report

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

Impacted file tree graph

@@           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.

@ruebot

This comment has been minimized.

Copy link
Member

commented Jun 5, 2018

.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?

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 5, 2018

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.

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 5, 2018

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.

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 5, 2018

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:
screen shot 2018-06-05 at 3 42 54 pm

Step Two:
screen shot 2018-06-05 at 3 42 55 pm

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

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 5, 2018

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.

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 5, 2018

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.

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 5, 2018

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.

👍

Applied natural log & exp logic instead of previous.
@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

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

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

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

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

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.

Copy link
Member

left a comment

Instead of "request changes" this should be "consider changes." ;)

var nodes = instance.graph.nodes();
var max = Math.max(...nodes.map(x => x.size));
nodes.forEach(x => {
if (isFinite(Math.log(x.size + 1))) {

This comment has been minimized.

Copy link
@ianmilligan1

ianmilligan1 Jun 6, 2018

Member

I found the scaling up and down a bit too gradual - it was hard to notice anything was happening.

Changing the x.size +1 etc. values to + 2 makes it a more vivid change, and I think is still granular enough to be useful. But I'm also happy to be convinced about using +1. 😄

@ruebot

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

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.

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

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

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

Going to try rounding to resolve the fmap error.

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

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.

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

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.

@ruebot

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

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

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

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?

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

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).

@machawk1

This comment has been minimized.

Copy link

commented Jun 6, 2018

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.

@machawk1

This comment has been minimized.

Copy link

commented Jun 6, 2018

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.

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 7, 2018

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?

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 12, 2018

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

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 15, 2018

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

Set state management for up and down.
@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 19, 2018

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.

@ianmilligan1

This comment has been minimized.

Copy link
Member

commented Jun 19, 2018

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

@greebie

This comment has been minimized.

Copy link
Contributor Author

commented Jun 19, 2018

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

Copy link
Member

left a comment

Just based on exploring with with @SamFritz yesterday - the tooltips popped out at me.

<span class="fa fa-level-up"></span>
</button>
<button type="button" id="modal-scale-down" class="scale-down" data-toggle="tooltip" title="Transform node sizes using log transform." disabled>
<span class="fa fa-level-down"></span>

This comment has been minimized.

Copy link
@ianmilligan1

ianmilligan1 Jun 20, 2018

Member

Was looking at these with @SamFritz yesterday.

"Transform node sizes by the power of e." is probably not going to mean much to a lay user. Is it possible to just use more straightforward language ("increase node size") and ("decrease node size") and then maybe connect with Sam and give her some suggested language to describe these in the AUK docs?

<span class="fa fa-refresh"></span>
</button>
<button type="button" id="scale-up" class="scale-up" data-toggle="tooltip" data-placement="top" title="Transform node sizes by the power of e.">
<span class="fa fa-level-up"></span>

This comment has been minimized.

Copy link
@ianmilligan1

ianmilligan1 Jun 20, 2018

Member

Same here as above

greebie added 2 commits Jun 20, 2018
@ruebot ruebot merged commit 9da5642 into archivesunleashed:master Jun 24, 2018
3 checks passed
3 checks passed
codecov/patch Coverage not affected when comparing 638b05a...3a5f218
Details
codecov/project 89.02% remains the same compared to 638b05a
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@ianmilligan1 ianmilligan1 referenced this pull request Jun 25, 2018
2 of 16 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.