27 Aug
2024
27 Aug
'24
2:26 a.m.
On Mon, 26 Aug 2024 at 21:27, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
I think there's many shades of grey between the extremes of "this should
be
presented to the user in a purple dialog box" and "the client SHALL leave
the chatroom".
There's lots of things that affect the user experience in all manner of
ways. We shouldn't prescribe how these are presented, certainly, but the
fact they happen is important.
Or at least might be - the key to my mind is if you have two clients, one
of which expects that setting autojoin to false (in this case) will cause
all clients to leave, and the other does not, is this going to create a
horrible UX due to the interoperability gap?
I would personally expect that removing a bookmark entirely would
(reasonably) cause clients to leave the chatroom - but merely removing
autojoin would simply cause the clients not to join automatically in
future. Some clients might choose to leave, others might not, depending on
whether they consider the room to have been "only autojoined". Otherwise,
setting autojoin to false is the same as a retraction, which seems to me
like the autojoin flag is entirely redundant, and should simply be removed.
(It reminds me of an IMAP client issue from about 25 years ago, where some
clients would immediately EXPUNGE messages with the \Deleted flag set,
whereas others treated the \Deleted flag as temporary "trash can", from
which messages could later be recovered if needed, and EXPUNGE as the
"empty trash can" UX. The latter was actually the intent of the spec, and
if you used multiple clients, the immediate-EXPUNGE type would constantly
"empty the trash can" of the other.)
As Kev notes, we actually do require it in various places.
But whether a client leaves a chatroom and when is absolutely a protocol
behaviour, and we should stipulate it firmly (ie, with normative language)
if there's an interoperability concern - as, indeed, XEP-0402 has done
since JC and I wrote it.
Dave.
That sounds
awfully like a MAY. SHOULD is "MUST unless you know what
you're
doing, and you probably don't".
Sure. I'd rather it be non-normative, or even omitted, but that's not a
change we can make at this stage I think.
I'm also unconvinced that specifying whether
clients leave chatrooms or
not
when things happen is "UX" - it's
client behaviour, and that seems
entirely
within the remit of a XEP.
I disagree. Client behaviour, especially user-visible behaviour, is
exactly
UX and is up to the developers of the app based on their use case, etc.
experience,
too, but that's OK, as many things we do have an effect on UX.
We assume, for example, that if you send a message to a client it'll be
visible to the user sitting in front of it
We perhaps commonly assume this, but we don't require it in the spec and
indeed there are clients which ignore various messages based on various
criteria and I think that is a valid thing for them to do.