I've been quiet on the list and perhaps this has already been discussed. My primary concern has to do with the way users interact with their browsers and tying the lifetime of the streaming sessions to the javascript on a webpage. Given the proposals, javascript will likely be used to setup streaming sessions and thus there will need to be automatic clean-up of these sessions when the related javascript objects are closed when a website page is "closed". This in my opinion can cause major issues with users. 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. I frequently click on those pages accidentally. If I'm simply viewing email, no big deal, I hit the back and while I'm annoyed I can easily recover. With a call in progress this will no longer be the case. The entire session state will be destroyed, the calls will tear down immediately as a result of the lifetime of streams being tied to the lifetime of the javascript objects on the page. I think practically speaking this will happen often. Users will be in a call with each other and say "have you seen that new cool video", and most non tech savvy users will simply type the search into their browser window and their search bar and the browser javascript will be torn down and bring down all the RTP streams thus ending any active communication as a result. How annoying it would be to have established calls torn up/down based on typical browser usage by a user! Expecting users not to navigate while calling is impractical and expecting users will open new browser tabs will be unworkable, especially to anyone like me has had to support family members confusion over browser tabs and accidentally closing what they are working on... I think the depth of this issue is unique to RTC-WEB proposal. Of course, I've seen this issue with videos and other places - where you are in the middle of watching a video, click to a new page and then come back to have the video start over and if it doesn't index itself properly will have to download and play from the beginning. Youtube has done a lot to solve those usability issues by doing many intelligent work arounds and keeping currently locations pretty accurate when going "back". But I fear no such work arounds will be easy or possible with RTC-WEB and solutions could open up new cans of security worms. For example, reopening a closed page with the "back button" could cause re-open a previously accidentally closed media sessions but could also open an intentionally closed sessions. Re-opening the connection automatically based on going "back" to a previous page could be embarrassing if you did actually intend to end the call and then the microphone was re-opened automatically broadcasting to the previous person you were connected. To keep media sessions alive even as users click around implies the lifetime of the call exists outside the active browser page. But this opens up other issues. For example, when does the call get automatically torn down if they leave the site? Or where are the controls for the call going to exist outside the site if the page with the controls is closed? (and the browser would have no understanding of what controls should be presented when navigating off the page since every website will have their own call control definitions). So maybe I'm missing something important like other browser future technologies introduced in conjunction with RTC-WEB (e.g. application based web sites) but I don't understand how RTC-WEB is going to get around these javascript-tied-to-a-webpage lifetime issues... Regards, Robin Raymond hookflash
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.
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. Robin Raymond hookflash On Mon, Mar 28, 2011 at 1:00 PM, Timothy B. Terriberry < tterriberry@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@mozilla.com <mailto:tterriberry@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@alvestrand.no <mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing listRTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing listRTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing listRTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Strikes me the natural way to deal with this is to put the 'call' page into an extension (term overload there - but I mean a browser extension) as in Chrome, the code effectively lives in the top bar of the browser, making it available to accept incoming calls all the time. The Google case is somewhat special in that many people leave a gmail tab open for a whole working day, not many other sites have that level of stickiness. We need to be aiming at supporting casual use too. Tim. On 31 Mar 2011, at 11:30, Erik Lagerway wrote:
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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@hookflash.com<mailto:erik@hookflash.com>> Date: Thu, 31 Mar 2011 12:30:54 +0200 To: Justin Uberti <juberti@google.com<mailto:juberti@google.com>> Cc: "rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>" <rtc-web@alvestrand.no<mailto:rtc-web@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<http://www.hookflash.com> On Wed, Mar 30, 2011 at 4:08 PM, Justin Uberti <juberti@google.com<mailto:juberti@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@hookflash.com<mailto:robin@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@alvestrand.no<mailto:harald@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@mozilla.com<mailto:tterriberry@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@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no>http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
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@hookflash.com> Date: Thu, 31 Mar 2011 12:30:54 +0200 To: Justin Uberti <juberti@google.com> Cc: "rtc-web@alvestrand.no" <rtc-web@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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@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@hookflash.com> Date: Thu, 31 Mar 2011 12:30:54 +0200 To: Justin Uberti <juberti@google.com> Cc: "rtc-web@alvestrand.no" <rtc-web@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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing listRTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@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.
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@google.com<mailto:sergel@google.com>> Date: Thu, 31 Mar 2011 13:52:09 +0200 To: Tim Panton <tim@phonefromhere.com<mailto:tim@phonefromhere.com>> Cc: <rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>>, Chris Wendt <chris_wendt@cable.comcast.com<mailto:chris_wendt@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@phonefromhere.com<mailto:tim@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@hookflash.com<mailto:erik@hookflash.com>> Date: Thu, 31 Mar 2011 12:30:54 +0200 To: Justin Uberti <juberti@google.com<mailto:juberti@google.com>> Cc: "rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>" <rtc-web@alvestrand.no<mailto:rtc-web@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@google.com<mailto:juberti@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@hookflash.com<mailto:robin@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@alvestrand.no<mailto:harald@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@mozilla.com<mailto:tterriberry@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@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no>http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@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.
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@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@google.com> Date: Thu, 31 Mar 2011 13:52:09 +0200 To: Tim Panton <tim@phonefromhere.com> Cc: <rtc-web@alvestrand.no>, Chris Wendt <chris_wendt@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@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@hookflash.com> Date: Thu, 31 Mar 2011 12:30:54 +0200 To: Justin Uberti <juberti@google.com> Cc: "rtc-web@alvestrand.no" <rtc-web@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@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@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@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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing listRTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On Mon, Mar 28, 2011 at 7:00 AM, Timothy B. Terriberry <tterriberry@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).
You are correct, they're called Pinned Tabs in Chrome. http://www.chromium.org/chromium-os/user-experience/tab-ui
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- John Luther Product Manager, WebM Project (518) 302-1773 www.webmproject.org US Eastern time zone
participants (9)
-
Erik Lagerway -
Harald Alvestrand -
John Luther -
Justin Uberti -
Robin Raymond -
Serge Lachapelle -
Tim Panton -
Timothy B. Terriberry -
Wendt, Chris