[messaging] Minimal requirements for group chat
Ximin Luo
infinity0 at pwned.gg
Thu Apr 17 09:19:58 PDT 2014
Yes, I agree with this observation. I haven't yet explicitly disagreed with the analogy to email threads before, because I didn't want to complicate things - people seemed to find "email threads" as a good existing conceptual anchor, when being introduced to partial ordering for the first time.
But I basically agree with what you say below Tom - the parent pointers in a partial-ordering scheme have a fundamentally different meaning to the References: header in email, and in fact to git parent pointers.
The former means "I have seen these and no subsequent ones", whereas the latter means "I want to directly reply to this message". The former is used to determine the ordering and consistency of message-events, the latter is used as a semantic context for the message body text.
If I wanted to implement a threaded view of a chat session, I would do "references" pointers as a separate type of parent pointer from the "seen" pointers. The ordering/consistency engine would only look at the "seen" pointers, the threading/UI code would only look at the "references" pointers. (There might also be some additional checks to make sure the pointers don't contradict each other.)
X
On 17/04/14 15:03, Tom Ritter wrote:
> I do not think that threaded email conversations is the best mental
> model - because threaded email conversations do not converge and they
> definetly have an authoritative master (on a mailing list anyway).
> When a threaded conversation on a list continues on two branches,
> there is no mechanism for me to attach my reply to 'both' branches
> (although I wonder what mail clients will do with two In-Reply-To
> headers...)
>
> But partially ordered chats do converge. And my instinct from a UI
> perspective is to represent the conversation 'side by side' to
> represent 'they talked at the same time.'
>
> Here Carol and Dave reply to Bob without seeing each other's messages,
> but Tom has seen both
>
> +--------------------------------------------------------------------+
> | Bob, 3:45:11.234 |
> | Who wants to get Ice Cream? |
> +---------------------------------+----------------------------------+
> | Carol, 3:45:12.412 | Dave, 3:45:12.567 |
> | I do! | I don't but who wants to kill |
> | | the president? |
> +---------------------------------+----------------------------------+
> | Tom, 3:45:12.987 |
> | Yes to the first, no to the second. |
> +---------------------------------+----------------------------------+
>
> It obviously gets more complicated. Carol and Dave speak at the same
> time. Earl has seen Dave's message but not Carol's.
>
> +--------------------------------------------------------------------+
> | Bob, 3:45:11.234 |
> | Who wants to get Ice Cream? |
> +--------------------+------------------------+----------------------+
> | | Dave, 3:45:12.567 |
> | | I don't but who wants |
> | Carol, 3:45:12.412 | to kill the president? |
> | I do! +------------------------+----------------------+
> | | | Earl, 3:45:12.678 |
> | | | That's intense. No |
> | | | one wants ice cream? |
> +--------------------+ +----------------------+
> | Tom, 3:45:12.987 |
> | Yes to the first, no to the second. Carol and I do, Earl. |
> | (But I know you know that because of this bitchin UI.) |
> +--------------------------------------------------------------------+
> | Trevor, 3:45:13.345 |
> | Don't flatter yourself Tom. |
> +--------------------------------------------------------------------+
>
> With this or similar UI, you also get to fix that super-annoying chat
> frustration where you reieve a message in the millisec before you hit
> enter. Instead of having the client 'order' your message after the
> just-recieved message, impose a delay (maybe with a color gradient
> fade in the UI) when you're typing and a message arrives just before
> you send your message. If you hit enter in that delay, your message
> does not ACK the just-recieved message.
>
> -tom
>
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140417/3b8bfca4/attachment.sig>
More information about the Messaging
mailing list