I'm interested in what is a reasonable start up time or behavior for applications on smart phones.

This is simply when you click an icon on the launcher (as it may be called on Android) to the moment you get the first animation / update suggesting something is happening, to finally when the UI is completely ready.

I wonder how much difference a person can see in these scenarios? Is it worth optimizing start up of an application to gain 100ms, or say 250ms?

Is it better to have a progressive start up decorated with animations compared to a simple best effort start? Any suggestions on where in time this break point lies?

2 Answers
2

Great question. The closest answer I found was in this infographic which states that the maximum users are willing to wait is 5 seconds after which they will exit the app.

A snippet from the screenshot which pertains to loads times for apps

Also do note that the different app stores do enforce an limit on the load time for an app. To quote this article

All mobile operating systems – iOS, Android, and even Windows –
enforce a maximum app startup time. For iOS, the limit is about 15
seconds, and if your app isn’t running by then the operating system
will kill it.

The designer cannot control performance all of the time. The network
might be slow; the device might be running other tasks in the
background; certain operations might require a lot of calculation. If
the user at least perceives that they are not losing time, then the
app will make a solid impression. Design can help communicate this,
even during unexpected delays.

The first step is to identify flows that will likely have delays
(fetching back-end data, performing a lot of calculations, etc.). The
second step is to guide users through these delays by introducing
additional steps that they would perceive as being necessary (showing
loading animations, displaying useful tips, etc.).

The following set of images shows possible steps in a content search:

The user here experiences four steps:

Hits the search button.

Sees a loading animation.

Sees the first part of the list, with textual content and placeholder images (which could be stored in the app itself).

Sees the actual thumbnail images appear.

The user experiences short steps, rather than jumping directly from
step one to four, and so perceives progress rather than delay.

Another example which is recommended is doing partial loads as shown below:

Another example is when an app starts loading up. By first displaying
a picture that matches the application’s layout, the user gets the
impression that the app is loading more quickly. The screenshot below
illustrates this; however, the perceived performance could be sped up
even more by adding a simple progress notification in the blank space
of the first screen. This would avoid the impression that something is
waiting to be loaded. (In case of a slow connection the app does show
a loading notification, thereby communicating progress to the user for
that situation).

The article also has two other recommendations namely smart loading and background loading which can help create an illusion of faster loading

Smart loading

Smart-loading mechanisms, such as lazy loading, first load visible
content and then move on to content below the fold. This technique
reduces the user’s waiting time and thus makes for a smoother
experience.

Background loading

This is another well-known example. Performance depends on whether the
background is one large image, an amalgamation of small tiles (say, to
create a texture) or a pure algorithm. The best solution depends on
the situation.

Yup, but anyway - it's an average. There is more tolerance for more complicated apps, especially games. Time is an investment made by users - if user is promised a better reward, he will be up for waiting a little bit longer. For some apps (the ones user expects simplicity from) even a short lag is quite destructive for the experience. Say, you have a notepad that loads for 3 seconds. But if you want to spend more time with the app (esp. game) and it is a powerful one (e.g. DeadZone or Asphalt), there should be no problem for the user to wait even 10-15 seconds.
–
Dominik OslizloFeb 14 '13 at 14:38

Makes sense,but as mentioned in my updated answer,some operating systems will kill a app if it takes too long to load. Also the fact that the app should also consider doing some partial loading to ensure that it doesnt seem to be hanging
–
Mervin JohnsinghFeb 14 '13 at 14:45

Great answers, I'm checking mostly because of the research paper. thanks.
–
auselenFeb 19 '13 at 15:15

In the general case, initial start up time should be as short as possible and only lengthened if a slower start up can significantly improve the responsiveness of the rest of the app after start up. This means less "jitters" and improved perception of speed after the initial load.

Gmail is a good example of an app that takes a bit to load first time, then is mostly very responsive after the initial load. (I'm talking about the web app moreso than the mobile one, since the web app happens to be a great, general case example of slow start up, fast run-time response) Gmail is a great app to allow a slower load time because of the follow attributes:

It's often open for a long time. Many will leave Gmail open in a tab, or go through very many emails at once, so the initial load time is less significant due to the extended session time

A user will generally navigate through many "pages" or bits of content in a single session

Gmail is complicated and it does a lot. It's not the particularly user's problem, but larger apps may take longer to load, and the more a user can do in an app the more they're likely to forgive it.

Compare this to a Camera app. A Camera app should loud as quickly as possible, and users are a lot less likely to be forgiving.

When I'm opening a Camera app, it's very likely I want to take a picture now. Sometimes I want the picture before I even took out my phone. There's no greater sin a camera app can commit than making a user miss a shot because it was still loading.

Camera apps are often used in short bursts. Most of us aren't professional photographers, we're just snapping a quick pic of our friends, or the meal, or that funny dog over there. We get in and out, so there's not too much to "eager load".

Note professional camera apps may have very different requirements; when taking multiple shots or tinkering with many settings, noticeable lag after start up will be a problem. That's not the get-in, get-out experience "lazy loaded" applications are usually good for

As for specific numbers, there's never a magic number or cutoff; temper your expectations. A faster than average app is usually preferable even if it's already below a magic cutoff, and an app may simply have to be slower than other apps or even slower than a common guideline. Only your users can tell you what's really too slow.

While there's no magic number, there's some good rough guidelines research has provided; KISS Metrics has a great article on How loading speed affects your bottom line though it's focused more on websites than apps (the lines between which are ever blurring).

One of the most important take-aways is that most mobile users would wait between 6-10 seconds for a page to load, while 47% of respondents expect pages to load in 2 seconds or less. Don't forget just because people are willing to wait X seconds doesn't mean they like waiting X seconds. For a native app I would tend to expect better performance of course, since that's based on mobile internet speeds. Also give a read to What is Slowing Down Your Mobile Apps? courtesy of Mervin's answer

Great answer,but considering that you wont have people accessing gmail through a tab in mobile,do you think that would be relevant or were you just giving an example?
–
Mervin JohnsinghFeb 14 '13 at 15:01

@Mervin it's just an example; plenty of Android apps work very similarly by operating as a "service" to stay hot loaded. I just couldn't think of any with a noticeable start up time like web Gmail.
–
Ben Brocka♦Feb 14 '13 at 15:35