Improve Web IDE panels and workflows to support with previews, traces, terminal and commits

@dimitrieh a sketch based on this mornings Web IDE discussion:

Your suggestion to split the commit interface out feels quite a natural, and I like how it removes the file list from the commit view which is not really relevant and consumes a lot of space. It also solves the problem of what to do with possibly open CI trace and web terminal.

An alternative approach could be automatically collapse the file tree when the commit panel is open. But it raises the question of what to do with the traces and terminal. We should probably explore both options as wireframes before settling on one.

/cc @sarrahvesselov

One way to things would be to only permit one secondary view to be open at a time, where the commit panel, job traces and web terminal would all be treated as a secondary view.

But, I really like the idea of finding a way to make the file tree disappear when review diffs and making a commit. I suppose it could automatically collapse? But I feel like that is more distracting than just completely changing modes.

@dimitrieh it struck me that one of the other aspects I like about have the commit panel on the left is that it means file lists are always on the left.

Tree list is a list of all files
Commit panel is a flat lists of files (with options beneath)

The sketch below uses a tab bar at the top of the list to toggle between All (normal file list) and Changes which is the commit panel.

I'm not sure about the always present Commit button a I drew at the bottom, but I thought it might help people familiar with Git work out what was going on.

@jramsay some notes:

Like having commit panel on the left if I am going to do a rigorous review -> commit
If commit panel on the right in edit mode, it allows for quick committing without reviewing
you will not commit stuff if you are actively testing something, different flows imo.

Figma ideation document for flows:

https://www.figma.com/file/YgEMUFpytYvZu6wsU53QdZ/Web-IDE-workflows?node-id=35%3A2

mentioned in issue #44846 (closed)

added to epic &71 (closed)

Summarizing progress, we are focussing on a three column layout:

┌────────────────────────────┐
│┌─────┐┌────────────┐┌─────┐│
││     ││            ││     ││
││  A  ││     B      ││  C  ││
││     ││            ││     ││
│└─────┘└────────────┘└─────┘│
└────────────────────────────┘

Left column (A) - project name/icon (context) and editor state, always shown
Central column (B) - primary area where project content is shown, always shown
Right column (C) - secondary information (project level), contextual and collapsable - e.g. CI traces, web terminal etc

IDE modes of use

The distinct modes of use we are currently considering are:

Edit: a user is trying to make a change to the project. This task might be supported by looking at a failed CI trace, verifying the changes using a web terminal, reviewing the description/discussion in an issue/merge request.
Review: a user is seeking to understand their changes in the context of the entire project. Is the scope of them sufficient? Has the broader context been considered? This task requires diffs, and access to the entirety of any file in the project. The review stage may in fact be two distinct stages:
- reviewing local changes not yet committed
- reviewing the entire set of changes of a merge request
Commit: a user is reviewing the immediately changes with the intention of selecting all or a subset of the changes to be committed as a unit, and writing a commit message describing what was changed and why it needed to be changed.

Left column

Currently always file tree. When committing, a change there is significant duplication if the file list, unstages changes, and staged changes are shown simultaneously. A single file could be visible in three lists, two of which will describe the same state.

We are exploring using the left column to describe and change the mode of the editor.

How might the left column handle switching between the three modes: edit, review, commit?
What information would the left column contain in each mode?
- edit: file list, changed/added files are highlighted
- review: file list, changed/added/deleted files are highlighted, maybe possible to switch between local changes, local + mr changes (if in context of MR)
- commit: unstaged/staged file lists with commit input box, options to create new branch/merge request

Center column

Currently this is where the content of files is shown, with a tab bar at the top. Only one file can be shown, but a secondary preview is supported.

How would the file specific secondary information work for:
- regex railroad: a visual preview of the specific regex selected by the caret, typically horizontal
- CI pipeline diagram: a visual preview of the entire file, likely horizontal
- markdown preview: a visual preview of the entire file, typically vertical
- linting errors: textual feedback of the code selected by the caret

Complex example: a markdown file with a Javascript code block with a regexp. The markdown should be rendered. When I move the caret to the regexp I should see regex railroad and JS linting feedback.

Right column

Currently this is the commit panel.

In the current proposal, it provide access to project level secondary information including:

CI trace
Web terminal
(idea) Issue description/comments
(idea) Merge request description/comments
(idea) Snippets

Each of these are information heavy, and in some cases interactive (web terminal: running commands, snippets: creating/editing/inserting a snippet).

Should we initially allow multiple secondary information of different types to be open simultaneously? For example web terminal and CI trace side by side?
Should we initially allow multiple secondary information of the same types to be open simultaneously? For example two different CI traces, or thee different web terminals (gdk run app, gdk run db, and rails console)

