|How NOT to Piss Your iOS App Users Off on your App's Login Screen
||[Dec. 4th, 2011|11:38 pm]
I just hate it when you download an iPhone app that is supposed to make your life easier on the go only to find that there are problems right on the login screen
If you're an iOS app developer (including using those lowest common denominator cross-compiler tools, which I think is at the root of the problem) here are a few things you can do to make users not hate your app the first second they attempt to use it.
- Portrait orientation only login screens
I absolutely hate apps that force the user to login in portrait orientation only. Usually, these apps require you to enter your email address and a password. While my email address is by no means the longest email address in the world, I'm loathe to type it in when in portrait orientation because that means typing with one thumb. Why? Because the most convenient way to type on the iPhone in portrait mode is by holding the device in one hand. The other common method would be to peck at the screen with the non-holding hand, but I'm even less enthusiastic about that proposition.
- Not using keyboard that has @ sign if I am having to enter an email address
It's also infuriating that if I have to type my email address to sign into an app, that I'm not given a keyboard with the "@" symbol and period on the initial screen. This means that I will have to press shift to get to the "@" symbol, the "." as well as be required to type the TLD.
This is ridiculous! If you know that the user is going to have to type an email address, help them out. The keyboard is in the OS. Use it.
- Not retrieving my email address from my contact info in the first place
Of course, if developers really wanted to take advantage of the "smart" part of smartphones, a little pre-emptive design work would do wonders for their apps. Knowing that the user is going to enter their email address, it could just be fetched from the user's contact info.
I suppose this is more of an OS thing than an app thing as the app would have to get the list of all the email addresses on the phone and then compare against that list while the user types her email address, whereas the OS that's performs the service when the user enters their context info in a web form.
I don't see someone else wanting to use my phone to check their account as a reason for not fetching my email address for logging into apps. After all, there's a two or three character matching that has to occur before the autofill kicks in on web forms, so unless we have the same character sequence in the beginning of our emails…but more to the point,
a smartphone the iPhone is such a personal device, so why would I let someone check a social account or their email on my device, particularly through an app? Even in the pre-Siri days, the iPhone was something of a personal assistant, it just becoming more so as time continues.
The only argument I can hear for not doing this is a security argument: Suppose a phone is stolen. Further suppose that someone with malicious intent finds the phone before the user discovers they have lost their phone and remotely wipes it (you DID set up Find My iPhone for such a time as this®, did you not? Corollary: It's all fun and games until someone loses an iPhone.)
Given the above scenario, the malicious fiend would only have to guess the user's password as the email address would be supplied. While it is admirable to thwart such a scenario, it is likely that the user's email address can be readily found, most likely by going to the mail app. If not there, than by perusing the email addresses in Contacts, iCloud account settings, open browser tabs, etc. Since this information is readily available on a compromised device (though it would give the user additional precious seconds to remotely wipe their device by it not being available through auto-complete) I lobby for the computer to do the dull, repetitive task and allow the meat bag holding the device to engage in non-rote tasks, like actually using the app.
- Hiding text fields behind the keyboard forcing the user to scroll w/o providing previous/next buttons
There is an app on my phone that I've only used a handful of times, but when I do, it makes my life easier as I'm able to perform the task the app was designed to do more efficiently. Despite being plagued with one or more of the previously mentioned design failures, there's a special failure worth highlighting that is not unique to the app: forcing the user to scroll to and then tap in necessary input fields to gain focus to type.
There is already a solution built in (again for web forms) but there's no reason outside of a possible lack of support in the iOS framework that already solves this problem: the previous and next buttons that appear at the top of the keyboard in a black header band. Even if the current framework is prohibitive of this solution, the app can always listen for the Enter/Return key and automatically advance to the field. A clever designer would cheat on email addresses by listening for a period followed by a list of common TLDs, advancing the user to the password field upon having those characters inputted.
Again, let the computer do the rote work, alleviating the confused, stupid human being.
- Login screens not supporting special characters in passwords
I understand that passwords can be a nightmare, specifically if you're passing the text that the user entered instead of hashing that text on the client side and then sending the hash to your servers. Even Dropbox seems to have fallen prey to this. Just because it's either a difficult or time-consuming problem to solve does not give you as a developer the right to ignore the problem. Your users are counting on your app to work flawlessly; when your app fails to do so, users have a negative experience with your app and thus with your product. Unhappy user, unhappy intertubes.
The solution to this problem is very simple: test your app. This can be done in a multitude of ways: either unit testing, acceptance testing or both.
If you automate the testing, you get a bonus feature for free:
- Longer password fields - This allows your users to be able to use passphrases instead of passwords. As we learned from Steve Gibson's Password Haystack page, length–NOT entropy–is the key to secure passwords. So if your test string is all of the upper case characters plus all of the lower case characters plus "special" characters present on a typical Latin 101 key keyboard (non-diacritic or Unicode only characters) then you should be in the range of about 110 character minimum supported length for a password.
Let's continue to have the iPhone be the standard against which competitive products are judged by writing apps that are a joy to use instead of crippling the user experience before the user even has the chance to properly get into the app.