On 23.10.20 17:32, Dave Crocker wrote:
Not conflating reply text with a summary reaction makes a lot of things
easier for clients and users.
It's not obvious to me that this is true. (In fact, I suspect it
isn't.) So feel free to provide a comparison between the two
approaches, in terms of affects on clients and users.
Let's just take the filter example. It's quite easy to write one that
checks for the existence of a certain header field (I don't care much if
it's "In-Reply-React" or "Content-Disposition: Reaction" in the
outermost header).
It's quite another thing to write one for:
check for a part with a "reaction" content-disposition at either the
outermost level or as part of a multipart at the outermost level.
3. Clients would most likely want to hide reaction messages
Why?
Maybe you're the type of person who prefers this:
Original message
3 👍 1 👎 1 🤔
User A reacted with 👍
User B reacted with 👍
User C reacted with 👎
User C: I don't like this because…
User D reacted with 👍 🤔
There's nothing wrong with that and (minus the summary) it's more or
less what you get with clients that don't support reactions.
However, I prefer a UI where reactions are summarized and displayed on
the original message. Who reacted how can still be displayed as a popup
or in an additional screen. But I don't want to see that information by
default. Seeing this is how popular social media/chat sites do things
I'm guessing I'm not alone in wanting this.
Original message
3 👍 1 👎 1 🤔
User C: I don't like this because…
This is the main reason why I believe recognizing reaction messages
should be as easy as possible. Combining reactions and comments in one
message adds complexity without any meaningful advantage I can see.
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822