Category: Design

Splash screens

Twitterrific has a splash screen and I would like to get rid of it. But I can’t.

Splash screens hurt the user experience from a purely psychological point-of-view. They don’t change the launch time of your iPhone application at all, but it looks and feels longer.

But there’s a problem: you can only specify one Default.png file to be displayed at launch time. Unfortunately, applications can have many visual states which you’d like to show as the code is loaded. In the case of Twitterrific, the list or detail view can be active and they have no visual commonality.

So what are the current options?

Some people have suggested that you have a single startup image (like the list view in Twitterrific) and use a Core Animation transition to the actual state the user was last in. This would work, of course, but it has a major flaw: it increases the amount of time needed before the user can actually start using the application (they need to wait for the transition to finish.)

Another option would be to show a blank screen. I tried this, and my first thought was that the application had crashed. Not acceptable.

Why not replace the Default.png on-the-fly? As Tom Insam notes, you can’t modify the application bundle: doing so breaks the application signing and will leave you with code that won’t run.

So that leaves us with splash screens. The user knows the launch is in progress, there are no jarring visual changes, and it’s the quickest way to get to an active state.

Of course, there are mechanisms to have multiple startup screens. You can see it in the Clocks app: the world clocks view has a different startup image than the stopwatch view. Another example are the new chrome-less Safari pages that you can put on the home screen: these apps take a snapshot of the current screen at exit and display it at the next launch.

Apple should expose this functionality to third parties. If you agree, please submit a duplicate for Radar ID# 5872097. Until that happens, please excuse our splash screen.

Written on October 8th, 2008 for Design, Development

[REDACTED]

Thank God—that’s the last time I’m going to type that word for awhile. The meme is dead, long live the SDK.

As a way to celebrate the lifting of the NDA, we bring you some very special source code. To wile away the time between our product submission and the launch of the App Store, my buddy Anthony Piraino and I worked on this very special treat. Something that will be familiar to all developers who have had to keep their mouths shut since March 6th, 2008. Just compile the source code and install it on your device. Typing pleasures await.

(You’ll need to install Twitterrific from the App Store to get the full user experience. But you’ve done that already, right?)

Besides being a fun inside joke, this very special application also shows an important aspect of iPhone development: URL schemes.

As we’ve seen many other times, the needs of a mobile user are very different than those of a desktop user. On the desktop, tight integration of several application domains makes applications like Coda a joy to use.

On the phone it’s better to focus on one task. From what I’ve seen, the best iPhone applications do one thing and do it well. Supporting URL schemes in your application makes that single task more attractive to other developers and users. It leads to what my friend Daniel Jalkut has aptly called the “Un-Coda-fication” of iPhone apps.

The benefit for a developer is obvious: it minimizes the scope of an application and the attendant memory footprint. You could write your own Twitter update code using a NSURLConnection, or you could use one line of code like this:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitterrific:///post?message=EASY"]];

There is a less obvious, but equally important benefit when you look at URL schemes from a user’s point-of-view. Since your application’s scope is limited to one task, users will depend on it when they want to perform that task. Even if that task is in the context of another application.

An example of this is sharing photos. Users know that the Camera application takes pictures and that the Mail application sends messages. You don’t see a camera button in Mail; you see an “Email Photo” button in your Camera Roll. The user’s first task it to take a picture and the next task is to mail it.

Since we’re not Apple, we can’t achieve the high level of integration between the Camera Roll and the Mail application. But we can use URL schemes to accomplish much the same thing.

I worked with Fraser Speirs and Ian Baird during the development of Exposure and Cocktails so that their applications could support a “Post to Twitter” button. Clicking on that button initiates a workflow that lets the user share what they’re looking at on Flickr or what kind of drink they’re enjoying. Leaving their app/task and launching Twitterrific makes complete sense.

If you’d like to include a “Post to Twitter” button in your own application, all the code you need is in the postToTwitter: method in the very special application mentioned above. If you want to handle your own URL scheme, take a look at application:handleOpenURL: in the application delegate. Be careful about validating inputs: you don’t want malicious URLs to do bad things.

