Experiments for Completing the User Registration Flow in BrowserID

Over the past several months BrowserID adoption by sites both inside and outside of Mozilla has started to take off. We have received a lot of feedback from site operators, some good, some bad. Far and away the biggest complaint from site operators is that completing the new user flow in BrowserID is causing drop off in potential users converting to verified users. Because of this, our own User Researcher Mary Trombley and UX guru Crystal Beasley have made it their mission to make this experience as smooth as possible.

Mary user tested our current sign up flow with people who had never used BrowserID. The results were eye opening. Users are doing things we suspected may cause problems, but we did not realize the extent of the confusion we were witnessing.

The core problem is that users get lost once they verify their email with BrowserID. No clear indication is given for how to return to the original site being signing up to. Sometimes users close the original site, sometimes they open the verification page in a new window, sometimes they start on mobile and finish on their desktop, sometimes they do everything we expect but don’t realize the original site is still open in another tab. All users see after completing the new user flow is some text that says (paraphrased) “You have finished signing up to BrowserID…. You may now close this window.”

account_completion

Clearly, we have to do better.

Lloyd Hilaiel came up with some initial ideas outlined in the GitHub Tracking Issue. Skinny (Crystal) took these ideas and ran. She’s got UX talent. The changes she suggested were so obvious it was like “duh, how did we not think of this before?” But then again, it’s easy to say that in retrospect – the process for coming up with a smooth flow is anything but smooth.

Lloyd and Skinny’s initial suggestion was to use some browser trickery to get the user back to the initial site once they have completed the verification step.

If the original site is still open, we can use a window.alert to return focus to its tab. This works in Firefox, Chrome and Safari – neither Opera nor IE play nicely. Mobile browsers universally show the alert message, but fail to return the user to the correct tab.

If the original site is no longer open, we can redirect the verification tab back to the original site. Overall this offers a much better experience, but still leaves a huge hole – if we have to redirect the current tab to the original site, currently we have no way of indicating to that site that the user is now logged in. We think we have a solution to this using DOM events. I did a quick proof of concept on this last night and will post a video once something more concrete is available.

These simple changes boosted our conversion rates quite a bit. Skinny then took the flow and made it even smoother. She thought “why not enter the password inside the dialog?” Brilliant – when the user opens the verification link from their email, they have no additional work to do – all they have to do is worry about logging in.

BrowserID New User Verification Flow Experiments Screencast from Shane Tomlinson on Vimeo.

Both of these flows can be tried with right now. This is experimental work made for user testing and feedback – these flows should not even be considered alpha quality.

Flow 1 – https://feature385.myfavoritebeer.org/ – window.alert if original site is still open or redirect to original site if closed.

Flow 2 – https://feature1000.myfavoritebeer.org/ – Same as flow 1 with initial password entry inside the dialog.

Note, for these experiments we are using “hacksign.in” as our test version of “browserid.org” – you are not being hacked. Both domains are running in separate environments, so you will have to create an account on each.

I will be continue hacking on these flows over the next couple of weeks. Additional user tests will be done. We are going to keep refining until we get it right. Any and all feedback is welcomed and encouraged.

Check it out, see what you think.

Want to get involved?

We’d love to hear from you about how we can make this better!

  1. Can I make the suggestion that if you want people testing this you not use a domain like hacksign.in. I can’t think of a worse possible experience playing with a new login system for the web than being asked to trust something called hacksignin.

    • Thanks for the suggestion – even if we did show the bookmark toolbar, bookmarklets will only work for HTML polyfilled version of BrowserID. Once native browser implementations of BrowserID are implemented, bookmarks are likely to be unavailable for the password field. If we find a lot of users are asking for this feature, it wilgene pushed up in the priority queue for rediscussion.

  2. I’m new to browserID but I’m wondering why even have a browserid.org central server? Why not make it easy so any site can plug into the browserID api and never leave the site they are on? I am curious about browserID as a distributed authentication tool, wondering how it lives up to that, or if that’s even possible. I figure this is phase one of development, where there is a “central” server, but why not bundle the server code in a way so people can easily plug into it then end users never have to leave the site they are on.

    • Hi Milan,
      One of the goals of BrowserID is to actually make the central BrowserID server less relevant over time. For this to happen, two components need to exist – first, we need native browser implementations so that resources no longer need to be loaded from BrowserID. Second, we need identity providers to support the BrowserID protocol so that the BrowserID servers no longer have to act as secondary verification authorities. With these two in place, the large majority of the central BrowserID server roles will be delegated away, making them less relevant. Where some sort of central server may still play a role is in syncing your data across devices.

  3. I think ideally you wouldn’t even advertise “BrowserID” people would just put in their email address to authenticate and go, or get stopped for verification if their session data is incorrect, but never leave the site they are on?

  4. I’ve found BrowserID logins to be a bit confusing. Here’s my experience with my first login to mozillians.org:

    1. The BrowserID window pops up, that’s fine.

    2. It says “Enter you email address to sign in to mozillians.org”, I do, and then hit “next”.

    3. The password field appears, I type it, but button says “select email” — huh? I already typed in my email address! Oh well, I press it.

    4. Then it says “sign in using nnethercote@mozilla.com“, and there’s a “sign in” button. I haven’t entered any new information, why do I need to press another button? Oh well, I press it.

    5. And then it takes me to the site.

    On subsequent logins, it goes straight to step 4. But on the first login, it would be much nicer if steps 3 and 4 were merged so that I just have to type my email address, password, and press one “sign in” button.

Leave a Comment

Post comment

What is Persona?