Subject: [Simple] is-composing: has-focus?

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 08 Mar 2004 05:55:23 -0500

The AT&T Hubbubb IM/presence client (http://www.hubbubme.com/) has an 
interesting feature that fits nicely into the is-composing draft: a 
'has-focus' indication that shows if the IM application has the user's 
window focus, i.e., the user is paying attention to what's being sent 
from the other side or is likely to respond soon. Any opinions of 
including this as an optional state, i.e., a user MUST be able to choose 
whether this gets sent and it MUST be off by default?

Henning

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 01:41:06 -0500

Firstly, "has-focus" is probably a bad name, since its dangerously close 
to "is-focus" which means something entirely different in the SIP 
specifications...

Secondly, does this really provide useful information? Just because the 
window doesnt have focus doesnt mean I'm not paying attention. Indeed, I 
frequently look at another window while a user is typing to me (often 
another IM conversation). Or, to ask more concretely, how would a user 
change their behavior in knowing that my IM window didnt have focus?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 01:41:06 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Mar 2004 05:31:14 -0500

> to "is-focus" which means something entirely different in the SIP 

We have another "session" word :-)

> change their behavior in knowing that my IM window didnt have focus?

Probably mostly the converse: if the IM application doesn't have focus 
and I don't get any response, it may well be that my counterpart is 
distracted.

The problem is similar to <idle>: it's an observation that approximates 
an unobservable reality. A long idle time may just mean that you're 
reading next to your PC, but it might also explain why you're not answering.

One possible generic solution is to define an 'interaction state' 
variable and allow multiple values, including 'composing' and 
'out-of-focus'.

I doubt this is the most important feature in IM systems, but it would 
be much harder to add later than now, so I'd rather settle this now.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Mar 2004 05:31:14 -0500

Henning

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Mar 2004 14:21:44 -0800

At 5:31 AM -0500 03/09/2004, Henning Schulzrinne wrote:
>
>I doubt this is the most important feature in IM systems, but it 
>would be much harder to add later than now, so I'd rather settle 
>this now.
>
>Henning

I certainly agree with the first part of the statement, but I'm a bit concerned
about the second. There are lots of systems for which the "focus" metaphor
doesn't work all that well (if a flip phone is open when the IM comes through,
is that "focus"?), and I'm concerned that working through them might
be a distraction for low value, especially if later states are needed.

As a simplifying proposal, is there an *action* (like typing) that can
be used to express this, rather than an "interaction state"?   If so,
I'd more inclined to say throw that action in, rather than trying to
get a "state" defined.

Again, just my two cents.
			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Mar 2004 14:21:44 -0800

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Mar 2004 22:07:56 -0500

> be a distraction for low value, especially if later states are needed.

I would argue for simplicity here: "if there is no obvious window system 
that has the notion of input focus, that state just can't occur".

> I'd more inclined to say throw that action in, rather than trying to

I'm confused by this paragraph. The current draft already defines typing 
as a state and that has been non-controversial for a while. I'm not 
quite sure what you are suggesting here.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Mar 2004 22:07:56 -0500

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 09 Mar 2004 22:14:57 -0800

There are a lot of types of focus in a UI. It could be keyboard focus, mouse
focus, window frame was in foreground, the virtual desktop was in focus, the
voice recognition stuff was in focus, the gesture recognition system was in
focus for this window. Hmm, the combination of gesture recognition and
emoticons is quite interesting now that I think about it.

Seriously, I think that focus is how the window system abstracts the
application from knowing about what devices it is currently has and giving
the application the virtual impression that it has access to all the human
interface devices. Breaking this abstraction is generally bad. Making
protocol explicitly require application to break this abstraction does not
seem good. 

Providing a fuzzy metric of how much the user is paying attention to this
application might be a good idea but has a lot of issues ranging from how
would the application compute this to what policies would be used to reveal
it. 

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 09 Mar 2004 22:14:57 -0800

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Mar 2004 10:28:41 -0500

> be much harder to add later than now, so I'd rather settle this now.

Why is it harder to add later? We should make sure there are hooks for 
future states, and then we can do it down the road if it proves important.

Given such hooks, in the interests of focusing on a well-scoped and 
well-understood problem, I would suggest not trying to tackle this now. 
Cullen raises a lot of questions which indicate that an unambiguous 
definition of focus might be harder to write down than it would seem.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Mar 2004 10:28:41 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Mar 2004 21:15:25 -0500

We can indeed add more states later, but then probably should change the 
current schema to use an IANA-registered string, not the token list 
that's in the current schema. I'll make that change and allow for 
additional states in the text, as the has-focus state suggestion seems 
to be both insufficiently specified and insufficiently important to 
further discuss at this point.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Mar 2004 21:15:25 -0500

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Mar 2004 00:38:47 -0500

Henning Schulzrinne wrote:

> that's in the current schema. 

You mean, change the schema for "status"? I would argue that this is a 
separate state altogether, peer to "iscomposing".

