POC: First draft of the panels/tabs functionality #204
Conversation
|
✔️ Deploy Preview for modest-rosalind-098b67 ready! 🔨 Explore the source changes: 72b7298 🔍 Inspect the deploy log: https://app.netlify.com/sites/modest-rosalind-098b67/deploys/61b75d2e109b5500072cde22 😎 Browse the preview: https://deploy-preview-204--modest-rosalind-098b67.netlify.app/ |
|
Hey @magicmatatjahu! First of all, nice work and POC you put together and thanks for the description helped gain context. Here are some UX questions/improvements I have
When clicking the vertical or hoziontal buttons on each panel, I'm not sure its required to ask for I see I can close sections by clicking "Delete Panel", I wonder also when removing all pages within a panel should also do this. I can see I can remove/add pages within panels, but when I remove all of them, I cannot remove the last one I wonder when user presses
At the start the left (nav panel) shows a loading spinner ( I guess it's waiting for me to select what I want to do in my panels).
Maybe at the start we could just hide this loading panel, then show it when we need too? Maybe we could always have the Terminal at the bottom rather than having it optional? I guess each tool could integrate with this terminal and show errors for tools etc, if user does not have it they might have issues with their Async doc, but not know as the terminal is hidden by default?
Thinking about it, I wonder if we keep the tools on the left, but rather than For example, loading the studio loads the spec and nav as usual. Clicking on Visualiser (or other tools) could load it in a tab (or another panel) and keep going, then users could see everything at once if they like or just close the panels if they no longer wish to see stuff.... just a thought! Anyway let me know what you think, It's a great POC nice one ! |
|
@boyney123 Thanks for awesome feedback!
I know exactly what you are talking about and I think we will go in the direction you described, however I would also like to be able to open the panel at the bottom or on the right and here is the problem, because if we go with the solution proposed by you then how to open the window at the bottom which will be only one? Something like:
🤷🏼
🤔 yes you're right, it's more natural and in VSC also it works in that way. I will change it, thanks! 💪🏼
Do you mean some dropdown? 🤔 It can be way. @mcturco you are really need here 😂
Yeah, it's a "problem" with current solution 😅 You should at least one time open the Editor, because in current source code editor "parse" spec and nav and html/visualiser only works with parsed spec. Don't worry, we will change that, but PR is only a POC to show idea and we will by iteration add new things :) I wrote in PR's description that I have a lot bugs in PR, but I don't wanna focus on them, only show draft of idea :)
I only wanna to show that we can open everything in tabs :) Of course terminal will be "pinned" to the Editor and also user will be able to open terminal as standalone view, but I don't wanna make a lot of things in the PR, but don't worry I will remember about that :)
Yeah, it's one of solution. We can go with that direction, when you click on the nav item in the left nav then it will open in the new tab the given tool, but we can also leave "+" tab button. What do you think? Maybe @mcturco will have some insights about good UX here? :)
❤️ What do you think about that part
? |
|
Wow great stuff, @magicmatatjahu & amazing feedback, @boyney123 !! 💪 See below for my comments.
I have to agree with @boyney123 here, I was also very confused about those options. I think we could actually consolidate the options on each panel to just one dropdown when you click on the three dots. Then, the options will be: Let me know if that suggestion makes sense! Then, if it is possible, I think it would be great if you could drag around panels to re-organize them to your liking.
I second this!!! Great catch, @boyney123
Agreed! I think it could be a dropdown (white background) with the options and maybe an icon & mini-description for each one to make it easier to choose.
I think that it might be best to just show the streetlights example as a "default" and then users will adjust as needed. What do you guys think?
IMO, I think we should keep the navigation there. There's a big chance that current users of the Studio are used to this behavior, so we don't want to confuse them or make them re-learn the system. I agree with @boyney123 that when you click any of these nav items that it should just open a new panel automatically, then it would be ideal to click and drag them around to organize your workspace. Then, if you toggle the nav buttons, the panels should just show/hide in the position that you arranged them in. This is very exciting! I can see this being a huge improvement as we add more function to the Studio over time 💪 |
Thanks! ❤️ and thanks for feedback! :)
No one requires you to make mockups right away, just take it easy and when you have time you will make them :)
🤔 I left in the tabs the icons to open next and below due to fact that also in VSC they are visible. We can leave the icon for opening horizontally and move to the dropdown the icon for vertically. What do you think? @boyney123 What do you think?
Yeah! I also thought about drag and drop but tbh it's not easy as it looks (😅 ), but we should go with that direction :) I very like solution in VSC, where you can exactly drag and drop panels and also tabs in the different panels. I will think about that :)
You should read my comment about that:
It will be improved, to support multiple AsyncAPI documents, don't worry! :)
Yeah, agree with you and with David, but I think that if someone click on the nav item, then it should open that tool as new tab in the "active" panel, something like in VSC. If you have two panels, and if you click on some file in the file explorer you exactly open that file in the given panel.
I think that nav items should only open tool in new tab, not show/hide that :) I will change code to show idea :) |
|
@mcturco @boyney123 Ok I fixed some things and added new:
Have fun and if you will find any problems/bugs please inform here :) Things to implement:
|
|
Woohooo! @magicmatatjahu
I actually don't think it needs the vertical split... I quite like the organization of just having the columns!!
This is awesome!! Very excited to see the functionality added of dragging and dropping panels around.
This I was a bit confused about when I was playing around with the changes before reading your explanation... To be more specific, I was not sure what the function of the circle was until maybe 5 minutes into exploring the new link. I think an easy solution for style of active window is as shown below in this quick mock up:
As you can see, the left panel is active and has a solid white border around it. I think then we can just remove the circle and leave the functionality of making the panel active if you click anywhere in it. In addition, I have a suggestion for the action where you are dragging the icons with the pink plus buttons on the left side to a new quadrant. See below: Add to Left Panel - Hover: Add to Right Panel - Hover: So basically, both panels get dimmed similar to how you have it now, then we are removing the thick pink dashed border from each column and instead we will add a transparent light gray (I think I used gray 300 here) with a thin solid white border when you are hovering over the panel with the add icon. Let me know if that makes sense! Here's something I caught when I was playing around: I'm not sure why the scroll bar is there on the right side as it doesn't scroll much of that panel and the editor has its own scrollbar within that. Probably just a height thing?
And last thing: I am thinking because there is no limit to the amount of panels you can add to left and right, the icon to add a new panel should probably have a plus button in it somehow... Not sure if there is already an icon in the lib that you are using but just something that I thought might communicate that action a little better. Everything else is great!! 😄 💯 |
|
@mcturco Thanks for great feedback! It is very helpful :)
Thanks! I tried to propagate your suggestion about that grey border when panel is active and I have big problem with box-sizing 😅 it doesn't look good, so I tried to add opacity in 50% percent to non active panels. You can check this (panel where is editor is active):
I propagated your idea, but that grey background is only showed when user will hover given panel - like in VSC :) I hope that's good :)
🤔 Do you use another browser than Chrome, because I don't have any problems?
Unfortunately (probably) there isn't any better icon. We exactly use icons from Visual Studio Code, you can check all available collection - https://react-icons.github.io/react-icons/icons?name=vsc and the current icon is probably the best, but I'm opened for suggestion :) In the future we can add limit of panels to 3 or 4 :) Thanks! |
I see what you mean. After messing around with the chrome inspector, I think I came up with a solution. We would add a
I think this should resolve that box-sizing issue of everything shifting around when the active panel changes
This looks great, thank you! 😄
I use Chrome too, so I'm not sure why I am the only one who can see this! I was looking in the styles for an explanation as to why that is even showing up but I couldn't find anything so far.
No problem, as I was looking at VSC again I realized that they are using the exact same icon for this type of functionality, so I think it works for now! |
|
Hey! Sorry taking me some time catch up on this. @magicmatatjahu wooow, love the improvements very nice!!
Loving the drag and drop stuff, it starting to feel very very nice! Good job man.
@mcturco yeah I quite like this, I like what you did with the change of color on the tabs themself, but if you could highlight the panel itself too, would be good. I know you had some issues with it, but just some extra feedback!
@mcturco ha, yeah odd! I don't see any of it, glad you do though, finding issues we can't see 🤣🤩 @magicmatatjahu @mcturco yeah I quite like the design where we have the + next to the widgets on the left (nav bar). Like VSCode ( I think ) I would personally just add the new widget to the first window/tab view and then allow users to split if they want. This is kinda behavior on VSCode when I add / view a new file. It shows as a tab in my current window then I can drag where I want. This is looking slick, nice work @magicmatatjahu @mcturco 👏 |
|
Kudos, SonarCloud Quality Gate passed!
|
|
@magicmatatjahu this is looking awesome. Have you considered the possibility of forking VS Code for Web? We'd get all of this for free plus compatibility with VS Code plugins and themes too. |
|
@fmvilas Thanks Fran for the feedback! I've been thinking about it too, but there are a few issues we would have to deal with (if we decide to use "forked" VSC for Web):
I don't want it to sound like I'm looking for any excuse not to use VSC instead of writing everything from scratch, but we need to keep in mind the problems I described above. I would like to have as little work as possible and the effect would be amazing but using VSC will not be that easy. If we actually consider VSC as a base then I think we should focus on the VSC plugin and not our studio, but here we have to remember about points above (especially 3). A regular VSC plugin also has the problem (in addition to the above) that not everyone uses VSC and IntelliJ users would have to migrate to VSC when developing AsyncAPI. With our integration Studio + CLI, someone can use IDE that prefers and use Studio only for additional action like rendering the docs, visualiser, bundler etc. At the end I want to mention that we now have full control over the Studio and the code is not that difficult to understand. Additionally Studio can go in the direction of not only creating AsyncAPI but also providing additional things from community like extension registry. In VSC it will be very difficult to make this available. What do you think? |
|
Agree, it will be harder to get started.
Then, what's the point of mimicking the VS Code functionality of panels in Studio? I mean, wouldn't it be better if we encourage the user to link Studio with their favorite IDE instead? This way we keep Studio simple and we provide a simple editor in case someone wants to touch something there. For writing long files from scratch, I honestly would prefer to get back to my favorite IDE where I have all sorts of plugins, snippets, key bindings, etc. I think having the concept of projects and multiple files (in the middle panel, where the current file is) is useful but, again, I'd encourage people to link Studio with their file system instead. I think the UX would be superb compared to what we can offer with an editor in the browser. |
|
@fmvilas This is a good observation why we need panels if we are going to focus on integration with CLI, but we also do not know what tools inside the studio people will use and in what configuration, I mean how many at once on a single view, and panels+tabs help with that. At the moment it don't actually makes sense, because we have only two tools unrelated to the document editing (HTML and Visualiser) but if we will have more? E.g. configuration that people can see linting (terminal), documentation (HTML) and dependencies between operations (Visualiser) in one view and every tool should be visible? It may be that we end up without tabs, but the idea of panels will be strongly needed. Take into account that tabs are not only for files but also for tools, in one panel you can have several tools opened and each tab keeps its state. If we have 2 panels and we need to switch between 4 tools, this state will be forgotten (it's a implementation details but related to the UX - I'm talking about the local state of the component/tool). |
Interesting. I have the opposite feeling 😄 I think tabs will be much needed, for editing multiple files. However, we already have a "Terminal" panel at the bottom of each file. This panel can, at the same time, have tabs like
Yeah, just as we have right now with Playground. You don't need unlimited tabs, only one per tool. And the state can be preserved too. To be clear, I'm not against this PR. I'm just curious where we should be drawing the line of "this is for the IDE" vs "this is something we should implement too". I have the feeling we're going too far and we're providing little value to the developer because they already have an IDE that's always going to be better than our Studio. |
You may want to have a terminal without an editor.
I disagree that one per tool is a good (and final) option. It should be up to the user. If I will have a final vote, let the user have the option rather than not have it.
Thanks and I appreciate it :) I also don't want to make another IDE out of the studio either, but I've been testing both SwaggerHub to see the options and Stoplight studio and the first thing that caught my eye (even before implementing this PR, about a month ago, when I set up this issue #167) is that there are maximum two panels. Another thing about Stoplight studio is that when you edit a spec but you have it divided into models in separate files, you can't open those models side by side, but only one file in one editor (without several at once), the same way I wasn't able to open linter next to editor as well as html preview, seeing all tools at once and I had to click between new views in their application. It was a bad UX experience. We should do this better 😄 |
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
|
@magicmatatjahu what about this PR? Are you going to continue on this one or starting a fresh one? |
|
@fmvilas It's very outdated PR, but it still have some good code, for example for tabs and drag&drop functionality (we will implement drag&drop for files and tabs later, don't worry), so I wanna reuse some parts and then we will close it - I don't wanna close and delete branch. |
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
Description
First draft of the panels/tabs functionality:
I tested several react libraries to handle split views and only https://github.com/johnwalley/allotment https://github.com/microsoft/vscode/blob/main/src/vs/base/browser/ui/splitview/splitview.ts has only good solutions, similar to split view from VSC, but it still lacks some necessary things (like dynamic showing/hiding panels, hardcoded size etc) and has numerous bugs. Most probably we will go in contributions to this library, or just write our own based on source code from VSC - https://github.com/microsoft/vscode/blob/main/src/vs/base/browser/ui/splitview/splitview.ts 🤷🏼 I opt for second option, but we should discuss it.
Feedback are more than welcome! :)
cc @boyney123 @mcturco @jonaslagoni (I ping you because you opened issue for supporting multiple AsyncAPI docs)
Related issue(s)
See #167