- From: Sam Dutton <dutton@google.com>
- Date: Thu, 16 Jan 2014 14:57:14 +0000
- To: Justin Uberti <juberti@google.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Tsahi Levent-Levi <tsahi.leventlevi@gmail.com>, public-webrtc <public-webrtc@w3.org>
- Message-ID: <CAACxJ5pEXNdFRK+OFxcRfOUNYQ=iKysSbCzRjpiMPE2wB=Om_w@mail.gmail.com>
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 14:58:02 UTC