Subject: RE: [Sipping] Application Interaction Requirements

From: "Eric Burger" <[email-masked]>
Date: Wed, 2 Oct 2002 16:32:49 -0400

Short of the "Wildfire" example, e.g., using word-spotting, I don't think
we've got a chance for legacy support using DTMF keys.  The reason is that
the application development community used them all up long ago, and they
all look different.

Just take a look at the ISO voice messaging menu specification.  It looks
great, until you read the appendices, which give TWELVE alternative key
mappings.  I would offer that we just give up on trying to support focus on
black phones and focus [sic] on how to make things work on future devices.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Henning Schulzrinne
> Sent: Saturday, September 28, 2002 5:26 PM
> To: Jonathan Rosenberg
> Cc: Steve Fisher; 'Fairlie-Cuninghame, Robert'; 'David R. Oran';
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] Application Interaction Requirements
>
>
> I'm not a UI guy, but this is apparently a very old UI problem. Indeed,
> the primary job of a windowing system is to manage keyboard and mouse
> focus. The only exception are "modal" inputs, such as pop-up
> confirmation boxes, where an application can grab focus from the current
> application. From all I've heard, modal input is considered a very bad
> idea except in very limited circumstances ("Your PC is about to explode.
> Shut down?").
>
> Windowing systems use many different means of changing focus, from
> Alt-TAB to mouse-over-window to click-on-window. Many systems, such as
> the X-based window managers, make this a user-configurable option.
> Emphasizing what Jonathan said: all modern systems explicitly leave this
> to the windowing system, rather than the application. Anything else
> makes the system too unpredictable. Adding another application should
> not break what used to work before. I believe that's a fundamental
> principle of system design and rules out most matching algorithms except
> those where false switches are extremely unlikely (e.g., using
> wordspotting with a strange word that's unlikely to occur in normal
> conversation is probably ok.)
>
> I'm not up-to-date on audio operating systems, but I suspect that some
> of the speech interfaces for the blind have to deal with the same
> issues. Systems like Wildfire use word spotting to detect when they are
> being addressed, using the keyword to switch focus. The "windowing
> system" does not necessarily have to reside on the end system, as in the
> example of Wildfire.
>
> Jonathan Rosenberg wrote:
> > Ultimately, the problem here is the determination of "focus".
> >
> > Focus is the selection of an application with which the user is
> > currently interacting. The proper way to solve this is to provide the
> > user with some kind of user interface by which they can select a focus
> > in which their stimulus is interpreted. As an example, a web-based
> > calling card application would provide the user with an html form that
> > they can use to enter their credit card and pin. The calling card app
> > gets the focus when the user selects that window. It is clear that the
> > stimulus is targeted at that specific application. The client would
> > provide its form post directly to the credit card app. There is
> not even
> > a hint of a feature interaction problem here.
> >
> > As another example, consider a phone with buttons on a display. A
> > transfer connect app might "own" one of those buttons, such that its
> > label is "transfer connect", and once its pressed, the user is told to
> > enter the target number and press pound. Once they do that, the
> > resulting number is sent ONLY to the transfer connect app, since it had
> > the focus for the input.
> >
> > Now, our problem is that the legacy telephone network has (by todays
> > standards) a horrible user interface. One of the problems is that when
> > there are multiple applications running, there is no explicit way that
> > the user can provide focus. For example, if a voice recorder app is
> > running while I am speaking to an answering machine, there are
> two apps,
> > each of which is expecting DTMF stimulus. When I press #, who receives
> > the pound? Generally speaking, how is focus determined, and by whom?
> >
> > It is my view that focus can ONLY be determined by the element which
> > knows about all the applications which are requesting user input. Thats
> > because the focus will need to determined by looking at all of the
> > stimulus inputs that have been requested, so as to determine which
> > one(s) should and should not receive it. That is the client, NOT an
> > individual application. Focus determination is **purely a client
> > issue**. Applications should never have any visibility or control of it.
> >
> > So, how does the client determine focus? If we generalize Steve's
> > transfer-connect application, the idea is that each application,
> > presumably, has some kind of digit map (in mgcp-speak) which determiens
> > the stimulus they are looking for. For the transfer connect app, its
> > [*Txxxxxxxxxx]. So, if we assume that there is a set of such
> digit maps,
> > Steve's proposal is that focus is determined by a matching process to
> > the digit maps of each application. The one whose digit map matches
> > first, receives the focus. As a policy, this clearly has problems -
> > multiple digit maps may match, and the matching may require too
> much input.
> >
> > So, I am not convinced that this is the right policy. I'm on the fence
> > about whether we even need to specify the policy. Dave, for example,
> > might like to apply his patented technique to his phones. I might like
> > to build phones with the tabbed display approach I describe
> below. Can't
> > he do what he wants, and I, what I want? Why do the applications care?
> >
> > We may want to recommend or describe a baseline algorithm, though. As
> > such, some requirements for it would make sense. Here are the ones I
> > would propose:
> >
> > R-JR-1: The framework must specify a way to determine focus in a client
> > when the client cannot explicitly determine focus
> >
> > R-JR-2: The focus determination algorithm should attempt to minimze the
> > delay in providing stimulus to applications
> >
> > R-JR-3: The focus determination algorithm should attempt to minimize
> > false positives, that is, it should aim to provide stimulus to a single
> > application at a time
> >
> > The recipient of the media streams can be considered an application for
> > purposes of these requirements.
> >
> > I don't know what the right algorithm is, and I think we need
> to work on
> > it. I am sure that some of the existing work on feature
> interaction will
> > be helpful here.
> >
> > Let me make an additional comment on R-JR-1. The problem at
> hand here is
> > strictly a CLIENT problem. An application can still expect pure DTMF
> > input, yet the client can provide focus. One can imagine a client
> > display with tabs for each app. When you select a tab, any keypad input
> > goes only to that app. In this case, the client does have a means of
> > explicitly determining focus. Thus, the problem Steve is having is a
> > client problem, not an application problem. It therefore cannot be
> > solved by an application telling the client to suppress input. The
> > client must determine which app(s) to send it to based on information
> > from the apps.
> >
> > Finally, I would like to emphasize that I believe the aim of the
> > application interaction work is NOT to design for these dumb
> phones, but
> > rather, to design for the smart ones, with UI capabilities, and deal
> > with the dumb ones as a special case. I would prefer not to profilerate
> > these awful problems into the future.
> >
> > -Jonathan R.
> >
> >
> > Steve Fisher wrote:
> >
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 02:16:19 -0400

> black phones and focus [sic] on how to make things work on future devices.

I think we can give up on uniquely determining focus, but I think its 
important to describe a baseline algorithm that a phone or gateway 
should run in order to figure out where to send DTMF. This should do as 
good a job as we can do given the user interface constraints of the phone.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com