On 9/07/2015 03:13, John Gruen wrote:
> We should really be doing a better job of automating and testing spam
> scores for FxA emails. One of the major factors determining email
> spammy-ness is the overall reputation score of the email service
> provider. This means that running spam tests from l
On 9/07/2015 12:00, Ryan Kelly wrote:
> On 9/07/2015 11:48, Mark Hammond wrote:
>> I think the new mockups look better. I share the concern about adding
>> extra friction, but that seems under control.
>>
>> The only other point is that there was some discussion about letting
>> users correct the
On 9/07/2015 03:30, Ryan Feeley wrote:
> I’m more interested in engagement than adoption. I think we need to
> consider single-device syncers as a failure of UX because sync is not a
> good back up solution (until we make it one, which I support).
This is an important perspective, although I don't
On 9/07/2015 12:00 PM, Ryan Kelly wrote:
In Mark's example above, the user completes customization of their
account before realizing that they typo-ed their email address. To fix
it up, they just do a normal "change your email" operation and get on
with things, without losing their customized pr
On 9/07/2015 11:48, Mark Hammond wrote:
> I think the new mockups look better. I share the concern about adding
> extra friction, but that seems under control.
>
> The only other point is that there was some discussion about letting
> users correct the email address they used (eg, on a typo). ISTM
I think the new mockups look better. I share the concern about adding
extra friction, but that seems under control.
The only other point is that there was some discussion about letting
users correct the email address they used (eg, on a typo). ISTM we might
as well get that in this flow too -
John Gruen has submitted 56 hours of PTO from Aug 13, 2015 to Aug 21, 2015 with
the details:
I am taking a vacation.
- The Happy PTO Managing Intranet App
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct
Ryan,
Changing the sub-header on the first run page goes a long way:
https://www.dropbox.com/s/0fflalrtnn85f5e/Screen%20Shot%202015-07-08%20at%202.37.06%20PM.png?dl=0
> On Jul 8, 2015, at 2:26 PM, John Gruen wrote:
>
> Here’s something we can definitely agree about. The demo first run page do
Here’s something we can definitely agree about. The demo first run page does
very little to support the multi-device value prop [1]
A lot of our users have no idea that we make Android of iOS clients. For them,
the term “everywhere you use firefox” currently just refers to a single
machine. Why
Again, if Pocket has 98% acceptance of the email permission screen, we can
assume a similar screen will have similar success. We don’t need to rush people
into registering for something they don’t understand. There may be benefits to
introducing this before verification, and I agree, we should m
I’m definitely in agreement that multi device signup is the right thing but by
lengthening the pre-verified flow by 400% we’re going to heavily increase
exit/bounce and lose the relationship altogether. It feels like we’d be cutting
off our nose to spite our collective faces. Without an account,
Ryan and John,
Can you coordinate this with the Growth team? They have similar goals to
drive multi-device and are proposing other solutions.
FWIW, even asking for the "Make Firefox Yours" info pre-verification makes
me somewhat nervous about how that'll affect signup. It's testable though.
Shane
I’ve added some comments to the slide you should be able to see in link below
(green post-its).
I’m more interested in engagement than adoption. I think we need to consider
single-device syncers as a failure of UX because sync is not a good back up
solution (until we make it one, which I suppor
I'd like to see an A/B test where we put 'make fx yours' screen
before/after verified email screen. Our users will tell us if increased
friction vs early customization gets users through the flow.
-e
On Wed, Jul 8, 2015 at 8:33 AM, John Gruen wrote:
> Agree with Mark and Ryan K. on the problem
We should really be doing a better job of automating and testing spam scores
for FxA emails. One of the major factors determining email spammy-ness is the
overall reputation score of the email service provider. This means that running
spam tests from localhost will not produce consistent, repre
Agree with Mark and Ryan K. on the problem of overloading the funnel before
registration. It seems like there are two competing interests coming into play
here: increasing signups vs increasing engagement. Is there a middle path where
we can do both?
I’ve reworked the flow to hopefully address
16 matches
Mail list logo
