Year: 2007

MobileTwitterrific

There are two things that I really want on my iPhone: Twitterrific and Frenzic. Last week I started taking care of the first one and am happy to announce a proof-of-concept.

Don’t expect much in terms of usability or elegance. The application only initiates a network connection to Twitter, downloads a timeline feed as XML, and then parses it into a data model. The user name from the model is then displayed in a table view. Sounds pretty simple, right?

Bzzzzt.

It took a lot of head scratching to parse that XML data. NSXMLDocument is hidden in the OfficeImport framework (presumably to handle Office XML files.) The ARM linker can’t see the symbol in the framework, so the document is instantiated with [NSClassFromString(@”NSXMLDocument”) alloc]. Many thanks go to Lucas Newman for figuring that one out! Also, there aren’t any XPath methods available, so extracting the information isn’t as easy as with AppKit.

(Do a search for “NOTE:” in the source code for more information on the cause and resolution to these problems.)

It’s pretty clear that the development of a native Twitter client should be done “in the open.” There’s a lot of reverse engineering involved while developing native iPhone applications, so getting more brains involved will result in much quicker development. It will also aid in the development of similar types of network-based applications, such as Ian Baird’s Pownce client. It’s also my hope that this project will spur Brent Simmons into doing something creative :-)

So take a look at MobileTwitterrific, and if you think you can help out, please get in touch via my Gmail account. Thanks!

Written on August 19th, 2007 for Development

Hacking quicker

It’s no secret that I’ve started hacking on my iPhone.

And what’s the most frequent thing I use in development? SSH2 to copy new builds onto the phone and view NSLog output from the shell.

And is it a pain to enter your password every frickin’ time? And is it slow to connect? Yes and HELL yes.

But we can make it better.

First, let’s make a public key that’s compatible with SSH2. Using the id_dsa.pub key generated by OpenSSH on Mac OS X, we’d use these commands:

% ssh-keygen -e -f id_dsa.pub > id_dsa_ssh2_aster.pub
% scp id_dsa_ssh2_aster.pub root@192.168.0.100:/var/root/.ssh2

(“aster” is the name of my development machine, where I’m logging into the iPhone from. The “192.168.0.100” is the IP address of the iPhone on my local network. You may need to create the /var/root/.ssh2 directory on the iPhone first.)

Now, on the iPhone, you need to create a file that tells the SSH2 daemon where to find the public key. In /var/root/.ssh2, create a file named “authorization” with the following contents:

key id_dsa_ssh2_aster.pub

If you login from multiple machines, you’d add a new “key” line for each reference to the public key.

That’s all you need to do to avoid the login prompts. We’re halfway there!

