-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clicking on node #30
Labels
Comments
wking
added a commit
to wking/depviz
that referenced
this issue
Nov 29, 2016
As requested by Victor Bjelkholm [1]. [1]: jbenet#30
I agree with these o/ -- said more in #45 |
On Tue, Nov 29, 2016 at 03:13:05AM -0800, ᴠɪᴄᴛᴏʀ ʙᴊᴇʟᴋʜᴏʟᴍ wrote:
**Github Icon**: Open new tab with issue on github.com
**Issue title**: Navigate to that issue in depviz
I like having the host icon link to the host, because that's what the
icon represents. I expect the default meaning of links to be “link to
${link-content}”, not “link to this issue on ${link-content}”.
Similarly, we have the person image linking to that person's page, and
not to the issue somehow in the context of that person's page/site.
With this approach, the ID (e.g. jbenet/depviz#45) is the obvious
choice for linking to the native issue itself (e.g. [1]).
The problem with my approach is that all the real estate on collapsed
cards is gone, and we still need to bind “center on this card and
update the location” to something. #45 proposed a new
permalink/anchor button to get some space for this, but it doesn't
seem to be gaining traction.
@victorbjelkholm posted an example of how Waffle handles links to the
native issue (with the host icon and the comment icon both linking to
the native issue) [2], but that doesn't seem like an intuitive choice
to me (why the host icon, but not the person icon? Why the comment
icon, but not the title?). But consistency and intuition aside, I
agree that a link to the host is less interesting than a link to the
associated people. So I'm not very strongly against the proposal
here. I just feel like there should be an approach that gives us a
clear “center…” action without subverting the host logo.
I think the “link to this issue on ${link-content}” intepretation is
more obvious if there are *choices*. That's a bit hard for us, since
a GitHub issue is probably only going to exist on GitHub (for example)
and not also be mirrored on some other host. Maybe you could link to
GHTorrent or whatever? And if we have a small, boxy depviz logo (#14)
in that list, maybe it would be a good anchor for “center…”. So the
collapsed card would hold something like:
${ID} ${host-logo} ${depviz-logo} [${mirror-logo}…]
e.g.
jbenet/depviz#45 🐙ⓥ🐈
Then you could have the whole “${ID} ${host-logo}” span link to the
native issue, the depviz logo being “center…” (i.e. link to the issue
on depviz), and the mirror logos being “link to this issue on the
${mirror}”.
Or maybe I'm just overthinking this, and folks will get used to
whatever we pick ;).
[1]: #45
[2]: #45 (comment)
|
wking
added a commit
to wking/depviz
that referenced
this issue
Dec 12, 2016
We currently don't walk dependencies for closed issues, because they're not related to future progress. However, the completed-issue graph is useful for historical context, and Juan is interested in walking that graph [1]. To make this straightforward, we probably want a way to configure a hop-depth from a current node. But the current UI lacks a "current node" concept and we haven't settled on a UI for selecting nodes [2,3]. In the meantime, this patch gives users a way for users to drill down into the dependencies of any closed issue by clicking on its dependencies indicator. unwalkedDependencies is currently a bit sloppy, since it should be false if all of the parents have already been walked. The current implementation is good enough for a first pass though. [1]: jbenet#13 (comment) [2]: jbenet#30 [3]: jbenet#45
wking
added a commit
to wking/depviz
that referenced
this issue
Dec 13, 2016
We currently don't walk dependencies for closed issues, because they're not related to future progress. However, the completed-issue graph is useful for historical context, and Juan is interested in walking that graph [1]. To make this straightforward, we probably want a way to configure a hop-depth from a current node. But the current UI lacks a "current node" concept and we haven't settled on a UI for selecting nodes [2,3]. In the meantime, this patch gives users a way for users to drill down into the dependencies of any closed issue by clicking on its dependencies indicator. unwalkedDependencies is currently a bit sloppy, since it should be false if all of the parents have already been walked. The current implementation is good enough for a first pass though. [1]: jbenet#13 (comment) [2]: jbenet#30 [3]: jbenet#45
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, this is the behavior of clicking on a node:
Github Icon: Go to github.com
Issue title: Go to that issue on github.com
Clicking/Hovering depends/related/blocks icons: Nothing
Suggested behavior:
Github Icon: Open new tab with issue on github.com
Issue title: Navigate to that issue in depviz
Clicking/Hovering depends/related/blocks icons: Show what the icon means
depends on #33
depends on #45
The text was updated successfully, but these errors were encountered: