Be careful that your splash screen doesn’t squander the foreground love


Commenter Erbi has a program which creates a splash screen on a background thread while the main thread initializes. "I create and then destroy this splash screen window just before creating and displaying the main window." The problem is that the main window fails to obtain foreground activation. Commenting out the code that creates the splash screen fixes the problem, but then there isn't a splash screen any more (obviously). "Is there an explanation for this behavior?"

This behavior is explained by two earlier blog posts, plus a PDC talk. The first blog post came out years before this question was asked: The correct order for disabling and enabling windows. Destroying a window is a rather extreme case of disabling it, but the effect is the same. When you destroy the splash screen, foreground activation needs to move to some other window, and since your main window isn't around to inherit it, foreground activation leaves your program. When the main window appears, it's too late.

The PDC talk came next, followed shortly thereafter by a blog post version of the same talk. As marketing folks like to remind you, "You get only one chance to make a first impression." Similarly, you get only one chance to use your foreground activation permission, and you decided to blow it on a splash screen. That's fine as far as it goes, but if you want to transfer that permission to another window, you have to manage it yourself. The recommended way is to establish an owner/owned relationship between them; that's the case that the "disabling and enabling windows" article focuses on.

Comments (37)
  1. Anonymous says:

    Or just don't use a splash screen. Bonus points if your splash screen is Always On Top and doesn't add anything (like, for example, showing which modules are currently being loaded) … and even then.

    Nobody. Needs. Splash screens.

  2. Anonymous says:

    @Marquess: I don't agree. I've seen many people click on an app, click again, click again, until something happens. It can be even more true on netbooks that are not exactly fast to boot apps. For those people, showing something ASAP is akin to the system saying: got you, look the app is starting.

  3. Anonymous says:

    @Marquess: Given the alternative (nothing visible happening for 15 or 20 seconds) I think I'll take splash screens.

  4. Anonymous says:

    @Marquess

    While I agree that most splash screens are annoying, it seems in this case the person is trying to use them correctly. I don't mind a "loading" splash screen as long as it is run in a different thread. If the program takes >2-3 seconds to launch its main window, the splash screen can provide immediate feedback that the launch was successful, but hasn't finished yet.

    The worst splash screens are ones that wait on a timer, then after begin loading the rest of the program.

  5. Anonymous says:

    "The worst splash screens are ones that wait on a timer, then after begin loading the rest of the program."

    Ah, yes.  The dreaded request from management: "we spent $5000 on the graphics for this splash screen, and you've made the program start so fast it's only visible for half a second… can you slow it down a bit?"

    <sarcasm>Not that that's ever happened to me.</sarcasm>

  6. Eckankar says:

    Splash screens are good for showing that something is indeed happening, agreed, but I could do without the inexplicable desire that the application designers have to make them "Always On Top", as Marquess points out.

  7. Anonymous says:

    We are preparing to put back the splash screen.

    This time it will be in the shim-check for updates process that spawns the main one so the splash screen doesn't show so late in the load anymore.

  8. Anonymous says:

    I'm not buying it. Splash screens, by their very existence, slow down the application start, especially via Remote Desktop. And it's not the user's job to check if the app successfully started. Later instances can easily check if they are already running and immediately terminate (there are very few programs which actually need to allow several instances of themselves).

  9. Anonymous says:

    @Marquess –  and what if it was a program that the user could legitimately run 2 instances of?  And what if the user actually did wish to run 2 instances of it?  Congragulations – you've just thrown the user out of something that they actually wanted to do.

  10. Anonymous says:

    @Marquess

    And I hate programs which do not allow me to open several instances.

  11. Anonymous says:

    @Jules:  Although I'd rather fake a delay than do what my previous company did, where they added a splash screen on an app but still let it start practically instantaneously.  So then all the splash screen did was obscure the window that was available and ready to go, but you couldn't start using it for a few seconds until the splash screen went away.

    Drove me nuts.

  12. Anonymous says:

    Programs that have a legitimate need to run in several instances better have a small enough footprint to start quickly. Others would be better off with a command line switch and/or passing a message to the already running instance (which would not process it until it has already displayed it's main window).

  13. Anonymous says:

    @Marquess: "Programs that have a legitimate need to run in several instances better have a small enough footprint to start quickly."

    How does that follow?

    Imagine a 3D rendering application, maybe it's a little older and not multi-threaded properly. It could easily need a long start-up time (loading models, textures, etc.) and also multiple instances (a modern user taking advantage of their multi-core processor.) I think you're making unwarranted assumptions.

    In general, I feel:

    1) Splash screens are fine, if you're already tried and failed to make your UI appear instantaneously

    2) Unless the user's focus is stolen when the main window appears

    Nothing makes me madder than a program that steals focus.

  14. Anonymous says:

    “Imagine a 3D rendering application, maybe it's a little older”

    Problems that require a time machine to solve are not conducive to this discussion.

  15. Anonymous says:

    Fortunately many if not most programs allow you to disable the splash screen. I disable them routinely, but I can see that some people might like it, as mentioned by the other commentators.

  16. Anonymous says:

    @Marquess: "Programs that have a legitimate need to run in several instances better have a small enough footprint to start quickly."

    No. Let the user decide.

    ===========

    One problem with splash-screens in Windows is how windows keep taking the focus. For programs that take a long time to start, I'd rather be interrupted once. Maybe, one could create the main window of the app (with some sort of indication that it is still loading) instead of using a splash screen.

    Gratuitous splash-screens (ones with timers) are evil.

    Giving the user the option to turn it off makes sense.

  17. Anonymous says:

    I can't help thinking that there is something wrong in using splash screens as a way to deal with unintentional multiple clicks (or, for that matter, delays blogs.msdn.com/…/9574643.aspx). This should be handled on a different level.

    Splash screens can be useful as a progress indicator. Though I prefer programs that start up instantaneously and can be run in several instances (I love Notepad). Single-instance programs always run counter my intution (which says "1 open file = 1 window = 1 running program").

  18. Anonymous says:

    @Marquess:

    Looks like you're fighting a losing battle here :)

    As it happens, I agree with you.  All too often splash screens are nothing other than another way software reminds the user, "Look at me! I'm still here, working hard!"  I'm sure there's also some research someplace that shows a pretty splash screen makes users feel better about the $50 they just dropped on the program.

    Useful splash screens are the exception, not the rule.  If your program starts so slowly that users think it didn't launch at all, I would suggest investing some resources in improving startup time rather than paying somebody for a pretty picture.

  19. Anonymous says:

    Shouldn't the .NET library itself show a splash screen while being loaded ;-)

    It could say: Thank you for using next generation technology!

    All .NET apps would profit from that, and the programmers and designers resources would not

    been wasted.

  20. Anonymous says:

    A workaround could be: On Window Show event activate the window manually.

  21. Anonymous says:

    @Hans:

    .NET WinForms apparently already has a facility for showing splash screens.  Not sure about WPF.

  22. DWalker59 says:

    Visual Studio is a large program where I have legitimately needed to run more than one copy.  It takes a little while to load (several seconds), especially if you're using Team Foundation Server, and the source code is on a server a few hundred miles away, and the program gets the source code that you're working on through a VPN over the Internet.

    Sometimes I run Visual Studio 2005 and Visual Studio 2008 at the same time.  

  23. Anonymous says:

    Marquess: "Problems that require a time machine to solve are not conducive to this discussion."

    Sorry, I'm a bit confused. Are you suggesting that Microsoft dictate to users what software they can or can not use (based on age), or are you suggesting that Microsoft should buy every user of the older version an upgrade for free?

  24. Anonymous says:

    Marquess: "Problems that require a time machine to solve are not conducive to this discussion."

    If we were talking about going back in time, fine. We aren't. Using an older program today doesn't require a time machine.

    Marquess: "But you don't start those instances in parallel, do you?"

    It doesn't matter. Your suggestion was that "Later instances can easily check if they are already running and immediately terminate". Doing that would be a bad user experience, so your suggestion is a poor one.

    As others have stated, if the program takes more than a couple of seconds to load a splash screen is useful. Giving feedback to users is a good thing. Suggesting that we disallow multiple-instance programs (unless they open instantaneously) and instead require command line switches seems a silly idea. There aer plenty of bad examples of splash screens, but they definitely have their place. Far better to use a splash screen appropriately, than to avoid them and create silly workarounds just because you have it in your head that all splash screens are bad.

  25. Anonymous says:

    @DWalker59

    But you don't start those instances in parallel, do you?

    @James Schend

    No, but sins of the past cannot be changed. If we are talking about an older program, the question about how the splash screen should be handled has already been decided. But if you are creating a *new* application, you should think for a moment about its startup behavior. Do you actually need a new process or would the user be better served with a new window inside the existing process? Are several instances the norm or the exception? Why does it take so long anyway?

  26. Anonymous says:

    The annoying always on top splash screens are probably always on top because for the developer it was easier to set the always on top style on the splash window than writing code to detect creation of the main window and making sure that it is displayed under the splash screen, and then write code to properly set the foreground window.

    And by the way, why would the user start your program if they want to do something else, let alone switch to another application :(

    @ Marquess

    running more than one instance at the same time of Visual Studio 20XX is sometimes necessary for debugging, for instance client server apps.

  27. Anonymous says:

    Classic example:

    When I switch on my cellphone, it takes several seconds to give me any feedback. During that time I have no clue if the phone is booting, so I have to wait actively without doing anything else. I feel frustration.

    I would prefer some kind of immediate "OK, I'm booting" acknowledge message. Then I can passively wait for it to complete the operation.

    If feedback is bad, then why? If it is not, why are not splash screens proper feedback?

  28. Anonymous says:

    @dalek – /Especially/ in a long-startup application you want your user to be able to switch to other apps.  Commonly, while, for example, I'm loading up a PDF I also want to be browsing the web.  Or while the browser is starting up so I can search for documentation I could be coding.  If Firefox or IE threw up an Always on Top splash-screen when I was trying to work it'd be a PITA.

  29. Anonymous says:

    @No One

    I totally agree with you.

    The "And by the way, why would the user start your program if they want to do something else, let alone switch to another application :(" part was sarcasm.

  30. Anonymous says:

    Step 1:  Implement a splash screen

    Step 2:  Optimize app loading to the extent that a splash screen is no longer necessary.

  31. Anonymous says:

    @dalek — oops.  My sarcasm detector is off today

  32. Leo Davidson says:

    I don't mind splash screens but they do still seem redundant in almost most cases.

    The mouse cursor changing to the "program is starting" one is usually a good enough indication that the launch is happening (and you can stop double-clicking), except for things which take a ridiculous amount of time to load (like a certain popular image editing program).

  33. Anonymous says:

    @Devlin Bentley

    You forgot

    Step 3: ????

    Step 4: PROFIT!

  34. Anonymous says:

    @Leo Davidson: "except for things which take a ridiculous amount of time to load (like a certain popular image editing program)"

    Actually I think that's one of the few things that adobe seems to have gotten right:

    • Not always on top (imho the most annoying thing of all)
    • Disappears instantly as soon as the app is loaded (no timers, no "press esc")

    Um those are the two most annoying things of splash screens I can think of – as long as those two are avoided, I think splash screens are a good idea. Not that I see splash screens often these days.. a SSD is just great (even PS loads in less than 2s, no 15seconds staring on the screen and waiting, sigh)

    PS: And I can think of at least one rather well known program that gets both things wrong ~~

  35. Anonymous says:

    It's very hard to manage owner/parent/child/… relations between windows when using a managed api like vb6, .net winforms or .net wpf. What's the recommendation for thease environments?

  36. SimonRev says:

    Thanks — this post (and the linked ones) actually helped me solve a problem with my app not getting the foreground love when it launched. :)

  37. SimonRev says:

    Thanks — this post (and the linked ones) actually helped me solve a problem with my app not getting the foreground love when it launched. :)

Comments are closed.