Now for the more annoying thing: delays at login. It’s not because the iPhone is doing something stupid like running Javascript: it’s trying to resolve the client host name. Since the iPhone isn’t running lookupd, that’s kinda hard to do, so all we’re really doing is waiting for a timeout :-(

The simple fix is to turn off the “ResolveClientHostName” feature in the SSH2 daemon. As long as we’re tweaking things, let’s also add “NoDelay” to improve TCP network performance. Open /etc/ssh2/sshd2_config on the iPhone and update the configuration to:

#       ResolveClientHostName           yes
	ResolveClientHostName           no
...
#       NoDelay                         no
        NoDelay                         yes

Now restart the iPhone and watch your blood pressure decline as you continue hacking.

Update: These instructions assume that you are using OpenSSH2, not Dropbear. Installing OpenSSH2 gives you a full suite of tools for communicating with the iPhone.

Written on August 17th, 2007 for Advice, Development

Benchmarking in your pants

Just how fast is the iPhone?

Let’s run some benchmarks comparing the iPhone to my iMac running Safari 3 on a 1.83 Ghz Intel Core Duo processor:

Test iMac iPhone Slower by
100,000 iterations 0.041 secs. 3.209 secs. 78x
10,000 divisions 0.005 0.413 82x
10,000 sin(x) calls 0.009 0.709 79x
10,000 string allocations 0.010 0.777 78x
10,000 function calls 0.010 0.904 90x

This means that Javascript on the iPhone will take about 80 times longer to run than it does on the desktop. Keep that in mind while you’re writing your Web 2.0 applications.

If you need any more proof of how much slower Javascript is on the phone, take a look at the plotting application I did for C4[1]. Make sure to run it on the phone and the desktop: the performance difference is palpable.

But our benchmarking story doesn’t end there. What kind of performance would we get from a native iPhone application running these same kind of tests?

Thanks to the hard work of many developers congregating at the iPhone Dev Wiki, there is now a toolchain that allows us to create applications that don’t rely on sweet technologies like Javascript.

(Note: use Google if you’re interested in these tools; I’m honoring the request to not link directly.)

That, combined with the talents of Lucas Newman (author of Lights Off and other goodness at Delicious Monster,) resulted in a series of tests written in Objective-C. Here’s the source code: Marbles.zip

Let’s see how Javascript compares to native code running on the iPhone:

Test Native Javascript Slower by
100,000 iterations 0.015 secs. 3.209 secs. 214x
10,000 divisions 0.004 0.413 103x
10,000 sin(x) calls 0.105 0.709 7x
10,000 string allocations 0.085 0.777 9x
10,000 function calls 0.004 0.904 226x

In looking at these numbers, it’s easy to see that there are huge performance wins with native applications: lower function call overhead along with faster iteration and calculation. Even transcendental functions and object allocation sees a 700-900% speed increase.

More reasons for developers to crave a real iPhone SDK.

One thing that’s interesting to note: in the process of writing the Marbles test, Lucas noticed that _objc_msgSend_fpret was an undefined symbol in the ARM runtime libraries (triggered when calling NSDate’s timeIntervalSinceDate: method.) I looked around the libraries on the iPhone and couldn’t find any definitions, nor could a workaround with NSDecimal or NSDecimalNumber be found. Maybe this is one reason why the iPhone SDK isn’t available yet: important stuff is missing.

My guess is that developers just need to be patient. Apple is smart enough to realize that there are major advantages to having third party applications running natively on the iPhone. Not only will these applications be easier to write and faster to run, but they will also add to an ecosystem that makes the iPhone even more attractive to consumers. Apple also realizes that releasing an SDK means having interfaces that don’t change, code that works correctly, and documentation that explains its use.

If you’re a Cocoa developer and haven’t started looking at UIKit, now would be a good time. You have what you need to start experimenting. And you’ll be ready whenever Apple is.

Written on August 15th, 2007 for Development, Observation

Why stop at the Dock?

If the changes to the Leopard Dock are a good idea, shouldn’t Apple go all the way and do the same thing to the Finder? And then applications, too! Hell, I can totally see these windows flying around with Spaces and Exposé and Core OMFG!

The Finder of the future?

Forget about October, I’m stoked about 10.6! Let’s hope they add more reflections and transparency, too!

Written on August 9th, 2007 for Design, Observation

Does your app icon suck?

Yeah, I see a lot of icons in my business. I often get asked what makes for a successful desktop icon. And I’ve answered many times—but never in public. This essay also gives me a chance to write about something other than the iPhone :-)

Let me begin with this disclaimer: this discussion is directed at independent software (”indie”) developers. Our corporate clients, like Adobe, Apple and Microsoft, have very different needs and objectives when dealing with iconography for software suites. Please also remember that I’m a software developer by trade, not a designer (although, I’m not completely clueless when it comes to the arts.) This discussion will cover a lot of things designers already know—and things that developers need to know.

Before I talk about the specifics of icon design, it’s important to realize what your application icon represents. It’s your brand: it shows up in the Dock, on your download page, and in product reviews. People may remember your app icon more than they remember your product name. A strong icon design results in an equally strong brand.

What do you think of when I describe an icon that’s a truck sporting a yellow cab with a purple cargo?

That’s Transmit’s brand. It’s so good, other people want to use it.

Would you believe that people actually thank us for making that little truck icon? It’s true—an icon can have a huge impact on people’s perception of your product. If your app is a joy to look at in the Dock, people will be in the right frame of mind when launching the application.

This effect of good design is contagious, too. The Twitterrific icon is an example; the strength of the icon has carried over into other applications either directly or indirectly. People associate a blue bird with Twitter now—at the time we created the application, Twitter’s only brand was the word mark.

It’s also important for your design to be unique. The world doesn’t need another globe icon for a network application. Be careful about using the “document and tool on the desktop” metaphor; it may be recommended by the HIG, but it also means you’re playing on a field crowded with other similar designs.

