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

Plots: Improving the Grid #1254

Closed
sroy3 opened this issue Jan 27, 2022 · 4 comments
Closed

Plots: Improving the Grid #1254

sroy3 opened this issue Jan 27, 2022 · 4 comments
Assignees
Labels
A: plots Area: plots webview, side panel and everything related 🎨 design Needs design input or is being actively worked on story Product feature aka epic. Discussion, progress, checkboxes for implementation, etc

Comments

@sroy3
Copy link
Contributor

sroy3 commented Jan 27, 2022

Currently, the grid for the plots is built following these rules:

  • No matter the size of the plots, they will arrange themselves in rows as long as they can fit one next to the other
  • For large plots, we initially set the width to be 100% of its parent (the whole screen for now) minus its padding (20px). Once the plot has reached a width of 1000px, it will stop growing and align itself in the center until there is enough room for another plot to fit at its side (the parent being at least 2060px [1000px * 2 + 3 * 20px] [max_plot_width * 2 + left_gap + middle_gap + right_gap])
  • For regular plots, we initially set the width to be 50% of its parent with a gap of 20px between the two 50% plots. Once the plots have reached a size of 500px, they will stop growing and align themselves in the middle until there is enough room for other plots (1, 2, or more) to fit at their side.
  • For small plots, we initially set the width to be 33% of its parent with two gaps of 20px in between the plots. Once the plots have reached a size of 300px, they will stop growing and allow other plots to fit at their side once there is enough room.
  • For multi-view plots, they follow the same rules as above, except that their width and max-width are multiplied with the scale of the plot. The scale is calculated by the number of revisions of the plot. If there are two revisions in the plot that is regular size, its width will now be 50% * 2 and its max-width will be 500px * 2.

Drawbacks from These Current Rules

The bigger the size, the longer it will take for another plot to fit on the row when the plots have reached their max-width. For example, between the window sizes of 1040px and 2060px, the plots will appear pretty much static.
When the window is extra small, small plots might look very small. At a window size of 400px (the user might place multiple web views next to another), a plot would have a width of 106px.

Possible Solutions

Media Queries

By using media queries, we could further fine-tune how the plots react when resizing the window. That means that we could have the large plots be 100% of the screen until it reaches 1000px, then the plots could be 50%. With similar rules for the regular and small plots. We could then avoid the max-width and have plots always taking the maximum space, which would make things more fluid.

Let the User Do the Resizing

We could remove the plots sizes entirely and let the user resize the plots, either individually or all at once. Resizing them individually would allow total control to the user, but it could become a nightmare to manage when there are too many plots. Resizing that way could also be problematic when resizing the web view.

Allow Zooming

It could also be interesting for the user to see multiple plots at once (small or regular size) and then zoom on a certain plot to analyze. This could be done while applying the current rules and media queries.

Conclusion

I think that by adding media queries to what we currently have, we could make the current grid much more fluid, all the while continuing to use the current sizes.
The user resizing the plots would be a lot harder to manage for us and possibly the user.
Zooming on a certain plot could be a nice addition in the future.

@sroy3 sroy3 added story Product feature aka epic. Discussion, progress, checkboxes for implementation, etc A: plots Area: plots webview, side panel and everything related labels Jan 27, 2022
@sroy3 sroy3 self-assigned this Jan 27, 2022
@shcheklein
Copy link
Member

@sroy3 thanks for the summary, and I like the idea with making them smaller/larger at certain break point to allocate all space. That will be a good improvement.

Let the User Do the Resizing

I think this is not even an alternative, but rather an expansion of the current idea and can be done as a next step on top of the media queries step. I would say, we should go this direction. I think it's fine for all of them to keep the same size first within a section even they are resized individually. As far as I understand it should be pretty straightforward, right?

@sroy3
Copy link
Contributor Author

sroy3 commented Jan 31, 2022

For the user resizing the plots, I have a few questions:

  • Do we also keep the current sizes?
  • If we keep the current sizes, should it change to "custom" when resizing? ("custom" wouldn't really be an option to pick, it would only be in the dropdown when the user has resized the plots)
  • Does it reset when we resize the window?
  • Do we save the custom size so that it is persistent?

@sroy3
Copy link
Contributor Author

sroy3 commented Jan 31, 2022

#1263 adds media queries to the plots grid and the comparison table.It improves a lot, but there are a few edge cases that need to be discussed and reworked.

  • The first breakpoint is 1000px. From that size, we have 2 large plots, 3 regular plots and 4 small plots side by side. This breakpoint is best for large and regular plots, but makes small plot a little bit too small. One way to fix this is to not change the size of the small plots at that breakpoint, but then regular and small plots would be the same size. We could also increase the breakpoint, but that might be making the large plots a little too large at that same size. I'm not sure we can get this one perfect.

Screen Shot 2022-01-31 at 3 57 55 PM

  • There might be something about the comparison table looking the same when there is only one column, but I need to test a little more before.

@sroy3 sroy3 mentioned this issue Apr 20, 2022
@shcheklein shcheklein added the 🎨 design Needs design input or is being actively worked on label Apr 20, 2022
@maxagin
Copy link
Contributor

maxagin commented Jul 23, 2022

Great stuff @sroy3 👍
What you have put together is very helpful. Closing this for now.
I will be reflecting here:
https://github.com/iterative/design/issues/31
https://github.com/iterative/design/issues/34

@maxagin maxagin closed this as completed Jul 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: plots Area: plots webview, side panel and everything related 🎨 design Needs design input or is being actively worked on story Product feature aka epic. Discussion, progress, checkboxes for implementation, etc
Projects
None yet
Development

No branches or pull requests

3 participants