Hacker News new | ask | show | jobs
by lonelyasacloud 1247 days ago
> This. To me, it seems like a weird market blind spot. Most of the tools in this space can't even do a proper tree - typically they limit you to 2-4 levels, like "project", "task", "subtask" and "checklist". The few that don't, stick to the tree model, even though work naturally structures itself into a DAG.

I did wonder that myself. But having tried implementing, I'd wager that deep many-to-many parent-child relationships are not directly visible more often is because no one has figured out good paradigms [1] to surface the functionality in a way that users would want to use most of the time (witness MS Project) versus the alternative tags, saved search, etc approaches.

[1] It's a fairly chunky challenge. Consider for example, what happens, and how is it presented to the user during the simple operation of removing an item. What happens when it has multiple parents? What about if it also has child dependencies? What about if some of those children have different ancestors? And it must be undoable and also needs to be usable on the limited screen estate of a mobile phone? ...
1 comments
TeMPOraL 1247 days ago
> I'd wager that deep many-to-many parent-child relationships are not directly visible more often is because no one has figured out good paradigms [1] to surface the functionality in a way that users would want to use most of the time

I suspect that might be a big part of the reason. I believe [0] that one big change that happens when you "upgrade" from a tree to a DAG is that you lose the ability to visualize your model in a compact and direct plaintext form

Sequences you can print an item per line, or separate by commas. Trees you can visualize with indentation, possibly decorating with some form of arrows. But DAGs seem to require you either use indirect references[1] (or duplication, which is just a more verbose and limited form of references), or give up and start drawing arrows and boxes. There's a qualitative jump in difficulty here - you (or rather, the software) needs to start thinking about layout, which is pretty much a non-issue with trees.

The biggest problems are with the evolution of the data structure. Trees and sequences don't "jump around" when you add or remove single nodes - edits cause, at worst small local rearrangement, and the rest of the tree is shifted to make/take space. DAGs are the first stage in this "from sequences to graphs" progression at which any single edit could force you to re-layout the entire visualization to keep it readable.

I have one nit though:

> And it (...) also needs to be usable on the limited screen estate of a mobile phone?

This is true now, but it wasn't true just a few years ago. Where are all the products from the last decade, that didn't have the "design for smartphones" constraint?

--

[0] - I strongly suspect this to be a mathematical fact, but I haven't encountered a proof of it.

[1] - If you want to keep parents next to their children, you're almost always forced to start doing things like:

  #1=Parent1 ----v
  Parent2  ---> Child1

  Parent3 ---> Child2
           #1# --^
... which kills readability, as now the reader has to keep a cache of those labels and dereference pointers in their head. If, instead of references (like #1#) you just duplicate the node (e.g. write "Parent1" again), the reader still has to keep a mental map of which nodes are represented multiple times in the text, and which are just similarly named.
link