[RTW] My biggest concern

[Justin Uberti]

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> 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>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> 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
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>>
>>
>> _______________________________________________
>> RTC-Web mailing listRTC-Web at alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>>
>>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110330/a09fe50a/attachment.html>