Of course there is still room for creativity when working with familiar metaphors. If you look at Bryan Bell’s icon for NetNewsWire or Jon Hicks’ work for Firefox, you’ll see that the globe is a secondary element in the design. The complementary colors of the satellite and the fox are what draw your eye and make the image memorable.

One of the most unique icons to come around in a long time it the Coda icon. (I feel fine making that claim because I had no substantive involvement in its design—I’m just happy to have it in my Dock.)

There’s a interesting story that went along with this icon’s creation. This story illustrates how much thinking and rethinking goes into a successful design. It also shows that you shouldn’t work in a vacuum when dealing with something as important as defining your brand.

The early concepts for Coda’s app icon was a forklift; a natural extension to the Panic truck. But the release of a similar application that used this metaphor forced us to consider a new direction. In retrospect, that was one of the best things that happened in the project.

So without a forklift to work with, some more brainstorming ensued. Gedeon Maheux came up with the idea of using a leaf or seedling to represent the continual care and growth that a web application typically receives. Dave Brasgalla started developing this concept with a series of hand drawn sketches and simple vector artwork.

Coda concept artworkOriginal concept sketch for Coda

Cabel Sasser, who did the UI design for Coda, liked the concept sketch, but was hesitant about its use in their product. Ged convinced him it was a good idea because of its uniqueness.

Once we got the go ahead from Cabel, David Lanham started developing the icon. As with any design job, there were multiple revisions before everyone was happy. I first saw the icon toward its final revision (before the addition of trichomes and the rearrangement of water droplets.) Like Cabel, I had doubts about the icon’s simplicity.

Coda icon before final releaseCoda icon before its final release

The deciding factor was that it stood out on product website and in a list of other icons. Its simplicity and uniqueness was its greatest strength.

Comp of Coda icon on Panic websiteComposition showing how Coda icon would show up on Panic website

And the punchline for this story: a conversation with Cabel at this year’s WWDC revealed that he and Steven Frank originally had the idea of doing a leaf to represent their web studio application. But they discounted it and never mentioned it anyone. I guess that means that great minds really do think alike :-)

Note: There’s more that I’d like to show about this project, but I don’t want to steal any thunder from Cabel and his presentation at C4. Hopefully this post will whet your appetite as much as a link to Gina’s. It would also be safe to assume that this post will be updated sometime after our little get together in Chicago :-)

So what should you look for when developing your own application icon? It’s really pretty simple when you get down to it—the key elements are:

  • Color
  • Shape

When dealing with these elements, strive for simplicity and clarity. How the icon looks at 16×16 pixels is just as important as its representation at 512×512. Complexity in the larger sizes will not work well at the smaller sizes. A vibrant color that looks great at 16×16 might be overpowering at 512×512.

To get an idea of how these two elements are important, let’s do a little experiment. (Regular readers will find that I love doing “real world” tests to back up my statements.)

Open your Applications folder and set the list view to the smallest size (16×16.) Now scroll down through the list and pick out which icons jump out at you. Now ask yourself why—the answer is color and/or shape.

Here are the applications that caught my interest, their strongest design element, and some thoughts I have about each one:

Adium (color & shape)
A green duck makes a strong statement, although I think making the color a preference is taking customization a bit too far.

Firefox (color)
Circular icons tend to be overused, but the fox’s “C” shape overcomes this.

GarageBand (shape)
A unique shape that draws the attention of people who like music (like me.)

NetNewsWire (color)
The complementary colors in this icon are particularly strong and make for a very dynamic icon.

PhotoBooth (color)
Unique in that it successfully uses a gradient—ranges of color typically get lost in smaller sizes.

Skype (color & shape)
One of the few icons that incorporates the word mark clearly and successfully.

Parallels (color & shape)
I have no idea what the shape represents, but it’s unique and clearly represents the brand. Without the gold coloring, the shape would be reminiscent of the brand used by DC Shoes.

QuickTime (shape & color)
A clever icon that uses the letter “Q” to represent the brand. It’s been around a long time and still looks good—you can’t say that about most applications that were released in the early 1990’s.

Hopefully this essay has given you some basic insights on how to approach the design (or redesign) of your application’s icon. There’s no way that a fantastic icon can overcome crappy code, but something nice to look at will definitely affect people’s perception of your hard work. And be sure to give brand development as much care and thought as the lines of source code in your project: it’s not something that you just slap on your application before you ship.

Written on August 3rd, 2007 for Advice, Design, Development
Newer
Older