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 )<p>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 .<p>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 <a href="http://art.sy" rel="nofollow">http://art.sy</a> - Which isn't Apple taking a screengrab.<p>A simple way to think about this is, what happens if you open the app in a different orientation a screenshot wouldnt work then.
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.<p>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.
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.<p>I'd like to put similar feature in my HTML/JS application.
[[EDIT: a web-application for desktop computers; no relation to iOS]]<p>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.<p>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.
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.
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.<p>Windows 8 is full of animations, to disguise latency.
For user experience, perception is everything. Making the user not experience latency is as good as not having it.<p>'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.
Semi-related note:<p>On its own, the title is ambiguous.<p><a href="http://public.wsu.edu/~brians/errors/deceptively.html" rel="nofollow">http://public.wsu.edu/~brians/errors/deceptively.html</a><p>I'm also not sure why "deceptively fast" is in quotes because it's not contained in the linked post.
Chrome for Android has "learned" this lesson too. And you can tell when launching a link with Chrome set as the default browser.<p>The Chrome UI (Chrome) will load <i>instantly</i> 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.<p>Actually Chrome is pretty slow, but it is deceptively attempting to give the impression that it is fast.<p>It's gotten on my nerves to the point that I have replaced it with Firefox beta as my new default browser.<p>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 <i>not ready</i> is much better than lying.
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.
This is well documented in Apple's developer documentation and can be overridden with a custom loading image:<p>> 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.<p>- App Launch (Default) Images: <a href="http://bit.ly/LMLbu0" rel="nofollow">http://bit.ly/LMLbu0</a><p>It's been this way for close to 5 years now.
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 <i>full</i> progress bar makes time seem to pass even <i>more</i> slowly than nothing at all.<p>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.
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.<p>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.
Sometimes it's the simplest things that are the most effective.<p>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.)
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.<p>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.
Reddit… How can you read these flamewars without getting incredible agitated? <i>rage</i><p>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.
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).<p>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.
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.<p>A loading dialog that flashes on the screen for a second would be annoying, and the phone wouldn't be as good that way.
This is a symptom I feel of people getting hung-up on specific "quality" or "performance" indicators.<p>For example, for years people would judge the quality of a car by the "thunk" sound on closing the drivers side door.<p>Now car manufacturers have teams of people who engineer that specific sound (same with exhaust noise).<p>See also weights inside speaker cabinets.
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.
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".
Example: the progress bar shown by the Mac's "Software Update" has no particular correspondence to reality.<p>(The progress bar shown when copying a big file OTOH is accurate.)
Very true.<p>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.<p>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.<p>I want it now and get it now with no illusion!
I disagree completely with the analysis and with the conclusion. As I posted there:<p>"
Sorry, you are completely wrong to object, <i>since it actually is faster</i>. 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.<p>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.<p>But that's obviously wrong, and obviously a non-blank screen is part of 'using it.'<p>Recap.<p>Current photoshop<p>1) For x seconds: Loads... I get to read some credits instead of being able to look at the app's interface.<p>2) For another y seconds: I stare at the interface deciding what to do.<p>3) For another z seconds: I am taking my first action<p>4) after a small processing time (p) the action I first took is completed.<p>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.)<p>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.<p>Every app should put up a screenshot while it loads!<p>Or even a bit more than a screenshot!<p>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.<p>It's just two little input tabs. Why not fake them for awhile?<p>The App screenshot trick is similar. I approve completely*.
> This looks to the user like the app actually starting, but what they've really done is buy themselves several seconds of load time.<p>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.<p>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.<p>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 :)
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.