On 10/21/2020 6:43 AM, Ned Freed wrote:
First of all, I think there's at least one more key insight that we need to
pull out of existing reaction facilities: In many if not most cases they
operate independently of reply messages. Indeed, this is what makes them so
attractive: As a user I can offer an opinion of something without having to
write anything. I just click on a button, up comes a panel of emoji, I make a
selection, done. (Yes, I realize this is a UI detail, and we don't do UIs,
but it's such an important capability that it warrants our attention.)
(I'm responding, here, only to the above text, and not yet to the
proposal that followed.)
In spite of the above text's latter comment on UI detail, it seems to
confuse UI design with semantics.
Specifically: Triggering a reaction is, in fact, making a reply.
The UI means of doing that are, of course, quite different from typing a
text reply, and the display of the reaction is handled quite
differently. That's possible because the reply is data-typed specially.
In a sense, this is on a par with distinguishing a message's being a
reply, versus being standalone. It's created somewhat differently and
it (can be) displayed somewhat differently (linking it to previous
messages), by virtue of attaching the In-Reply-To header field. (Let's
ignore the earlier, heuristic of matching Subject: text.)
These creation-side and display-side UI differences are hugely
important, of course, but they don't alter the underlying, transactional
nature of an affect-indication response, from a free-form text response.
ietf-822 mailing list