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

Menu Panel Improvements! #1193

Merged
merged 13 commits into from
Oct 19, 2024
Merged

Conversation

daslyfe
Copy link
Collaborator

@daslyfe daslyfe commented Oct 14, 2024

  • instead of closing the menu with an x button, it can now be "pinned" or "unpinned" when unpinned, hovering over the menu pops it open
  • improved styling and mobile device compatibility
  • improved readability of reference page on sidebar and mobile views
  • default panel now set to bottom, because it has the best readability for the reference page and the best device compatibility
2024-10-14.12-48-04.mp4

@felixroos
Copy link
Collaborator

felixroos commented Oct 14, 2024

pinned mode looks useful!
i probably wouldn't default to bottom panel, because the different views work better with more height and less width imo. the reference will get more space with #1174 ( list of functions gets whole panel width, on click it shows only the selected function + a way to get back to the list )

@daslyfe
Copy link
Collaborator Author

daslyfe commented Oct 14, 2024

pinned mode looks useful! i probably wouldn't default to bottom panel, because the different views work better with more height and less width imo. the reference will get more space with #1174 ( list of functions gets whole panel width, on click it shows only the selected function + a way to get back to the list )

the main reason I defaulted to the bottom panel was because it works better on mobile and in side by side setups, I can change it back though if that is preferred. The vertical window looks better on a single standard computer screen window, but usability suffers in other setups imo

I think the lag problem could be solved by using virtualization like this: https://github.com/bvaughn/react-window

@felixroos
Copy link
Collaborator

pinned mode looks useful! i probably wouldn't default to bottom panel, because the different views work better with more height and less width imo. the reference will get more space with #1174 ( list of functions gets whole panel width, on click it shows only the selected function + a way to get back to the list )

the main reason I defaulted to the bottom panel was because it works better on mobile and in side by side setups, I can change it back though if that is preferred. The vertical window looks better on a single standard computer screen window, but usability suffers in other setups imo

I think the lag problem could be solved by using virtualization like this: https://github.com/bvaughn/react-window

I'd expect a standard screen to be the most common way to use strudel, as live coding on mobile is not the most convenient. On mobile the difference is that you'd get a split view, instead of a full height view right (width is full in both panel orientations)?

I also wonder how to close the panel when it's full height and no code editor is visible?

Good point with https://github.com/bvaughn/react-window , tho it might still be preferable to have a detail view, to get more width for the reference. When each function has its own page, it might also be more welcoming to add more content to it with more examples / guides etc..

@daslyfe
Copy link
Collaborator Author

daslyfe commented Oct 14, 2024

pinned mode looks useful! i probably wouldn't default to bottom panel, because the different views work better with more height and less width imo. the reference will get more space with #1174 ( list of functions gets whole panel width, on click it shows only the selected function + a way to get back to the list )

the main reason I defaulted to the bottom panel was because it works better on mobile and in side by side setups, I can change it back though if that is preferred. The vertical window looks better on a single standard computer screen window, but usability suffers in other setups imo
I think the lag problem could be solved by using virtualization like this: https://github.com/bvaughn/react-window

I'd expect a standard screen to be the most common way to use strudel, as live coding on mobile is not the most convenient. On mobile the difference is that you'd get a split view, instead of a full height view right (width is full in both panel orientations)?

I also wonder how to close the panel when it's full height and no code editor is visible?

Good point with https://github.com/bvaughn/react-window , tho it might still be preferable to have a detail view, to get more width for the reference. When each function has its own page, it might also be more welcoming to add more content to it with more examples / guides etc..

I think one of the benefits of full a full page of docs is that it encourages you to explore and read through and find things. The reference page does look much better on the vertical mode in this update at least.
That said, I think deeper docs pages for functions would also be useful!

I know at least one person who is performing with multiple versions of strudel on a different android phones. Probably an outlier though! This update also ensures that the panel in vertical mode can never take up more than 80% of the view width.

On a side note I think it would be great to have better mobile compatibility in the future in the UI. Way more people in the world have access to smartphones than laptops after all. I sometimes start projects on my phone and its not too bad other than some fiddly ui things.

@daslyfe
Copy link
Collaborator Author

daslyfe commented Oct 15, 2024

@felixroos updated the default panel position to be dependent on user's screensize (under 1000px the default will be horizontal) This solves for mobile compatibility as well :)

@felixroos
Copy link
Collaborator

that's a good way to set the default i think! still 2 things...

  1. I wonder how the sidebar animation fares with the recent discovery of slow/expensive css transitions on older machines.
  2. I am not sure about is if it's a good to always have this "hot edge", where you accidentally move close with the mouse and the sidebar comes out. It can be a bit annoying on a big projection. I've seen someone write a python script to avoid moving the mouse to the top of the screen to avoid the address bar to come out, so maybe this is worth thinking about. I'd maybe prefer to be able to close the sidebar and only get it back by clicking something, so maybe the close button is worth keeping?

I hope I am not being too nitpicky.. If you want you can still merge it and we'll see how it pans out.

@daslyfe
Copy link
Collaborator Author

daslyfe commented Oct 19, 2024

that's a good way to set the default i think! still 2 things...

  1. I wonder how the sidebar animation fares with the recent discovery of slow/expensive css transitions on older machines.
  2. I am not sure about is if it's a good to always have this "hot edge", where you accidentally move close with the mouse and the sidebar comes out. It can be a bit annoying on a big projection. I've seen someone write a python script to avoid moving the mouse to the top of the screen to avoid the address bar to come out, so maybe this is worth thinking about. I'd maybe prefer to be able to close the sidebar and only get it back by clicking something, so maybe the close button is worth keeping?

I hope I am not being too nitpicky.. If you want you can still merge it and we'll see how it pans out.

I dont think the sidebar animation should add much at all in terms of performance, it is very short and not continuous. I know what you are talking about with the topbar behavior in browsers and that is super annoying. This feels a lot better imo because it is off to the side, and if you choose to unpin it you can keep it out of the way when you are performing until the moments you need it. The experience for me has been a big improvement anyway. Maybe lets give it a shot, and if it turns out that some people dont like the behavior, I can add an option in the settings to revert the open and close behavior to how it was previously. Zen mode is still an option as well.

@daslyfe daslyfe merged commit 835c7b6 into tidalcycles:main Oct 19, 2024
1 check passed
@daslyfe daslyfe deleted the orgin/daslyfe/feat/pinmenu branch October 19, 2024 02:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants