

Apple's iOS is "deceptively fast" - xkcdfanboy
http://www.reddit.com/r/AskReddit/comments/uc6qy/reddit_today_i_was_reading_about_bose_thanks_to/c4u50kr

======
orta
One of my pet peeves is people saying this about iOS. What he says is a half-
truth, a mixture of two different features. ( Link TLDR: Apple takes a
screenshot of your app and shows it on launch )

What actually happens: When you background the app, Apple takes a screenshot
to do the fade-out animation with. This caused a bit of hubhub a few years ago
because if you jailbreak you can find the screenshot of the last closed app .

It's actually the developers job to give a launch image for the app itself,
and the apple guidelines are that you should aim to emulate your app's
homepage with no data in it. You don't have to, we don't at <http://art.sy> \-
Which isn't Apple taking a screengrab.

A simple way to think about this is, what happens if you open the app in a
different orientation a screenshot wouldnt work then.

~~~
celalo
I don't understand the technique at art.sy - It loads a lot of stuff when you
open a page for the first time but interestingly when you navigate for another
page, it does not seem to be loading anything except for a 1x1 gif. How come
the URL changes (full change not just like hashbangs) but nothing particular
is loaded from the server? Is there a name for this technique? Is there any
framework supports this?

~~~
TazeTSchnitzel
HTML5 history.pushState

~~~
udp
I still don't understand why Twitter doesn't use that where available.

~~~
scott_w
Because when Twitter started, pushState wasn't available to them. It will take
time to transition over, and to fully deprecate hash bangs.

(Hash Bangs were still the wrong way to do it of course, even back then).

------
vibrunazo
I have an opposite example. My father built a cryptography software in the
80's. Some of his clients complained that the app felt too simple and cheap
for the price they were paying. So my father added a timer so the app would
wait a few seconds pretending it's working. Just so the whole process would
take longer. No one ever complained about the app feeling cheap again.

Which reminds me of the incredibly bloated software by Adobe and Autodesk.
When compared to Blender.org which opens and runs dozens of times faster on
hundreds times less memory. For a full featured product. I can't count how
many times I've heard that blender feels worse than maya only because it's
faster and free.

~~~
samwilliams
This really is an excellent observation.

I have often wondered whether this feeling of software being insubstantial
slows down the propagation of FOSS in general? People seem to feel they are
getting less of a tool when they can download something for free and don't
have to wait for it to perform tasks as they would with larger, more bloated
works.

This may be a little off topic, but I wonder how much of this phenomenon is
born out of consumerism? We are used to having to wait or forfeit other
luxuries in order to gain access to high quality things, so when we are
presented with an excellent, free solution our perception of it is
automatically jaded by our beliefs? Is this international?

~~~
mattgreenrocks
It's a stretch to automatically call FOSS well-optimized.

But I think you're right with the perception of powerful = slow to start.

~~~
samwilliams
Sorry, I didn't mean to imply that FOSS was neccessarily optimised at all, I
just meant the programs that were.

------
dexen
Using a screenshot is no cheat. The screenshot is an useful visual cue for
user, helping her grasp the GUI as soon as possible, and direct her finger
towards the right widget to be clicked. App loading becomes asynchronous, with
user able to (start to) perform meaningfull navigation very soon. The user
thus makes a good use of the screenshot.

I'd like to put similar feature in my HTML/JS application. [[EDIT: a web-
application for desktop computers; no relation to iOS]]

Currently in my app, any click that pops a new dialog waits for server to HTTP
reply and only then draws anything on the screen. What I'd like to have, is to
show the dialog right away, with empty fields at first, and inject contents
once it arrives from the server. The idea being, the user can grasp the GUI
and start moving mouse cursor to the right widget a bit earlier; i.e., less
wait after the click.

Btw., Nokia N900, with Maemo Linux, behaves exactly like iOS in that regard --
shows app screenshot very quickly, and loads the app in background. It shows
clearly on XTerm app, for example.

~~~
Jare
The screenshot thing is very disconcerting in HTML webapps: when you click on
the app to go back to it, you are shown the screenshot and think you can
interact with it, but the webview and app are then (visibly) cleared and
reloaded. It looks and feels horrible. I'm not sure if there are ways to
improve this with their meta tags.

~~~
notjoeflynn
You can specify apple-touch-startup-images that load on web app startup. These
ideally consist of your app's chrome with any dynamic or textual elements
removed.

