[RTW] My biggest concern

Thu Mar 31 14:33:04 CEST 2011

I also believe that it is the new, unthought of scenarios that will drive
this effort forward.

I simply wanted to point out that Call Classic™will still be available :)

/Serge

On Thu, Mar 31, 2011 at 14:23, Wendt, Chris
<Chris_Wendt at cable.comcast.com>wrote:

>  Interesting, I would hope use-cases that exist today aren't the
> sole consideration.  My, perhaps wrong, assumption was the goal is to
> provide standard javascript API/html tags that, combined, provide the
> generic capability to transmit voice, video, media, whether one way, two
> way, always on, periodically on, browser to browser, browser to device, …
> and those that are much more creative, than at least I, will find the
> applications whether traditional or not.
>
>  Just my 2 cents.
>
>  -Chris
>
>   From: Serge Lachapelle <sergel at google.com>
> Date: Thu, 31 Mar 2011 13:52:09 +0200
> To: Tim Panton <tim at phonefromhere.com>
> Cc: <rtc-web at alvestrand.no>, Chris Wendt <chris_wendt at cable.comcast.com>
>
> Subject: Re: [RTW] My biggest concern
>
>  Agree that calling is not the only scenario, but an important one.
>
>  I think that application developers will need to put HTML5 notifications<http://www.html5rocks.com/tutorials/notifications/quick/>to good use for incoming calls, messages and such.
>
>  /Serge
>
> On Thu, Mar 31, 2011 at 13:43, Tim Panton <tim at phonefromhere.com> wrote:
>
>> Our experience at phonefromhere.com is that on-for-a-long-time (!= always
>> on) is actually the main use case.
>> We had assumed that short calls to sales/support would be the main usage,
>> but it isn't (at least for us).
>> We see more take up as a deskphone substitute for folks on the road/home
>> (taking incoming calls - hence 'available' for 8 hours a day )
>> or deeply embedded in collaborative environments (conference calls, shared
>> whiteboards etc) where the calls also last for hours.
>>
>>  The only place where short calls seem to happen much is the "I don't
>> want my/your number recorded" market - think dating and recruitment.
>>
>>  Tim.
>>
>>  On 31 Mar 2011, at 12:15, Wendt, Chris wrote:
>>
>>  I would envision that the use case of a traditional phone/video
>> conferencing terminal, security camera, etc. (i.e. always on) is something
>> that would be either not implemented using RTCWeb, or would use some form of
>> an "embedded browser".
>>
>>  The use case of embedding voice/video/etc. capabilities in a web page in
>> a traditional browser would be more for temporary availability use case.
>>  Customer service call, game chat, virtual environment, etc.
>>
>>  That, of course, is not to say the "always on" case would be impossible
>> to implement in a traditional browser, but at least, for me, wouldn't be my
>> first choice.
>>
>>  Curious if others agree, or if I am way off-base.
>>
>>  -Chris
>>
>>
>>   From: Erik Lagerway <erik at hookflash.com>
>> Date: Thu, 31 Mar 2011 12:30:54 +0200
>> To: Justin Uberti <juberti at google.com>
>> Cc: "rtc-web at alvestrand.no" <rtc-web at alvestrand.no>
>> Subject: Re: [RTW] My biggest concern
>>
>>  It could be that this will become more of an apparent issue as the web
>> apps we are speaking of are increasingly used for incoming calls as well?
>>
>> *Erik Lagerway | hookflash | m. +1.604.562.8647 | www.hookflash.com*
>>
>>
>>
>> On Wed, Mar 30, 2011 at 4:08 PM, Justin Uberti <juberti at google.com>wrote:
>>
>>> It's not clear to me that users who close the browser every time they
>>> want to go to a new page are the kinds of users who would multi-task while
>>> on a call.
>>>
>>>  FWIW, we haven't seen this as a problem with our web applications
>>> (which alert the user when closing the page when a call is active).
>>>
>>>
>>> On Mon, Mar 28, 2011 at 11:47 PM, Robin Raymond <robin at hookflash.com>wrote:
>>>
>>>>
>>>>  Except that the alert before a page closed will effectively mean the
>>>> users can't browser while a call is established. I know they can open tabs
>>>> but for many more novice users tabs are still complicated and they usually
>>>> hit the close for the browser instead of the tab because of their confusion
>>>> if a new tab is automatically opened for browsing purposes.
>>>>
>>>>  Yes, some UI tricks might help to fix this issue (especially browser
>>>> concept improvements like background apps) but I think it's important to
>>>> raise the issue even if it is beyond the scope of the protocol itself.
>>>> Otherwise a strong protocol will exist with a fatal flaw (I do understand
>>>> from a protocol perspective this isn't important). For some websites (like
>>>> games since), this might not matter but if a user is intending to use their
>>>> browser for the primary means of communication in the future this is an
>>>> issue especially with the way browsers are currently working.
>>>>
>>>>  Robin Raymond
>>>> hookflash
>>>>
>>>>
>>>> On Tue, Mar 29, 2011 at 2:05 AM, Harald Alvestrand <
>>>> harald at alvestrand.no> wrote:
>>>>
>>>>>  On 03/28/11 14:31, Robin Raymond wrote:
>>>>>
>>>>>
>>>>>  Pinning as an app tab is not something the average user is going to
>>>>> know how to do and it does not remove the search bar or the ability to
>>>>> navigate away. While it might be a possible solution if browsers added this
>>>>> concept programmatically (relying on the user is not practical IMHO), that
>>>>> would open another can of worms on how to prevent abuse where ads start
>>>>> creating themselves as auto-pinned "app" tabs.
>>>>>
>>>>>  While it might not be a concern for the draft per-say, if you design
>>>>> something that in practice doesn't work in the real world it will be a
>>>>> draft/RFC that won't get wildly adopted and that's death for anything as
>>>>> implementation is critical. I think it's important not to ignore this issue
>>>>> and a workable solution must be found or it will never get used by real
>>>>> users.
>>>>>
>>>>>  There's an even simpler workaround employed by many pages with
>>>>> in-progress state:
>>>>>
>>>>> Attaching a Javascript popup to the "close" action saying "You're in
>>>>> the middle of a call. Do you want to hang up?"
>>>>>
>>>>> A more advanced implementation with background app pages would offer
>>>>> multiple choices:
>>>>> - Suspend the call, but make it available for resumption
>>>>> - Keep the call open, running in a background page
>>>>> - Hang up the call
>>>>> I think Javascript has the necessary hooks, and we can leave this one
>>>>> to the UI designers.
>>>>>
>>>>>                  Harald
>>>>>
>>>>>
>>>>>
>>>>>  Robin Raymond
>>>>> hookflash
>>>>>
>>>>> On Mon, Mar 28, 2011 at 1:00 PM, Timothy B. Terriberry <
>>>>> tterriberry at mozilla.com> wrote:
>>>>>
>>>>>>  In my own situation, I have a list of common viewed websites at the
>>>>>>> top
>>>>>>> of my browser and a simple accidental click will go to those new
>>>>>>> pages.
>>>>>>>
>>>>>>
>>>>>>  If that's your biggest concern, then I have good news for you.
>>>>>> Firefox 4 has a feature called App Tabs designed to address these use cases
>>>>>> (I believe Chrome has something similar, but I don't use it so I don't
>>>>>> actually know). More information here:
>>>>>> http://support.mozilla.com/en-US/kb/what-are-app-tabs, but the
>>>>>> relevant sentence is: "Links to new websites open in a new tab so that your
>>>>>> App Tab doesn't change." I think this does exactly what you want.
>>>>>>
>>>>>> In any case, this is fundamentally an issue for the user-agent, and
>>>>>> not, I think, one that has much impact on the actual standards.
>>>>>> _______________________________________________
>>>>>> RTC-Web mailing list
>>>>>> RTC-Web at alvestrand.no
>>>>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> RTC-Web mailing listRTC-Web at alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> RTC-Web mailing list
>>>> RTC-Web at alvestrand.no
>>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>>
>>>>
>>>
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>>>
>> _______________________________________________ RTC-Web mailing list
>> RTC-Web at alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>>
>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110331/02315fd6/attachment.html>