Daniel Jalkut:
I’ve been running my tool for a few weeks, confident in the knowledge that it will prevent me from accidentally typing my password into a public place. But its aggressive nature has also revealed to me a couple areas that I expected to be secure, but which are not.
[…]
The nice “•” is new to Yosemite, I believe. Previously tools such as sudo just blocked typing, leaving a blank space. But in Yosemite I notice the same “secure style” bullet is displayed in both sudo and ssh, when prompting for a password. To me this implies a sense of enhanced security: clearly, the Terminal knows that I am inputting a password here, so I would assume it applies the same care that the rest of the system does when I’m entering text into a secure field. But it doesn’t.
[…]
Apple makes a big deal in a technical note about secure input, that developers should “use secure input fairly.” By this they mean to stress that any developer who opts to enable secure input mode (the way Terminal does) should do so in a limited fashion and be very conscientious that it be turned back off again when it’s no longer needed. This means that ideally it should be disabled within the developer’s own app except for those moments when e.g. a password is being entered, and that it should absolutely be enabled again when another app is taking control of the user’s typing focus.
Bug Mac Mac OS X 10.10 Yosemite Security Terminal
UX Launchpad (via Ole Begemann):
Google has decided, in many places in Android and their iOS apps, to feature search prominently. And that prominent placement puts the microphone to the right of the text field. Apple, on the other hand, puts their microphone in the keyboard itself.
Apple Maps doesn’t need to feature the microphone because, unlike third-party apps, it can use the hardware home button or “Hey Siri.”
Ok, it looks pretty abstract like that. But the big takeaway is that they’re doing the same thing, in the same order, but Apple uses five screens and Google uses six. But, again, fewer steps doesn’t necessarily mean better! We’ll analyze those screens in a moment.
[…]
Apple doesn’t have public transit or biking information. Maybe they’ll add it one day. But for today, that means their flow can be a lot simpler. The single feature they can match with Google is “Choose alternate paths, including walking”. So Apple featured it on their third screen with a label rather than using more complex and heavyweight controls.
[…]
Once again, tapping the “directions” button changes the flow from three screens to two. Once again, they drop the user directly into a screen that assumes your starting location is where you’re standing. Once again the suggestions switch from general guesses to a search-while-you-type pattern.
[…]
I love this comparison. Google is optimizing for driving because everything is one tap away. Want to cancel the trip because you’re looking for parking? One tap. Want to figure out how to turn on the traffic map? One tap. Want to re-orient the map to the direction you’re facing? One tap. It’s a very flat system where everything is right there, even things like seeing what time it is our checking to make sure your battery is ok.
Apple is optimizing for driving because it’s tucking everything away. There’s far more canvas available to show the map. When you drag the screen with your finger, it snaps back into place rather than putting you in another mode. It doesn’t show the current time, but it does tell you how many more minutes you’ll be driving, and your estimated time of arrival. Apple is doing what Apple does, for better or worse. They’re cutting as close to the bone as they possibly can. Nothing is assumed to be necessary on this screen.
Apple Maps Design Google Maps iOS iOS App Maps Siri
