Closed timothyclemansinsea closed 2 months ago
The design is unclear.
Alternatively we could have a threading system like zulip, where basically the chatroom has a namespace (like in python) as does each message.
We could also have hashtags in messages, with autocomplete to make them very easy to add. Have a tag bar at the top to restrict to thread by tag. Just some ideas here....
Note that we will have %sage, etc., cells at some point... always keep that in mind.
Threaded chats could be very useful for real-time Q&A sessions. Each question could be a separate thread to which people can respond.
Each question could be a separate thread to which people can respond.
Can you suggest what the user interface might look like? In particular, could you point to a chat client that has threads that you actually like? Thanks!
Implementing threads in terms of the UI to create them and the underlying data model to store them isn't very difficult, but actually representing them in a useful way to users is more challenging (to me at least). I happened to have completely rewritten our chat a few weeks ago, so it's much easier to improve now, by the way.
I am referring to individual messages as "posts".
Discourse does a reasonable job of this. Each post sprouts links on the top right to their parent (with the parent posters username) and on the bottom left if there are multiple replies (left figure below). Clicking on these opens the immediate posts - either all replies, or the parent post.
The one thing missing for me is the ability to see an entire vertical thread, but this could get quite hairy if there are multiple threads.
For the Q&A idea this could be limited to each post being allowed to have only a single branch: Only root nodes could have a thread and these root nodes would have at most one reply each: users would be forced to reply at the end of each such thread. This is quite restrictive, but I think reasonable for the Q&A use-case, and would remove confusion on the part of the user: Replying would take you to the bottom of that current thread.
Perhaps one could set the maximum thread depth in each chat - the Q&A format I described above would have a maximum depth of 1. Current chat behaviour has a maximum depth of 0.
The zeroth order UI would be simply to have the links act as navigation tool, allowing one to move up and down threads. (Maybe left and right "arrows" could be used to jump laterally, but it is not clear to what level they should jump.)
The next order UI would be something like what Discourse does.
Finally, the one feature I find lacking with Discourse is a way to see the entire contiguous thread. In the Q&A case of max thread depth 1, it should be relatively easy to insert this below the root post. Maybe one more "show thread" button could be included (or activated by holding down the "replies" button) that pulls in the entire thread. This would probably not work for full trees - maybe it would pull everything until then next node that has replies, then would need to be repeated there.
I like the way Zulip does it. See for instance zulip.sagemath.org or leanprover.zulipchat.com
An interesting thing about using Discourse as an example is that it is not a chatroom, but instead a forum. That worries me. Do you have any examples involving chatrooms? I'm also a bit worried about notifications of new activity -- when should they happen and how? I just checked and Slack has a notion of threads similar to what you propose, and they do address notification rules immediately: https://slack.com/help/articles/115000769927-Use-threads-to-organize-discussions- In contrast, Discord just has a way too quote a previous message and @mention a person in a whole new message, which is exactly what @timothyclemansinsea suggested in making this issue.
"I like the way Zulip does it." - I browsed both of those zulip servers for a while, and also googled "zulip reply", and I couldn't figure out how (from a UI point of view) what zulip does solves this problem in CoCalc of replying to messages in a chat. I don't even understand my own comment from 2016 above about zulip! Can you elaborate? My best guess is that the analogue of zulip for cocalc would be that a cocalc chatroom (or side chat on a file) would basically be replaced by an unlimited number of distinct named chatrooms (analogous to the "topics" in Zulip). I guess when you reply to a message, maybe you can make a new topic? But zulip doesn't do that, does it?. Are you sure zulip does anything at all related to the problem of replying to messages in a threaded way? It seems like they just avoid the problem entirely by making topics very easy to create. I've used zulip a reasonable amount, but it's always because I get @notified in a message (which is part of some long topic), then I respond to it, and this has given me no experience with how threads are handled, and basically feels the same as any chatroom.
Twitter also solves this reply problem, and there solution is incredibly confusing and disorienting (IMHO) to use. I almost feel dizzy and dazed whenever I use twitter...
Anyways thanks for all the ideas!
I think I don't like chatrooms... and I don't use them unless forced to do so - so discord and slack are my only references, and I like neither. I think I could like CoCalc chat if it worked this way:-) Of course, that means I have no experience using something like this, so maybe it would be a pain. User testing is needed.
Slack seems to take my first-order approach of a max-depth of 1. Posts in a thread cannot have subthreads. The threads appear to the right of the discussion if the screen is wide enough, or require swiping left or right. This is also pretty reasonable, but when you swipe out of a thread, it can be disorienting as to where you were. I think I might prefer that the thread expand in place keeping the single column, but I don't do these things on a mobile device, so someone else who uses Slack should chime in about the user experience there.
Slack's suggestions for notification seem reasonable. Thread posts should only notify those subscribed to the thread, while top-level posts (with quoting enabled perhaps) would notify those participating in the full discussion. Not clear what happens when someone subscribes/responds only to a thread - do they automatically get subscribed to the whole conversation (probably should be).
Slack seems to take my first-order approach of a max-depth of 1.
I happen to have been using slack a lot during the last week in a group that uses threaded messaging a lot... and I like their approach. Basically, they completely hide all responses until you explicitly click a button to reveal the response thread. Basically, when you click where it says "1 reply" on the left here:
it then reveals the column on the right with basically an entire new chat conversation. It's much better than what facebook or github (say) does, since you don't see any of the replies on a first glance. It's also nice because when you do want to see the replies, showing them has little impact on the main conversation, so you don't loose context, which is actually VERY nice. Implementation wise it is also likely pretty easy, since the reply thread is really just another chatroom. Probably for side chat in cocalc we would have to expand the the thread in place (rather than off to the side).
Anyways, I could see implementing this soon...
We have threads now so all this auto quoting is relevant or needed.
Each chat message would have a reply button. Clicking on it auto quotes that message.