Re: Using watch()

[Jeff Schnitzer]

Any thoughts on this? I am considering pushing it into production
now, stubbed to survive the removal of .experimental. Am I crazy?

Jeff

On Wed, May 30, 2012 at 7:25 PM, Jeff Schnitzer <je...@infohazard.org> wrote:
> The watch API works great.  I like the way auto-login is completely
> transparent to the API.  Overall, this is easier to implement than the
> old api, even though it requires passing the email address into the
> client all the time.
>
> However, the new-user email roundtrip doesn't seem to work the way I
> was hoping.  Is this just still TBD?
>
> I found two behaviors when I log in with a fresh browserid account:
>
> 1) If I do the "smart user thing" (ie leave the browserid popup alone,
> and click on an email link that pops up in the same browser) then I
> get the same old instruction to "go back and find the window with the
> website in it".  The displayed domain is teasingly unclickable.  This
> is same as behavior with navigator.id.get().
>
> 2) If I do the "dumb user thing" (close the browserid popup, or open
> the email link in a different browser) then the UX is *really*
> confusing.  I don't even get the "go back and find the window"
> instruction; rather it seems to just log me into browserid.org as if
> that's what I wanted all along.  This is going to terrify a
> significant portion of my userbase.  I am worried.  This might be the
> same behavior as navigator.id.get()... I will try it right now.
>
> What I really want to happen:
>
> The final browserid signup screen has a link to my website and a HUGE
> button that says "click here to continue".  Ideally I can control this
> link, but right now I'd settle for it just sending the user back to
> the page they were on.  When the user gets back to my site, the
> watch-onlogin method will be called with their identity.
>
> Is this just pending or did I misunderstand how this is supposed to
> work?  If it's pending, any idea when this will be in production?
>
> Thanks,
> Jeff

[Jeff Schnitzer]

On Wed, May 30, 2012 at 7:25 PM, Jeff Schnitzer <je...@infohazard.org> wrote:
>
> 2) If I do the "dumb user thing" (close the browserid popup, or open
> the email link in a different browser) then the UX is *really*
> confusing.  I don't even get the "go back and find the window"
> instruction; rather it seems to just log me into browserid.org as if
> that's what I wanted all along.  This is going to terrify a
> significant portion of my userbase.  I am worried.  This might be the
> same behavior as navigator.id.get()... I will try it right now.

A quick fix that might help is to put a big "PLEASE DON'T CLOSE THIS
WINDOW" on the popup, something like this:

https://img.skitch.com/20120601-t2eqxi8ixh2d3uebf7h5cncmnq.jpg

Jeff

[Ben Adida]

Hi Jeff,

>> The final browserid signup screen has a link to my website and a HUGE
>> button that says "click here to continue". Ideally I can control this
>> link, but right now I'd settle for it just sending the user back to
>> the page they were on. When the user gets back to my site, the
>> watch-onlogin method will be called with their identity.
>>
>> Is this just pending or did I misunderstand how this is supposed to
>> work? If it's pending, any idea when this will be in production?

This general approach is indeed pending. One of the goals of the
.watch() approach is specifically to enable this.

So, you are safe to move to .watch() on your site, that's the way we're
headed, and that's where we'll support the new, far smoother
registration flow.

-Ben

[Jeff Schnitzer]

On Mon, Jun 4, 2012 at 7:07 AM, Ben Adida <b...@adida.net> wrote:
>
> This general approach is indeed pending. One of the goals of the .watch()
> approach is specifically to enable this.
>
> So, you are safe to move to .watch() on your site, that's the way we're
> headed, and that's where we'll support the new, far smoother registration
> flow.

Great - I have actually deployed this in production, including the
"deal with it myself" flow for change email. I'm actually quite a bit
happier with this API than the old one.

The one nasty edge case is changing the email address that you are
currently logged in with. Basically, the user has to be logged out of
browserid otherwise the login code will automatically create a new
account for them with the old email. My solution was to change to an
add/remove multiple-email system, which is better anyways - less
chance for accidental duplicate accounts.

The key is that you can add emails all you want, but if you try to
remove the email you are currently logged into browserid with, you
will be logged out (with a warning, of course).

This is not as good as being able to fire up the browserid dialog to
perform the change email, but it works.

My biggest usability issues right now are:

1) Expired cert in chain for autologin, which seems to be regular and
unavoidable now.

2) Getting back to my website after the email dance (is there a date
for when this might be in production? I'd be happy with an
'experimental' version of this - even buggy it would be better than
the current UX).

Jeff