[http://developer.apple.com/library/ios/#documentation/userex...](http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/IconsImages/IconsImages.html)

------
simonsquiff
One similar anecdote I really like is what happened with diesel cars. You used
to have to wait when starting the engine for it to ‘warm up’ and drivers
obviously didn’t like that. Now you don’t have the wait. They actually hadn’t
reduced the warm up time. What happens now is the warm up starts when you
unlock the door, not when you try to start the engine! So by the time you go
to start the engine it’s already done – to the driver there is no warmup time.

~~~
wazoox
Hum, I call BS. Direct injection reduces greatly the need for warming up, and
almost all modern diesel engines come with direct injection.

~~~
simonsquiff
I'm not saying this is the only reason for the lack of warm up (especially
today), but it was a significant part of the perceived reduction from old
diesels. It's also why if you put petrol in the car by mistake, you can still
ruin the engine even before you've turned the ignition (as opening the door
starts the warm up and fuel pumps etc)

~~~
wazoox
Modern car aren't actually completely on or off when you turn the key, sure.
However I've put petrol by mistake in a diesel car twice and didn't ruin
anything (but lost some money cleaning the mess up).

------
TazeTSchnitzel
Microsoft have been using deception to make Windows (and now Windows 8) seem
faster for years. Windows XP went very quickly to the desktop, but it could
take a whole minute (or on very slow machines, several) for it to fully start
up.

Windows 8 is full of animations, to disguise latency.

~~~
gaius
Ahem, take a look at your Linux startup - does or does not getty start before
all other daemons?

~~~
Inufu
Yeah, but my Linux systems always start way faster than my Windows systems -
even though I hardly use the Windows ones and haven't installed much.

~~~
gaius
Irrelevant. The truth is, both OSs are designed to give you a basically
usable, interactive system before all startup tasks are finished. There's no
reason not to this since it doesn't matter if you get a shell prompt before
e.g. sendmail is started - even if you manage to write an email in the interim
period, it will simply be queued until sendmail is started. But it's not a
"deception" when Windows does it; everyone does it.

Imagine a car that didn't let you drive until the aircon had reached the
desired temperature...

------
Lerc
For user experience, perception is everything. Making the user not experience
latency is as good as not having it.

'course this ultimately will mean one day we'll all just be brains in a big
vat fed drugs directly by Apple, but trust me, that'll feel awesome.

------
ilitirit
Semi-related note:

On its own, the title is ambiguous.

<http://public.wsu.edu/~brians/errors/deceptively.html>

I'm also not sure why "deceptively fast" is in quotes because it's not
contained in the linked post.

------
josteink
Chrome for Android has "learned" this lesson too. And you can tell when
launching a link with Chrome set as the default browser.

The Chrome UI (Chrome) will load _instantly_ and then it will sit there idly
and do nothing and be irresponsive for a few seconds before it wakes up and
starts loading the page.

Actually Chrome is pretty slow, but it is deceptively attempting to give the
impression that it is fast.

It's gotten on my nerves to the point that I have replaced it with Firefox
beta as my new default browser.

I general I oppose tricks like this. They are annoying and counter-intuitive.
Most users will probably wonder why the UI which is present on screen is
irresponsive, etc. Having a loading-screen or showing that you are _not ready_
is much better than lying.

------
dalke
Jef Raskin's "The Humane Interface" describes this techniques applied to the
Canon Cat UI he designed in the 1980s. This parallelizes the time for users to
reestablish the mental context with the time needed for the software to
restore its own context.

------
bambax
Relevant TED talk: Rory Sutherland -- Perspective is everything

<http://on.ted.com/BygC>

------
alexyoung
This is well documented in Apple's developer documentation and can be
overridden with a custom loading image:

> When the system launches an app, it temporarily displays a static launch
> image on the screen. Your app provides this image, with the image contents
> usually containing a prerendered version of your app’s default user
> interface.

\- App Launch (Default) Images: <http://bit.ly/LMLbu0>

It's been this way for close to 5 years now.

~~~
sil3ntmac
Er, almost. Your app provides a "Default.png", which is shown at initial app
launch. This often contains either a loading image or a prerendered screenshot
of your app with a blank state. However, since iOS4 and "backgrounding" (which
imho is a better example or using hacks to give the appearance of speed),
Apple will also dynamically snap a screenshot of your app at the time you
close it, so that re-opening it feels instantaneous and more like "switching"
to an app.

------
mistercow
There's a related trick I've recently begun using with progress bars which I
plan to turn into a little JS library when I have time. Basically, watching a
progress bar fill up makes time pass quickly, but making short-lived progress
bars update asynchronously is a huge waste of time. You can use a spinner, but
that's less effective. Alternatively, you can make the bar fill in a fixed
amount of time, which is a problem if the operation takes longer than
expected, because staring at a _full_ progress bar makes time seem to pass
even _more_ slowly than nothing at all.

The solution I found was an exponential fill. Say you estimate an operation
will take 4 seconds (this can even be hard coded). You show a bar that starts
empty, and after 2 seconds, it is halfway full, after 4 seconds, 3/4 full, 6
seconds, 7/8, and so on until the operation completes and the bar disappears.
That way, you never end up paused on a full progress bar, and you are still
conveying a reasonable estimate to your user, and you never have to write
another line of code to update a progress bar.

~~~
Kesty
We did something similar for a search webpage. But with some query it could
take too much and the slowing down of the bar filling wasn't well met with
both our users and our boss.

We changed that with bogus writing under the progress bar. The first bar had
"searching" under it, and usually that was enough.

If it was still searching after the bar was at 100%, the bar would start the
animation again and we would change the text with random stuff like ("building
indexes","fetching images","generating tables",etc...).

~~~
mistercow
> with some query it could take too much and the slowing down of the bar
> filling wasn't well met with both our users and our boss.

One idea I've toyed with, which adds some complexity, would be some random
variation, so that you'd still get some faster jumps at the end, even though
the average would be exponential.

------
jpalomaki
I would argue that a lot of iOS smoothness feeling comes from the simple fact
that somebody implemented a blazing fast routine for panning/zooming a static
bitmap on screen based on touch input.

For example on web browser you don't need to constantly re-render the page
when user is dragging or pinching. Just move around and zoom the static image.
Once user let's go, then you redraw the page.

------
fredsted
I assumed everyone knew this. It's pretty obvious in the Clock app, for
example.

------
Splines
Sometimes it's the simplest things that are the most effective.

It's easy to over-engineer a solution to this problem (let's freeze-dry the
application when the user left, or, the user has a pattern of launching this
app after that one, let's warm it up for them just in case, or, the user
always launches this app when turning on their phone at 8 in the morning, etc.
etc.)

------
jakejake
I've always suspected that OSX (and so iOS as well) was loaded with little
tricks like this to give the perception of a really snappy interface. I've
suspected these kinds of things were built in at the very lowest graphics
levels which is why Apple devices graphics always seem so smooth compared to
other brands.

Coming from windows, I always felt like when I dragged a window around that
the buttons were likely to fall off! On OSX it's so smooth that I suspected
they did things like take a screenshot while the window is in motion and use
blurs, etc, so that all of the objects are not moving independently. I'm not
sure that's actually true but what is obvious is that Apple has always been
very obsessive about using visual tricks to make the UI seem very responsive
and smooth.

------
ralfd
Reddit… How can you read these flamewars without getting incredible agitated?
_rage_

I like that hacker news is relatively free of that. Or at least I try to stay
clear of every "Google is evil / no Apple is evil / have faith in Microsoft,
they are still the evilest" threads.

------
conradev
The only reason a screenshot (or a default image) is used is because of the
way applications are launched. They expand from the center of the screen, and
the image expanded cannot be a live view of the application. This is opposed
to Android, which uses a fade animation to launch applications (at least on
ICS).

It is not deceptive, it is smart. Android applications appear to have a delay
in launching because there is a moment of inaction after tapping an icon.
Apple made it so that immediate action is taken after an icon is tapped, and
that does make it more responsive.

------
maxharris
But it's not a trick. It's a seamless way of being responsive. If it flashed a
loading message every time an app was started, the user would know that their
selection was registered by the phone, but the result would not be seamless
like Apple's ingenious solution.

A loading dialog that flashes on the screen for a second would be annoying,
and the phone wouldn't be as good that way.

------
jiggy2011
This is a symptom I feel of people getting hung-up on specific "quality" or
"performance" indicators.

For example, for years people would judge the quality of a car by the "thunk"
sound on closing the drivers side door.

Now car manufacturers have teams of people who engineer that specific sound
(same with exhaust noise).

See also weights inside speaker cabinets.

------
GBKS
Perception is reality, and this applies to the smallest details. For example,
most apps use a rotating circle spinner to indicate that it's busy doing
something. The speed at which the circles rotate can make you feel like the
app is working it's but off for you, or it's dragging it's feet.

------
nivertech
Apple's trick: fast GPU, but slow CPU

------
ImprovedSilence
A few years ago I interviewed with a company that made high end blu-ray
players. They sold them for thousands to people with private jets and
penthouse suites. It was a normal blu-ray player, but they put weights in it
so it felt "solid".

------
hollerith
Example: the progress bar shown by the Mac's "Software Update" has no
particular correspondence to reality.

(The progress bar shown when copying a big file OTOH is accurate.)

~~~
ralfd
Are you sure? I always thought OS X would just go through the installed .pkg
packages and check for new versions on Apples Servers, which would make it
easy to have a sense of the tasks done and ahead.

The 10.5.3 Update also has a release note about the progress bar:

"Improves the accuracy of the Software Update progress bar indicator."

[http://support.apple.com/kb/HT1141?viewlocale=en_US&loca...](http://support.apple.com/kb/HT1141?viewlocale=en_US&locale=en_US)

~~~
hollerith
Well, it's still pretty useless for predicting how long the update will take
in 10.7.4.

~~~
ralfd
Oh, well. That is true. ^^

------
gouranga
Very true.

I find actually find that iOS quite laggy after using WinPhone for a bit. It's
obvious a fair amount of crap is hidden behind pretty graphics in iOS.

Conversely, if WinPhone is doing something, it makes you aware of it up front
by making you wait. To put that point in perspective before everyone blows and
says "WinPhone is shitty", it's done that only TWICE since I got the phone 3
months ago and both times were after the only two reboots the phone has ever
had. Apart from that, EVERYTHING is instant.

I want it now and get it now with no illusion!

------
its_so_on
I disagree completely with the analysis and with the conclusion. As I posted
there:

" Sorry, you are completely wrong to object, _since it actually is faster_.
You said it yourself: you notice the trick when an app is exceptionally slow,
you can't interact when you're ready to. That means in every other case you
get to 'begin using' immediately. Interaction isn't only pressing something.
It's also processing and deciding what to do. If Adobe Photoshop spit out a
fake blank screenshot instead of the splash screen, you could start to think
of what tools to use and what to do with them. This is part of using the app.

I mean, by your argument the screen might as well be blank except when you're
moving the mouse, clicking, or typing. Since seeing the interface when you're
not using it actively isn't part of using the app.

But that's obviously wrong, and obviously a non-blank screen is part of 'using
it.'

Recap.

Current photoshop

1) For x seconds: Loads... I get to read some credits instead of being able to
look at the app's interface.

2) For another y seconds: I stare at the interface deciding what to do.

3) For another z seconds: I am taking my first action

4) after a small processing time (p) the action I first took is completed.

In the splash screen scenario, the time until my first action is completed is
defined by x + y + z + p . But by putting up a fake image you can reduce the
time to y + z + p, eliminating the extra time from x entirely! (or at least
eliminating as much of it as is covered by y. Y is almost never exactly zero.)

It's that simple. Faking the first screenshot is ALWAYS faster, unless you're
not a human but a computer script that takes an action 0 milliseconds after
the interface is put up.

Every app should put up a screenshot while it loads!

Or even a bit more than a screenshot!

Clicking the "Firefox" icon should instantly (notepad.exe speed) bring up a
fake window. Then you can slowly mosy your mouse over to the URL tab or the
Google search tab, and slowly start typing where you want to go first. By the
time you hit enter, hopefully firefox has really loaded.

It's just two little input tabs. Why not fake them for awhile?

The App screenshot trick is similar. I approve completely*.

------
franzus
> This looks to the user like the app actually starting, but what they've
> really done is buy themselves several seconds of load time.

I don't know what's so bad about that. We (programmers) have been doing this
stuff since beginning of time. Caching is nothing different than what he
describes and calls it deceptive.

As long as there's an impression of speed and the user doesn't actually feel
like he's waiting too long everything is fine.

For our current project we render views into images and animate transitions
between those images and not the views itself. Only to make it look more
smooth and speedy. And I still can sleep at night :)

------
chj
I am immune to this trick. Still feels slow if it doesn't response to my
actions. And even worse, I feel cheated. The cpu should be doing what is
important, not loading a useless image.