Edit mode

default mode to open when opening web ide

Review mode

Diff mode is editable (cc: @timzallmann @jramsay)
edit opens a dropdown similar to what we currently have to switch between the 2 diff review modes
edit dissappears when the ide has not opened from a merge request

Default review mode (latest changes)

Merge request review mode

This mode opens automatically if opened from a merge request

Commit mode

unstaged and staged icons are introduced
only 1 file can be opened at the same time
opens by default the file you had last open in edit/review mode (@jramsay I think we could iterate on this with a general all files diff blob view similar as in vscode/atom, when no files are selected)

@jkarthik could you post a copy of your sidebar layout design for pipeline details on this issue for reference? thanks!

Last things to do on this issue:

Visualize how the secondary information panel is going to look like. Consider bottom drawer vs sidebar (both?)

@dimitrieh Here you go.

Right Sidebar Collapsed

Right Sidebar Expanded

These are slightly rough mockups. Ideally, the tabs should look identical to the left-sidebar tabs in your designs.

How are we looking here @dimitrieh? Do you think we can get this completed in 10.8 along with your other assigned issues or do we need to push this off further? Please be frank about your time, don't try to do more than you can handle.

@sarrahvesselov I expect to finish this Friday and/or else at the latest next week. I will see @jramsay this week in the Netherlands in person, so the idea is to do some quick back and forths to finalize the last bits of this design, mainly for the secondary information panel (ci/terminal/etc). The essentials for 10.8 were already figured out

Great, thanks for the update @dimitrieh. I am going to roll this over to the 10.8 milestone as you are still actively working on it. cc/ @jramsay

changed milestone to %10.8

mentioned in issue #44604 (closed)

@jramsay as discussed here is the result of our discussions

We are going for a short-term design solution for the right sidebar for secondary information like terminal/logs etc. Short-term is a bit vague here, with this is meant we are choosing for a simpler solution without difficult (multi)window management which we do need in the immediate future. Also, we'll be reusing existing UI from the left for the right. We can adjust from there.

For documentation purposes, I'll leave some non-expanded screenshots of WIP mockups:

Here are the basic collapsed and expanded modes:

there is the potential to add additional tools or instances etc with the + button for example

Some potential examples that put this concept into practice:

Concept of https://gitlab.com/gitlab-org/gitlab-ce/issues/44316#note_68275067
- concept
Terminal concepts:

For now we can go with 1 terminal instance per app icon and don't worry too much with inner window navigation (like additional tabs).

For CE, we can simply hide the right sidebar

Would love to here any additional thoughts, otherwise I think this issue has sort of reached a conclusion.

cc: @sarrahvesselov

@dimitrieh I'd like to resolve the header of the tab a bit more. In those concepts there are quite a few different styles shown. I think the header should be consistent.

I also find it strange that the line doesn't extend all the way to the top when no tab is opened. (more like this https://gitlab.com/gitlab-org/gitlab-ce/uploads/08ff25a9e04e2b8ec84f075f22c36685/Right_Sidepane_Collapsed.jpg)

@jramsay makes sense, I had was thinking differently, but this works out better

Reusing header design of the left and also boldened so we align it with other headers throughout the interface:

Terminal concept example:

The following example makes better use of width, but works less well with our sidebar tab system

Thanks @dimitrieh - I agree the last mockup isn't as consistent and prefer the one before it because of it's consistency

@sarrahvesselov care to lob any UX grenades our way before we call this issue done

No grenades (this time ).

The only area that feels a little funny to me is the terminal. There is a white frame around it that is not present on the other sidebar. I understand why you did it @dimitrieh but I am wondering if it needs to go all the way around. It may make more sense for it to only exist on the side with the tab. I hope that makes sense!

No grenades (this time ).

hah!

@sarrahvesselov are you thinking of something like this?

are you thinking of something like this?

Yup, nailed it! WDYT?

Will this be wrapped up today @dimitrieh?

changed the description

@sarrahvesselov Done, updated description! This issue can essentially be closed.

added ~2024186 and removed UX labels

Done, updated description! This issue can essentially be closed.

Thanks @dimitrieh. I will leave it up to @jramsay whether he wants to move the designs to a new issue or simply roll this over to another milestone for development.

closed

Thanks @dimitrieh

mentioned in issue #46245 (closed)

marked this issue as related to #44846 (closed)

Improve Web IDE panels and workflows to support with previews, traces, terminal and commits

Proposal

Design

Designs

Child items ...