Simplify sign up for mobile users

[mvexel]

From a mobile user's perspective, sign up is currently not optimal. A cursory search did not turn up other tickets related to this, so here's a new one.

Current workflow has these steps:

1. Enter required information, including email address TWICE and password TWICE
2. Accept contributor terms
3. Check for confirmation mail
4. Click confirmation link in mail

I don't know if we have any metrics to prove this, but my hunch is that not many folks make it through the sign up process on mobile.

Could it be simpler, perhaps something like this:

1. Enter email only
2. Check for welcome email
3. Finish registration on desktop

This could entice more mobile app builders using OSM to include an OSM sign up link (I am looking to do this for Scout) and also more mobile users to actually sign up.

I haven't done any work on this yet, but I would like to explore if there is traction to get something going.

[tomhughes]

Err, isn't the major problem with this plan than people will be signed up without having agreed to the CTs?

[mvexel]

They will not be signed up yet before they open the initial welcome email and finish registration through a link in there. This link would lead to screens similar to the current sign up screen and the CT agreement.

[mvexel]

I really like the flow proposed in the top answer for this UX StackExchange question.

[tomhughes]

So I don't see how this helps then, if all you're doing is changing the order in which they see the screens?

[tomhughes]

The stack exchange question seems to be about something entirely different, namely whether to let people use the site before they have confirmed their email or not - that's a valid question and different sites make different decisions about it but personally I would be reluctant in our case.

[alexilisei]

Not an expert in this area, but is there a reason why sign ups using Facebook/Twitter/Google accounts are not available? For mobile especially this would be great since most of the people are already logged in with one of those accounts and it would be really easy to sign up.

[tomhughes]

@alexilisei Perhaps you might like to look at the signup page before opining that Google accounts aren't available?

