ably / specification

The Ably features spec for client library SDKs.
Apache License 2.0
0 stars 4 forks source link

Update/Limit default typing timeout #238

Closed sacOO7 closed 2 days ago

sacOO7 commented 4 days ago

PS: While we currently have a negative timeout check for typing events, we should also introduce a max_typing_timeout check to prevent users from setting unrealistic values.

AndyTWF commented 4 days ago

The reason we set this number high was quite deliberate - we wanted to make it so that when users experiment with it, it was something that had a sense of permanence to it (we felt going too short would make it look temperamental, whereas what we wanted to show was a long enough time that the developer could comfortably observe it). For reference, when we tried with other platforms timeouts, most of them were around 3 seconds.

capped at 1 second since the event is transmitted in real-time, and we don’t want the receiver to see “typing” events after the sender has stopped typing.

Wouldn't we get that anyway? The receiver is still going to receive presence events in order, and we provide realtime ordering guarantees, so they'll see something regardless.

we should also introduce a max_typing_timeout check to prevent users from setting unrealistic values.

Is there a technical reason for us to do this? I'd rather not apply arbitrary constraints on users unless there's a technical reason to do so. Sure, 10 seconds is long - but if that's what somebody wants, we probably shouldn't stop them.

sacOO7 commented 4 days ago

Wouldn't we get that anyway? The receiver is still going to receive presence events in order, and we provide realtime ordering guarantees, so they'll see something regardless.

I’m not sure I fully understand this. The receiver will still get the stop event after 5 seconds, even though the sender has already stopped typing (before 5 seconds). Wouldn’t it be better to have default values that make more sense to the customer, rather than providing values that might seem like an error or misconfiguration?

I do see the point that they might want to configure the typing timeout themselves, but at the same time, we'd be forcing them to set a specific timeout value. The problem is that this value might not align with what they consider a "standard" timeout. So, having a current timeout of 5 seconds doesn't seem ideal, especially since the customer will likely need to adjust it anyway.

The current demo app works as per default configuration, but from the user's perspective, the typing event looks like a bug or misconfiguration. I’m also concerned that developers might end up with a negative impression, which goes against the experience we’re trying to create.

sacOO7 commented 4 days ago

I also believe it’s better to provide a default config. (across all features) that allows the app to run with minimal setup or intervention.

AndyTWF commented 4 days ago

The receiver will still get the stop event after 5 seconds, even though the sender has already stopped typing (before 5 seconds). Wouldn’t it be better to have default values that make more sense to the customer, rather than providing values that might seem like an error or misconfiguration?

After 5 seconds, IFF they haven't called typing.stop() in the meantime. If someone actually sends the message, then you'd expect the developer to call this to cancel typing earlier.

5 seconds was chosen (as well as the above reasons) because that sort of range was what we saw in other applications we looked at. Every customer is different, some may want a near-instant timeout, others might want a bit of leniency. I don't think we can realistically predict a value that's going to work in all cases. Of course, this is only if someone starts typing and then just sits there.