W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

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

From: Tsahi Levent-Levi <tsahi.leventlevi@gmail.com>
Date: Thu, 16 Jan 2014 18:53:02 +0200
Message-ID: <CAKzE3MLukfNHnMgc6JmhizH2zo7s_fQo=A9QPLPVapfeiiTNCA@mail.gmail.com>
To: Sam Dutton <dutton@google.com>
Cc: Justin Uberti <juberti@google.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-webrtc <public-webrtc@w3.org>

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
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
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.


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
Received on Thursday, 16 January 2014 16:53:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC