[RTW] My biggest concern

Wendt, Chris Chris_Wendt at cable.comcast.com
Thu Mar 31 14:23:34 CEST 2011


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<mailto:sergel at google.com>>
Date: Thu, 31 Mar 2011 13:52:09 +0200
To: Tim Panton <tim at phonefromhere.com<mailto:tim at phonefromhere.com>>
Cc: <rtc-web at alvestrand.no<mailto:rtc-web at alvestrand.no>>, Chris Wendt <chris_wendt at cable.comcast.com<mailto: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<mailto:tim at phonefromhere.com>> wrote:
Our experience at phonefromhere.com<http://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<mailto:erik at hookflash.com>>
Date: Thu, 31 Mar 2011 12:30:54 +0200
To: Justin Uberti <juberti at google.com<mailto:juberti at google.com>>
Cc: "rtc-web at alvestrand.no<mailto:rtc-web at alvestrand.no>" <rtc-web at alvestrand.no<mailto: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<tel:%2B1.604.562.8647> | www.hookflash.com<http://www.hookflash.com/>



On Wed, Mar 30, 2011 at 4:08 PM, Justin Uberti <juberti at google.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:RTC-Web at alvestrand.no>
http://www.alvestrand.no/mailman/listinfo/rtc-web



_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no<mailto:RTC-Web at alvestrand.no>http://www.alvestrand.no/mailman/listinfo/rtc-web



_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no<mailto:RTC-Web at alvestrand.no>
http://www.alvestrand.no/mailman/listinfo/rtc-web



_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no<mailto:RTC-Web at alvestrand.no>
http://www.alvestrand.no/mailman/listinfo/rtc-web


_______________________________________________ RTC-Web mailing list RTC-Web at alvestrand.no<mailto:RTC-Web at alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no<mailto:RTC-Web at alvestrand.no>
http://www.alvestrand.no/mailman/listinfo/rtc-web


_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no<mailto:RTC-Web at alvestrand.no>
http://www.alvestrand.no/mailman/listinfo/rtc-web




--
Serge Lachapelle, Product Manager, T: +46 732 01 22 32
Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880

This email may be confidential or privileged.  If you received this communication by mistake, please don't forward it to anyone else,please erase all copies and attachments, and please let me know that it went to the wrong person.  Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110331/fabae793/attachment-0001.html>


More information about the RTC-Web mailing list