Better handling of che workspaces link, when using the link multiple time. #23402
Labels
area/dashboard
area/ux
Issues related to User Experience Design
kind/enhancement
A feature request - must adhere to the feature request template.
severity/P3
Lower priority than a P2. Optional work that might get done, or not. See also help wanted issues.
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your enhancement related to a problem? Please describe
Workspaces can be created / accessed via a URL (typically stored in a README) of the form https://<che_fqdn>#<git_repository_url>
As a developer, if I click for the very first time on the link, I would expect to get a brand new workspace for that project. It's working like that, great.
As the same developer, if later I click again on that very same link, I think it's fair to expect this should bring me to the existing workspace. Instead, I get a warning. Yes it gives me the choice to "open the existing one", or to create a new one, but this warning is a bit conterintuitive, and I think it's fair to expect it should just open the existing one, without warning.
The very fact that the url parameter ?new exists seems to imply that without the ?new, it should default to the existing workspace.
Now, I understand that the developer may at some point create multiple workspace for the same project (using the ?new parameter), and then, if that developer were to click on the normal URL, it would make sense to receive a warning "multiple workspaces exists for this project, which one do you want to pick?" But overall, I think most of the time, a developer will just want to click on the URL to re-open his/her unique existing workspace, and having to wait a bit, then click, then wait a bit will become annoying imho. Better to just default to open the existing workspace (wait a bit, then code).
Describe the solution you'd like
I would like that by default, when clicking an a workspace URL it brings me to:
Describe alternatives you've considered
Alternatively, a URL parameter of the form:
?existing
or
?existing=workspace-name
could be use.
Additional context
Note that I made these requests in the context of Red Hat OpenShift DevSpaces downstream project. I hope that what I wrote makes sense to upstream.
The text was updated successfully, but these errors were encountered: