Don Melton:
We were reviewing the bookmarks user interface in the yet-to-be-released Safari. At that time, all bookmarks were contained in a single, separate modeless window. It was homely but easy to implement.
And Steve didn’t like it. Probably because he didn’t want the complication of switching between windows. We started looking at how other Mac browsers did it. He didn’t like those solutions either.
So he turned directly to me, leaned forward with that laser-like focus of his and asked, “What would you do?”
Considering that what we just demoed was what I had done — or, technically, what my engineers had done — I was screwed. Everything else in the world seemed to fade away in a blur around Steve’s face, and for a moment I couldn’t think. But I didn’t panic. Or soil myself.
After a beat I said, “I actually like what Internet Explorer for Windows does, with the bookmarks in the same window as the Web content. I just don’t like how it puts them in a sidebar. There’s got to be a better solution than a sidebar, but I don’t know what that is yet.”
I liked the original design better than the current one, where the bookmarks are in the sidebar unless you’re editing them.
Steve didn’t like the status bar and didn’t see the need for it. “Who looks at URLs when you hover your mouse over a link?” He thought it was just too geeky.
Fortunately, Scott and I convinced Steve to keep the status bar as an option, not visible by default. But that meant we had a new problem. Where should we put the progress bar to indicate how much of the page was left to load?
This is what I’d always assumed was the reason Safari put its progress bar in the address bar. I’ve never liked that, and I always run Safari with the status bar shown so I can see on mouseover where a link will take me.
Apple History Mac Safari Steve Jobs
Brent Jackson (last year):
For the iPhone, Apple conjured up three fairly solid navigation patterns: the tab bar, the table view (e.g. Messages & Mail), and the card stack (e.g. Weather). All three work fairly well if used as intended, but there’s always room for experimentation and evolution in UI design – and always room for designers and developers to screw it up.
Path and Facebook’s mobile left nav flyout pattern is one such experimentation that should be avoided. Mark Kawano calls it the “hamburger icon that slides open the basement.” Why call it the basement? Because it’s hidden, dark, there’s a ton of crap in it, and, frankly, it’s scary and no one wants to go down there.
The Facebook app has since switched to a tab bar.
Update (2014-07-11): Kelsey Campbell-Dollaghan (via Jeffrey Zeldman):
It turns out that the burger comes from the Xerox “Star” personal workstation, one of the earliest graphical user interfaces. Its designer, Norm Cox, was responsible for the entire system’s interface—including the icons that would effectively communicate functionality to the earliest computer users. The hamburger, which looks like a list, seemed like a good way to remind users of a menu list. Skip to about 21:05 in the following video to see an explanation[…]
Facebook iOS iOS App iPhone
Adam Langley (via Wolf Rentzsch):
But an attacker who can intercept HTTPS connections can also make online revocation checks appear to fail and so bypass the revocation checks! In cases where the attacker can only intercept a subset of a victim’s traffic (i.e. the SSL traffic but not the revocation checks), the attacker is likely to be a backbone provider capable of DNS or BGP poisoning to block the revocation checks too.
If the attacker is close to the server then online revocation checks can be effective, but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed. In short, even revocation checks don’t stop this from being a real mess.
So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it’s worthless because it only works when you don’t need it.
Google Chrome Mac Mac App Security SSL/TLS Web
