1. 程式人生 > >Apple’s FaceID and Magnified Failure

Apple’s FaceID and Magnified Failure

I just got Apple’s latest magical piece of glass and I found some weird usability bugs with FaceID. I upgraded from an aging iPhone 6 plus with touch ID. Here’s what I found…

At first, I really liked FaceID, it’s just so seamless and reaches that seemingly impossible goal for all technology in that it “just works.” At least it just works, when it works. Just as TouchID had issues with wet hands there are limitations to FaceID like when facing up on a table.

But with TouchID the screen immediately shows the passcode, so no problem you just type in your passcode and carry on. That’s not the case with FaceID. When FaceID fails it doesn’t just show the passcode, it waits for what seems like forever (2 full seconds) before it shows you the passcode.

This long pause magnifies the failure. Instead of just tapping in your passcode you’re forced to wait for the phone to think about whether it failed or not and then show your passcode? Seems like an odd usability choice.

With my old phone it just immediately shows the passcode and if your finger works great it’ll use that, no awkward pauses there. With the “greatest phone Apple has ever made” it waits before it acknowledges “Yup, I can’t see your face” here’s the passcode.

For something as common and trivial as unlocking your phone this pause is magnified and makes the user question how good or bad FaceID really is. I saw all the backlash against it last year, but with iOS12 and their latest phones, they haven’t rectified the issue that reminds people every single time that FaceID fails that it is not as good as TouchID was.

To fix this UX issue and stop magnifying FaceID’s failure simply show the passcode input when the user swipes up when the phone is locked. While they’re typing in the passcode if a known face is identified simply pause the input on passcode and let them in — their originally intended action.

Now, I know I’m writing all this to Apple the king of usability for technology, but I just don’t know why this is not changed. It would help the PR for FaceID and stop reminding everyone how often it doesn’t work.I have a few educated guesses as to why the designers chose to do it this way.

First guess is that unlike TouchID which has the user taking a decisive action to get into the phone (putting a fingerprint mapped finger onto the home button and pressing down) FaceID is more passive. So the user would be typing in their passcode and suddenly, and unexpectedly, land on their home screen. But, after FaceID fails, that’s exactly what the phone does when you start typing in your passcode and it sees your face. It lets you into the phone mid number press.

So if it already does that what is the point of that 2-second lag before dropping in the passcode numbers?

I’ve been talking with some other UX design friends of mine and they think it is less about usability and more of an Apple power move to force people to use FaceID. For instance, on the old TouchID phones, when you swipe into a notification it would tell you to get into your phone by pressing on the home button, despite your finger already being above where the numbers would be if they immediately showed the passcode option instead of making you tap the button to get into the passcode area.

I mean, I definitely understand where they are coming from for this idea, but am not sure it makes sense since unlock is much more important than swiping into notifications. I mean a 2-second lag every time you want to unlock your phone when it’s on the desk?! There just as to be another reason…right?

But those are my only ideas for Apple making this really obvious UX bug that just makes us all question FaceID overtime if fails.

What do you think might be the reason for the 2-second lag to show the passcode after failure?