Monday, August 2, 2010

Time Moves On…

Justin from CarpeAqua has an interesting rant this morning about pull-to-refresh. I don't expect everybody to like every new mode of interaction that gets introduced (I certainly don't), and I've been known to rant myself at times, but I must admit I don't quite get the fervor with which some people, like Justin, hate experimentation with new methods of interaction.

In his post, Justin sums up his feelings by quoting a tweet by Marco Arment that reads:
The problem, like gradients, reflections, animations, and PHP, is not that it's a bad idea but that many won't use it properly.
This argument reminds me of the arguments I've heard against dot notation in Objective-C. It amounts to "somebody might use it poorly, therefore it's bad".

I've got news for you: There's almost nothing in life you can't say that about. If you're holding up the potential abuse of something as a reason not to use it, then you're making excuses for your own desire for things to stay as they always were. In the history of human innovation, there's almost nothing that couldn't be abused or put to an inappropriate use.

Sure, you can do this with Objective-C 2.0+:
someObject.release;
That's a perfectly legal way to release an object. Most, including me, would argue that it's not a good way; it's likely to cause confusion and makes the intention of your code harder to read. But, just because you can do this doesn't mean dot notation is inherently flawed (though a vocal minority of Objective-C developers argue exactly that). The same thing goes for gradients, reflections, PHP, animations and, yes, pull-to-refresh. Actually, scratch that… PHP really is bad¹. But the rest of them aren't.

Even the greatest interaction ideas can be mis-used and over-used and, in fact, they usually are. I'd almost argue that they have to be. All ideas get refined as they are used more. It's natural behavior to explore, expand, and find the limits of any new idea. Thought experiments are all well and good, but until you get a new mode of interaction in front of a lot of people to try it, all you've got is your best guess based on your own opinion. In other words, overuse of the novel isn't, in the scheme of things, a bad thing. Over time, the overuse ends and we're left with something we understand much, much better and that works really, really well.

Basically, we don't know how to use new concepts "properly" until they've been used a lot, in a lot of different ways, by a lot of different people. There's nothing to guide the use of the novel. There's no way to find what works and what doesn't except by trying. And sometimes the things we try won't work, or won't work for all people. Sometimes they'll be downright bad.

A lot of our current desktop interaction model, things that we think of as universal and standard, weren't always standard or universal. I can remember when ⌘C, ⌘X, ⌘V, and ⌘P did not automatically mean cut, copy, paste, and print on the Mac. It took several years for key commands to truly become standard and universal on the Mac. Heck, many early versions of Mac applications didn't make much use of key shortcuts at all, and when they did, they weren't at all consistent in which keys they used to do what. You can't dictate what works in user interaction. You have to put it out there, observe and listen, and be willing to change based on what you see and hear.

Personally, I like pull-to-refresh as it's used in Tweetie Twitter. I find myself doing it in Mail.app, even though it doesn't work there. To me, it's the perfect gesture for the iPhone in apps where you're primarily consuming small chunks of content in a table, like your inbox or twitter apps. When I'm using apps of this nature, I'm often in one-handed mode, using my thumb to scroll. My thumb can't comfortably reach the entire screen (e.g. a refresh button in the navigation bar), and I don't want to bring my other hand over every time I want new tweets. When I'm in editing mode, I'm naturally using my other hand, and that's great, but if I'm standing in line at the grocery store or waiting to board a plane and I'm just reading my timeline, I like that I can just flick my thumb to get more tweets. It's a benefit to me to be able to work one handed. It's a nearly ideal form of interaction for the way I use the application most of the time. Obviously, I'm not the only one who feels this way. You don't see lots of people rushing to copy features that don't work or aren't liked.

In other apps, or especially on the iPad, pull-to-refresh doesn't seem like it would be a natural form of interaction, but I've never tried pull-to-refresh in other contexts, so I don't know. But developers will try it (and are trying it), and many uses of pull-to-refresh that don't work well will die. Either the application will fail to sell, or the author will decide to change it to something that works better for his or her users. But we might just discover new and wonderful uses for the concept in the process.

That's how this whole messy process works. That's how we get progress in user interaction. We try things. Sometimes they work, often they don't. If, as developers, we only use things that are tried and true, nothing will ever change.

Progress in user interaction, like anything else where hard-to-predict humans play a major role, is messy and slow and imperfect and no amount of ranting about it will change that fact. If we want progress... if we want to keep moving forward, that's the price we pay. You can get angry about it, but you can't change it. You'd have about as much luck arguing with the weather.



1 No, not really. That was a joke.

Sunday, August 1, 2010

NSOperation Xcode File Template

Although I'm generally averse to using a lot of template or boilerplate code, there are times when it's handy to have file template beyond those that Apple provides. Something I've done a fair amount of lately is to create NSOperation subclasses, and there's enough work involved with setting up an operation that I made an Xcode file template that contains all that setup work.

