Gitpod: Improve the way you process URL's by appending gitpod.io/#...

[nmaxcom]

First time I come up with this great product. I read a bit about the features and so on and in my mind, there was dangling around the part of "Prefix any GitHub URL with gitpod.io/#".

I prefixed a GitHub repo I was taking a look at to try Gitpod (a good way to generate leads BTW, congrats). So Gitpod started loading the environment, calculating things aaaand... finally giving me an error:

We have trouble parsing your context
Error: Couldn't parse context 'blabla/bla'.
Please file an issue if you think this is a bug.

As you can see, this error doesn't tell me anything at all; it might as well have read: "I dunno. I am not feeling it today".
I thought, what a shame, first time I try and a bug to my face, it looked nice. Right before closing the tab and go back to my things (having double-crossed gitpod forever in my mind) realized that gitpod.io/# had to be prefixed to the whole URL including the schema and everything.

I did gitpod.io/#blabla/bla when in fact it was gitpod.io/#https://github.com/blabla/bla

So yes, I screwed up, but I don't think is a very uncommon mistake to make for first timers. I don't know if you are logging these requests, I bet I'm not the only one. And your potential client sees a very lazy error and closes the site forever. This is so easy to fix you shouldn't even think about it.

I recommend parsing the string that's after the # with a regular expression to get the /blabla/bla part, whether the URL is complete or not. After all, you only want to know what is the repository.

Sorry for the length. Sometimes it's hard to convey how some little things can have a big impact and I go overboard.

[svenefftinge]

Thanks for the feedback. I agree totally. While we cannot parse any possibility, we should try and in case of failure tell the user what was expected rather than just telling the user it was wrong.

[nmaxcom]

That would be better than nothing, sure. But how come you can't read a URL and extract the part you want?

[svenefftinge]

Sorry, yes, of course we can in your case and probably a couple of others. Just not anything, so we should also make sure the error message is explaining what we expect so there is some action that the user can do.

[nmaxcom]

I understand. But why show an error message when you can accept both methods?

gitpod.io/#blabla/bla
gitpod.io/#https://github.com/blabla/bla

[svenefftinge]

We wouldn't show an error message as long as it is understood.

[nmaxcom]

As long what is understood? I'm trying to help you make a wise UX decision but for some reason, it seems we are not speaking the same language 😂 What's going on?

[jankeromnes]

Thanks for the great feedback @nmaxcom! Here is what I understand from this discussion:

1) gitpod.io/# should support more formats (e.g. user/repo in addition to https://github.com/user/repo), by being smarter / more lenient / having a look at what format people try if it's logged somewhere (@nmaxcom's point)

2) we should improve the error message, to make it much clearer what we expected behind the prefix (so that, if we really can't guess what users wanted e.g. with gitpod.io/#what is this, we still show a helpful message) (@svenefftinge's point)

Both are great points that we should address.

One thing that worries me about automatically supporting gitpod.io/#user/repo is, what happens if we want to start supporting GitLab, BitBucket, and other things? (For example, another cool idea we had was to support starting new projects from templates, e.g. with gitpod.io/#https://cdn.com/template.zip.) I guess that our desire to support more things in the future is part of why we didn't try to see GitHub repo URLs everywhere.

EDIT: To be fair, you also made point 2) in your original comment. Thanks again!

[nmaxcom]

Yes! Thank you.

Your point is very valid, if you want to expand, you'd be tightly coupled and that's not a good pattern. A couple of ideas come to mind: since people will paste 'gitpod.io/#' on the very site, you can take a peek at the referral info, like js' document.referrer. That should take care of all brand hosts.

As per the wild zip... I don't know the other website's schemas but I doubt they'll have a zip extension? You could also check first the metadata to be sure of what you are receiving and make a decision as to where it needs to go.

As a safeguard, you can show a simple message while you are loading what the system thinks it is. Something like "We're loading your GitLab repo" (with the GitLab logo for easy spotting), and below in a small font something like "it's not from GitLab? Please click here to pick the source".

You know, there are plenty of ways to do plenty of things :)

Good luck with the service!

[stale[bot]]

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.