Discussion about our IDEs, their boundaries and the future.
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Here is the original slack thread
Hey there! I want to start a discussion about our IDEs, their boundaries and the future. Here is a small presentation. But I'll explain everything above
What do we have now
We currently have 5 editors. They are all hidden behind a select button, so the user can choose which one to use. But we also have a "favorite editor" and some users don't know about others. It's not so obvious where the boundaries are between editors and which one I need to use in my case.
High Level Use Cases
I would like to group our users by types of the work they do right now.
Case 1. One file fix. Basically it's about md files or other text files.
Case 2. Short flow with obvious end. For example MR review or small tasks without the environment.
Case 3. Full-time developer experience. So it's a long big tasks with the environment.
Case 1 — Single File Editor
If user wants to fix just one file, we have to help him do it. That's why I suggest to split select button on two: [Edit file] and [Open in Web IDE].
Why is this solution good:
- Not experienced users will find this button quicker. And experienced users will have the opportunity to start working from this file in IDE.
- Buttons work predictable, but not a select button with "favourite editor"
But we can't just add this buttons — it will be a mess. I suggested how to reduce the number of buttons on this page in this issue. Please, like it if you like the idea
Relevant issues
#388087 (closed) Reduce the number of buttons on single file page
Case 2 — Web IDE
For environment-free tasks Web IDE is perfect! It's fast, it's simple, and it's the VS Code that we are all love. But for tasks like Review MR, commit changes and others we can help users.
For example:
- I need to review a MR. I click on MR page [Open n web IDE]. Than I want to see GitLab extension with open MR tab. So I can see all changed files. Or maybe even open this files.
- For commit flow I'd like to add some other states of the sidebar: there are no changes, this branch is protected create a new branch, your changes successfully committed create an MR
Relevant issues
#386256 (closed) Open changed files when opening MR in Web IDE
Case 3 — Remote Development
This is the best solution for full developer experience. I believe that users know do they want to use remote server or not. So I think we have to show them this option on the project page and others.
But we still have a lot of question. And I'd like to start from this:
- Can we avoid of page reload for current solution when we open remote server? I'd like to see a smooth flow for user.
- Do we want and can we switch between projects in IDE/Remote?
- Will we connect to the same environment?
- How long will environment stay alive?
- Do we want to keep just Remote Development without the Web IDE? Or do we want to keep them both?
- Where is the entry point? It could be on project page or separate entry without chosen project
- Should any settings be user-, project- or organisation- specific?
- Do we want to remember non-GitLab servers and show users this option for fast connection?
It's not all, but we could start here.
Relevant issues
#384500 (closed) Should we have two IDE options: client-only and remote-enabled?
What do you think of this editors boundaries? What do you think of this changes especially for Case 1 and 2?
What do you think of Case 3? What do you think of everything?