This template includes a delegate and a protocol and some private methods for communicating with the delegate. Now, when I have lots of NSOperation subclasses in a single project, I'll actually move much of this stuff to an abstract parent class or a category on NSOperation, but templates don't have any way of setting up dependencies, so I've made this self-contained and you can do your own refactoring.

I added this particular template under the Objective-C class icon so that it comes up as a new option under the Subclass of popup menu.

Screen shot 2010-08-01 at 1.53.48 PM.png

You can find the template files right here. The zip file contains the full path to install everything in the correct place, so if you want to install it so that you can use it from Xcode, you would use the following command:
unzip NSOperationTemplate.zip -d /

If you just unzip it regularly, you'll find the actual files nested several folders down as a result of the path information.

I've only touched one existing file, which is a property list that causes the new template to show up in Xcode's Subclass of dropdown menu. The rest are new files, so installing this shouldn't interfere with Xcode in any way. But caveat emptor. You do keep good backups, right?

Hopefully this will be useful to some of you. If you have suggestions for making it better, please let me know.

Wednesday, July 28, 2010

App Licensing

Google took an interesting step recently by adding a service called App Licensing to the Android SDK. I haven't looked at it in detail, but the gist of it is that it's a license validation system for third party apps. It allows third party apps to check with the Android Marketplace to see if it's authorized to run on the particular device. To simplify it beyond recognition: It's sort of like Steam for Android Apps.

This is a bit of a double-edged sword for Google, though. Steam-style online authentication isn't exactly warmly embraced by the proponents of "open" systems, but given how easy it is to pirate applications downloaded from the Android Marketplace (and then return them for a refund!), it's probably a necessary step to attract developers to the platform. Google has to at least look like they're trying to stop the rampant piracy.

But here's the thing: With an open source OS, I can think of a dozen different ways to try and circumvent something like this, and I'm hardly a 1337 hacker. Google can add complexity and make it harder to circumvent, but if someone with the right skills has full access and control over the hardware and software, you can't stop them from getting around any kind of licensing authentication scheme you create. It's like DRM. Within a few months (at most), there'll be an exploit or hack to allow pirated Marketplace apps that use App Licensing to be run without a license. I can almost guarantee it. Google can keep changing the process to fight the pirates, but it's a losing battle, and likely would entail a lot of inconvenience to developers in the process.

This is one area where a closed system has advantages. For us iPhone developers, only about 10% of our potential audience can possibly pirate our apps because pirating requires jailbreaking. That 10% is the starting point. The most it can be. Jailbraking is a quid pro quo, so 90% of our potential market can't, won't, or wouldn't know how to pirate an app. But the real number is even smaller than that. Not everybody who jailbreaks their phone pirates apps - there are other valid reasons to jailbreak (so I'm told, I've never been tempted myself) - and I know people who have jailbroken their phones who are ethical and wouldn't consider pirating an app.

There's no doubt that there are advantages to "open" systems, but there are also disadvantages. In this particular case, one of the most major drawbacks of "open" doesn't hurt Google or the Wireless providers, it hurts third party developers. If that wasn't true, Google wouldn't be devoting engineering hours to try and stop it with 'app licensing'.

Life as an iPhone Dev has it's problems, no doubt. When you have an app sitting in review for months, the way Briefs has been, when you get rejected on seemingly arbitrary or inconsistent grounds, or when you can't implement something that would benefit your users because of a term in the license agreement, it sucks. But, when all is said and done, a good app on the App Store properly promoted can make enough money for a development team to live on. Until that can be said about the "open" Android Marketplace, I simply can't buy into the "open is better" mantra.

If a curated platform offers a better user experience and allows third party developers to actually make money, I just don't see "curated" as a dirty word, no matter how many times Google's Android Evangelist tweets it.

Tuesday, July 20, 2010

Those Were the Days…

The Computer History Museum has recently posted the original source code for MacPaint and QuickDraw! Apple has given them permission to publish them both, and they're well worth taking a look at if for no other reason than to realize just how good we programmers have it today.

The source code is a combination of 68k assembly, resource files, and Pascal, and all of the code was written by the incomparable Bill Atkinson, one of the early heroes of Mac programming and author of Hypercard (among many other things).

As an interesting aside, Bill stopped programming several years ago to focus on photography, but started programming again after the iPhone SDK came out so that he could create PhotoCard.

If you're not really familiar with who Bill is, you might want to read some of the stories on Folklore.org, but be warned, it's easy to lose track of time at that site if you have any interest in Apple history.

