Continue On... accessible through the Remote indicator

[kieferrm]

I observe myself clicking the remote indicator to get to "Continue On" and it's not there. Rather than a generic "Continue On" entry it might make sense to have for each remote group a separate one. Like "Continue on in a Codespace" in the second group.

[joyceerhl]

It looks like you are possibly in an empty workspace here (since you're in https://insiders.vscode.dev and there is no Continue On from Remote Repositories). Continue On is currently disabled in this scenario because I don't think we have any Continue On options which allow you to start in an empty workspace--currently they all assume you have a git or remote GitHub repository. Is this an empty workspace or a local folder here? What would you expect to be able to do in this scenario?

For the location of Continue On in the remote indicator, there was similar feedback here: #162119

[bpasero]

I also think the remote menu is a good place for "Continue on". However I also think that "Edit Sessions" and "Continue on" should be closer together and not disconnected. I find that "Edit Sessions" is the technical requirement to get "Continue on" working, but it is not so obvious.

I wonder if we should rather hide the "Edit Sessions" entries and make this all acessible via the concept of "Continue On". So the naming would be along the lines of:

• Enable to Continue on
• Disable Continue on

[joyceerhl]

I explored three options for surfacing Continue On through the remote indicator in desktop, since it's currently not there at all (and these proposals would also apply to the remote indicator in web). I think we would still want to retain the Continue Working On command which presents all options in a single list when entering the feature via the terminal and debug welcome views, so this mostly relates to how Continue On options are presented in the remote indicator.

Single top-level Continue On entry

This is the same as what we have in VS Code for the Web today, i.e. a single Continue Working On entry in the remote indicator that would now be present in web, desktop, and remote windows. It's compact but requires two clicks to get to the list.

top-level-continue-on.mp4

Separate Continue On category

This flattens the list of Continue On items into the top-level remote indicator, removing the need for two clicks, but it means that extensions which have their own remote group and a continue on contribution will appear in two different groups in this list, which can be confusing.

continue-on-group.mp4

Continue On integrated into each remote group

This integrates the continue on options into each extension's remote group. (NB there's an adoption cost here since the contributions would have different display names depending if they're shown in the Continue Working On... picker or inline with the extension's remote group)

integrated-continue-on.mp4

cc for feedback and suggestions @aeschli @daviddossett

[daviddossett]

At a glance, I prefer option 1 despite the extra step since it solidifies the concept of "Continue Working On" as a top-level task. I don't feel like I have to think when I see that.

2 somewhat buries that value props and the options feel a bit like we cherrypicked items from the list below. I'm also not sure most users would read the section label since it's aligned to the right. So we might miss out on users making that connection to "Continue Working On" when they see it elsewhere.

3 is nice but, to me, too closely couples to specific extensions with the concept. They will also potentially be lost in this long list if a user is just scanning through.

[aeschli]

To me, the remote menu is more for connecting to another machine. Many actions open a new window and that window is a remote window.
Continue On is more like an Open, or even more an Open Recent. I would therefore add something in the File menu, right after the Other Opens, or inside Open Recent submenu.

[joyceerhl]

It's true that Continue On from web RemoteHub to desktop RemoteHub / desktop git clone or from desktop RemoteHub to a desktop git clone don't relate to connecting to another machine per se, so I can see how it may make sense to instead move it to the File menu:

It doesn't feel like a fit for Open Recent to me though, since Continue On transfers your current working context to a new development environment, and 'recent' implies a window I have already visited before.

[bpasero]

Can we UX discuss this Wednesday before making a decision?

[joyceerhl]

Yes definitely, I intentionally made the impl a draft PR.

[joyceerhl]

@brettcannon had related feedback on wanting a Codespaces: Continue On in a Codespace command palette action in slack:

I was viewing the action as, "I want to go to this place," not, "I want to take my edits somewhere." So the destination was what I had in mind, not the fact that I wanted to generically move my (future) edits to another place as I had not done anything (yet).

[joyceerhl]

I have added support for one-step actions like Codespaces: Continue On in a Codespace in the command palette (requires a new release of the Codespaces extension and latest VS Code Insiders.

@aeschli since some but not all Continue On options deal with opening a remote, what would you think of surfacing the one-step actions which relate to remotes in the remote indicator in their specific categories? i.e. Dev containers and Codespaces would have actions in the Dev containers and Codespaces categories which say 'Continue on in a (Codespace | Dev Container)'.

[aeschli]

Codespaces: Continue On in a Codespace fits very well in the remote menu.

In fact now I realize that it's about the reopening the current folder in a remote location. The same what already have for Dev containers (Reopen in Container) and WSL (Reopen Folder in WSL).
So I would even suggest to consider using Reopen: instead of Continue On: Reopen in Codespace