kickingbear

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.

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.

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.

Too much time is spent talking about attention to detail in user interface design. Forget that. Or at least let’s all agree to take it as a given, a prerequisite.

I’ll lay this out simply: when things are static our brain will pick out the details, when things are in motion we’re in tracking mode and the details escape us. This is the order of things and it’ll likely be a very long time before that changes.

This is one of the truisms baked into the earliest GUIs. On the oldest Macs you’d double click to open a document and a zoom rect would appear to illustrate that an action was in progress. If you dragged a window, on Mac OS or Windows, you’d drag a simple outline. The developer-designers (that’s how it was back then) understood that the immediacy of dragging an outline was more valuable than slowly dragging the object itself. Given the trade offs of the time they were correct.

If you think this is a quaint notion, read this piece in mobile Safari and double tap this column of text to zoom it to fit the screen. Did you see what happened? The lower resolution rendering of the page zoomed to fill your screen and was then replaced by a higher resolution rendering once the transition was completed. This is the modern zoom rect and is enabled by leveraging the extremely fast graphics hardware we enjoy today. What started as a way to quickly render brown wall textures in a 3D shooter is now being used to make interacting with an obnoxiously binary device feel like a more natural, analog affair.

There’s a long litany of effects I’m tempted to dive into here. From the old NeXT window server full-window drag, to OS X fully buffered windows and the Minimize to Dock effect and to Core Animation and iOS in which all content is backed by a texture. I’ll dodge that for now because it’s too rich a history.

If you write interactive software know this: fluidity of motion is more important than accurate rendering, once a scene is static fidelity is paramount.

To boil it down, your take away is: drop fancy rendering effects to achieve the most fluid interaction possible.

If you’re using iOS or Core Animation you’re doing this already in more places than you’d guess. Keep this technique in mind when dealing with your own interaction issues. You can labour endlessly to make accurate rendering as fast as possible or you can appreciate how people perceive things and end up with the best possible interaction.

Always implement the simplest possible solution that fits your understanding of the problem space modulated by your anticipation of the inputs you’ll be dealing with.

This may sound like a re-statement of the K.I.S.S. principle but it’s not — it’s more robust than Keep It Simple, Stupid and is self justifying in the following way: The added complexity of parsing this rule is worth the sacrifice in communicability in order to more accurately express the argument behind it.

The “KISS Principle” is often rejected by those who know better. Their experience in a field has taught them that the simplest possible solution is likely unsuited to any amount of serious usage in the real world. They then abandon this principal and resort to implementing along lines that too often show signs of Second System Syndrome. The resulting code being heavily influenced by what they’ve done before only, this time, improved upon by the lessons they’ve learnt the first time they wrote something similar.

These people are smart and are learning from the mistakes they’ve made in the past. Anyone worth their salt should be at this self correcting level. But there is, as always, another level beyond that.

I call this next level the “Fuck It” level, though that may be too technical a term for some.

Achieving the Fuck It level entails knowing the problem space well enough and understanding the limits of your inputs well enough that you can gauge how complex an implementation will be required to match the requirements you’ve been given. Many nerds come to believe that their task is to come to the most optimal solution given the input and the hardware. That’s cool, they’re nerds, they do that. The actual task is to come to the best solution that suits the requirements in the shortest amount of time. That’s what your manager wants and that’s what the company wants. Where you shine, as a fancy pants and experienced engineer, is in doing exactly that while leaving yourself wiggle room to get more performance and more features out of what you’ve written once they come back to you for more. The trick is never in building the best possible implementation — the trick is in building the implementation that will provide the best possible future. The best possible implementation changes from year to year according to hardware trends or the software you’ve build upon. The implementation that will provide you with the best possible future changes far less frequently. When you understand the problem space well enough you’ll be able to define the implementation accordingly. When you do, implement the simplest possible solution you can and leverage the abstractions you’ve built from your experience to give you as much wiggle room to change things the next time out.

Details change quickly, patterns change slowly, your code base is glacial. Make it broad and adaptive and don’t overly tax yourself fitting into the cracks.

Every year I mean to take the time to note how the leaves grow on the trees around me and how the plants spring back to life. This year I’ll be making a real effort. I’ll be using Everyday to remind myself to go outside and take a photograph of the tree behind my place from my balcony. It will ask me to align my nose and mouth and I will laugh at it as I choose to align my photos with the branches of the tree.

And that’s what you’ll be doing too. We are all going to agree to take a photograph every day of our favourite plant or tree as it starts to recover from being depressed about just how stupidly cold the world can be at times. We will then share these with each other and the collection will be a wonderful crowd-sourcing of spring time happiness.

So, download Everyday and get to work. When you upload your series of photographs email the link to me at spring at kickingbear dot com. I will collect them and we’ll work out a great way to share them. No, I’m not sweating the details. It’s spring, have some fun.

For myself this is a deeply personal project. Each year my favourite tree grows slowly, its foliage gradually fills out and, in doing so, robs me of enjoying the sun as I relax on my deck. My photographs will be documenting how much of an asshole this thing is so that when I chop it down the judge will understand. Some of you may have more positive and happier motivations though. And I suppose that’s ok too.