Re the limiting to hardcoded 100 nodes without any criteria:

The best of the best is of course our https://phabricator.wikimedia.org/T4007 ;-)

In T4788#185751, @bd808 wrote:

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

In T4788#184537, @epriestley wrote:

so the UI should still look good given that edge-case.

Understanding the use case is important in choosing how the UI degrades.

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

Here's approximately where I'm headed with this:

I'm not particularly sold on putting context in the timeline, particularly because I think we've received about as much feedback about Differential having "too much stuff" as we have about this context being desirable.

@epriestley, I'm not expecting any particular solution, just as long as the list of subtasks is navigable in some sane fashion.

so the UI should still look good given that edge-case.

Although the new graph display has the branch-like display at the left, that column is removed from the task titles (2 columns away) - which aren't indented to clearly show the parent-child relationship.

@epriestley, the use case is actually from my content development department. It's hard to explain the task, but the hundreds of direct subtasks was unavoidable, and the project workboard did not work well in their workflow. Developing content for educational software can be extremely demanding. That said, I'll admit it isn't common to have hundreds of subtasks. Still, it is a scenario that can happen, so the UI should still look good given that edge-case.

I'm leaning toward making it a "Relationships" box with "Task Graph", "Mocks" (with a thumbnail/gallery view instead of just titles), and "Commits/Revisions" (probably with a little more status information than we currently show).

That would be perfect!

One possible solution might be to make "Task Graph" box "Task Dependecies" and have a separate tab for a straight list (default, parent/sibling only) and graph.

Just FYI, but on this install there's some weird rendering going on:

Turns out that CustomFields sort of just work properly with EditEngine out of the box, so D16226 provides a technically-functional dashboard.panel.edit, which allows you to edit text panels like this, for example:

We probably need to do almost all of this work before adding new panel types anyway, since building a new panel type on top of CustomFields would make moving everything from CustomFields to EditEngine harder.

FWIW we'd be perfectly fine with the following:

• allow editing phriction documents via Conduit
• create a panel which shows the contents of a specific phriction page

The actual panel transactions that we need to update for this aren't too bad. The board transactions are a little more involved, but we can skip them.

We can fix the highly-tractable web UI part, at least.

I'm moving this to "Rugged Terrain", as the best available pathway forward leaves us with dramatically higher implementation cost than the reasonable value of the feature. We can pursue this after tasks with better aligned costs and value are addressed.

This doesn't appear to even to be possible in Firefox. Here's a simple example:

From the Firefox bug and this linked one:

This appears to be stable, and is now accounted for.

This seem quiet and is now accounted for.

This appears functional and is now accounted for.

Haven't seen issues; now accounted for.

The upstream part of this is working in production, and this is now accounted for.

We haven't seen issues with this and it's now accounted for (I believe it's also in production).

This is accounted for and we haven't run into any issues upstream with it in production after using it for about two weeks, but let us know if anyone runs into issues deploying it.

Current task graph is great for visual representation... but can we get somewhere very simple list of blocks/blocked by?

T2637 cycles down to itself again

A few tasks (like T2637) are still drawing crazily enormous trees. I think our tasks are especially highly-connected and 97% of what I've looked at seems reasonable, so this might not be much of an issue for other installs, but I think we definitely need some kind of behavior where we hide the more distant parts of the tree once it gets too big.

No, no I can't. I can't make a Phriction Panel.

I might be able make a Phriction Panel

I guess that after some exposure, it would be clear; If we're prioritizing experienced users over new ones, it's fine the way it is.

It's clear enough to me that higher -> more parental. It might be nice to make T123 not a link and bold, like elsewhere, for easy copy-pasta.

Not a good idea, but an idea:

After looking through real-life applications, this now seems obvious and in @avivey example A is Parent of B. At first glance - there's relation. But yeah, arrows would help, only thing problematic is agreeing on arrow notation.

@avivey Do you have any ideas on how to make that more clear? I'm imagining it will probably be obvious on real data when you know what the tasks are and you'll get used to it pretty quickly, but maybe not.

in first glance, I'm not sure if A depends on B or the other way around:

Now it looks pretty and actually first glance tells something :)

Seems kinda good now? Could maybe use some style/layout tweaks on the table (I'd like resolved tasks to be more obvious, for example), but that graph seems like it's actually pretty good/useful to me at first glance. Need to poke around more.

wut

Woooo pretty pictures graph! Can't say I can deduct any task relationship from graph, but nevertheless, it's very pretty!

Looks like I didn't think that one through very well.

I'm pretty tempted to try using the "graph trace" interface to show task graphs. My major concern is that it task dependency graphs tend to be fairly wide and shallow (one task has many dependencies) while commit/revision graphs tend to be narrow and deep (long chains of dependencies). The element isn't as good at showing wide, shallow graphs. If a task has ten subtasks, we'll get a graph like this:

Regression possibly caused by this: https://phabricator.wikimedia.org/T137394