Where to put login field in a mobile app?

Question

I normally put a login/register/avatar button at the very right of the navigation bar for webapps (desktop). However I use this space for actions like edit or add for my mobile apps. Where should I put the user login? My app can be used with and without login. Many other apps that I had a look at put it in the sidemenu, but I always liked the navbar option so users would know right away that there is additional content for registered users.

Answer 1

I'll suggest what you already decided not to use, so this may not be helpful, but I'll give you more reasoning as to why you could use it, and tips on usability.

If your app doesn't require it, don't force it

Considering how your app works, I would use the solution that you see in other applications. If people can use the app without logging it, I wouldn't make it a big deal and intrude their experience by always showing a big button that says "LOGIN." If you would prefer people having an account, I would consider making it a requirement before they start using it, and maybe use the not logged in version for people to trial it before they sign up, in which case you could then use the big button to login.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Bring the menu to attention after sign up

With your concern that people then won't know if there is additional content after they sign up. The hamburger menu in applications has become pretty self explanatory nowadays, but if you have important content you don't want the user to miss, you could consider drawing attention to the menu after they login. Such as changing the color, or using a ping effect. Note that this should be done on first login after initial sign up, after that you taught the user that there is additional content in the menu, and they will know to tap the menu to access them next time. If you have an existing app tour in place, you could tie this step with it as well to teach users where to get to certain pieces of content they need to complete their tasks.

^{download bmml source}

Answer 2

There's no way we can effectively answer this without more context.
But you do bring up an important point:

User registration / sign-in is a significant business goal for most apps.

Even when an app can be used anonymously, it's rarely in the business' best interest. For this reason, the app is commonly designed so it's not in the users best interest either.

So the real question is:

How do you incentivize registration and sign-in on mobile?

1. The lazy answer

Hide it behind a menu. You are right to question this approach: Where's the sense of urgency for the user? This option is really only useful in apps where users already know they want to sign in and will look for it. When they hunt, the app menu is one place they'll look. But how do you create that desire in the first place (see #3)?

2. The simple answer

The simplest answer is to make room for a call-to-action in the header, however minimal. It's never impossible, but it may not be the most desirable solution in your case.

3. The complex answer

Embed cues in the workflow of your app. When the user tries to do something, you point out that their anonymous status does not allow that action, then provide a link to sign in. Figuring out how to do that without ruining the UX is tough. Who said our job is easy?

Why stop there?

You may find that you need a combination of 1 or 2 with 3 for added conversion. Test it until you hit the sign-up threshold you're after. Then set the bar higher!

Answer 3

I agree with Chris that it should be basically a very large button that is always present.

I my opinion it should be an "uber" UX element. Even "more prominent" than a nav bar.

For me, I'd just have a large "all the way across the screen" button at the top or perhaps bottom of the screen which stays in place at all times, and says "LOGIN".

Consider too that instead of a button which takes you to another screen (which then user user/pass fields), just have those fields right there at all times. So, I'm proposing a large user/pass/login form which perhaps floats at the bottom of screen (so, it would be perhaps 1/4 of the screen height and the whole width) at all times.

Note too that we live in the era of the hell of "Facebook et cetera crosslogins". It's extremely likely that sadly your client will want the ability to have the usual hell of logging in via Twitter, Facebook, etc etc accounts.

---

And something to consider...

An interesting thought is this:

Simply, don't allow anonymous use.

Take a "KISS" approach. After all, with sites like say online banking or the like, of course you have to be logged in, there's no meaningful "anonymous" use case. Ask yourself - is there truly a need for anonymous use?

In fact - if you do allow anonymous use, isn't it really the case that you're only doing that to try to "suck up" to then get conversions to logged-in use?

If you do allow only logged-in use: it incredibly, I mean incredibly, simplifies things and tremendously slashes costs for your client (or you if it is your own app).

It's a little bit like the argument FOR paid apps. A thumbcandy game on phones that is simply three bucks to buy, is "honest". It is what it is - pay three bucks and play. "Free To Play" games in contrast are one of the big hassles of our era.

In a sort of similar way, consider simply "honestly" just plain requiring that users do login. The cost saving (tremendously less development cost) is huge.

Logged-in versus anonymous modes cause UX problems at every turn. The whole experience of the app is dramatically simplified if you just plain have to be a known user to use it. New thoughts for a Happy New Year.