Change "Search workspaces" to "Enter workspace ID" and disable contextURL search.

[laushinka]

Workspace ID search returns quite fast, and searches usually do use the workspace IDs.
Therefore we will only allow workspace ID searches and disable the free text search.

[laushinka]

Cc-ing @geropl in case you disagree or have other thoughts 🙏🏽

[geropl]

@laushinka Thx for the ping.

Therefore we will only allow workspace ID searches and disable the free text search.

Thoughts:

• 💯 agree with "disable free text search"
• we should allow to search for workspacenId and instanceId
• either we keep the code that try to guess from the given input - or add a dropdown to specify the searchtype explicitly (with [workspaceId, instanceId])
• if we choose the dropdown, this is straight forward to extend later on, e.g. for contextURL (once we indexed that). And can be replicated for the user search (email, accountname, etc.)

[laushinka]

• we should allow to search for workspacenId and instanceId

@geropl Do we know in which cases or how often we search with instanceIds? If we go for now with guessing from the given input, it's very fast for workspaceId but still slow with instanceIds.

cc @jldec

[laushinka]

@gtsiolis I'll probably need your design input for a search dropdown 🙏🏽

[gtsiolis]

@laushinka I've added this to product design board to take a look later.

[laushinka]

@gtsiolis Thanks! And it doesn't have to be a dropdown, something like a search with radio buttons would also work?

[gtsiolis]

Breaking down the issue, here're some thoughts:

1. Removing free text search that tries to search across all fields like context, projects, etc sounds good! 💯
2. Keeping search visible and simple[1] is a good UX practice. To this extend, I'd vote for keeping a simple search input instead of adding complexity ahead of search using a dropdown and definitely include a default option if we need the option to do so
3. Introducing more filters later on that can narrow down search as described in Change "Search workspaces" to "Enter workspace ID" and disable contextURL search. #8453 (comment) sounds better and definitely worth exploring, see also Introduce better filters or search options for the global workspaces list #8419. For example, in the projects list it could be intersting or useful to search within a team scope, in the workspaces list it could be intersting to search for specific teams using query parameters like team: gitpod. This is also common in search engines with key-value search[2][3] or using regexp[4], etc.
4. However, we still haven't figured out the best way to surface context information like this in the workspaces list, see Improve the context column information #3594. This will be also useful in the new workspace modal improvements in Design improvements for the new "New Workspace" modal #8088 for surfacing context, etc.
5. While the admin dashboard matures as we add more functionality it will become clearer where users can search for what kind of information, like projects, teams, or workspaces.
6. The change in [server] use owner and repo name for workspace id #7391 introduced new workspaces names (IDs) that are based of the username and project itself, making it easier to search for project within the workspaces list.
7. Currently the workspaces list includes unnecessary or duplicate information that can be skipped or consolidated in future iterations as we focus on improving the workspaces list now that we also default to /workspaces when loading the dashboard.
8. Taking into account Change "Search workspaces" to "Enter workspace ID" and disable contextURL search. #8453 (comment), does it make sense to search for an email on the workspaces list and not the users list?
9. Given that teams and projects are growing as the best way to use Gitpod, does it also help to search project names or context URLs when the workspace name (ID) already contains most of this information?

Taking the above into account, changing the backend to search only across workspaces names (IDs) as described in the issue sounds good. However, I agree that the placeholder Search Workspaces sounds a bit abstract and could be misleading but also currently follows the pattern we're using across the product for all search inputs.

What we could also do is either keep the input placeholder as is or improve this by rephrasing the placeholder to be more explicit. For example, using Search by workspace name or simply Search by name sounds like an improvement. What do you think? Cc @laushinka @geropl

CURRENT	Option A	Option B

Sorry for the lengthy comment! 😇

[laushinka]

@gtsiolis Thanks for the comprehensive comment! Definitely a lot coming down the road and that's good to know.
Keeping it simple for now works, as long as admins can find the workspace they need quickly.
I can create a ticket already as a follow-up to improving the workspace (or any) search, so we make sure to schedule it and put ideas there 🙏🏽 cc @jldec

So the minimum changes here we can make are:

• disabling the free text search
• only allowing workspace and instance ID searches (I was leaning towards only workspace ID searches but from @geropl's comment it seems that instance ID searches are important)
• rephrasing the placeholder. @gtsiolis I'd propose to stay with "ID" instead of "Name", i.e. "Search by Workspace ID or Instance ID"

[laushinka]

8. Taking into account Change "Search workspaces" to "Enter workspace ID" and disable contextURL search. #8453 (comment), does it make sense to search for an email on the workspaces list and not the users list?

If I understand your question correctly, should we allow searching for emails on the workspaces list? I haven't run into that usecase, but if there is please let me know.

9. Given that teams and projects are growing as the best way to use Gitpod, does it also help to search project names or context URLs when the workspace name (ID) already contains most of this information?

This was also a question I had - what admins actually need to search on regarding workspaces. It seems that usually when there are customer issues, we ask for their workspace IDs and contextURL to investigate (Gero and Jürgen can correct me if I'm wrong). Down the road we can allow contextURLs again, but for now workspace IDs should suffice.

[gtsiolis]

Regarding #8453 (comment):

If I understand your question correctly, should we allow searching for emails on the workspaces list?

@laushinka I was playing devil's advocate here. I also think this is not a useful or valid use case. 😈

This was also a question I had - what admins actually need to search on regarding workspaces.

I think just the workspace name (ID) suffices when it comes to customer support but I could be wrong. Cc @geropl @jldec

---

Regarding #8453 (comment):

1. To clarify, with workspace ID we're both referring to the workspace name here, right?
2. I'd be in favor of using a less scary term than ID here but I'll leave this up to you to decide. Both options can suffice.
3. Is there a use case where admins search for a workspace ID or a workspace instance ID in the admin?

[geropl]

I think just the workspace name (ID) suffices when it comes to customer support but I could be wrong

IMO workspaceId is by far the most important one, so fine to take that approach as MVC.
instanceId, however, is also used during debugging. But as this is mostly done with DB connection open, the additional lookup in those cases is ok for now.

[gtsiolis]

IMO workspaceId is by far the most important one, so fine to take that approach as MVC.

Thanks, @geropl! Makes sense and probably would solve 90% of the use cases, right?

Later on we could introduce better ways to debug or discover workspace instance IDs from the admin dashboard while browsing workspace IDs, too.