Re: Changes to Hello

[Romain Testard]

Hi Gervase,

The Hello project is focussing on sharing websites (see
https://wiki.mozilla.org/Loop - a blog post explaining the reasons will
also be coming soon and more details on the wiki). Essentially we want to
focus on delivering the sharing use case rather than try to address many
different scenarios.

About your specific issues on the experience:
- "Stop" is not an ideal string, we're discussing a change on bug 1220608

- The pause functionality is being implemented on bug 1220608
 although we first
will remove the pause button first so that we clear the confusion around
the button being there but not functioning (bug 1231808
 uplift to Aurora)
- Please ping me if your "rooms lost" issue happens again, it would be good
to collect logs and understand what was happening there.



Romain

On Mon, Jan 11, 2016 at 5:04 PM, Gervase Markham  wrote:

> On 05/01/16 17:32, Gervase Markham wrote:
> > Firstly, I had a number of rooms. I had given the URLs to those rooms to
> > various people I like to communicate with, including bookmarking one on
> > the browser of a less techno-literate person. I open my Hello
> > mini-window today to find them gone, and no way of creating new ones.
> > Are all those links now dead? What user experience will someone have who
> > clicks one?
>
> Hmm. Seems like they've returned. Although they are listed under a
> "Recently Browsed" heading, which seems odd, and I can't see a way of
> creating a new room.
>
> Tab sharing seems enabled by default when one enters a room. OK, I
> disagree with that as a product decision, but it's your call. However,
> when I click "Stop" on the tab-sharing bar, it seems to end the call!
> How do I just cancel the tab-sharing bit? "Pause"? That UI language
> seems to violate the Principle of Least Surprise a little bit.
>
> Gerv
>
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
>
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Loop minimum viable calling solution

[Romain Testard]

Thanks Nils, some good comments here, I added my views below.

On 7/25/2014 5:16 AM, Nils Ohlmeier wrote:

Hi,

not sure if this is best place to start a discussion, but I wanted to 
throw out my view on a minimum viable calling solution for loop.


The link clicker in my view is not an acceptable solution for the end 
user.
It would be as if I give my parents a phone number where reachable for 
the next X hours, but if they want to call me tomorrow they first need 
to ask me via email (or some other communication tool) what my number 
today is. In my experience this is really hard to explain to 
non-technical people.
The account-less mode indeed does not address recurring communication 
scenarios in the most convenient way although we're hoping people will 
see value in the fact that you don't need to sign-up or share permanent 
identity to talk to someone else. We'll be monitoring the drop-off rates 
between "URLs shared", "URLs clicked" and "people actually getting in a 
call" to understand if this URL sharing solution makes sense to the 
users and where it should be improved through better UX.
The other reason is that on mobile devices it is not easy to copy a 
URL from a calling app into some other communication tool to send it 
out to some.
I'm not sure I fully understand your point here - on mobile you'd either 
click a link or if you have a client app (FFOS) you can generate a 
call-back link that you'll share leveraging app's features which make it 
easy. Not sure I understand why you'd want to copy / paste the URL?


On the other hand on desktop I don't see why we have to have an 
address book integration a.k.a. contacts. This is only valuable if my 
address book contains the Firefox Account email of my contact, or the 
contact has verified his phone number via the Loop MSISDN server. Both 
are pretty unlikely in my opinion.
There will indeed be challenges there related to the social graph for 
direct calling although the hope is that:
1 A contact list will make it easier to share URLs initially as the 
e-mail address of the callee will be known already (you try to call a 
contact but if he's not on the social graph you get offered to send him 
a call-back link to his e-mail address contained in your address book)
2 As URLs get shared to non social graph members, these people have an 
incentive to sign-up to Hello themselves so that the social graph gets 
bigger


In any case it is understood that at the beginning there will be very 
low volumes of direct calls between registered users.


Never the less I think a direct calling solution based on 
authenticated URLs is viable. If we integrate Firefox Accounts that 
would allow me to hand out either my email address or maybe permanent 
URL like loop.com/nils as the URL where I'm permanently reachable. 
Without an address book integrated into the Loop client this would 
require some form of input field where I can enter the email address 
or URL of the target user. But that should be easy to implement.
Totally agree regarding the value of vanity URLs although as per a 
previous discussion with Adam on this subject the challenges we'll need 
to overcome around such URLs will be their discoverability and access 
control.
Given we have no identity solution implemented as yet it also makes 
sense to start with random time limited URLs for account-less users to 
understand user appetite for them but I agree we'll probably want such 
URLs once FxA integration gets implemented.


We could also store once dialed email addresses or URLs locally for 
convenience until we have a server based address book integration.


Best regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media


___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox 30 WebRTC release notes?

[Romain Testard]

The Firefox release notes are on 
http://www.mozilla.org/en-US/firefox/releases/
From that page select a release to see the main changes and you also 
have a link to the complete list of changes - here 
 
(FF30 example)


Bugs are tagged by component and if you look-up the "WebRTC" component 
you'll see all the relevant bugs delivered in specific releases.



On 6/11/2014 3:22 AM, bryandonno...@gmail.com wrote:

Hello,

Do you have WebRTC release notes anywhere for new Firefox versions?

It is very helpful that the Chrome WebRTC team provides this information,
but I have not seen it for Firefox.

Thanks
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media


___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC Service: On temporary call URLs

[Romain Testard]

Guys, I want to clearly understand, will this prevent URL customisation 
(mz.la/romain) as well as easy to remember generated URLs 
(mz.la/two_driving_dolphins) ?
I'm not sure we want to do these things but I want to understand the 
implications of that decision.


Romain
On 2/20/2014 8:31 PM, Adam Roach wrote:

On 2/20/14 12:08, Dan Mosedale wrote:

On Thu Feb 20 09:15:15 2014, Adam Roach wrote:


Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible)
deliver it using the contact means (email or phone/SMS) corresponding
to the address book entry. So, when we create the URL, we'll know who
the user intends to give it to.

This is important because it allows us to say "You have an incoming
call from Alexis" rather than "You have an incoming call from some
random person." The delivery of calling party identity is simply
considered table stakes for a communications service nowadays [1].


I'm confused.  Isn't the main use case for the "call me link" making 
it very easy for someone
who doesn't already have an account to become engaged enough with our 
tool that they will be interested in upgrading to get an account to 
get the better user experience you're describing?


The "better user experience" you call out *is* for the user with an 
account, for whom we presumably want as pleasant an experience as 
possible.


The user *without* an account still has to deal with activating the 
link that has been provided to them. In fact, from the perspective of 
the user *without* an account, there will be literally zero difference 
in experience between the system I describe and one without this feature.




___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Naming the project

[Romain Testard]

Hi all,

Thanks for your input regarding re-naming the project.
This came to a draw between Loop and Archway and we decided that Loop is 
a good name for the WebRTC application project (the product name will be 
different).
Loop is concise, fits all of Andreas requirements and can be turned into 
a verb just like you do with Skype (Loop me in).


So please use "Loop" to name the project moving forward - a Wiki using 
the Loop name will be created and I'll be in touch with some of you to 
get that going.


If you see any issues with it please let me know!

Romain
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media