Note: One question that occurred to me looking at this source code was "how could Bill could have coded this back then?" These were written before the Mac shipped, and the Mac shipped with only 128k of RAM, which is smaller than the MacPaint Pascal source. You couldn't have opened some of these source code files on an early Mac due to their size. The answer appears to be that they were written on a Lisa, which shipped with a meg of RAM. That was some crazy amount of memory for the day and part of the reason the Lisa cost $9,999 (somewhere between $19k and $40k in today's dollars. I do seem to recall reading, though, that the early versions of QuickDraw (aka LisaGraf) were written on some model of Apple 2, though.

Sunday, July 18, 2010

A few things iOS developers ought to know about the ARM architecture

The Wandering Coder has a great post today titled A few things iOS developers ought to know about the ARM architecture. There's some really good information about the different ARM architectures in different iOS devices and different generations of certain devices. Well worth the read.

Saturday, July 17, 2010

On Swords, Perspective, and Spin…

Although I thought Apple started off a little too defensive yesterday, when you boil it down, I thought they did the right thing. If you're having a problem and a case can fix it, here, have a free case. If you already bought a case, they'll refund the money you paid for that case. If you bought an iPhone 4 and the problem keeps you from being able to use or enjoy your phone, they'll take it back, no restocking fee, no questions asked.

All other issues aside, I'm not sure what more Apple could or should have done. There aren't many products that come with an unconditional guarantee any more, yet reading some of the output of various so-called tech "journalists" since yesterday's press conference, it seems that there are many who think that Apple didn't do enough and didn't "do the right thing". Short of Apple's senior management taking out swords and falling on them (at least proverbially, if not literally), I don't think anything would have made certain journalists (and I use the term very loosely) happy.

Of course, it's not exactly good for the tech press if this quietly goes away or turns out to be much ado about nothing. They're having a grand old time and raking in a lot of page hits on this whole "antennagate" thing they've created, so I guess it's understandable that they don't want to accept a reasonable response from Apple. They clearly wanted nothing less than a fall from grace… an admission that Apple didn't design or test properly. Instead, they got treated to a number of facts that didn't jive with what they wanted to hear. They were shown other phones experiencing similar phenomenon. They were shown a little about the testing procedures the phone went through and the investment Apple has made toward testing their antenna designs. They were shown, in short, why Steve doesn't think they did anything wrong.

The natural reaction to cognitive dissonance is anger, so I guess I shouldn't be surprised by the angry diatribes from some sectors of the tech press, especially those who aren't fans of Apple to begin with. But anybody who expected anything else out of yesterday's conference call are either intentionally stoking the fires for their own benefit or else they're morons who fail to realize there are perspectives other than their own. Perspective is an interesting thing, and it's not quite the same thing as "spin", which it is often mistaken for. Perspective is your own world view. It's a combination of a whole bunch of things that make up the way one person thinks about things: their likes, dislikes, biases, priorities, and fears. Spin, on the other hand, is when somebody intentionally tries to conflate facts, or select facts to make their position look better.

And make no mistake, we saw some spin yesterday. Some of the statistics early on were very carefully selected. The iPhone 4 dropped call rate being 1 in 100 less more than the 3Gs call drop rate, for example, sounds small, but what was the 3Gs' dropped call rate? If it was 1 in 10,000, then that's a statistically huge change. If it was 3 in 100, then it's statistically tiny, probably within the margin of error. We weren't given enough information to know what that statistic meant. If I had to guess, I'd say the difference was probably statistically significant (though not necessarily huge) or they wouldn't have presented the data that way.

But, even with the spin, it was pretty clear that from Steve's perspective Apple went through a very rational, valid design and testing process and achieved something pretty amazing. And I tend to agree. I wouldn't easily give up my iPhone 4 now. It's an amazing piece of technology. It really is. I love just holding the damn thing in my hand. It's such a refreshing change from all the cheap plastic consumer devices in my life. Every other device that the iPhone manages to replace in my life (my point and shoot camera was the latest casualty), the happier I am. I would quite honestly give up using cell phones before I'd let somebody replace my iPhone 4 with a junky plastic Blackberry or Nokia phone with their confusing, poorly written and terribly designed software.

Now, that's not meant to downplay the antenna issue, because for some people it is real and a hassle, I'm just stating my own perspective. Regardless of your perspective, however, the evidence seems to show that statistically speaking, most people in most places are going to have better reception with this phone. All design is about tradeoffs and all products are designed to meet the needs of a wide variety of people. Moving to an external antenna system was a conscious choice that Apple made, and it appears to have been well thought-out, researched, and tested. A conscious design decision was made that would make more room for battery and additional sensors and gadgets while making the phone more solid feeling and still thinner than any previous phone. The tradeoff, other than the obvious ones of manufacturing costs, was the increased possibility for attenuation. Now, we know, thanks to Anandtech, that this attenuation can cause a reduction of up to 24dBm of signal strength. We also know that that amount makes no measurable difference in data speed or voice reception for most users in most locations. Months ago, before the iPhone 4 came out, and without the benefit of hindsight or knowing what kind of media circus would ensue, that almost certainly would have seemed like a perfectly valid tradeoff. "Wait, if we do this, most people, most of the time will have better reception and we can make the phone smaller and have better battery life and fit a gyroscope, and the only tradeoff is that some people in some situations if they hold the phone in a certain way will have one or two less bars? Great!"