Not to dampen your enthusiasm, but please be aware of a couple of limitations with URL schemes. First, there is no way to know if a URL scheme is supported or not (rdar://problem/5726829). Currently, the best you can do is to performSelector:withObject:afterDelay: then openURL:. If the selector gets called you know that the URL failed to open. Also, be aware that deleting an application can sometimes leave the URL registration database in a state where it no longer recognizes a scheme (rdar://problem/6045562). This only happens when two applications support the same URL scheme, so you can avoid the problem by using a unique scheme name. Please use the Radar bug ID# for a “me too” bug report if this becomes a problem in your own application.

Now let’s enjoy our newfound freedom to discuss the iPhone SDK and the first of many sample code releases on this site!

Update October 1st, 2008: As Jonathan Rentzsch and Thomas Ptacek point out, URL schemes can be an attack vector for your application. Pay particular attention to the code in -application:handleOpenURL: in your application delegate. If you find any vulnerabilities in my code, please let me know so I can update this essay. Thanks!

Update October 7th, 2008: Once your application supports URL schemes, it’s likely that you’ll want to provide a bookmarklet in Safari. Here’s the one we use in Twitterrific:

javascript:window.location='twitterrific:///post?message='+escape(window.location)

The hardest part about doing this is guiding the user through the setup process. Joe Maller came up with a simple solution that lets the user get the Javascript into their bookmark list. This was later refined by Alexander Griekspoor. Make sure to view the source on these pages for additional hints and installation instructions.

If you agree that this setup process is too difficult for end users, please submit a duplicate bug for Radar ID# 5935641. Thanks!

Update February 4th, 2012: UIApplication now provides a -canOpenURL: method that lets you check if there is an application installed that supports the URL scheme.

Written on October 1st, 2008 for Design, Development

Nike – iPod

Having just presented a talk at C4[2] about the human factors involved in developing touch-based applications, I find it rather ironic to see the Nike + iPod integration move into the latest iPod touch.

Why? Because I see some serious problems with how our bodies will interact with this device and its software.

Note: These are first impressions. I obviously haven’t had a chance to use the product, so the implementation by Apple/Nike is just a guess at this point in time. I’ve heard that there are some special controls in this software that allow “eyes off” control: if that’s the case, then we’ll all learn something from that UI.

The first problem is the size. When I’m running, I want the smallest piece of equipment possible. The simple reason is that any mass acts as a pendulum as you move. Sure the new iPod touch is lighter than its predecessor, but it’s still bigger and heavier than its nano sibling. Bigger is certainly not better.

There’s also a problem with where this device will attach to your body. Because of the size and weight, it’s likely that you’ll need to use it on an armband or in your pocket. Both of these locations present problems with interaction. You can’t see buttons on a touch screen when they’re in your pocket. It’s also uncomfortable to operate an interface that is strapped to your arm: try to unlock, launch and use an application while it’s positioned on your upper arm. Now do it while you’re running.

Good luck finding the PowerSong button without looking, too. Unlike the Nike + iPod application on the nano, this and other operations can’t be done solely by feel. Being able to operate the device while running is essential: you literally don’t want to take your eyes off the road. This “eyes off” approach to interaction is why the new iPod touch has physical volume buttons and why it was the most popular request by customers.

Some may argue that this device will be fine in a more controlled setting such as a gym. But if you’re running on a treadmill, there is already plenty of feedback from the machine’s built-in sensors and monitors. You don’t need a sensor in your shoe.

But in either case, you’ll find the biggest interaction problem is that sweaty fingers don’t work well on a capacitance-based touch screen. The salts in your body fluids make it much harder for the device to recognize your input. If you don’t believe me, try dissolving a teaspoon of salt in a cup of water. Then dip your finger in the salty water and try using the screen. You’ll find touch controls are jerky and non-responsive. Now add some body movement and you’ve got a real interaction problem.

Sometimes a few simple buttons, and not a fancy multi-touch UI, is the best way to solve an interaction problem. 

 

Written on September 10th, 2008 for Design, Observation, Opinion

Thank you

Wow.

There’s no denying the physical beauty of the award or the cool prizes that accompany it. But in this “day after” the thing that I’m finding most rewarding is the outpouring of support and congratulations. The six weeks of eating, sleeping, and breathing [REDACTED] preceded by months of digging through class-dump and respondsToSelector output was far from easy: but it’s all worth it.

From everyone here at the Iconfactory, all we can say is thank you. It means so much.

Unfortunately, we’re still under NDA and have been advised by Apple not to share screenshots. We’re all anxious to show off our work, but we need to respect the wishes of our new partner.

If you’re here at WWDC, you can get a look at the UI on the panels on the third floor. There are also some photos from last night’s event that hint at what’s about to come. For those of you wondering about the photo I took before going on stage last night: my big fat finger was over the lens on my iPhone—a great example of why ergonomics in your application is important.

Written on June 12th, 2008 for Design, Development, Miscellaneous

Brain surgeons

Unless you’ve been stranded on a remote Pacific isle, you’re no doubt aware of the current furor over third party iPhone applications not being able to run in the background. To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.

As someone who has been involved in iPhone development for the past six months, please let me offer you a healthy dose of reality.

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

(Those of you under NDA with the iPhone SDK should take a look at the documentation for Core Location. After reading about how it should be used, you’ll understand why getting your location in Maps and similar applications is only done on an “as needed” basis.)

And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world.

What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding.

In my opinion, such a scenario is quite likely. As a satellite device, the iPhone requires contact with other machines to do interesting things. Periodically hitting the network is the primary reason that developers want to run in the background.

Some have stated that Apple is limiting innovation. My opinion is that they are helping us from collectively shooting ourselves in the feet.

It takes several months of actual iPhone development before you eventually realize that the iPhone requires a completely different mindset. Until that happens, you’ll make assumptions based on desktop experience, and that in turn will lead to a lot of bad designs.

For what it’s worth, I think Apple will address this issue in the future. I can imagine a solution based on a plug-in (bundle) architecture that lets your application do things when the phone decides it’s a good time (not when you decide it’s a good time.) If the radios go on because you’re checking Mail, then you get a “network active” notification and a chance to run some short-lived TCP/IP connections. If you take too long, you’d get killed, much like Safari does with Javascript that runs too long.

Do I expect such a sophisticated system to be available in a beta of version 1.0? Hell no. And neither should you.

Written on March 16th, 2008 for Design, Development, Observation, Opinion
Newer
Older