There is a PR (#153) to add Facebook and MS Live support - it was blocked for a long time on legal issues but is now cleared I believe. Somebody needs to update it against the current code base though as it's probably very out of date now.

Twitter requires adding support for OAuth based signup as it doesn't support OpenID like the others we currently support.

[tomhughes]

Right, so there is, just not with a direct icon on the create account screen - you can either put "google.com" or "gmail.com" in the openid field, or you can go via the login screen where there is an icon, which will handle account creation if necessary.

The point is that it's not "create an account with google" it's "login with google" which will create an account if you don't already have one. That may be something we need to explore though if people still commonly expect to think of it as account creation.

[alexilisei]

Indeed, I was looking for the Google account option on the sign up page instead of login, and I'll explain why.
When implementing OSM login in a mobile app, ( usually with OAuth ) you would offer a way of signing up for users that don't have an account. The natural option would be to redirect the user to the sign up page, that's why I was looking at that page mostly. Maybe a better option would be to redirect the user to the login page, even if he doesn't have an account.

[alexilisei]

Also, about whether to let people use the site before they have confirmed their email or not, how about allowing them to log in at anytime but simply do not allow to edit the map until they confirmed the email? As @mvexel said, the whole idea is to make it easier for people to sign up on mobile devices, which now is kind of cumbersome.

Note that I'm definitely not an OSM power user as you guys, so this is just some feedback from an 'outsider' who's involved in implementing a login/sign up component that will most likely end up in Scout.

[tomhughes]

Well presumably the person is signing up on the mobile device for a reason, not just for the fun of it. So they will probably then want to edit right?

[simonpoole]

@alexilisei the only really valid reason to sign up is to edit as nearly all functionality is available without login in the first place and the small things that aren't, for example sending messages, are things that we would likely want to restrict to a confirmed account in any case..

[simonpoole]

@mvexel while I'm sure nobody wants the sign up process to be complicated, but I don't really see a lot of opportunity for streamlining. And actually the signup process is fairly OK on mobile (just tested) given that the forms are really simple and don't require a lot of effort to fill out. The point about receiveing e-mail on mobile devices is however valid and maybe we should investigate that a bit more.

Outside of the above: repeating the e-mail address is probably not really a hard requirement and the PD checkbox doesn't really need to be on the sign up form (actually that goes for non-mobile too).

As to the legal stuff, agreeing to the CTs is a must, and if it was up to me, I would make both our privacy policy (once rewritten) and the AUP more prominent.

[alexilisei]

@tomhughes , @simonpoole I totally get your point, as a user you don't really do anything else besides editing. But I would also argue that you don't immediately start editing after you create an account. I see the signing up feature as a minor first step towards actively contributing.

From a mobile app perspective ( not the browser ), this would be the current flow:

1.  From the app, press Sign up which redirects to browser.
2.  In the browser, enter required information, including email address twice and password twice. Exit browser manually.
3.  Go to the email client app, check for confirmation mail.
4.  Redirects to browser, when the link is clicked.
5.  Exit browser, go to initial app.
6.  Login ( using OAuth ).
7.  Redirected to browser, enter the credentials AGAIN. This would be the third time.
8.  Use the app.

This would be an improved version in my opinion:

1.  From the app, press Sign up which redirects to browser.
2.  Enter required information. (ideally without writing the email & password twice ). When done, automatically login the user and send the verification link.
3.  In the app, attempt login with OAuth.  Redirected to browser.
4.  Because the user is logged in from the registration step, he only presses the ‘Allow’ button for the app that’s requesting permission.
5.  Use the app, even if not allowed to edit at that point. Later when he checks the email, verifies the account. 

In the second version, the user entered the credentials once instead of three times and didn't actively switched between 3 apps in order to register.
So this wouldn't be an improvement in providing more functionality when the account is not verified because it's not doing that, but strictly in how fast and easy a user can sign up using a third party app, that's all.

[tomhughes]

But it doesn't help a third party app if they get the user signed up and then find that every API call they make fails because the user has completed the registration yet...

Likewise, asking for email and password twice does actually have a reason, namely to combat people's inability to type. If anything it's even more likely that they will mistype on a mobile device than in a web browser!

[mvexel]

It's not so much about immediately being able to do anything - however great that may be, but that is for another discussion. It is about ever more people becoming (or being made!) aware that they are using OSM maps in their mobile apps and converting more of those people to active OSM contributors.

A great first step, and to my mind a prerequisite, is to give these folks a very straightforward way to start connecting to OSM. The current sign up process does not qualify, @simonpoole, I don't agree that the current process is even 'fairly OK' for today's mobile users.

[tomhughes]

So your goal is to get people who are "just browsing" to sign up?

If we were a startup whose goal was to get the biggest number possible for out next press release then I would understand that, but it's not clear it really helps us at all...

[emacsen]

Tom,

The issue isn't casual users, it's modality. It's hard to sign up on a mobile device. I think what Martijn is asking about is "Can we decouple the web site from the experience of a signup?" For example could you send the Contributor Agreements in an email? Could you make some other workflow for users who want to sign people up via an application? Is there some way to support this workflow other than "Go to website, enter your preferred display name and password, click through agreements, etc."

[tomhughes]

Nobody is objecting to making it easier to signup on a mobile device - we are objecting to the proposed way of doing so, which involves not taking some of the steps which we currently take and which we believe are critical.

The principle is fine, the proposed solution is not.

The argument in favour of the proposed solution is that there are use cases where taking those extra steps are not critical. I for one am not convinced those use cases are real, or at least important enough to spend time and energy on.

[emacsen]

Tom.

Where would a good place to discuss this be? On this ticket? Somewhere else?

Here's another potential workflow:

A new API is made for signups, but this API has keys you must request. To get a key for your application, it must adhere to some rules, such as making sure that it's clear the user is signing up to OSM (and not to the application), that the contributor terms are displayed prominently and agreed to, etc. Then that application could make signups directly via this new API.

Any of these solutions will require some development work, so maybe the problem is just finding what will work for people.

[tomhughes]

Well I'd really like to understand the use case first.

The claim seems to be that Jane Smith is using an app that just uses OSM map data and that app then encourages her to sign up just so that she is "joining the community". There seems to be little reason for the app to do that though, either for her, for us, or for the app author.

She gets signed up to a web site she is probably never going to use. Sure a few people may go on to use it in ways which need the login, but has getting lots of them to sign up actually increased the proportion that actually go on to really use it?

We get lots of new users, most of whom will probably just sit on our books and never be active.

The app author gets (no matter how simple the signup flow is made) an extra flow of complications and support calls from any issues that arise with the signup, and probably some kickback from people who object to being pushed into signing up.

[alexilisei]

I don't agree that "joining the community" is a bad reason for signing up. Once the user signs up and sees how things work, chances are that he'll become a contributor. A good example for this would be Waze, I don't think anyone sign ups to report speedcams and police cars, but to have access to the crowdsourced information. Once the user gets that sense of community, chances are that he'd start to contribute, why not.
If a mobile app manages to execute that well, OSM would still get a decent amount of contributors and many non-contributing users, which doesn't seem like something bad to me.

[emacsen]

@tomhughes you mention that we'll have all these accounts on the book that haven't done anything, but don't we have something like a million of those now?

Should we maybe open up a new ticket that says "If you haven't made an edit, or a note, or a comment, or a diary, and your account has been active for a year, we'll send you a warning email, and then shortly thereafter, close the account?

That'd address your concern and save us tens, maybe even hundreds of bytes in our database.

[mvexel]

@emacsen that is a good idea. The email could be an opportunity to get people re-engaged with OSM, given the right wording. We can discuss that there though, if it comes of that.

Back to the issue at hand, I am sorry that I did not make it clear that I am not at all suggesting that we should be skipping any steps in the sign up process, I propose to split it in two parts, with a very straightforward part taking place on the mobile device (just enter your email address) and the rest being deferred to a later point in time where the user is at a computer.

As for the new users 'just sitting on the books' - as @emacsen pointed out it's not that we don't already have that now. And it can be an opportunity also: all these people have expressed interest in OSM and we have their email addresses. I know we historically have not done anything with that information, but that does not mean that we can't. Even if we decide we can't or won't do anything to that effect, I don't see how it hurts.

To give a concrete use case that would benefit from this change: say you have a map based app that uses OpenStreetMap for its map data. The app incorporates a feature where people can give feedback to OSM, or even contribute new information. (Scout (US) does the former right now.) Many of its users are not even aware of what OSM is, but an information screen educates them and encourages them to sign up / in so they can help make the map better. A streamlined sign up process as proposed here would convert many more passive map users to active users.

[mvexel]

I am going to rename this ticket to emphasize that this targets the mobile use case specifically.

[simonpoole]

@mvexel the short version of what you are proposing is correctly summarized as: "lets collect the e-mail addresses of everybody that shows interest in OSM"? While that is fine and dandy, DP legislation severely limits what we can do with addresses that we collect, at least we would have to provide some kind of opt-in facility for unsolicitated mail.

Now there are some things that a purely passive OSM account could be useful for

• subscribing to local OSM news via the group facility
• selecting faviourite layers
• and likely more ...

The problem is that nothing of the above is implemented at this point in time, making the case for increasing the number of non-active signups over what we already have not particularly strong.

[simonpoole]

I just wanted to point out something which is obvious, but may have got lost in discussion. Essentially every Android user has an google account (I assume Apple likely has something similar) that could be used for this. We currently have an issue in that google is moving from OpenId to OAuth 2.0 and we need to support that (but have to in any case).

For more information see https://developers.google.com/accounts/docs/OpenIDConnect

While not 100% sure, I expect a sign up via this would essentially boil down to ticking a few check boxes (and could all be run in a WebView without starting an external browser).

[SomeoneElseOSM]

@simonpoole Well, ish... It's probably true (in the UK at least) that most do, although I suspect that quite a few of the "landfill Android" users around the world have never created an account, and Android apps run in plenty of places (Amazon, Sailfish, Blackberry) where a Google account isn't a requirement.

[simonpoole]

@SomeoneElseOSM while there is the special case of amazon, I suspect "quite a few" amounts to sub 100ths of a promille. A standard Android phone is essentially unuseable without a google account.

[mvexel]

Looking at other potentially less involved ways to make sign up simpler, I tried to create an OSM account using OpenID. Following the instructions at the Yahoo OpenID site:

I tried inputting yahoo.com into the OpenID field but got this:

Is this something I am just not getting or is there a separate issue here?

[tomhughes]

It's a tricky one - technically it should be a URL and we have set the field to type=url to reflect that, which is causing your browser to validate it and decide it's not valid.

Whether it would work if you get past the browser check I'm not sure. It doesn't look like we special case yahoo, so I suspect not. We do special case google by converting anything that include gmail.com or google.com to the real openid endpoint address.

[tomhughes]

Just to add, most likely just adding http:// to the front will work, although me.yahoo.com is what we actually use behind the yahoo button on our login page.

[mvexel]

Hmm, looking again at @simonpoole's thought of using OpenID Connect might be promising... Google has already implemented it it looks like.

[tomhughes]

@mvexel as already being discussed in #897 and #918 you mean?

[mvexel]

@tomhughes exactly. This ticket still has relevance though, right? I mean even if we support OpenID Connect, the sign up page could still be improved to be more friendly to mobile users, for example by emphasising the OpenID options.

[tomhughes]

I'd rather not try and push one method or the other. I suspect the real answer is to do what a lot of sites now do and merge the login and signup pages - currently the best way to signup with a third party provider is actually to start from the login page not the signup page, but I don't really want to duplicate all that logic on the signup page.