A Rant Against Splash Screens
An anonymous reader writes "This controversial post by Adobe's Kas Thomas asks if splash screens are just a sign of program bloat and callous disregard for users. It suggests that big programs should launch instantly (or appear to), perhaps by running against an instance in the cloud while the local instance finishes loading. Users of cell phones and tablets are accustomed to apps being instantly available. This is the new standard for performance, the author argues. Nothing short of it will do, any more."
Adobe complaining about bloat?
Kettle, meet blackhole.
PlusFive Slashdot reader for Android. Can post comments.
And most of the apps I use on it have splash screens...
Don't you mean perhaps run against a local instance until the so-called cloud loads?
Are you saying that Lotus Notes MIGHT BE "bloatware"?
It really bugs me when a webpage take forever to load because it's waiting on ad servers to dish up a new ad
Why can't they write there pages to load the ads last so you can read the page while the ads load?
http://Lenny.com
4 great justice!
You can e-mail the CEO of Adobe at snarayen@adobe.com (to tell him to keep me or fire me).
But on the other hand, I wonder if he was aware of the network problems some of his proposed solutions represent. Surely, he must realize that "Run my gestures against an image in the cloud" amounts to increased network traffic. Don't even get me started on the privacy of those "gestures." Let's say you open up Photoshop to edit some 12 megapixel family pictures immediately. Are they transferred to the cloud in the process? And transferred back? Who has the network to do that faster than just loading to main memory with CPU cache? This increases what Adobe must now host as far as server farms and will, probably, raise the price of Photoshop in doing so. And, you know, it's already too expensive for me. Furthermore his post rails against "bloatware" but it's not like hosting this out on the cloud is going to make the application any less bloated. On the contrary, it can only make software more intricate, bloated, buggy, susceptible to attack, expensive, etc. Furthermore are there any users out there that are stationed on top of an internet backbone on Google's campus that could even take advantage of this additional functionality? Perhaps decades into the future this will be reality but until the infrastructure catches up to your consumers, this is a logistical headache.
..." ad infinitum while we're still concentrating on minimizing highway deaths. He's probably sitting there with the latest iPhone asking why everything doesn't run like this but I have coworkers that are complaining about the latest iOS 5 updates to their older iPhones and all the problems associated with it. Good luck with pushing that "instant on" standard to all hardware out there man, I really will be amazed if you pull it off.
As a developer, this all sounds very much like a two year old prattling off "and then I want a hover board, and then I want a flying car, and then
My work here is dung.
Four things:
1) Launching an app from the cloud isn't going to be faster. Hell, many of those apps already use a modal web dialog that essentially acts as a splash screen while all the Javascript bloat sent down to the client gets its defecations together.
2) Angry Birds has some of the worst launch time that I've ever seen - and it's a top tablet and phone app.
3) Adobe, you want disregard for users? Try your stupid EULA clickthrough every time a new version of your PDF reader comes out.
4) Try a usability test in an app without a splash screen some time. What you get is poor end users clicking (launching) the app multiple times because it looks like "nothing's happening". The splash screen is an "ack" at the usability level - "yep, we're launching the app!" As long as it's not modal and the wait isn't long (e.g., the user can go finish surfing on his browser during the 10-15 seconds the apps loads) then there's usually no problem.
The author of this article is an asshole who doesn't understand how computers work. To paraphrase him: "I want it, and I want it now. Period. PERIOD." Sometimes even with computer technology as advanced as it is, applications need time to load. A splash screen says "Don't worry Mr. Computer User, this program has successfully launched and is now loading." Without the splash, you'd sit and wonder if the program was loading or not... and then probably launch it a second time before it was finished loading, further slowing the process.
Loading . . .
First post!
Ah, nuts
How about - now call me kooky - using some of the massive parallelism that desktops have been shipping with for the last half-decade? Launch background threads to do your resource loading; ensure that your main UI thread is doing as little blocking work as possible? You know, all the "tricks" that have been around for ages, but fell into disuse until mobile platforms became mainstream?
What kind of diseased mind thinks that the answer to a slow-loading client-side app is to connect it to a cloud instance, thus introducing external dependencies and unpredictable network latency?
Splash screens were originally designed to let you know the program was launching, so you weren't sitting there wondering "is it opening or not". Now, some splash screens are unnecessarily intrusive, particularly those that require you to click (or press enter) before they disappear and allow you to use the software.
The real problem is lack of responsiveness. The author points to that in his proposed alternatives, but he's misplaced the blame. For interactive processes, response time is more important than speed. 0.1 seconds is essentially instantaneous for most tasks, that is, the user won't notice that little delay. Games are an exception to that. 0.25 seconds starts to become noticeable, but it it's only occasionally that long, user's will barely notice. 0.5 seconds or longeer is noticeable in almost all instances. Any process that takes over 0.25 seconds should display some form of busy indicator or a progress indicator.
make imaginary.friends COUNT=100 VISIBLE=false
They are good for really long processes (OS or window-system startup, game loading), because they give confirmation that something is really happening. However, they have to have progress bars or at least something (I like KDE's system with icons) by which you can tell how far it is.
However, I have noticed a recent trend towards splash screens with an endless loop and no connection to what's actualy happening. Window 7 has such a screen, so does Ubuntu. This is something I'm very annoyed by, because I always think it's complete before it actually is.
PlusFive Slashdot reader for Android. Can post comments.
The author complains about various things. He may have a point with some of them, but some are just ridiculous. For example, he mentions how it takes X amount of time to boot up his laptop, but his phone starts "instantly." I am 100% sure that his phone does not start up instantly from a reboot. Rather, his phone is simply on the vast majority of the time. The more complex the application, the longer it takes to prepare to run. I know numerous applications on both IOS and Android that deliver a splash screen while they load up. Many of these are games or similarly graphic intensive applications (comparative to other more "utility" focused apps). Or if they do not have a splash screen, they deliver no useful function while the data is loading. Ever started up google maps or something similar, and seen your position sitting there on a completely blank field for five or ten seconds? While I agree that perhaps splash screens/load times should be more streamlined as a whole, this "zero load time" environment that he purports to enjoy with phones and tablets simply does not exist.
Attempts to fix this problem usually seem to take the form of some abysmal hack to keep the program in memory when not in use. There's one of those memory hogs for OpenOffice, Microsoft Office, Photoshop, and Java. (Java's "jqs.exe" is particularly wasteful of resources. It tries to keep the whole Java environment in memory, deliberately causing page faults, even when there's been no use of Java in hours or weeks.) This is one of the reasons it seems to take gigabytes of memory to do anything today.
Nobody thinks much about linkers any more. That's part of the problem. What's needed is something that organizes the executable file so that the stuff you need to get going loads first, using one big read operation. Linkers which once did that were once common, but are now rare.
Then there's the DLL/shared object problem. Many programs need only a small part of some shared library, but requesting it either brings in the whole thing, or it gets loaded one page fault at a time.
Much of the problem is just bloat. Adobe's PDF reader (which is now unnecessary, since there are good alternatives) takes far too long to load for what it does. Most people don't need the text to speech system, or "WebBuy" (electronic commerce in PDF, a feature used by nobody), yet each adds a noticeable delay to startup.
Hooking something up to the "cloud" makes it worse. Then you get to wait for the server.
I don't mind splash screens, but I HATE HATE HATE splash screens that insist on always-on-top. Let me launch the app and then go back to what I was doing while it loads. When you force always-on-top, you're basically saying "Stop everything you're doing and look at me for 30 seconds!"
"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
I agree that putting up a full screen graphic that looks like your loaded app can just be a gimmick cell phone manufacturers prefer to give the *illusion* of performance. There is no harm in showing a splash screen rather than the fake user interface. The splash screen serves your interests, the fake user interface serves the cell phone manufacturer's interests. Serving your interests rather than the manufacturer's does not harm the user, **unless** you do something like introduce a delay to force the user to see your splash. And as you say apps should delay loading of resources to minimize their startup time.
In a calculator app (RPN scientific statistics business hex) that I've developed the screenshot that I use was converted to gray scale and dimmed to suggest the buttons are not enabled. My splash is just a product name and copyright notice and I put that in the standard numeric display. The user experience is an instant but disabled user interface with a copyright notice, the notice is replaced with numerics as soon as the interface is enabled. There is no artificial delay. Splashes can be done is a reasonable and honest (UI has a disabled visual appearance) manner.
Fucking modal windows don't have any place in an application.
Fucking having to cancel out of a modal display to copy-paste what you wanted into it because it didn't happen to be in your clipboard.
The modal option need to fucking die; if your shit required modal, you've fucking done it wrong.
Developers and marketoids have abused that option for too long and they need to have their toy completely taken away.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.