Join GitHub today
x/pkgsite: provide multiple "copy to clipboard" options #38514
What is the URL of the page with the issue?
Any package page (e.g. https://pkg.go.dev/github.com/sirupsen/logrus?tab=doc)
What is your user agent?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36
What did you do?
Click the "Copy path to clipboard" button
What did you expect to see?
What did you see instead?
I almost never want an import statement; I want something I can copy into a
Sharing some additional relevant information, in case it's helpful.
Gerrit has a "Download" button. Pressing it opens a dialog where multiple text boxes appear, each with their own copy-to-clipboard button:
I'm not sure that more than 1 way of copying the import path is really needed, but if so, I've found the above UI to work well to solve that problem.
I can tell you the current behavior bugs me greatly, as either:
Having a clipboard button next to a package name, then clicking it and the clipboard containing something entirely different than what I thought I was copying is not my preferred UI. If a "copy to clipboard button" is next to a piece of text, I expect to copy that text. I have to remember that it's going to do this, and select the name I want somewhere else, eliminating the button from my workflow entirely.
godoc.org doesn't have this problem. It has the import statement at the top, where someone could select just the name or the import as desired, or use the URL bar (which contains no query params).
I just want the button to do "what it says on the tin".
Apologies, I totally missed this in the description.
That makes total sense as a use case. As does, I would suggest, wanting to paste directly into code. i.e. we have multiple use cases.
So as I understand it we have a number of options (and at this point I defer to @julieqiu and team) not limited to:
I don't think this is a necessary step, per my points above. There are an unknown number of people who are happy with the current value (modulo the point below about the poor UX of the copied value being different from what is shown) who are not providing feedback here.
The motivation behind inserting the
I understand and empathise with the use case. Per my comments above, assuming we can and want to support this in the UI/UX, this doesn't need to be an exclusive choice between use cases.
I would suggest this is worthy of feedback in a separate issue; however, if you want to use the copy-pasted value from an unadorned import path for other reasons, you'll continue to be able to in a world with multiple options via UI/UX wizardry.
This is a good point and one I 100% agree with. It should be addressed. FWIW the motivation behind wanting a different copy-paste value came from godoc.org, where the full import directive is shown:
I get your point in that there has not been a broad survey of this, but in our sample size of the 8 people who've shown up on the issue tracker to talk about this, only 1 seems to be in favor of
I agree wholeheartedly that it can be a mistake to please the vocal minority, but one wonders in this case which side that applies to.
Based on the various Go packages I have seen over the years, I'm willing to bet that if you took a survey of all Go code, you would find that the vast majority have multi-line imports statements with parens. Therefore it seems that in the majority of cases we are getting an extraneous
To me, it's very easy to:
It's also very easy to type
I think it was a good spot that this was dropped from pkg.go.dev and I do like having the import statement there in the Godoc version, but to me the value is communicating to the reader how the package is used. "Oh, so to use this I say
One thought on this: an even more valuable display of import directive would be in cases where the package name doesn't match the path.
Let's take this example: https://github.com/graarh/golang-socketio which godoc shows the import for as
import gosocketio "github.com/graarh/golang-socketio"
I can make this the subject of a separate ticket but I think it's worth discussing in the context of what's valuable about having the import path in the docs.
Yes, agreed, multiple use cases can be good.
I think this is where the philosophies diverge. If we can only have one copy option, I believe we should go with the least common denominator (just the path) and users can type
There can be further debate, but I think the best solution here is to devise a header that enables:
(As a note, Godoc displays both the package path and the import statement, as you can see from that screenshot snippet.)
I think you misunderstood my point. People are coming here because they also see a problem with the current behaviour. People who do not have a problem with the current behaviour are not coming here. So there is a selection bias. That there is a selection bias is not a problem, indeed it's totally to be expected. My point is simply that we need to be aware of that. Incidentally, I'm only commenting to give some context/rationale behind my previous issue on this.
But in any case, it's not worth dwelling on this point. We should instead focus on what we are solving for here.
Let me also be clear: my goal is not to defend the position I laid out in #36809. What I was and am trying to solve for is to help come up with the best possible solution, given various constraints. I'm absolutely not an expert in UI/UX design, indeed I'd prefer to defer to @julieqiu and team to help steer the process.
I wouldn't describe myself as having a philosophy on this
I now agree with your point that the least common denominator of a bare import path is almost certainly the "best" option if we only have a single copy UI/button/whatever, because it achieves exactly the goal of satisfying the greatest number of people with minimal impact on their workflow.
That said, I also agree with this as a proposed way forward:
I did actually understand your point! And it's very good to consider this for any issue. I was trying to point out that #36809 had selection bias as well, that's all.
Great, thank you!
Ideally @julieqiu & team can consider this as part of their broad, ongoing review.
My 10c is there's almost no world where
I usually end up just highlighting it and ctrl+ins it rather than using the button.
I agree that this would be the best way forward, and we are planning to add this feature in an upcoming round of design updates.
In the meantime, it seems like having the copy button only copy the import path is the least surprising behavior, so we can revert #36809.
Ah I see. Indeed, #36809 did have a selection bias, totally agree. But the basis for the change was to make pkg.go.dev more like godoc.org, but with the addition of the copy button. The one thing that was missed (as was pointed out above) in that change was that the copied value differed from the text shown, which is a jarring UI for sure. Notwithstanding that point, I think we're headed in the right direction now, thanks @julieqiu!
The copy button at the top of a details page now puts just the path on the clipboard, rather than import "path" Updates golang/go#36809. Updates golang/go#38514. Change-Id: I7f475d0415f67a4ff72e95abef750d2604717a51 Reviewed-on: https://team-review.git.corp.google.com/c/golang/discovery/+/722967 Reviewed-by: Julie Qiu <email@example.com>