Currently when you connect to a SSH host, you land in an empty window. From here you can then open a folder or open a workspace on the remote host.
While this makes sense in principal, in talking with @chrisdias and seeing a few people do it for the first time, it's not immediately obvious what to do next. This creates a rough on-boarding experience for new users.
I'd propose we instead:
Once you've initially opened a folder or workspace, you can access it again via the SSH explorer, so optimizing for the first time experience seems to make sense here.
//cc: @chrisdias @roblourens @kieferrm
We talked about this initially but currently we don't have a way to pass some parameters through to the new window. It could be encoded in the remote authority but I don't think that's the right place for it.
If developers do not want to open a folder, they can then hit "ESC" and do something else instead.
The ESC is a problem, it will confuse. I guess we could have a dialog that lets you select files, folders or workspaces.
@roblourens, Given the effort, @aeschli brought up a good point here that we could consider as a starting point to help orient people.
The empty window first also solves some issues for us. One issue is that we have 3 different artifacts you can open: files/folders and workspaces, with 3 (MacOs: 2) different commands and keyboard shortcuts.
I suggest we make the empty window experience better, e.g. by showing a welcome page with prominent open buttons.
This welcome page could also include other features people may not be aware of like port forwarding in the SSH case given we can hyperlink commands. So it isn't annoying, we would show the welcome page the first time you get a new window for a given connection type - any SSH host or WSL, but in the SSH case we probably wouldn't need to do it for every time you connected to a new host.
We could potentially do this for containers as well, but you end up opening a folder to get the config, so it is probably less critical there. You very much open with intent in that case -- even in the remote docker case. There's also a proposed Open Workspace in Container command to address that gap (#387).
Extensions don't have a way to contribute to the welcome page today we either need to open this up or we open a custom welcome page the same way other extensions have done. If open folder is the key problem, we can for example always show the file explorer on first connect to a remote host with an empty window. There we have a big Open Folder button.
@kieferrm Hmmm. That might help -- but I think the main problem is it looks like your local empty window, so it's not obvious that the connection actually worked unless you know where to look. Pointing to what should be done next would resolve that... we could fall back on a one time notification, but we know that UX is getting to be overused. A one time custom page might be more useful.
+1 on @chuxel first post. I basically wrote this in another issue:
This empty VSCode window does provide any useful functionality and we want to get the user as soon as possible out of this. The only thing that the user can get out of this is that he is happily connected to remote.
I propose that once the connection is made that we automatically show a quick open dialog and offer the user to choose a remote folder to open.
I understand this is not the pattern that we commonly use, however we already have some multi step quick open actions for remote, the only difference here is that one of the steps is opening a new window.
This opening of a dialog should only be done after the user invoked the "Connect to a Host" action, not every time he is in an empty window on remote.
The alternative would be to make sure the explorer is opened, and we could tune the empty explorer text. To change the wording that it is clear the the user is opening a folder on the remote.
I simply prefer the first approach since I believe it is more straight forward to the user and we skip this state where the user can no do anything useful.
To @aeschli point since we use a custom dialog we could support that the user can select anything just like on the mac.
As for the techinical difficualty of opening this remote dialog on a new window. We could support some new parameters or there might be something we could already use @bpasero
There is currently no parameter to my knowledge that opens a new window and then opens a remote file dialog.
The challenge we have in Remote is the same we had in the local case and we mitigated/solved by introducing the welcome page. In the Remote case we also supports editing individual files or opening folders. Therefore, opening a modal dialog on top of a new window to hint the user at what they could do next is not a great idea. We could
Recent as those are all local when you use Remote for the first time@kieferrm I can look into opening the explorer by default and polishing the message there if you think that is best?
@kieferrm @roblourens I tried the SSH, and have a couple of questisons / feedback
workbench.view.explorerUnrelated to that I am still not convinced that automatically opening quick open is not the best way to go here. As for Kai's argument that users can still edit individual files and open folders -> for both those activites they need the quick open first. As far as I understand the quick open supports opening both. I am simply not aware of any action a user can do that does not require first to use quick open.
Let me know what you think
@isidorn
About 1) This is an interesting idea. We'd then miss an action to open a new empty window on a SSH box since "New Window" opens a local window. So, we can't simply change the behavior here without impacting other areas.
About 2) Sounds good. Need to find a good trigger for calling the action.
About 3) How about: "Connected to ${host} via SSH". The "Open Folder" button would still be right below, so I think we can omit the call to open a folder in the text.
Connect to Host with Empty Workspace.... Also I would introduce this action only if we see users complainingvia SSH, since that is specific for only 1 extension. I think a cleaner way would be to have something in common for all remote extensions. I'll check this in the afternoonI made the following experimental change in the SSH extension: If the workbench is empty and no welcome page is shown then reveal the explorer and open the terminal.
I have pushed the changes to the empty view in the explorer.
So let's see how this behaves. The text has no "ssh" hacks, it simply says Connected to ${host label}, the same host label which is shown in the status bar. This solution is nice since it works for all remote cases. In case the remote is not yet connected it simply says "Connecting..."
I would also suggest changing 1), though leaving that up to @kieferrm
Let me know if I can help more.

About 3) How about: "Connected to ${host} via SSH".
馃憤 but let's keep in mind that the message should also be tuned for the other authorities WSL, Containers, but also consider contributed ones (e.g. Cloud Envs).
@egamma yes, my solution covers all those cases.
Yeah the early results from the interviews with full-time SSH users @bowdenk7 has been driving have indicated a 50/50 split between whether they were confused at first when they hit this or not. It was never considered a big problem, however, as they all figured it out - but each were very experienced SSH users. They also all were opening a folder when they first tried out the SSH extension (not a file or VS Code work space). The unprompted suggestion was usually to go right to open folder as a result. On the containers side, we need more data, but the open folder behavior it has seemed to meet with expectations.
That said, we can get a bit more insight from part-time users to understand how confusing/painful this actually is for them. Pain was low for full-timers. What is described here seems like a good first step to me -- we can compare the full-time feedback to part-time users as we talk with more of them formally this week and decide if we need to do more.
- SSH: connect to host does not remember my previous folder, it always enters a no folder vscode. Is it possible that this action remembers the last active folder in that SSH connection? This way the user would not end up in the empty folder experience this often
- If we decide that showing explorer is the best way is it possible for the ssh extension to simply execute the following command once the connection is established
workbench.view.explorer
Is there any progress on the suggestions 1 and/or 2 of @isidorn in the comment dated June 21, 2019?
Specifically, my usecase is to land into the previous opened folder once I ssh into a server.
Note : The present setting is such that if I ssh into server A , open folder A_f and close vscode, I would land into A_f the next time I ssh into A only if I had not sshed into another server B .