prefix workspace URLs to avoid clutter in browser history to improve readability

[HBehrens]

1. Today, Gitpod creates unique workspace URLs, in the form of https://ab5ed640-d67b-4b53-96b2-02991973fc43.ws-eu03.gitpod.io/#/workspace/some_name.
2. This is leading to a growing number of URLs (in the browser's history) that may start with common characters such as characters "a", "b", "c", "c", "d", "e", or "f".
3. When entering URLs the the browser's address bar, this results in suggestions of addresses that are
   a) probably not, what the user wants (e.g. instead of Amazon.com you may end up with a long-obsolete Ab5ed640-d67b-4b53-96b2-02991973fc43…), and
   b) difficult to scan, if you do want to share a link to a workspace or preview but the address is truncated

I am proposing a change from today's format in the form of

• <guid>.<region>.gitpod.io/#/workspace/<human_readable_id>
  to something in the direction of
• gitpod-<humand_readable_id>-<guid>.<region>.gitpod.io#/workspace

The idea here is that the leading "Gitpod-" allows for easy distinction from other services such as "Google" (see 3a). Following with the human readable ID allows for convenient scanning and address recognition, e.g. when sharing preview URLs (see 3b) even if the URL is truncated in the UI.

[svenefftinge]

Timely feedback :) as I'm currently working on changing the URLs to something more human readable. That however would not add a stable prefix (e.g. gitpod-), yet.
I have actually not exerienced nor heard anyone running into that issue. I'm using chrome most of the time (other browsers only for testing) and it doesn't propose me workspaces when I type a single letter. Maybe that is because I don't go back to the same workspace a lot. Also, Chrome seems to match any word of the URL and denotes hyphens as word boundaries, so prefixing with gitpod- might not help with showing false positives.

[svenefftinge]

Also in my PR I propose [color]-[animal]- as a human-readable prefix. I wondered if we should use the project name instead, as you suggested. It’s for sure more memorable and provides better context. I’m just a little concerned about deriving project names and making URL parts of it. We'd for sure need to clean/shorten/lengthen them, but that shouldn't be a too big problem. We could also just make that optional, i.e. seeding the URL generator with one or two names and it would then decide whether and how it uses those given words.

[csweichel]

Timely feedback indeed.
I'd be a weary that the gitpod- prefix makes the already quite long workpace URLs even longer. I reckon, if anything, we'd want them shorter (e.g. #2905).
While using the project name would make the URL more memorable, normally workspaces are fairly short-lived and one wouldn't need to remember them anyways (too idealistic/aware from reality?). Also, we'd have to make sure we can still keep narrow matching expressions for those URLs to keep prefixed stuff from breaking (think a project named blobserve or preview or something like that).

[HBehrens]

I have actually not exerienced nor heard anyone running into that issue.

@svenefftinge , I am using Safari where it seems to value most-recently / -frequently addresses higher

Being still inexperienced with Gitpod, I am not entirely sure how one would manage their personal workspace URLs but from my limited understanding I cannot see how lengthy URLs are a problem. I agree with @csweichel – workspaces are short-lived and "remembering" them a secondary concern. If anything, they should go "out of the way" and not mix with "normal" URLs a user interacts with as stated in my point 3a, hence the suggestion of a prefix to act as a "namespace".

Coming to think of it, most value of adding the project name to the URL would probably occur when sharing a workspace with other people as they may want to recognize the expected project before following the link. Such as share URL is structurally different already in order to generate a new workspace (URL) once followed, right? In that case, my previously remark 3b is less of a concern.

Anyway, I am not aware of the many edge cases involved (e.g. pattern matching is a good remark!) and mostly wanted to provide feedback about the inconvenient completion handling in my browser's address bar.

[gtsiolis]

FWIW, I could reproduce this with one (1) character for a new browser user with limited browsing history in Chrome, however, I don't think this could be an issue for regular users with a significant amount of browsing history as Chrome prioritizes search terms over URLs in the search omnibox input. You have to explicitly disable the #omnibox-drive-suggestions flag to prioritize URLs over search terms.

Regarding Safari, this seems to be specifically related to the Top Hit feature which has been an issue in many cases outside the product.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.