[standards-jig] JEP-0022 - Additional Events
michael at aurora.gen.nz
Sun May 12 17:27:13 UTC 2002
> > I would advocate adding some more event types to this JEP. In
> > events <lostfocus/> and <gainedfocus/>. ICQ chat used to have something
> > similar to this (not sure if it still does, because it doesn't work
> > NAT) and it was very useful. Basically it means that the client can
> > some visual feedback if the remote user looses focus of their current
> This is just my opinion, of course, but I'll put forward two reasons
> why I don't think we should do this:
> (a) 0022 is informational, documenting what we have. Any new stuff should
> be in a new namespace, or at least a new JEP ('extending x:event' or
Uhh...ok. So if I add these events to my client first, I can get it into
this one, huh? ;-)
I actually think this is the ideal namespace. These events are very close
to the composing message event in both concept and usage.
> (b) 0022 is specifically related to messages (the composition and delivery
> thereof). Focus has arguably nothing to do with either of these. On the
> hand, focus on a window doesn't mean that any particular message 'tab' (or
> whatever GUI form the app might take) is showing - i.e. knowing the focus
> is on the Jabber app doesn't mean that any message _is_ being read.
You misunderstand - the implementation of this depends a lot on the client
design naturally. For those clients, where you have separate chat windows,
then you can do it with an event being generated when the user switches so
that the window in question has focus. Obviously if your client has only
one window with tabs (or whatever) then the focus event has to be raised
when the user switches to the appropriate tab.
It is hard to claim that if a user has your message window in focus, and
he/she is sitting at the computer, that he/she is not going to read what you
are typing. Is it possible? Yes, but without some sort of eyeball tracking
hardware, I think this is as good as it gets.
> On the other hand, not having focus on the Jabber app doesn't mean
> that a message _isn't_ being read.
This is more true than your last statement, but as with the last one,
without some sort of hardware device, it is as accurate as we can get.
> So one could say there's no useful connection between focus and the
> knowledge that a message might be being read.
One could say that, but if one had used a client that has such a feature,
one may be of the opinion that in practice it works pretty well. People
will understand how the events are raised, and will treat them accordingly.
For example, when I use Jabber today, I know that just because someone has a
status of "Online" it is a good indication that they are sitting in front of
their computer. This is not 100% accurate, as they may have just stepped
away to pile the dishes and answer the phone, but in this case no one is
saying that there is no useful connection between the two events.
> > Also, at the risk of going overboard, <chatclosed/> and <chatopened/>
> > might also be useful to indicate when someone has closed a chat session
> > you. This might get around the multiple goodbyes problem when one
> > isn't sure if the other has finished the conversation or not.
> To be honest, I didn't realise this was regarded as a problem. I just say
> ciao and go :-)
It's not a *problem* per se, but the advantage of IM over email, is that
each user has some real-time presence information to go off, which makes it
closer to a face to face conversation. This extends on that, providing a
little more feedback on how the user is reading and replying to your
messages (or not).
More information about the Standards