Indeed, one might argue that we could just define is-composing and 
has-window-focus (or whatever) as pidf extensions, and just ship a pidf 
document in the message body. We did conclude that sending this stuff 
in-band in the message stream is a better idea than using a separate 
presence subscription. Using PIDF means that a presence agent could say 
something about my *general* availability for IM because of my status in 
an IM session I have with someone else... just a thought....

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Mar 2004 00:38:47 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Mar 2004 08:57:03 -0500

Jonathan Rosenberg wrote:

>> We can indeed add more states later, but then probably should change 
>> the current schema to use an IANA-registered string, not the token 
>> list that's in the current schema. 
> 
> 

Let me be more precise: Instead of the current schema of

    <xs:element name="isComposing">
       <xs:sequence>
         <xs:element name="status" type="tns:status"
           minOccurs="1"/>
          [...]

       </xs:sequence>
     </xs:element>

     <xs:simpleType name="status">
       <xs:restriction base="xs:string">
         <xs:enumeration value="active"/>
         <xs:enumeration value="idle"/>
       </xs:restriction>
     </xs:simpleType>

we'd have

   <xs:element name="isComposing">
       <xs:sequence>
         <xs:element name="status" type="xs:string"
           minOccurs="1"/>
         [...]
       </xs:sequence>
     </xs:element>

> an IM session I have with someone else... just a thought....

Interesting possibility. This would be a kind of parallel to the 
draft-rosenberg-peterson-simple-pidf-phone-00 draft, just for IM-style 
devices.

Something like

<composing since="..." media="text">active</composing>

The advantage is that this would also allow to convey this easily to 
third parties, via PIDF subscription.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Mar 2004 08:57:03 -0500

</xs:sequence>
     </xs:element>

we'd have

Something like

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Mar 2004 09:47:35 -0500

>         <xs:element name="status" type="xs:string"

OK, except I see "has focus" as being orthogonal to is-composing, so I'd 
think you'd want both.

>> has-window-focus (or whatever) as pidf extensions, and just ship a 
>> pidf document in the message body. We did conclude that sending this 
>> stuff in-band in the message stream is a better idea than using a 
>> separate presence subscription. Using PIDF means that a presence agent 
>> could say something about my *general* availability for IM because of 
>> my status in an IM session I have with someone else... just a thought....
> 
> 

Similar, yes.

> third parties, via PIDF subscription.

Yes, that was the idea.

I'm on the fence on this one. The state is really dynamic, and its not 
clear how useful for me, or anyone else, it would be to know that you 
are currently typing an IM to someone else. Indeed, its far from clear 
that even if I did know, would this impact your availability to receive 
another IM? Not clear.

Another question is authorization. Do we ever think anyone would 
authorize a third party to see their is-typing indicators? Or that we 
would expect a PUA to publish them to a PA?

Another drawback is that the pidf document is larger than a simpler 
is-composing format, though not by much I suppose.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Mar 2004 09:47:35 -0500

Similar, yes.

Yes, that was the idea.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2004 10:08:57 -0500

> draft-rosenberg-peterson-simple-pidf-phone-00 draft, just for IM-style 

This is sort of interesting. But I do think there is an important 
difference. In presence, is-composing will presumably be generic. But in 
the context of a message session I really want is-composing to mean that 
a message is being composed for sending within this session.

Often with I see such a status I just wait for a message rather than 
sending a message myself. The status would be much less useful it it 
weren't that specific. I might be sitting there waiting for your message 
while you are busy chatting with your kids.

> third parties, via PIDF subscription.

So, I think the pidf extension would be useful in any case, but it might 
not be the right thing here.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2004 10:08:57 -0500

Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Mar 2004 10:20:30 -0500

> OK, except I see "has focus" as being orthogonal to is-composing, so I'd 

My assumption was that composing implied focus, but not vice versa. How 
could I compose without window focus?

> is-composing format, though not by much I suppose.

At this point, since there don't seem to be compelling advantages and 
given Paul's subsequent note on the importance of a per-session nature 
of this indication, maybe expediency and making-progress argue for 
sticking to the minimal notification variation.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Mar 2004 10:20:30 -0500

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2004 09:40:07 -0600

> whether this gets sent and it MUST be off by default?

I know in more "interactive" environments, asking the  question "Are you 
looking at me?" often presages more vigorous discussions. Indeed, it is 
often followed by the question "Do we have a problem here?", or an 
assertion that the addressed should "Look at me when I talk to you, mister!"

I think we're approximating (or at least attempting to approximate) an 
analog of "eye-contact" here -- the sort of thing that cues us into 
whether or not the party which wich we are attempting to communicate is 
also attempting to communicate with us, or has perhaps buried our 
communication attempt beneath a stack of other distractions.

So, what's the use case? Is window-focus an adequate determinate? Is 
further information, such as "window is visble" needed?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2004 09:40:07 -0600

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Mar 2004 16:06:32 -0500

