Re: What is missing for building "real" services?

Hi Tsahi

I'm not suggesting ClickToCallUsingWebRTC.com force their customers to
re-architect their sites – just that there's more than one way to skin a
cat :^).

CTCUWebRTC can provide JavaScript that enables a popup, something like the
following.

>From any page that needs to provide access to a Click to Call popup:

1. Add <script src='js/ctcuwebrtc.js'></script> (or whatever).

2. Add JavaScript (for example) specifying the ID of an element which, when
clicked/tapped, opens a Click to Call popup or, on mobile, opens a new
window.

There may be better options, but at this point, other than by providing a
Chrome extension or similar, I can't think of a better way for CTCUWebRTC
to enable customers to use their service. The popup approach described may
not be ideal, but it doesn't require any major re-architecting.

Sam



On 16 January 2014 16:53, Tsahi Levent-Levi <tsahi.leventlevi@gmail.com>wrote:

> Sam,
>
> I understand that we can change websites to fit WebRTC, but think of the
> business model and value chain:
> I am a company called ClickToCallUsingWebRTC.com.
> What I offer is a widget to place on websites, and my focus is ecommerce
> sites.
> I focus on large ones - Travelocity.co, Shoes.com, Shopping.com - you get
> the drift.
> To get my sh*t together, I provide a single java script line that my
> customers need to embed in their websites, and magically, they get that
> capability.
> I need this kind of a thing so that the marketing guy can just add it in
> and be done with it with minimal interaction with his IT department (those
> notorious guys that kill every good initative).
> What you suggest is for me as ClickToCallUsingWebRTC.com to suggest to my
> customer (the marketing guy) to go to IT and start a whole transformation
> and redesign project for the website to this new tech called
> single-page-applications so he can use my widget.
>
> Now... what adoption rate will you see for WebRTC in such a case versus
> enabling it to work nicely on web sites as opposed to web pages?
>
> Just a thought.
>
> Tsahi
>
>
>
>
> On Thu, Jan 16, 2014 at 4:57 PM, Sam Dutton <dutton@google.com> wrote:
>
>> The Web is very page-centric!
>>
>> This is a problem for any site that wants to maintain some kind of
>> service while users navigate content, not just for WebRTC.
>>
>> For example, the BBC had to design their radio player<http://www.bbc.co.uk/radio4/>so users could listen while navigating
>> bbc.co.uk. They opted for a popup. Window.open() is not so great on
>> mobile – the BBC approach is to open the radio app when you click on the
>> Listen link on mobile – but on desktop it's an easy way to provide an
>> independent context (and UI) for objects to live and die. Forcing windows
>> to 'stay on top' is pretty hacky and (I think) undesirable in terms of UX.
>>
>> Of course, lots of popular websites load content dynamically via XHR
>> rather than using the click-on-a-URL-and-load-a-new-page approach. In this
>> case it's relatively straightforward to incorporate a video chat component
>> that 'sticks'.
>>
>> A more old fashioned technique is to use frames, which can work
>> reasonably well, but come with their own problems. Web apps with background
>> pages could also solve the problem, but only where available.
>>
>> All-in-all, I think the answer now is dynamic sites or popups or both.
>>
>>
>>
>>
>> On 15 January 2014 23:05, Justin Uberti <juberti@google.com> wrote:
>>
>>> I guess you could pop-under a window, and anchor the SharedWorker to
>>> that window so that the SharedWorker and PeerConnection persist, but that
>>> seems pretty unpalatable.
>>>
>>>
>>> On Wed, Jan 15, 2014 at 2:59 PM, Silvia Pfeiffer <
>>> silviapfeiffer1@gmail.com> wrote:
>>>
>>>> On Thu, Jan 16, 2014 at 6:01 AM, Tsahi Levent-Levi
>>>> <tsahi.leventlevi@gmail.com> wrote:
>>>> > Hi guys,
>>>> >
>>>> > One of the things that I am seeing is the lack of support in websites.
>>>> >
>>>> > WebRTC works great on a webpage, but not in websites. This means that
>>>> it
>>>> > makes perfect sense to use it in SPAs (single page application), but
>>>> if I
>>>> > want to embed it into a website (an ecommerce one for example) - it
>>>> is far
>>>> > from easy - the moment the user leaves the page in favor of another
>>>> one -
>>>> > the call drops.
>>>> > This causes a lot of vendors offering click-to-call services that get
>>>> > embedded into websites to open up the video/audio session in a
>>>> separate
>>>> > browser window, which then doesn't float around. The experience you
>>>> get is
>>>> > broken due to that.
>>>> >
>>>> > Fixing this by having a way for the service to express the fact that
>>>> it
>>>> > wishes to maintain WebRTC sessions across web pages within the same
>>>> domain -
>>>> > or in any other way - will imrpove usability.
>>>>
>>>> Hmm, interesting challenge. I don't think there is a way to retain
>>>> objects between navigations, not even same-domain.
>>>> You can create a separate browser window with window.open() [1] and it
>>>> remains open while navigating. But it doesn't stay on top FAICT.
>>>>
>>>> [1] http://www.quirksmode.org/js/popup.html
>>>>
>>>> Silvia.
>>>>
>>>> > On a similar note, it would be nice to be able to float the video on
>>>> top of
>>>> > the screen - not the browser window, but the whole desktop (and
>>>> mobile).
>>>> > This enables looking at things in parallel to the conference and still
>>>> > having context or the ability to see the people you are talking to.
>>>> >
>>>> > Call it my two cents...
>>>> >
>>>> > Regards,
>>>> > Tsahi Levent-Levi
>>>> > http://bloggeek.me
>>>>
>>>>
>>>
>>
>