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.
The poster is right, iOS takes a screenshot and uses it when switching to your app. The default.png is used only when you first open the app (ie, it was closed).
What happens when you switch orientations? The screenshot/app will show as rotated and rotate to whatever angle the device is currently at.
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?
Sorry, I should have been more specific, I meant for the art.sy iPad app! A lot of what the website does is black-magic (or backbone js -whichever) to me :)
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.
I once worked in a company where one of the teams was working on a large database indexing routine for a client.
The whole thing took a couple of seconds to run, even with a live data set, which was perceived by the account manager as "too fast" - basically not worth the amount the customer was paying as it was seen as doing too little, so a 30 second delay was implemented in the routine. Did nothing, just waited 30 seconds. Account manager happy, software delivered, client happy.
A couple of years later one of the team, now a contractor was asked to help the client optimise the system as with the increased data volumes the indexing routine was now taking closer to a minute to run.
I don't even want to think what he charged them for the 30 second performance improvement he managed...
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?
I don't think it has much to do with consumerism, but rather how your perceptions shape your expectations. If it is 'difficult', we expect it to require a relatively increased amount of effort (see: time) to complete. This is only heightened when the task is something we are unfamiliar with, and have no idea how it should work.
For example, encryption - I, and apparently the people in the above example, have little or no understanding about how it works at a fundamental level. So if I was having something encrypted I would expect, due to ignorance and having it's difficulty on a pedestal, that it would take a reasonable amount of time to complete - certainly not instantaneous.
I think this idea applies to everything, not just software. If you paid $10k for something you probably will consider it valuable and treasure it. Even if there are better alternatives out there you're likely to have some emotional attachment. You put in research before investing that much money and you're likely to rationalize and defend your decision to purchase it.
Whereas when you get something for free you obviously have no financial investment. You can just throw it away without any care or feeling of loss. You're likely to perceive it as having no tangible value at first. The more time and resources you invest into that the more you will start perceiving the value.
I had the same thing happen with a site that did searches for, lets say hotel deals (not really but same idea). At the time expedia and all of the other competitors searches took a while with a loading page displaying for several seconds. But since their data was pulled in and cached locally the searches were as fast as any normal page load. They thought it seemed too fast compared to the industry and that people wouldn't trust it. So we stuck in a transitional loading page that lasted a few seconds.
Neither here nor there, but FYI in English "software" is typically partitive and not denumerable, i.e. you should say "some cryptography software", or else something like "a cryptography program" or "a cryptography application."
wasn't there an article saying they had to do the same with the face unlock for android? they had to delay it's action because it was too fast to seem it was actually working.
>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.
I don't know about Autodesk. This "bloated Adobe software" meme doesn't hold though. Try opening a 200MB to 1GB image file in Photoshop and any competing editor. See which one will crumble. See which one will perform actions on the image faster.
PS may have UI bloat (custom flash panels, for one) and feature bloat, but it's a very performant and stable application for what it does. It does not have "memory" bloat. Most of the size of the app is assets (icons, vectors, fonts, templates, etc).
As for the actual code, if you don't use a feature the code isn't even loaded in memory --the OS does that automatically for any app.
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.
Especially true with new users as they flick between several apps quickly to transfer or gather information. (Such as phone numbers and addresses.) There is often no immediate need to manipulate the screen, but there always a need to see what is on it.
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.
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.
What if they were to desaturate the screenshot to give it that 'disabled' look and/or overlay a 'loading' caption? It would be less deceptive - the user would be able to distinguish it from the app being ready for interaction while still familiarizing themselves with the UI so that they can immediately take action once it's ready.
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.
That story reminds me of something I did for a classical music e-commerce site I was working on. I needed to update the ID3 tags on MP3s and FLACs when the user downloaded an album (I couldn't do it in advance as a batch - arcane nonsensical licensing rules w/ storing digital content).
The problem was that it took too long to modify the files when the user clicked "download" after completing their purchase - they had to wait as the ID3 modifier chugged away doing its thing. So instead of waiting for the user to fill out their CC data and complete the sale, I started updating the ID3 tags as soon as the user put the MP3s into his/her shopping cart and cached the result. It didn't really matter much if the cart got abandoned, but the files were all ready for the customer once they got done checking out if they made the purchase.
On a similar note, the image sharing site min.us[1] will display your local copy of the image you wish to upload in place of the uploaded image as it is uploading. Gives it a feeling that it uploads absolutely instantaneously, even though it also gives a real progress bar.
By warm up he's talking about the pre-heat system that helps diesels start when they are cold. Diesel engines ignite fuel by compression heat alone, there are no spark plugs. When it's cold, they can be harder to start. Two approaches, one is to heat the intake air with a heating element in the intake, the other is to have a glow plug (heating element) in each cylinder. Once the engine is running those pre-heating devices shut off.
With a diesel car, it's better to not let them "warm up" after starting... diesels don't warm up very quickly if they are not under load and they will accumulate carbon and parts will wear more if you let them "warm up" at idle after starting.
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)
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).
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.
It's a well-known technique used by a lot of products. Github, for example, has a little "slide-in" animation of when you click on a folder in a repo to achieve the same latency masking.
I don't think this should be seen as a negative or bad thing. But it should put things in perspective for those comparing the "performance" between different platforms and OS's.
Another similar example is how Apple doesn't show a pop-up message when an app crashes in iOS, while Android does (Force Close), which makes people think Android crashes a lot more when they keep seeing these Force Closes, even though there have been some reports saying that iOS apps crash more often than Android apps on average. But the perception matters a lot more.
Although in some ways the quick to desktop thing in XP actually achieves the reverse - it creates the impression that you spend a long time waiting for the Windows GUI rather than the one-off boot process, which might have been a better scapegoat for them.
They made that decision back when people expected to reboot at least daily, and "shutdown at night" was still current advice. It could have gone either way, I guess.
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...
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.
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:
> 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.
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.
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.
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...).
> 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.
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.
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.)
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.
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.
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.
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.
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".
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."
One change I noticed about that (although I couldn't pin-point the time/version) is that updates download in the background if you choose to defer the update, as opposed to during the update itself.
It took me a while to realise why my updates were going much faster than they used to.
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 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*.
> 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 :)
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.
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.