Sen. Franken Quizzes Apple Over Location Logs

You’ve heard of the kerfuffle surrounding a log file on iOS 4 devices whose entries contain, troublingly, time and position data. I know you have because I have. Ever the good son, I enjoyed a coffee with my mother this afternoon and she asked me if I’d heard about it. There’s been an awful lot of opinion pieces written about this mis-feature but I’m with Dan Moren and his Don’t Panic argument.

I’d chalked up these revelations as a Molehill-cum-Montain issue. Looking at the data involved I had a high degree of confidence that this was either a bug or an oversight. I could envision technical reasons for this caching and engineering reasons for why it might be accumulating either longer than expected or even why just not caring how much backlog was kept might be a valid trade off in terms of engineering time spent on the problem.

I had opinions on the matter but none that wouldn’t be ably covered elsewhere and so had no plans to comment. Then I came across a piece at Talking Points Memo, an American political news blog, that said Senator Al Franken had written a letter to Steve Jobs asking for the specifics of the situation.

My initial impression, as I wrote to a friend privately, was, “Man … someone is going to be working this weekend!” The letter read as sincere, concerned and to the point. Naïve from a technical perspective perhaps but, ultimately, on point and crystallized the sort of questions the public was asking either through the media or through citizen soapboxeries like Twitter. By “someone” I meant the segment of Apple that comprised the engineers who’d written this code and the public relations and management people who would no doubt be rushing to understand its details and the decision making process behind them. All these people were probably already at red alert due to coverage of the issue in the New York Times and on CNN. A concerned letter from a US Senator would’ve moved them all to the even more serious state of Redder Alert. The morning of Good Friday will see a bunch of people locked up in a cave who won’t re-emerge until Easter Monday with a fix in hand and some great messaging.

Still, I had nothing to say about the subject because, really, what’s there to debate?

And then, a very smart fella called another very smart fella an idiot on Twitter. “Kontra” (@counternotions) took issue with the tone of Senator Franken’s letter. You should read our conversation here. I don’t know Kontra personally but he seems like a sharp guy with a good understanding and an ability to communicate it. Arguing with someone you don’t know personally on the Internet is almost always a bad idea so I dove in.

The debate here appears to centre upon the role of a government in society. Should a government move to quickly and publicly secure answers from a business when there’s a possible danger to the rights of its citizens, or should the government defer until they’ve secured more data and inquire discreetly in order to engender a social environment less tumultuous for businesses?

I’d err on the side of a government calling out business shenanigans where it may see them. There is an argument to be made that uninformed media or government intervention and inquisition into a business may hinder it’s ability to innovate or even unfairly punish it for small oversights that are blown out of proportion. My position is that Franken’s questions don’t create a sufficient “chilling effect” that the damage done to the citizenry via the potential damage to Apple, Inc via lost sales outweighs the potential damage to the privacy rights of the citizenry that the Senator is concerned about. What if he is wrong and Apple loses a few sales? We won’t care once it’s time to bash on the next thing in the news cycle. If there is a privacy issue here concerning millions of iOS 4 customers then there’s some serious potential damage to the privacy rights of millions of citizens.

I’ll bet Senator Franken will have a set of answers to his questions by next week. His concern is, I believe, misplaced. On that point I believe Kontra and I are in agreement. But is worrying that untrusted code executing on a Mac or iOS device being able to steal a time-stamped log of where you’ve been “idiocy”? No, not at all. That is a genuine concern. Is it more of a concern than nefarious code reading your text messages or email? No, probably not. The thing is that just as people will download a movie and excuse themselves for not stealing anything “real” they perceive a breach of email accounts as awful but less horrific than some third party knowing where they are, physically, in the real world.

At the end of the day this location data may not be as important or as telling as some other personal data but people relate to it far more intimately. There’s a reason beyond it simply being related to Apple that this story gained traction. The idea of being tracked, as a human, is very scary stuff. The ancient sort of scary. The sort of scary that wiggles down subconsciously to the fight or flight level of reasoning.

So, though I’m an Apple fan, I think that Senator Franken asking Apple a few questions about why there’s an obviously overly long location log on their phones trumps the extra thousand or so units of iOS 4 devices Apple might’ve moved without this bad publicity.

That said and done, no one has yet asked the really interesting question — if this had happened once Apple was shipping an iOS device that backed up automatically to an Apple server how much more of a shit storm would this have been? A very shittier shit storm is the answer. I’ll bet there’s more than a few managers who’re thinking very carefully about how to make damn sure they don’t have to spend an Easter weekend working to prove to Stuart Smalley that they’re good enough, and smart enough, doggone it.

Embarrassing

Well, let’s just call it. We’ll do it with The Globe And Mail, RIM home-turf, running this piece: RIM’s PlayBook gets rough early reviews opening with this line, “The initial verdict for Research in Motion’s PlayBook is in — and it’s generally not good.”

That’s just embarrassing. For me. Here I was thinking they were getting something to market to get back in the game. Here I was thinking they were picking up a great base OS in QNX and leveraging AIR to get a decent, or at least better, application development layer than they’d have been able to field otherwise. Here I was thinking ditching essentials like a mail client and a calendar was because they didn’t think they’d get them to their quality levels in time and they were happy with just getting something decent out there that they could iterate on. Here I was thinking RIM was trying to do what Jack Gruber explains Apple does: roll.

