How many apps are there in that app, anyway?

Software product teams working on large products need to give names to individual application components just so they can communicate effectively – but that’s not a good reason to force a user to learn names for different parts of something that, to them, is a single entity.

A common example: a Setup app is a little application that helps install a bigger application. The software team needs to keep straight which application they’re talking about (in specs, bug reports, etc.), so they give the Setup app its own name. The user ends up having to bear the burden of figuring out who does what. The following is a particularly egregious (and unfortunately very common) example:

So here we’ve got one named thing (Java Runtime Environment Setup) that’s preparing another named thing (an InstallShield Wizard) that will help the user install a third named thing (Java). The user could care less about these other pieces that are involved, so there’s no reason to confuse them by introducing these other components by name at all. All the user cares about here is getting Java onto their machine (and they may not really care about that either – maybe what they’re really trying to do is get a Java app to run).

The dialog could easily have said, "Please wait while Java is installed", or even just, "Please wait."