Skip to content
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

ListView - compact representation #62

Open
jbenet opened this issue Dec 11, 2016 · 6 comments
Open

ListView - compact representation #62

jbenet opened this issue Dec 11, 2016 · 6 comments

Comments

@jbenet
Copy link
Owner

jbenet commented Dec 11, 2016

On seeing this, many people have requested a List View. I think this is a good idea. I've mocked this up.

Notes:

  • can sort by deps
  • show all edges faintly
  • highlight edges on hover
  • easier keyboard navigation
  • may not need graphviz.

depviz mocks 013
depviz mocks 014
depviz mocks 015
depviz mocks 016


depends on #70

@wking
Copy link
Collaborator

wking commented Dec 11, 2016

For an issue list of any size, I expect having your related nodes all on screen is unlikely. We could keep your hover stuff, but add click-to-(un)select, which would hide all unrelated nodes. More on click-to-select in #30 and #45.

@wking
Copy link
Collaborator

wking commented Dec 11, 2016

Is the sort order something like:

function sortNumber() {
  return youAreOpen * bigNumber +
    sumOverDependants(dep.sortNumber()) / 2 +
    createdSecondsSinceEpoc / hugeNumber;
}

Where hugeNumber is big enough for creation time to just breaks ties, and bigNumber is big enough to avoid sorting a closed issue after an open issue.

@wking
Copy link
Collaborator

wking commented Dec 11, 2016

And is this orthogonal to expanded-ness? I.e. will links look like ?expanded=true&list=true or ?view=list? I like the former (with a wide version of the expanded card) because I really like seeing the title, and on non-phones we'll have a lot of spare width anyway.

An alternative would be to make the width responsive & add more data as we get space.

@wking
Copy link
Collaborator

wking commented Dec 14, 2016

And just to clarify, the dark red background and bold ID in your mocks are “this is the selected node”?

And the background grows to the right to represent the fraction of completed tasks within the issue (#18, like we have for both expanded, #8, and collapsed, #9, nodes now, although there the fill color is always green)? What happens when you select a task with tasks but no completed tasks? Is selection only shown through the bold ID? Or do we want to draw a border around only the selected card, or some such?

@wking wking mentioned this issue Dec 21, 2016
6 tasks
@jbenet
Copy link
Owner Author

jbenet commented Dec 22, 2016

  • not sure on that sort function. i would use something more strict, like actually walking the graph to determine order, and let ties be broken by dates directly, instead of collapsing it to one continuous function. that probably works, but looks complicated
  • expandedness could be designed here, but it should look different. emphasis here is to make a smoother list.
  • yes, the bolder one is the selected one. everything else should fade down to avoid visual overwhelming
  • yeah the background was shown here as a progress bar, though this could be a "progress circle" instead.
  • sure, we can use a border to help show the case of no progress and no graph to show

@wking
Copy link
Collaborator

wking commented Dec 22, 2016

not sure on that sort function

What do you think of listSortKey?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants