The thing that defines what you’re working on. To achieve this goal, you have to find the “nut” of your application. (I’m using the plural pronoun here because the interface design was a team effort.) And it turns out that “doing as little as possible” was one of our greatest challenges. Both in terms of functionality and beauty.įrom the very first day, we tried to do this. In a word, strive for one thing in your iPhone application: simplicity. If you’re still to fricken’ lazy to read that link, here’s what I like to call Gruber’s First Law of iPhone Development:įigure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience. And again: you can’t call yourself an iPhone developer until you’re read that fireball at least three times.
John Gruber’s recent essay on iPhone-Likeness is a definitive manifesto for iPhone development. So while tryptophan was coursing through my veins, I started to look back on our past choices and think about where I see things going in the future. It’s been only recently that where we’ve been and where we’re going have gelled to a point where I can express these thoughts in an essay. I’ve wanted to write about what led to the user experience in Twitterrific for quite awhile. It’s all about developers making choices. In spite of all these apps using exactly the same API at Twitter, there are many different user experiences. One of the most fascinating things about these native Twitter applications is the variety of user interfaces.
#Twitterrific desktop skin
(And please do all developers a favor: tweets like “twitterific sux, twhatever rocks” do absolutely nothing besides make our skin even thicker than it already is.) Making Choices In essence, users get to choose a developer whose preferences match their own. Having many choices for a Twitter client means that developers don’t need to create a “one size fits all” solution. There will always be more than one way to solve a problem: a developer’s personal preferences will inevitably seep into the implementation. The most obvious benefit is that applications will evolve and improve more quickly as developers learn from each other and try to outdo the other guy.īut there is a more subtle benefit. Of course, this competition is also good for users. From what I’ve seen with Tweetsville and his blog entries about its development, it’s clear that his decision is a loss for everyone working on the iPhone platform.) I’ve been an admirer of his work since the days of Aaron and the Appearance Manager. (I’m particularly disappointed that Ed Voas has decided to go back to work at Apple. In other cases, it shows me how I don’t want to implement a feature (without the need to prototype.) In short, competition will make Twitterrific better. Looking at how other developers tackle a problem domain often adds insight into solving similar issues with my own code. Seeing the work of other developers whose work I respect and admire acts as an inspiration. It’s true, but it shouldn’t come as a surprise: consider the number of web apps that proliferated before the advent of the native SDK. A friend of mine recently commented that native Twitter applications are the new flashlights.