From the reviews it seems they’ve spent some time rolling around in it all right.

If you’re going to cut back on features and be late — make sure you’re good for what you are. The fallacy is that competitors need to ship a product that beats iPad in it’s first iteration. They don’t. They need to create a device that addresses a few problems better than iPad can. RIM had a clear niche there — integrating a tablet into the corporate infrastructure they’ve spent a decade dominating. Cut corners, hell, assume a BlackBerry companion if you need to, but know what your product is. Make it well and ship it with confidence that it’ll address the needs of the customers you’re targeting, even if that’s a smaller subset than you’d ultimately like to reach. Shipping a product that helps ten people is better than shipping a product that gives one thousand people a hassle.

RIM was in a position to do that. A nice custom OS with AIR atop it. Integrate it with corporate backends and BBM. Tell “Enterprises” they can let their “Web Guys” build custom AIR apps that don’t need to jump through any hoops to be deployed — there’s some traction there. Maybe not much, but what do you expect when you’re years late to the race? Pick the sure footing. Sprinters use a starting block for a reason, it’s a good solid launching point that can be leveraged to gain an initial thrust. Muddying your position, and product definition, won’t get you anywhere quickly.

You know who actually did that bit well? Microsoft. Windows Phone 7 was well received, competent, reasonably polished and missing a lot of functionality iOS had already had time to grow. That was more or less forgivable though. People asked where Copy and Paste was but it didn’t sink the product out of the gate. For what it was — it was good, and that still engenders some respect. Where Microsoft dropped the ball was in updating it. The whole key to starting with the essentials and rolling with it is in the momentum. The Windows Phone 7 team, for whatever reason, never developed momentum and I’d guess they never will.

Anyway, I stuck my neck out for RIM there thinking they’d ship something small but competent. Early evidence is proving me wrong.

Nice job, RIM, you’ve made me look like an asshole.

Progressive Refinement

Latency … is the worst. At the root of our cognitive abilities is our appreciation for cause and effect. The tighter the loop between an action we initiate and the effect we precipitate, the better we are able to correlate them. In many ways this serves as a cognitive short cut — the smaller the time between the input and output limits the amount of interference that could have been caused by a third party. An instantaneous failure result implies that we’ve misjudged the situation as it is, a delayed result suggests that the environment in which we’ve responded may have changed. Every millisecond of delay forces us to ask ourselves, “Have I done something wrong?”

As people who make things that others interact with we are responsible for reducing this potential window of fear and replacing it with a level of comfort our users can embrace. Our goal is to have effect follow cause as immediately and as responsively as possible. This may be old hat and a restating of a previous piece but it’s still a worthwhile point to make.

Using a rough approximation of a visual during animation is a subset of what I’ll call progressive refinement. When animating we’re trying to accomplish two things. First, and if you’ve elected to employ an animation this should be foremost, we’re communicating to the user a change of state or modality. Secondarily, we’re using the time we’ve spent entertaining our user to figure out what we actually want to show them. The state of our application has changed and we’re trying to communicate that to our user progressively. When zooming in on some text in a Safari column, we’re using a lower resolution image and scaling it up we’re using an interpolation (a bilinear filter, from the looks of it) of the original rendering as a progressive refinement of what they can expect the final result to be. After zooming in on a column in Safari the letters are basically the same size and in the same positions and once the final rendering is done, the view is replaced with a higher resolution version of the page that correlates well to the preview that’s been presented.

We take progressive refinement for granted in iOS apps. When we scroll in Twitterrific or Tweetie the scrolling is instantaneous. Filling in the user avatars can come later, or even highlighting the links in the Tweets. These are considered secondary refinements upon what is most important to the user — when they scroll the list it must be responsive. This is drawn from the iPod, or other media listing apps but is especially evident when using Home Sharing — A user will accept a slight delay in the progressive refinement of their view of the data but they’ll be frustrated with a delay in delivering that data to them.

Consider human vision. We’re accustomed to quickly changing our focus or entering a lightened or darkened room. We’re adapted to the idea that details may well present themselves gradually. We don’t find this onerous, we find it natural. If you’re writing software that interacts with humans this is worth keeping in mind — present an outline as quickly and as responsively as possible and from there refine your presentation of the data. Present buttons as disabled and then enable them once you know they’re applicable. Present a list of posts quickly but fill in the avatars individually as you’ve finished fetching them. Present a body of text and then present the result of the Data Detectors that have discovered that “Tomorrow 1pm” is a meaningful phrase. Progressive refinement is a hidden HIG directive that all of you should be aware of.

The hierarchy of information interaction is this: Immediacy, Accuracy, Fidelity. When interacting with information you want it to be fast, then you want it to be accurate, and then you want it to be exactly what was originally expressed.

It’s up to you to decide how the information you’re presenting to your users fits into these categories. If you think stalling a scroll gesture to pull in album artwork or user avatars is the right thing to do though — you’re very wrong and everything that’s good on iOS proves that. Consider what you’re presenting to your customer, consider the costs involved in providing each detail, optimize your interaction to provide the most value in the least amount of time. Then, fill in the blanks.

There’s no magic in software, there’s only ever forethought.

Luckily thinking is free but, hey, feel free to charge your clients for the time you’ve spent reading this.