[Standards-JIG] JEP-0085: suggested triggers

Ian Paterson ian.paterson at clientside.co.uk
Wed Sep 14 18:37:16 UTC 2005

Hi Peter,

Please bear with this long email. I hope you find it gets better towards
the end. :)

> > IMHO two seconds is the *minimum* time a typical user
> > would take. After switching, she has to assimilate 
> > the new screen layout, find the information in the 
> > other window, switch back, assimilate the screen 
> > again, process whatever information she saw, decide
> > what to write, and restart typing. This is not a quick
> > procedure for non-geeks, and even geeks insist on 
> > having one (or even two) big screens because of the
> > gains in efficiency.
> I think you underestimate the speed at which people can 
> switch contexts.

It's a shame we don't agree on this because it is central to our
discussion. :( Perhaps this would make a good PhD thesis for someone? ;)

I seriously doubt that typical users (not expert users) actually perform
the following process in less than 2 seconds, even 10% of the time:

1. stop composing
2. switch to another window (and assimilate new screen layout)
3. read whatever it was they were interested in
4. switch back to the chat window (and assimilate new screen layout)
5. decide what to write (based on whatever was read)
6. restart composing

Perhaps you and other people reading this thread typically take less
than 2 seconds, but I'm sure I don't (and, like any other geek, I'm an
expert PC user). I can only assume that Aunt Tillie will do it less than
1% of the time.

Even if 10% of the time the process takes less than 2 seconds, that
doesn't worry me, because the consequences of errors are trivial. If you
perform the whole process in a split second then your 'paused' state
will be corrected in a split-second too. So, IMHO, *there is no
significant downside.*

> > People don't typically pause in the middle of a 
> > sentence for very long. So if their client relies
> > on a short timer to trigger pause notifications,
> > then the 'risk' is always that you either:
> > 1) will never be informed about the pause, or
> Why not? No more composing activity after x seconds and 
> you're informed.
> > 2) will only be informed about the pause a split-second
> > before the person restarts typing! (i.e. when it is too late)
> Life is hard. :-)
> 1. What is the harm of waiting x seconds rather than
> trying to predict what might happen?

OK, for illustration purposes only, let's say a typical pause (not
necessarily involving a window focus change) lasts 6 seconds, and we set
our pause trigger to 4 seconds. Here are two problems:

1) Pauses below 4 seconds are never communicated, even though a pause of
2 seconds is a real pause (and hence interesting) and a pause of 3.9
seconds is even more likely and interesting.

2) Very typical pauses of 5 or six seconds are only communicated to the
other person when it is too late, when the pause has (almost) finished -
and is therefore no longer interesting. (When the state has to be
corrected immediately.)

You may say "Life is hard". I'm saying it doesn't always need to be.
These problems are both solved, in those cases where a paused
notification is triggered by a focus change. So IMHO *there is a
significant upside*. (As long as you believe that focus changes result
in more than split-second pauses at least a significant amount of the

> [OT: In general I don't recognize the terms "clearly"...

Thanks. You are right.

I hope I made it more clear this time? ;)

> What is the benefit of trying to predict what might
> happen rather than waiting x seconds?
> The benefit of waiting x seconds rather than trying to 
> predict what might happen is, in my opinion, certainty
> (rather than guesses) regarding the user's chat state.

With chat states I'm not interested in what *did* happen, I'm interested
in what *is* happening. It is not critically important that either state
is correct, the important thing is that the state reflects reality as
much of the time as possible.

So maybe it helps to think of it this way: The instant that someone
starts a pause, the 'composing' chatstate on the other person's screen
no longer represents the truth, and it will be incorrect for several

IMHO predictive 'paused' notifications fix this error much more often
than they introduce errors. Also a false 'paused' is fixed almost
immediately, whereas a false 'composing' takes five seconds to fix.

I'm not arguing for predictive chat states in general. But I am arguing
for them, whenever the state typically lasts very little time. In those
cases, if you don't predict them, then the notification is *typically*
never sent or is too late to be worthwhile at all.

- Ian

More information about the Standards mailing list