

The Instapaper Default.png dilemma - mattparcher
http://www.marco.org/1548306059

======
hyung
We've gone through the same problem. In our case, we wanted our game to resume
exactly where the user left off (i.e. no splash screen).

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).

------
kbutler
The AppleWay (tm) has another problem:

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

~~~
duopixel
The 'last snapshot as a splash screen' actually traces back to Jeff Raskin's
work on the Canon Cat.

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.

------
thought_alarm
Notes and Calendar are the only apps that still use custom launch images. I
always found it to be more annoying than useful because you can't tell when
the damn app has actually started running, so it's no surprise that they
didn't make that feature available to third-party apps.

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.

------
pkaler
Animate from Default.png to the first view:

    
    
      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.

~~~
Xuzz
May I ask why you aren't using the UIView animations, which, for something
like this, are easier (and don't need the extra CA power)?

For this case, do this (also uncompiled):

    
    
        [UIView beginAnimations:nil context:NULL];
        [UIView setAnimationDuration:3.0];
        [defaultImageView setAlpha:0.0];
        [UIView commitAnimations];

~~~
pkaler
From the documentation:
[http://developer.apple.com/library/ios/#documentation/uikit/...](http://developer.apple.com/library/ios/#documentation/uikit/reference/UIView_Class/UIView/UIView.html)

    
    
      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.

~~~
Xuzz
Interesting; I didn't know that. The block-based methods are, of course,
better, but then you can't support iOS 3.x, which is still a pretty big
percent of users.

Thanks!

------
mattparcher
This is another case of Apple not allowing third-party apps the same features
of it’s own apps (the previous privilege being multitasking, now mostly
allowed).

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).

~~~
cmelbye
It's not that big of a deal, let's not turn this into an "Apple is evil"
discussion. Apple deals with this in their own apps (iBooks, for an example
off the top of my head.) Every iPhone developer deals with it as well.

~~~
sudont
There does seem to be a difference in Apple's App store apps and the default
system apps, which could be considered more analogous to a OS feature. The
distinction is muddled since these OS features are accessed from the
springboard, along with actual apps.

------
jbr
This are my solutions: <http://twitpic.com/360tqd> or
<http://twitpic.com/360t2b>

Effectively, halfway between the dark and light.

~~~
gojomo
Nice. A gray evocative of either look was my first thought as well.

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.)

------
Splines
Possible solutions:

\- 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.

------
jonathanberger
On the fastest hardware, you could keep Default.png displayed just a split
second longer to avoid the "blink too quickly" problem.

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.

------
iuguy
Marco doesn't have any comments enabled, which is a shame. He seems quite
difficult to make contact with.

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.

------
benjoffe
This is also an issue for one of my apps, which can launch in a horizontal
landscape, there's no way to create two Default.png files, once for each
orientation (correct me if I'm wrong, would love to optimise for it).

~~~
thought_alarm
You can (and would) on iPad, because apps can launch in any orientation. On
the iPhone, apps always launch in portrait orientation (unless it's a
landscape-only app) so your iPhone launch image only needs to support a single
orientation.

------
ary
Correct me if I'm wrong, but isn't this problem solved by using a symlink?
Creating a symlink with the name Default.png and then dynamically generating
the file it points to is basically on par with Apple's built in apps.

[http://collison.ie/blog/2008/11/dynamic-defaultpng-files-
on-...](http://collison.ie/blog/2008/11/dynamic-defaultpng-files-on-the-
iphone)

The article is from 2008 and the SDK may have since disallowed this behavior.
I've not tried it myself.

------
fictorial
I would just forgo the launch image for Instapaper then. Just get the UI up as
quickly as possible. Also, supporting "multitasking" on iOS 4 helps with
getting the UI up quickly when brought into the foreground.

~~~
zach
I don't believe the launch image is something you can just forgo.

~~~
aaronbrethorst
You can skip the Default.png file. The experience without it can be terrible,
though. Your app will just show a black, blank screen until it finishes
booting.

It's a bad enough experience that it's not even worth considering.

------
daniel_iversen
I love the look of the splash screen... why don't you just go with that? What
does dropbox do? their app comes up with a lovely looking splashscreen as well
and it sticks for a little while..

------
efsavage
Using secret APIs and not allowing third-party developers to access them so
that first-party apps are better. Seems to me I've heard this before...

------
gaiusparx
iPhone User Interface Guideline recommends design a launch image that is
identical to the first screen of app, and avoid a splash/about screen and
branding elements.

[http://developer.apple.com/library/ios/#documentation/UserEx...](http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/IconsImages/IconsImages.html)

~~~
erydo
Yes, but his point was that the first screen of the app might look drastically
different depending on certain settings (e.g. dark mode).

