[HN Gopher] New way to have complex discussions
___________________________________________________________________
New way to have complex discussions
Author : anandbaburajan
Score : 203 points
Date : 2024-05-06 18:02 UTC (4 hours ago)
(HTM) web link (cq2.co)
(TXT) w3m dump (cq2.co)
| mm263 wrote:
| How is this tool different from https://quip.com/? I don't see
| any features that set it aside except "Conclude" button.
| nmstoker wrote:
| It's open source (https://github.com/cq2-co/cq2) and not part
| of Salesforce, both appealling features. But deeper than that I
| have no experience of Quip (and precious little of CQ2 beyond
| the blog post) so can't comment reliably.
| wenc wrote:
| How is Quip different from Google Docs? Neither are discussion
| tools. (I use Quip a lot)
|
| Quip has almost exactly the same feature set as google docs --
| which part of quip were you referring to?
| nakedneuron wrote:
| We need to rethink the foundations.
| adamfeldman wrote:
| How does CQ2 compare to Zulip?
| rockooooo wrote:
| Zulip is more of a Slack-like instant chat system with
| threading as a first class citizen; CQ2 looks like threads only
| exist in the context of one "root" document vs a channel in
| zulip where threads can intermingle.
| s3r3nity wrote:
| This seems to be heavily inspired by Workflowy's "fractal
| comments" feature: https://workflowy.com/help/fractal-comments/
| chrisjj wrote:
| Google Wave again?
| daedalus_j wrote:
| I was scrolling through looking for the Google Wave comment.
| Sad to see it at the bottom.
|
| Wave was, IMHO, the UI paradigm of the future for this sort of
| thing. I have hope that it was just too far ahead of it's time
| and something like it will catch on again.
|
| I think the problem it suffered from, besides being a little
| too "out there" for the average user, was that it required to
| much careful attention to how you used it. Where to fork the
| discussions, where to spilt them off into their own wave
| leaving only a link in their place, etc. It just doesn't work
| for people for whom the "reply all" button seems a sensible
| solution....
|
| I had such hope for it though. The technical side seems pretty
| well solved at this point, it seems like that we need is a
| crack team of psychologists and UX people to have a go at the
| problem.
| canadiantim wrote:
| I wish this website didn't have new ways to prevent me from
| scrolling tho.
|
| Anyone else unable to scroll the website on mobile?
| aeontech wrote:
| This also reminds me a little of Kialo (with a canonical holy war
| of Vim vs Emacs, of course: https://www.kialo.com/vim-vs-
| emacs-19293)
| basil-rash wrote:
| The best way IMO is still (somehow) a 4chan-style linear
| timeline, with heavy UI affordances to make following >-ref's
| simple. This application (and HN, and Reddit) go with the
| "threads on threads on threads" tree, which is awful for when you
| want to respond to a specific subset of replies to the same
| parent comment at once.
|
| How could it be improved? I say embrace the DAG nature of the
| beast and allow for selecting a specific set of parent nodes a
| comment is in reply to, and, importantly, make that set editable
| so when some other person comes in and replies to a comment with
| a topic that has already been discussed, you can link your
| earlier replay to that new parent without needing a "see my reply
| here" comment.
| senkora wrote:
| I like this thought but note that it would no longer
| technically be a DAG if you allowed editing earlier comments to
| link to later comments.
| James_K wrote:
| This is easy to solve by representing edits as amendments.
| Each edit forms a new "reply" node in the graph with the
| amended content.
| readyman wrote:
| Or each edit forms a new "edit" node that new replies are
| then connected to. Regardless, the DAG can always be
| preserved somehow.
| playingalong wrote:
| That possibly works for quiet discussions, say <30 total posts.
|
| For these with high level of engagement you often get distinct
| subtrees of threads which have little to do with each other.
|
| For the latter the linear structure is awful.
| basil-rash wrote:
| That's where the UI affordances come in, for instance a
| button on each node to hide/show all comments that are
| descendants of that node.
| pkoiralap wrote:
| DAG does seem natural here. Having a LLM add metadata to the
| nodes can make this even cooler. For instance, person A
| presents statement Sa. Person B comments on person A's
| statement, Sba and person C comments on person A's statement,
| Sca. The viewers now, especially new parties that are joining
| the conversation, would be able to see that Sba agrees to most
| of Sa said, but refutes a fact said by Sa. Sca doesn't agree
| with anything Sa is saying. Another example would be, nodes
| getting more weight as more people agree with it and smaller as
| more people disagree. Obviously, the implementation and
| implications are boundless.
| _bent wrote:
| Considering how debates tend to go in circles, I'm not sure
| if a DAG is the right data structure
| AnimalMuppet wrote:
| The _comments_ are a DAG. The _ideas_ go in circles.
|
| But I'm not sure you can get an automated map from comments
| to ideas, no matter what data structure you use...
| brobinson wrote:
| The 4chanx extension (userscript, run it in violentmonkey or
| equivalent) lets you nest comments in a chain to make following
| threads easy while maintaining the overall chronological state
| of the threads. You can also hide a reply, and it will
| automatically hide the entire chain of replies to that reply.
| anonymous_union wrote:
| did they reinvent email threading
| zbentley wrote:
| It seems like an enhancement of some parts of email threads
| rather than a reinvention: replies are identified by where
| they're rooted rather than a subject; a "concluded" metadata
| bit is present to at-a-glance delineate stale threads from
| completed ones; tree structure is enforced by the platform
| rather than the users following a plain-text convention re:
| top-posting and quoting; contribution, reply reading, and tree
| browsing all happen in a single place without involving
| transmission asynchrony or email clients (which mailing-list-
| all-the-things zealots probably do not consider an enhancement,
| but which history indicates most people prefer).
| lpapez wrote:
| > In CQ2, there's no mess of unorganised comments -- create
| threads inside threads so that each thread stays on topic and
| organised.
|
| Wish this could work, but my experience is that getting people to
| use even the first layer of threads is very difficult, especially
| non-technical people.
|
| IMO most often complex discussions will devolve into a "let's
| just jump on a quick call to settle this", for better or worse.
|
| The feature I am looking forward to the most in comminication
| apps is having a machine learning model listen to those "quick
| calls", generate summary and action items and post them right
| back in the thread. You get the benefits of both worlds that way.
| zbentley wrote:
| > getting people to use even the first layer of threads is very
| difficult, especially non-technical people
|
| I've found that as well. I wonder why that is--many times I've
| been working with someone who is extremely intelligent and
| methodical as an individual, but structured communication
| totally breaks down as soon threads enter the picture.
|
| Interestingly, this sometimes even happens verbally (at work,
| when doing tech support on either side of the phone, at
| feedback discussions with artists/writers, when talking with
| friends): some folks really do not like "zeroing in" on
| specific sub-discussion items, talking them out, then moving on
| or going back to the bigger picture. Instead, they like to jump
| around or "chroot" the discussion to whatever the most recent
| topic of interest is. Anecdotally, it's very much a "two kinds
| of people" situation, but I don't know what the common factor
| is (and again, I don't think this is a skill/bad-faith issue;
| these are smart and reasonable people. They just ... don't
| think in trees or stacks).
| James_K wrote:
| For the verbal phenomenon, I think that is just a symptom of
| human brain function. Only a small amount of processing is
| conscious verbalisation, so you will need to talk about new
| things while your subconscious processes other ones.
|
| As for online, I think the idea of threads is obviously
| antithetical to the concept of linear discussion. When you
| organise things as a tree, you present the many branches as
| though each is a valid target for a new entry. If you want
| things to be discussed linearly, you must present that
| discussion linearly. This linear discussion is feasible only
| in text, as you have time to think something over before
| verbalising it.
| SoftTalker wrote:
| Because nested threads get so deep into the weeds that the
| eyes start to glaze over.
|
| I liked the old Joel on Software boards. No threads, messages
| posted sequentially as they are created. If you want to
| quote, do it manually. I feel like discussion stayed on topic
| or at least evolved sensibly, there were no deep tangents on
| pedantic matters that pushed the rest of the messages off the
| bottom of the page.
|
| Edit: here's a post where Joel talks about the design of his
| forums.
|
| https://www.joelonsoftware.com/2003/03/03/building-
| communiti...
|
| I think there's a lot of good sense in there, if you are too
| young to remember, the JoS forums were the "Hacker News" of
| their time, a place where programmers and other people
| involved in software businesses had online discussions about
| a number of interesting things. Those forums were even
| simpler than HN is -- no threads, no replies to individual
| posts. You could read comments in linear order, and post your
| comment after scrolling to the bottom. That's it.
| jijijijij wrote:
| Although technically tempting, I think most people don't want
| to have a transcript/recording of person to person calls,
| especially in a work context. Even if you aim for "just" an AI
| summary, there has to be a recording, there has to be a
| transcript somewhere. Do you trust in the promise of deletion?
|
| Self-censorship, preference and knowledge falsification come to
| mind. People behave differently when there is no expectation of
| privacy, when they know they're observed. Apart from employment
| consequences, social alienation and mental health impact,
| panopticism may negatively affect creativity and innovation,
| when people behave less impulsive and more agreeable.
|
| In my practical experience, (local) transcription also tends to
| be anything, but instant, if you don't allocate significant
| compute to the task. So your summary may not be available for
| some time after the call ended. You may need to cognitively
| backtrack quite a bit to confirm plausibility/"correctness" of
| the AI production.
|
| Management will love it, everyone else will grow to hate it.
|
| For me, at least, private personal talks/calls are the last
| bastion of interpersonal bonding and social relief in the
| modern (remote) work environment.
| makeitdouble wrote:
| A different angle: cutting private personal talks and
| interpersonal bonding can help a lot in remote environments.
|
| It might feel paradoxal, but as there's little context on
| each other's private life in the first place, private talk
| stays limited and trite (basically close to grocery lane
| small talk)
|
| For instance imagine having a call for reworking a service
| and the other side starts asking what you did during the
| weekend, which happens to be medical follow up for your kids
| on the spectrum. Either you start explaining all your life,
| or you just cut it down and deal with the purpose of the
| meeting.
|
| There's of course a ton of personal preference, some people
| thrive in grocery lane talks. I just wouldn't expect most
| people to be so.
| jijijijij wrote:
| Luckily I managed to avoid socially alienated work
| environments so far. I actually enjoy working even.
|
| I presume the vast majority of humans needs and enjoys
| social warmth, and a personal connection. You can escalate
| almost any conversation out of grocery lane talk with one
| or two questions, so your experience is maybe a bit on you,
| too. Also don't shun chitchat, there is subtext, belonging
| and trust building encoded. It's an offer and a compliment.
|
| Apart from basic needs, this also creates an environment
| more resilient to worker exploitation.
| epolanski wrote:
| > IMO most often complex discussions will devolve into a "let's
| just jump on a quick call to settle this", for better or worse.
|
| The issue then isn't about communication but decision making.
|
| Complex topics, for the reasons listed in the linked blog post,
| should not end up in "let's settle this over a talk".
|
| I personally, to this date, consider moderated vBulletin/phpBB-
| like forums the highest form of long term communication online.
|
| There are active discussion threads on many forums I follow
| that are _decades_ old.
| wmf wrote:
| In that situation you need trained human
| scribes/editors/facilitators who convert people's unstructured
| blathering into the proper form for the tool.
| worldsayshi wrote:
| I like the concept. What I would want to see is a clear path to
| reaching consensus documents.
|
| Comments-upon-comments makes it hard to get an idea of what the
| overall consensus is. You pretty much need to read all of it and
| explore every comment thread to understand what are the generally
| agreed parts and what are the more controversial takes(?).
|
| Maybe some hybrid between this and Wikipedia?
| glassofbees wrote:
| You could maybe achieve that with this design if a summary
| could be set for resolved discussions and shown at a higher
| level (eg. when hovering over the source text of a thread).
|
| Having the ability to differentiate between a resolved, useful
| thread and a resolved but ultimately unnecessary thread might
| also help avoid noise.
| windowshopping wrote:
| Did anyone else find this post confusing? To me this looks like a
| sideways change, not a forward one.
| Jerrrry wrote:
| hmm, almost like how complex discussions work, instead of
| meandering trains of impulsive thought
| windowshopping wrote:
| What? I question your decision with this comment to
| prioritize condescension and sarcasm over making a clear
| point.
| Jerrrry wrote:
| I questioned your genuineness; given the context of the
| topic and the your orthogonal figurative of speech used to
| describe the issues with the article.
|
| If the meta-pun was incidental, apologies.
|
| This is why HN discourages puns or insubstantial jokes, as
| it impedes the benefit of doubt when attempting good faith
| discussions.
| windowshopping wrote:
| The pun didn't even occur to me. I wish I was that
| clever. God that would've been great.
| graypegg wrote:
| One thing that would be nice to add to the "concluded" status
| would be a updated version of the highlighted text that started
| that thread. Probably the old version striked out, and some
| conclusion appended after it, that way you don't even have to
| open the thread.
| durandal1 wrote:
| We're now back to email threads again it seems. (This is not the
| criticism it might seem, I miss the days of long-form proposals
| discussed through email, it promotes a kind of thinking that
| Slack etc doesn't).
| hathawsh wrote:
| Personally, I liked it when email threads followed the Usenet
| "laws".
|
| https://jkorpela.fi/usenet/laws.html
|
| Most of the best discussions I've had online followed those
| rules.
|
| (OTOH, those rules are written tongue-in-cheek and not likely
| to be understood well by most newcomers.)
| Jerrrry wrote:
| It's how comments are ranked, and displayed based on "rank"
| >couldn't* care less >my..."troll metric" / rage
| bait/"le reddit quantification", formalized as a response's
| comment's conversational entropy divided by parent comment
| length, this is a fantastic comment. > >Pure,
| distilled, thought provocation.
| patrickmay wrote:
| This seems similar to the good-old-days Usenet with threaded
| readers that showed only new posts and a culture of interspersing
| responses (with much scolding of people who top posted).
|
| I'd love to see something like this that works more generally. I
| suspect it might need a more graph-like structure akin to mind
| maps.
| solardev wrote:
| This feels a lot like Google Docs's commenting system, and seems
| to have the same issue in that it requires a lot of clicks to
| open each side thread one at a time. It's hard to "finish"
| digesting a series of replies at once.
|
| I think I'd prefer Discourse's current linear format, where all
| new replies are stacked at the bottom (but ideally with a quoted
| snippet for context). It makes catching up on updates easier,
| since you just keep scrolling and reading like any other
| document.
|
| IMO it often isn't super useful to go through each individual
| comment piecemeal unless you're working on a document together
| (ie tracking changes and commenting on them). Otherwise, being
| able to read through several comments at once and THEN replying
| to the whole of them in a summary can save everyone time.
|
| It's the infinite back and forth on every minor point that makes
| long form discussion impossible to track. That's the sort of
| thing that probably IS better dealt with in real time, over Slack
| or a call, and then summarized briefly back in the main convo.
| You don't need to have every sentence recorded in the main convo,
| just something like "Re: point 4, after talking it through with
| Joe and Jane, we all agreed it would be best to use blah blah".
| kaycebasques wrote:
| > This feels a lot like Google Docs's commenting system
|
| This was my first impression as well. The summary tree of
| replies to a thread seems like a possible improvement over
| Google Docs but the basic interaction workflow seems the same
| as Google Docs.
|
| Perhaps there is more innovation to be had by looking at the
| various specs for webpage annotation systems that have been
| proposed over the years?
| amflare wrote:
| Super cool. I've been thinking about building something like this
| for years. I have a background in debate, and the inability to
| "flow" complex discussion in any sort of digital format has
| always bothered me. I'm excited to try this out.
| dontdieych wrote:
| Thought arrow keys would work. :D
| James_K wrote:
| As much as they have a bad reputation, I think the image board
| style of comments is the best for these kinds of discussions.
|
| Each post has a unique ID, and you can insert links to other
| posts in the text of your post. Then each post is given a set of
| back-links showing all posts that quote it. In this way, posts
| form a hyperlinked network that you can traverse relatively
| easily, while also being displayed in chronological order.
|
| I've found this quite effective for long-form discussion. My only
| complaint would be that structure is needlessly limited. It would
| be better if posts simply formed a connected graph of content
| which you could ask the website to present in arbitrary ways.
|
| This project reminds me a lot of Xanadu in its layout. I don't
| really think this complex of an interface is necessary. In fact,
| it might get in the way of productive discussion. I find that the
| constraints on other mediums (character limits, reply depth,
| etc.) often aid clarity. The transmission of information between
| people is fundamentally linear, and so you are pretty much always
| just going to be composing short essays and exchanging them as
| the basis of any real discussion. Complicated features seem like
| they would obstruct this.
| basch wrote:
| Despite all the attempts to improve upon the basics, hyperlinks
| really are better than almost everything that's come after
| them.
| hypercube33 wrote:
| HyperCards need to make a comeback
| hollerith wrote:
| I spent 5 minutes on https://cq2.co/app/demo and failed to figure
| out how to navigate.
| James_K wrote:
| Having tried the demo, I can now say that it is a very
| confusing way to lay out content.
| zbentley wrote:
| 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.
| baxtr wrote:
| Instead of a long post like that I wished they had a realistic
| example I could experiment with.
| FelipeCortez wrote:
| There's a "Try demo discussion" button on the header. Leads to
| https://cq2.co/app/demo
| agambrahma wrote:
| This is something RoamResearch is squarely a good fit for.
|
| It's very useful for personal capture (with digressions etc) but
| also handles the "multi-player" case if needed.
| agambrahma wrote:
| ... and versions etc too
| hyperluz wrote:
| I think those investing efforts and time developing participatory
| democracy systems, are trying to solve these kind of
| communication and reasoning problems.
|
| Examples: https://www.noemamag.com/tomorrows-democracy-is-open-
| source/
|
| and
|
| decidim.org
| __MatrixMan__ wrote:
| I'd like to work on something like these, and I didn't know
| about them--thanks for sharing.
|
| But I don't think the web has the right structure for an app
| like this. (Decidim seems to be a web app. It's hard to find
| information about this "Open Insight" thing they're talking
| about, presumably it is too?)
|
| If you're using the web, somebody controls the server and the
| others have to trust that person to not abuse their role. It's
| not exactly primed for democracy.
|
| Blockchains aren't quite right either. You solve the
| untrustworthy admin problem but you've got this really strong
| notion of THE official record, which only some people are going
| to have the ability to update, and that will be used by the
| powerful at the expense of the weak.
|
| Whatever the right structure is, I think it's partition
| tolerant. Any party needs to be able to disconnect themselves
| from any other party such that:
|
| - everything not reliant on that trust edge still works (the
| web would struggle with this)
|
| - the untrusted party has no ability to censor the revoker,
| even if they're well trusted by the others (blockchains will
| struggle with this)
|
| I've been tossing around ideas for what the ideal protocol
| would look like. SSB is the closest thing I can think of to
| compare it to, but nothing about it feels very solid yet.
| SamBam wrote:
| I've wanted to create something like this for a long time. I've
| always wanted a threaded system where you can respond to a single
| line of text.
|
| One thing I wonder is how this can best be extended to
| argumentative discourses where much of the discussion is a
| dispute of facts. Of course you could do that with this, but it
| won't be clear looking at the comment tree whether people agree
| on what facts, if any, are correct.
|
| I wonder if this could be extended (or have a mode) that requires
| consensus on whether a thread is concluded (instead of one person
| deciding), which could be as simple as keeping the current UI but
| allowing the people the option to re-open threads; and the
| ability to attach summary statements to threads which percolate
| up to the thread's branch point.
| danjl wrote:
| Visuals are the big missing piece. Any text-based discussion will
| build different visions in each reader's head. Often, everyone
| agrees on the text description, and then, when a designer draws a
| picture, everyone disagrees because they weren't really aligned,
| they all assumed everyone shared their own personal vision. I
| love the concept of building a better way of discussing things
| asynchronously, but I would put visuals (images, videos,
| diagrams) at the center of that forum and overcome the biggest
| issue with visuals -- that they are often hard to make for many
| people.
|
| All the mentioned alternatives tie comments to a particular user
| and relate comments (responses) to other comments. Instead, the
| conversation could be focused on the topic of discussion, which
| is often best described as a set of visuals describing the
| concept. Rather than responding to comments, you could organize
| comments around the associated component of the problem as it is
| described visually. This would allow multiple individuals to
| support a concept, rather than just amplifying or criticizing a
| particular user's comment. This might even help avoid defensive
| behavior since the problem is the focus rather than a particular
| person's comment.
| noiv wrote:
| I think when a group wants to build something you're right -
| images help, but when you want to make a group build something
| text is often enough.
| danjl wrote:
| Heh, perhaps you could use the text comments to constantly
| update a visual description generated by AI? That way, nobody
| needs to make a drawing. Conversely, nobody has direct control
| over the visuals.
|
| I envision a UI where people type their comment into a text
| box, that comment is sent to the server which is constantly
| updating the "visuals that describe the idea". Each client
| updates their UI with the new visuals along with providing some
| way of attaching all the comments to the visual
| images/videos/diagrams. IOW, the AI-generated visuals are the
| center of the client UI, rather than just a scrolling tape of
| comments. Clients can then navigate the discussion by diving
| into different components of the discussion. Maybe there's even
| an AI-generated summary of some sort. Essentially, the AI is
| playing the role of a Designer drawing pictures in a side
| channel and a smart assistant who is constantly updating a
| summary abstract.
| flemhans wrote:
| MacSOUP had the best visualization of threads.
| layer8 wrote:
| > we started searching for a tool specifically built for complex
| discussions. We found none
|
| This was basically solved in Usenet, more specifically, in news
| reader software. You had a clearly arranged threaded view (you
| could see the thread structure of as many as 50 postings on a
| single screen), with unread threads and unread postings
| highlighted, and pressing Tab jumped to the next unread posting.
| Unread status was per posting/comment, not by time. Many more
| conveniences for quick navigation, filtering, and so on.
|
| All newer discussion platforms have been a step back in terms of
| efficiency of use and ability for deep, long running discussions.
| Initially due to web browser limitations (though nowadays that
| shouldn't be much of a problem anymore), and later due to mobile
| touch interfaces (still poses some difficulties).
| shsbdncudx wrote:
| You're right. We shouldn't try to improve what we are doing
| now.
| layer8 wrote:
| I'm saying it's worth looking into what worked in the past,
| and why. It's not uncharted territory.
| loceng wrote:
| So why do you think Usenet is not the mainstream status quo for
| conversations then?
| layer8 wrote:
| Usenet died due to spam. Newsgroups were unmoderated by
| default, and moderation wasn't built into the protocol. Then
| PHP web forums took over because they were discoverable by
| web search and only required the web browser that you had
| anyway. They also added support for popular features like
| posting images and using emoticons, instead of only text
| (though the latter hasn't hurt HN).
| jll29 wrote:
| We may distinguish between USENET the public network that
| is part of the Internet (considerd "out of date" by many
| because it is not Web based, and indeed suffering from
| spam) and the USENET protocol, which you can use to set up
| your private version of USENET-like discussion groups.
|
| In fact, many organizations had (and some still may have)
| inhouse groups, often prefixed "local." e.g.
| "local.events", "local.jokes" etc.
|
| Advantage: threaded discussions, open standard (many
| existing open source readers e.g. Emacs: M-x gnus)
| wolverine876 wrote:
| > Usenet died due to spam. Newsgroups were unmoderated by
| default, and moderation wasn't built into the protocol.
|
| Doesn't that make Usenet unfit for complex public
| discussions, at least?
| layer8 wrote:
| It worked quite well with a mostly-academia audience. For
| the general public, of course, moderation is
| indispensable. The spam in Usenet began when businesses
| and scammers discovered Usenet. My point in the root
| comment is that Usenet clients contained all the
| ingredients for efficient, structured, long-running, deep
| discussion, and those are orthogonal to moderation, which
| you nowadays need in any case.
| TranquilMarmot wrote:
| https://en.wikipedia.org/wiki/Eternal_September
| layer8 wrote:
| Eternal September lowered the average quality of Usenet
| content, but it's not what ultimately lead to its demise. I
| actually only started using Usenet around the mid-90s, and
| continued for a good decade. The problem later was spam,
| and web forums being much more discoverable, and somewhat
| easier to get started with, so that's where new users went.
| wmf wrote:
| Most people don't want to have truth-seeking complex
| discussions because it's hard and boring.
| makeitdouble wrote:
| Yes. The only critical issue I'd see with Usenet's client
| interfaces would be linking cross threads.
|
| At some point a thrrad becomes irrelevant because of parallel
| discussions in other threads, being able to easily redirect to
| a specific point in another thread helps a lot. But that
| requires an URL, and messages ids weren't used for that
| purpose.
| layer8 wrote:
| I actually remember using message IDs to reference other
| postings. Newsreaders had commands to jump to a certain
| message ID. You had to copy the message ID from the posting,
| but on Unix that was just a double-click, and a middle-click
| to paste, so quickly accomplished.
| uoaei wrote:
| Zulip has many of these features I believe. Anecdotally it
| seems to be great for running an online discussion forum for a
| high school or college level class.
| abdullahkhalids wrote:
| I used Zulip last week to ask a question on Lean on their
| community.
|
| I only sent like 3 messages, but it was awfully slow. Didn't
| come away with a good impression.
| Vox_Leone wrote:
| I like it. Takes some effort to get used but it sure does remove
| much of the usual BB mess. Some breadcrumb style widget on the
| top to show which level you are on could also be nice.
| sanitycheck wrote:
| I quite like the "conclude thread" concept (though I couldn't get
| that button to do anything in the demo), and I'm one of those
| strange people who would like infinitely nested threads in Slack
| too...
|
| But the issue with threads is always that people who aren't
| involved the side-discussion generally never read them. I think
| it might be nice to have every thread "concluded" with a "result"
| (summary, outcome, to-do list, etc) which is then injected back
| into the parent where everybody will see it. It could be manual,
| or it could be semi-automated with a LLM - I'm not generally a
| fan but this seems like a reasonable use case. I'd ideally like
| all the nested threads to naturally turn into a single linear
| summary of everything important that was decided.
|
| The CQ2 thing also looks a bit too document-oriented, might be a
| good fit for a wiki or something like that but I think being able
| to open a thread for every single word is too fine-grained for a
| typical discussion.
| micromacrofoot wrote:
| I find that as soon as you introduce threads as a form of
| organization, you've already lost the plot with 75% of users.
|
| One may argue that Facebook has threads, but I don't actually
| think people know how to use them. They simply click reply, say
| their piece, and then it's lost forever. They have no concept of
| structure.
| mathfailure wrote:
| This is nearly perfect! I've been thinking of that problem and
| possible solutions as well, I am very glad you've done it.
|
| 1 loaded question though: who should have the rights for
| concluding threads? And a sub-question: should concluded threads
| be locked into read-only state? Or the other party should be able
| to continue the argument?
| koito17 wrote:
| Pretty cool idea. It seems to address most of the UX issues I
| experience with BBS softwares. The only possible issue I see is
| density of information. People using mobile devices are not very
| motivated to read or write long sentences. This may have an
| impact on the overall quality of discussion. On my personal
| computer, this very post consumes two lines of text. On my
| iPhone, it consumes nearly half of the vertical space, thus
| appearing large (despite shallow content).
| jimmar wrote:
| I worked in a department that facilitated group discussions with
| a custom platform based on group decision-making research. One of
| the killer features of our platform was anonymity. Truth could
| arise in group discussions when people were free to comment,
| upvote, etc, without fear of retribution, being accused of
| playing polities, or just going with the crowd. Seeing
| everybody's name tagged in every comment in cq2 lets me know that
| people with uncomfortable ideas may be hesitant to post them. So
| I wonder what type of questions would be appropriate for the c2q
| type of tracking.
| epolanski wrote:
| At some point no solution is perfect and anonymity brings its
| own set of issues.
|
| What you are describing is also a cultural more than a
| framework issue.
|
| People should not fear retribution for voicing their doubts and
| I'm lucky enough that none of my latest clients or previous
| employer had such an environment.
| tunesmith wrote:
| It's sort of like a tree, except that a node can have a main
| child and a connection of other children. That's neat, and
| another helpful step in organizing discussions.
|
| I've always wanted something that is more like a graph structure,
| where you can reply to multiple comments. So a node can have
| multiple parents.
| clcaev wrote:
| Curating a discussion is not a technical problem, it's just work.
| Observers may be more numerous than participants. Casual
| participants may outnumber intense ones. Intense contributors
| might not be the best curators.
| kikki wrote:
| What does CQ2 mean? It's not an easy name to remember
| epolanski wrote:
| I'm not a fan of threading outside chats to be honest.
|
| I'd rather have a moderated linear discussion with
| quotes/references.
| karaterobot wrote:
| > We love complex, deep discussions.
|
| Well, that certainly does look deeply complex, so I have no
| reason to think it wouldn't create deeply complex discussions.
|
| Kidding aside, one thing I like about it is that it makes
| discussions start around specific snippets of a source text. That
| is to say, you begin a thread by selecting a piece of text. I am
| always very skeptical of top-level comments on HN that don't
| begin with a quote from the article being discussed--more often
| than not, I am suspicious that the person even read the text
| before commenting.
|
| That doesn't address how you'd have conversations around anything
| except a block of text. Videos, pictures, games or applications,
| etc.
|
| And they don't solve the toughest UX problem with this kind of
| pattern, which is how you treat overlapping excerpts: are they
| part of the same thread, or a new thread, and how do you define
| the boundary?
| SkyMarshal wrote:
| +100, this is a problem with popular chat services that has irked
| me for a long time. Anything that forces you to be constantly
| monitoring the chat stream synchronously is annoying. Some people
| can do that and still get deep work done, but I can't. I much
| prefer async chat, be it email or reddit/hn or some other
| attempts like Atlassian's erstwhile chat client. Always glad to
| see new attempts at solving this problem, thanks cq2 team! Will
| be following the project.
| dojitza1 wrote:
| Tiny UI feedback, I could not figure out how to go back easily.
| It took me 1 minute to figure out it was the conclude discussion
| button on top
___________________________________________________________________
(page generated 2024-05-06 23:00 UTC)