It's about time that #Signal is working on features to manage #groupchats with parallel discussions. 😞
It is really a drag when there are multiple threads ongoing at the same time. Although the tech could handle Signal group #chats with more than maybe ten people, the UX prevents me from participating.
The bummer was when we left #Usenet. Almost any issue with online discussions was solved beautifully back then. Then we started to come up with mediocre and primitive alternatives. 🤷
@publicvoit parallel discussions and polling!
Polling is a big reason why teams (choirs, soccer teams,...) do not change from #WhatsApp to @signalapp
Why don't you have this feature, @Mer__edith ?
@publicvoit I'd say netnews' approach to multiple conversations is quite good. Probably goes in hand with careful use of Subject: changes and with a client whose UI shows threading in a usable way.
Meanwhile, Mastodon doesn't show proper threading in the official UI and could also make at least subthreads directly accessible from feeds (hey, if it's so heavy in order to be dynamic, why not do this while at it?)
Webfora are also a place where threading is often not present: a lot of forum software packages out there just group posts by topic.)
@njsg @publicvoit The lack of proper thread display in the official Mastodon client is a client-side issue right?
I believe the API returns an `in_reply_to_id` field that allows for proper thread assembly and Fedilab for example takes advantage of this.
I guess the devs of the official client think that we are too dumb for proper threading :(
@publicvoit @zrzz I would not be surprised if the answer to "why?" was "it's how twitter does it". That seems likely to at least explain quite a few of the design issues - and also other characteristics - of the official web UI.
(I should really start trying to code a XUL client at some point, but an ActivityPub-NNTP bridge would indeed also help with this.)
Karl Voit 
thinkpad
stefan
njsg
zrzz