0

I am developing a password manager app that requires the user to enter a pin when the app starts. Resuming the app from background either asks for pin or fingerprint. There is also a settings option configuring a grace period that allows the user to skip authentication if the app resumes before a certain amount of time passed since it was sent into background.

The app has three root views (lists): accounts, cards and notes. From each of these views the user can navigate further, into item detail, add/edit, etc. When tapping the system back button, the user navigates back the hierarchy until reaching one of these root views.

I am unsure what to do when the user taps the back button from any of these root views. Technically and by default, the app should exit (and it does, unless I come up with a different implementation). However, I find exiting the app is less than ideal, as this means the user has to reenter the pin the next time the app is accessed (from recent apps, for example). More, it interferes in a confusing way with the option to skip authentication when the app resumes, regular users not making much of a difference between starting an app fresh or resuming it.

So, I thought of some alternatives:

  1. Ignore the user action
  2. Display a toast requesting the user to tap a second time to exit the app
  3. Minimize the app instead of exiting

I am mostly inclined towards the third option.

What are your thoughts from a UX perspective?

Thank you!

3
  • Just checked on my phone and pressing the back button minimizes the app, i.e. you can switch to it in the 'Recents' view where you can close it completely. Or am I missing something here? – Nash Dec 27 '20 at 15:19
  • @Nash Closing an app does not remove it from 'Recents'. Does it resume in the same state? Most apps don't, you can tell they go through init phase. – Sorin Comanescu Dec 27 '20 at 20:17
  • You are right, it re-inits again. Haven't noticed until now. – Nash Dec 28 '20 at 7:50
2

Ignoring the action or requesting a second tap to exit would be inconsistent with the standard behavior of apps on Android. I'd recommend against that, as it's likely to annoy users.

As for whether to "minimize the app", the question here really is whether to maintain unlocked state on back action exit or not. That's both a UX question and a security question. Let's examine the possibilities:

  1. Keep account unlocked on back action exit. This takes away the potential pain of having to log back in. It's hard to say whether the user would expect the app to lock or not, I personally wouldn't. For users that need certainty that the app is locked, I'd recommend adding an easily discoverable "Lock" action. As leaving the app unlocked can be a big security problem, it might also be worth it to let the user know it's unlocked via a notification. (Much like browsers show a notification when the user has private tabs open.)
  2. Lock account on back action exit. This is certainly the most secure option, but also potentially annoying if triggered by accident. If these accidents are common, users would be likely to have bad associations with your app.
  3. Keep user logged in on exit in general, given a grace period. You mention this is a setting. As most people stick with defaults, it's worth considering making this a default. For example, a 1 min grace period should be more than enough for a person who accidentally closed the app to get back into it, but should pose a relatively minor security threat compared to just leaving it unlocked in general. Moreover, it also makes leaving the app predictable. As many users don't make a distinction between "minimizing" and app and closing an app, this could potentially be a security win in general — even users accustomed to minimizing rather than closing an app would get their app locked.

I'd personally go for option 3.

Also, if accidentally closing the app via the back button is common, it'd also be worth examining why. Perhaps there's something misleading on the screen implying there's something one level higher? (I've personally seen this happen with navigation drawers — would recommend using bottom navigation instead.)

4
  • I agree with Tin Man but personally I’d go with option 2 instead. On Android phones I’ll expect the app to exit when I tap back out and would appreciate the app to log me out especially if the app deals with sensitive information, for example banking applications. – Eric Chia Dec 29 '20 at 0:14
  • Autolock is configurable, the user can choose between Immediately/15s/30s/1min/10min, default 30s (although I'm using it at 15s and still find it comfortable). Not autolocking is not allowed. You are right about asking why accidentally closing the app is common, I too was feeling navigation could be improved to avoid that. As I said, the app has 3 root screens: accounts list, cards and notes, accessible through drawer navigation. I find myself often starting the app (goes into accounts screen by default), navigating to cards, hitting back for accounts just to see the app closed. – Sorin Comanescu Dec 29 '20 at 8:28
  • Maybe having a single root screen, displaying navigation elements to the other 3 screens would convey better the idea of being at the navigation root, where Back would clearly close the app. Unfortunately, at the expense of having an extra tap to access the accounts screen when starting the app, which is the most used by far, being its main feature. – Sorin Comanescu Dec 29 '20 at 8:32
  • @SorinComanescu You don't need to add an extra tap for access — just use bottom navigation: material.io/components/bottom-navigation . That will make navigation between the 3 sections faster and should also decrease these accidental app exits. – Tin Man Dec 29 '20 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.