The Instapaper Default.png dilemma
marco.org
marco.org
Our solution was to use a pure black Default.png, and design our game to have very low upfront load times. On iPhone 3GS, our game takes 1-2 seconds to fade in from pure black.
This also fixed the problem we had where some users that preferred to flip the game upside down (landscape mode).
By displaying the last snapshot of the app as a splash screen, the Apple apps imply that you can immediately interact with the application - but you can't, because it's just a static image.
On slower hardware (e.g., the original iPhone/iPod Touch), this violation of user expectations can last for a measurable time - easily enough for the user to make multiple attempts to interact.
Touch...nothing happens. Touch...nothing happens.
A splash screen is better than a misleading "last view" snapshot.
Go with the night mode splash screen.
kb
It counts on the user trying to remember where he left off while the program loads, so by the time you think "aha, I was gonna send an e-mail to Ron" the UI is responsive. It's a nice trick that saves you time in the end.
Of course, if the app takes too long to launch the UI would seem unresponsive, which is why Apple chose to not make it available to third party developers.
But if you look at Apple's other software, say, iBooks or Remote.app, the launch image often doesn't match the initial UI presented when the app starts running. I don't think it's much of an issue.
In the case of Instapaper, I might consider doing a very fast animation from light to dark, when necessary, but I wouldn't spend much time on it.
CABasicAnimation *a = [CABasicAnimation animationWithKeyPath:@"opacity"];
a.duration = 3.0;
a.fromValue = [NSNumber numberWithFloat:1.0];
a.toValue = [NSNumber numberWithFloat:0.0];
[theLayer addAnimation:a forKey:@"animateOpacity"];
Warning: tapped out that code off the top of my head and didn't put it through a compiler.For this case, do this (also uncompiled):
[UIView beginAnimations:nil context:NULL];
[UIView setAnimationDuration:3.0];
[defaultImageView setAlpha:0.0];
[UIView commitAnimations]; Use of this method is discouraged in iOS 4.0 and later. You should use the block-based animation methods instead.
Frankly, it's because I can't remember the block based methods off the top of my head yet.Thanks!
This disparity makes it hard for a developer like Marco, who is only trying follow his rule of “If in doubt, do it Apple’s way” (as repeated in the HIG and similar documents Apple provides to developers).
That said, with the new multitasking support in iOS 4 for newer devices, perhaps this issue is less important than it once was, especially for apps that you use often (and thus keep running).
Effectively, halfway between the dark and light.
It could also be half-and-half -- for example a diagonal cut. (Then the transition to the actual could wipe the wrong color off to one side.)
Or, a shaded gradient, top to bottom, between the light and dark -- so either way the flicker-to-actual is half as harsh. (This could also work well with a fade/wipe to actual.)
- Make it a picture of the dark mode interface, and animate to the light interface on start (or vice versa).
- Show the splash screen, and animate in the UI components.
I have no idea how hard either solution is, but you might be able to get a less jarring start from an approach like this.
It sucks that you can't take a snapshot of the app when exiting though.
Yes, it's bad because it further delays the launch of the app but if the hardware is so fast that the short blink is a concern the slight added delay probably isn't a big deal.
I'd say start with the dark default image. If you're starting Instapaper in a poorly lit environment in dark mode it'll be more disrupting to your night sight to have a bright starting image than if you start in normal mode and have a dark starting image.
Are splash screens cheesy? That's a personal convention, but screwing with someone's night sight for a particular use case focused on it being dark is probably far worse.
I use dark mode during the day on Instapaper Pro, I just prefer it and find it easier on the eyes.
http://collison.ie/blog/2008/11/dynamic-defaultpng-files-on-...
The article is from 2008 and the SDK may have since disallowed this behavior. I've not tried it myself.
It's a bad enough experience that it's not even worth considering.
http://developer.apple.com/library/ios/#documentation/UserEx...