Closed willzeng closed 2 years ago
Just a comment: Since this come up again in one demo, as the current graph being not helpful, and in case deploying the substitute graph may take some time, I propose to first remove the current visualization, and then add the graph with the nested list or once the solution is agreed upon and tested.
+1
On Mon, Dec 6, 2021, 9:18 AM Nathan Shammah @.***> wrote:
Just a comment: Since this come up again in one demo, as the current graph being not helpful, and in case deploying the substitute graph may take some time, I propose to first remove the current visualization, and then add the graph with the nested list or the solution is agreed upon.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/unitaryfund/metriq-app/issues/347#issuecomment-986983823, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZDAUZS5P7PYTX2YLSPQLUPTV4TANCNFSM5JCCJ34Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Agreed. I'll remove the force simulation view right now, before the next demo.
This, of all current issues, is particularly important in function for presenting the taxonomy. Let me figure out an implementation.
After adding "seed data," I'm about to open a PR that restricts task and method index views to just top-level items. From the top level, users can click into child tasks and methods, to drill down to more specific topics.
I looked through freely licensed accordion views, for the purpose of displaying an arbitrary depth tree, and I wasn't impressed with the options, for our purpose. We might add a field that can filter all tasks/methods in the index views, but starting at top-level and clicking through to children works better than an accordion. This is being tracked in #411, and we can close a number of related issues at once, for that PR.
+1 to an eventual accordion view and doing top level in the meantime
On Tue, Feb 15, 2022, 2:48 PM Daniel Strano @.***> wrote:
After adding "seed data," I'm about to open a PR that restricts task and method index views to just top-level items. From the top level, users can click into child tasks and methods, to drill down to more specific topics.
I looked through freely licensed accordion views, for the purpose of displaying an arbitrary depth tree, and I wasn't impressed with the options, for our purpose. We might add a field that can filter all tasks/methods in the index views, but starting at top-level and clicking through to children works better than an accordion. This is being tracked in #411 https://github.com/unitaryfund/metriq-app/issues/411, and we can close a number of related issues at once, for that PR.
— Reply to this email directly, view it on GitHub https://github.com/unitaryfund/metriq-app/issues/347#issuecomment-1040724062, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZDAVT2TM6NFAGBYKPQX3U3KU2LANCNFSM5JCCJ34Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
There are 2 problems I notice with the accordion views that are freely licensed, based on the fact that most of them use indentation to show hierarchy. Firstly, I don't find the tree structure very clear at a glance based just on indentation of the items. Secondly, at arbitrary indentation depth, the views would become a mess, for overflow and line-wrap.
However, now, I'm about to take the UI we liked from top-level categories presented a couple of Fridays ago, apply that to the (newly hierarchical) task and method index views, and add flattened hierarchy text filter "searches" to the top of both index views. I think this is faster and easier than multi-level accordion views. However, we'll review at the weekly meeting, and we'll be eager for your critique.
@willzeng Given the new top level tasks, which let us click through the child hierarchy successively, and considering the addition of the global text filter on the tasks page, do we really need this as well?
In particular, I didn't like how the tree view packages I found on the NPM registry handled multiple levels of nesting. I worried that our hierarchy would tab right too far, after several nesting levels, and it would hurt aesthetics and make the tree harder to understand. I'm also not sure where this proposed view naturally fits, now that the tasks index page has been updated.
For the reasons explained above, I'm considering this closed by the other UI changes to the task index view. Please reopen, if we want to discuss further.
The network graph has some drawbacks for displaying a hierarchy:
Replacing this with a nested list (think reddit comments) adds to readability and scalability.
For example something like: https://commonmark.org/help/tutorial/10-nestedLists.html
@WrathfulSpatula @vprusso please do add if there's more from our previous discussion that isn't captured here or if this is a duplicate.