I quite like this for the niche of "medium to slow reply rates" + "larger posts" + "participants who are willing to thoughtfully participate in structure" + "participants interested in discourse" (that is, people who want to record their fully formed thoughts in a thread, or who want to structure persuasive arguments, rather than casual conversation or sniping).
In other words, ideal for dueling essayists, technical RFC documents, or professional/academic debates.
I see there as being 1-2 additional tricky problems to solve for something like this (other than ironing out UX kinks in the implementation, of which there are many--e.g. visual signifiers for overlapping thread sources outside of tree mode; a tree mode that allows users to browse responses without manually expanding things; making "conclude" meaningful):
The first is optional, but I think it would be valuable: in many contexts, discussion and collaborative writing overlap substantially--often more than they don't. It would be interesting to see how the notion of addressing/concluding threads could be tied to changes in the document. E.g. a thread for "I'm onboard with this proposal if we alter the paragraph this is rooted at to contain X because Y" -> "If it gets you onboard, I'm happy to make this change, how about <proposed rephrase>" -> approval/conclusion causes the document to be updated and the thread archived. While that's technically not hard to add, the question is whether bringing in those aspects of mutation/collaborative editing would dilute the utility of the discussion layer, resulting in a shitty Google Docs/shitty Discourse combo, rather than a single-purpose Discourse-but-better application.
The second problem I see isn't optional: thread topology needs to be mutable somehow. In addition to all the valid criticisms of forum/Slack/email-thread discussion formats, any significantly-sized discussion of a complex root document inevitably develops redundancies. You end up with Slack (or whatever) threads cross-linking to other threads ("as I said over here, <content that either may be invalidated with time or which breaks user flow to navigate to another discussion location>"). That leads to significant confusion, and more than a few cases of people making decisions based on stale information as the cross-references get more complicated. Sure, ideally everyone would root discussions at the single most relevant point of their parent content, and new contributors would carefully browse the existing tree to ensure that their contributions were on both the freshest and most germane leaf. But that's never going to happen in practice, so a tool like CQ2 needs some way to rearrange (or embed-with-live-updating, or make rooted at multiple sources rather than one, or something...) discussion trees.
I have no idea what this would look like UX-wise. The 4chan model solves the replies-that-are-relevant-to-multiple-places issue, but doesn't help with re-parenting/consolodation after the fact to make future readers' lives easier, nor does it deal with staleness issues caused by replies linking to intermediate posts on threads which changed consensus later on. Regardless, I think functionality like this (even if it were used infrequently, by curators or administrators) would make the difference between things like CQ2 being useful only for short-to-medium-lifespan discussions with small numbers of participants, and being useful for discussions that stand as long-lived artifacts on their own.
Thanks so much! Loved reading this. Both of the problems are very interesting and it would be fun to go deeper into them. Would love to stay in touch with you. Can you send a hi at anandbaburajan@gmail.com?
In other words, ideal for dueling essayists, technical RFC documents, or professional/academic debates.
I see there as being 1-2 additional tricky problems to solve for something like this (other than ironing out UX kinks in the implementation, of which there are many--e.g. visual signifiers for overlapping thread sources outside of tree mode; a tree mode that allows users to browse responses without manually expanding things; making "conclude" meaningful):
The first is optional, but I think it would be valuable: in many contexts, discussion and collaborative writing overlap substantially--often more than they don't. It would be interesting to see how the notion of addressing/concluding threads could be tied to changes in the document. E.g. a thread for "I'm onboard with this proposal if we alter the paragraph this is rooted at to contain X because Y" -> "If it gets you onboard, I'm happy to make this change, how about <proposed rephrase>" -> approval/conclusion causes the document to be updated and the thread archived. While that's technically not hard to add, the question is whether bringing in those aspects of mutation/collaborative editing would dilute the utility of the discussion layer, resulting in a shitty Google Docs/shitty Discourse combo, rather than a single-purpose Discourse-but-better application.
The second problem I see isn't optional: thread topology needs to be mutable somehow. In addition to all the valid criticisms of forum/Slack/email-thread discussion formats, any significantly-sized discussion of a complex root document inevitably develops redundancies. You end up with Slack (or whatever) threads cross-linking to other threads ("as I said over here, <content that either may be invalidated with time or which breaks user flow to navigate to another discussion location>"). That leads to significant confusion, and more than a few cases of people making decisions based on stale information as the cross-references get more complicated. Sure, ideally everyone would root discussions at the single most relevant point of their parent content, and new contributors would carefully browse the existing tree to ensure that their contributions were on both the freshest and most germane leaf. But that's never going to happen in practice, so a tool like CQ2 needs some way to rearrange (or embed-with-live-updating, or make rooted at multiple sources rather than one, or something...) discussion trees.
I have no idea what this would look like UX-wise. The 4chan model solves the replies-that-are-relevant-to-multiple-places issue, but doesn't help with re-parenting/consolodation after the fact to make future readers' lives easier, nor does it deal with staleness issues caused by replies linking to intermediate posts on threads which changed consensus later on. Regardless, I think functionality like this (even if it were used infrequently, by curators or administrators) would make the difference between things like CQ2 being useful only for short-to-medium-lifespan discussions with small numbers of participants, and being useful for discussions that stand as long-lived artifacts on their own.