Henning Schulzrinne wrote:

> 
>>
>> OK, except I see "has focus" as being orthogonal to is-composing, so 
>> I'd think you'd want both.
> 
> 

True, but the opposite is not true. If the window does have focus, I can 
either be typing or not. Thats what I was thinking about. But I think we 
should punt on this for now.

>> that even if I did know, would this impact your availability to 
>> receive another IM? Not clear.
>>

I'll go with that, and make a final comment on the differences between 
the two.

In a message session, the indicator means "I'm typing a message to you 
right now". In a third party presence notification, we generally want to 
convey information that helps a watcher make a choice about whether to 
communicate with the presentity, and with what tuple. I would argue that 
whether or not I'm typing an IM this instant is NOT useful for that 
purpose. Really what we are after is "I have an IM session active with 
someone else right now". Thats a coarser grained statement, and more 
useful. indeed, its the exactly analogy of being on a call, but for IM.

So, I more or less convinced myself that is-typing was not in and of 
itself useful for presence, and so using a pidf extension for this is 
not the right approach.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Mar 2004 16:06:32 -0500

-Jonathan R.

---

From: Alex Audu <[email-masked]>
Date: Wed, 17 Mar 2004 13:54:57 -0600

My experience with "is-typing" or "is-composing" is that it makes for a 
better user
experience during an IM session.  I think it serves a pretty good purpose.

Regards,
Alex.

Jonathan Rosenberg wrote:

>> My assumption was that composing implied focus, but not vice versa. 
>> How could I compose without window focus?
>
>
> True, but the opposite is not true. If the window does have focus, I 
> can either be typing or not. Thats what I was thinking about. But I 
> think we should punt on this for now.
>
>
>>
>>
>>>> Something like
>>>>
>>>> The advantage is that this would also allow to convey this easily 
>>>> to third parties, via PIDF subscription.
>>>
>>>
>>>
>>>
>>> Yes, that was the idea.
>>>
>>> I'm on the fence on this one. The state is really dynamic, and its 
>>> not clear how useful for me, or anyone else, it would be to know 
>>> that you are currently typing an IM to someone else. Indeed, its far 
>>> from clear that even if I did know, would this impact your 
>>> availability to receive another IM? Not clear.
>>>
>>> authorize a third party to see their is-typing indicators? Or that 
>>> we would expect a PUA to publish them to a PA?
>>>
>> given Paul's subsequent note on the importance of a per-session 
>> nature of this indication, maybe expediency and making-progress argue 
>> for sticking to the minimal notification variation.
>
>
> right now". In a third party presence notification, we generally want 
> to convey information that helps a watcher make a choice about whether 
> to communicate with the presentity, and with what tuple. I would argue 
> that whether or not I'm typing an IM this instant is NOT useful for 
> that purpose. Really what we are after is "I have an IM session active 
> with someone else right now". Thats a coarser grained statement, and 
> more useful. indeed, its the exactly analogy of being on a call, but 
> for IM.
>

---

From: Alex Audu <[email-masked]>
Date: Wed, 17 Mar 2004 13:54:57 -0600

Regards,
Alex.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2004 17:16:24 -0500

Alex,

I don't think Jonathan is suggesting that an is-typing indicator should 
not be there - only that it shouldn't be a presence attribute. Rather it 
is a property of a specific message session, and so needs to be 
communicated as part of a message session.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2004 17:16:24 -0500

Alex,

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Mar 2004 20:19:19 -0500

Paul,

You are correct. Thank you for more clearly stating my position.

-Jonathan R.

Paul Kyzivat wrote:

>> My experience with "is-typing" or "is-composing" is that it makes for 
>> a better user
>>>>> OK, except I see "has focus" as being orthogonal to is-composing, 
>>>>> so I'd think you'd want both.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> that you are currently typing an IM to someone else. Indeed, its 
>>>>> far from clear that even if I did know, would this impact your 
>>>> At this point, since there don't seem to be compelling advantages 
>>>> and given Paul's subsequent note on the importance of a per-session 
>>>> nature of this indication, maybe expediency and making-progress 
>>>> argue for sticking to the minimal notification variation.
>>>
>>>
>>>
>>>
>>> I'll go with that, and make a final comment on the differences 
>>> between the two.
>>>
>>> In a message session, the indicator means "I'm typing a message to 
>>> you right now". In a third party presence notification, we generally 
>>> want to convey information that helps a watcher make a choice about 
>>> whether to communicate with the presentity, and with what tuple. I 
>>> would argue that whether or not I'm typing an IM this instant is NOT 
>>> useful for that purpose. Really what we are after is "I have an IM 
>>> session active with someone else right now". Thats a coarser grained 
>>> statement, and more useful. indeed, its the exactly analogy of being 
>>> on a call, but for IM.
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Mar 2004 20:19:19 -0500

Paul,

-Jonathan R.