Was it the right decision? Well, with the benefit of hindsight, perhaps not if you factor in the negative publicity they've gotten. But, was the decision the kind of stupid mistake that deserves payment in blood? Absolutely not. Even suggesting it is ridiculous.

The iPhone is a consumer product. It's like off-the-rack clothing. It's not custom tailored to any one individual. It's the product of a long series of design decisions trying to make the best product for the largest section of the population. If you're an outlier - if you're one of those people for whom the issue is preventing you from using the phone, put it in a free case, or bring it back. Apple will give you your money back, AT&T will let you out of your contract. No questions asked, no restocking fee. You're then free to go find a phone that works better for you.

If you want or expect more than that, you've got pretty serious entitlement issues. If you don't want to do that because you think you can't find a better phone, then maybe you need to re-assess your own perspective.

Friday, July 16, 2010

iPhone 4 Press Conference

Well, the iPhone 4 press conference just ended, and I thought I'd type up my thoughts quickly before diving back into work. Overall, the end result is exactly what I thought they'd do: free cases and refunds for those who want them. Seems very like a fair response to me.

I thought Steve started the presentation sounding a little defensive, though I can understand why. By the middle of the performance, though, he really hit his stride, and by the end I'd have to say it was one of Steve's best performances to date when you factor in that he wasn't announcing a new product, but instead defending an existing one, which is never as much fun or as easy.

The main points were that yes, you can interfere with reception on the iPhone 4 by grasping it a specific way, but you can also do that on most smart phones (they demonstrated it on several models of competitor phones), and that the press was making a bigger deal out of this than customers were in search of a headline. He pointed out that both Apple and AT&T were seeing lower return rates for the iPhone 4 than for the 3GS, in fact the returns have only been a third of what they saw with the 3GS.

There were little bits of insight into life at Apple that were unusual. We don't usually hear much about their actual processes (except manufacturing processes which have been part of their PR since the unibody computers). Seeing the anechoic chamber was cool and it was interesting to hear a bit about the process they go through to test reception on the antenna designs. Hearing about the problems AT&T has with getting new cell towers approved in San Francisco was somewhat enlightening. I've been rather harsh about AT&T's signal in NYC and SF myself, but never really though about the NIMB factor. I'm not ready to become an AT&T fan boy, but I am ready to cut them a little bit of slack on that issue now.

We also heard that Apple has sold over three million iPhone 4s in roughly 3 weeks and that they're still selling every one they can make. That's impressive considering the amount of bad publicity they've gotten from this issue.

At the end of the session, Steve pulled up Bob Mansfield and Tim Cook to answer questions, and I thought that was especially well handled with some nice bits of humor, though they took off the gloves about a few reports, especially one from the NYTs about a supposed software bug contributing to the reception issue. I especially like the comment that was made when Bob Mansfield was talking about how they sometimes send engineers to a customer's house to test reception. Bob said "For the record, we notify them we're coming", and Steve chimed in with "…and we didn't bash in any doors". Just a great response, it showed a sense of humor while getting in a bit of a jab at Gizmodo (who were never once mentioned by name that I can remember - it was always "some website" when talking about things they did).

There were two other things that struck me, but I'm not sure if they are worth mentioning, they might just be be reading too much into things, but I will because it's fun to speculate about such things.

The first thing is that Steve mentioned that Apple has Verizon cells on campus in addition to AT&T cells. Now, it's not uncommon for large companies to have towers onsite to ensure their employees get good reception at work, but it seemed odd that he felt it was worth mentioning that they had Verizon cells on campus when talking about an issue that would only be affected by AT&T towers.

The other thing that struck me as odd was the fact that in one of the question responses, Steve talked about the press "going after" Google because they were successful and that he wished the they wouldn't do things like that. He talked about how great the stuff Google made was and made a weird little comment about people not appreciating innovation that's still happening inside the U.S. Again, it may not mean anything, he could have just been trying to think of a big successful U.S. tech company and that was the first one that jumped to mind, but given the state of affairs between Apple and Google lately, it seemed oddly conciliatory and defensive. Perhaps a hint that the Google/Apple competition is headed back to more civil grounds even if may never go back to the days of friendly coopetition of yore? I dunno, but maybe. We can hope.

That's all, now it's back to work. You should too, slacker.

Update: Apple has just posted a new page explaining attenuation and signal loss.