

The rule of silence, also referred to as the silence is golden rule, is an important part of the Unix philosophy that states that when a program has nothing surprising, interesting or useful to say, it should say nothing. It means that well-behaved programs should treat their users' attention and concentration as being valuable and thus perform their tasks as unobtrusively as possible. That is, silence in itself is a virtue. There is no single, standardized statement of the Unix philosophy, but perhaps the simplest description would be: "Write programs that are small, simple and transparent. Write them so that they do only one thing, but do it well and can work together with other programs." That is, the philosophy centers around the concepts of smallness, simplicity, modularity, craftsmanship, transparency, economy, diversity, portability, flexibility and extensibility. This philosophy has been fundamental to the the fact that Unix-like operating systems have been thriving for more than three decades, far longer than any other family of operating systems, and can be expected to see continued expansion of use in the years to come, particularly in the form of Linux. The rule of silence is one of the oldest and most persistent design rules of such operating systems. As intuitive as this rule might seem to experienced users of such systems, it is frequently ignored by the developers of other types of operating systems and application programs for them. The result is often distraction, annoyance and frustration for users. There are several very good reasons for the rule of silence: (1) One is to avoid cluttering the user's mind with information that might not be necessary or might not even be desired. That is, unnecessary information can be a distraction. Moreover, unnecessary messages generated by some operating systems and application programs are sometimes poorly worded, and can cause confusion or needless worry on the part of users. (2) A second reason is to avoid cluttering the display screen. Even today, screen space can be very limited in some special situations. (3) A third reason is that command line programs (i.e., all-text mode programs) on Unix-like operating systems are designed to work together with pipes, i.e., the output from one program becomes the input of another program. This is a major feature of such systems, and it accounts for much of their power and flexibility. Consequently, it is important to have only the truly important information included in the output of each program, and thus in the input of the next program. The rule of silence does not mean that any less information is available. Rather, by default it just does not provide information that is likely to be unnecessary in most situations. However, it allows the user to use options, also referred to as switches, to view detailed information if desired. Many command line programs have a verbose option, and it is typically -v. The rule of silence originally applied to command line programs, because all programs were originally command line programs. However, it is just as applicable to GUI (graphical user interfaces) programs. That is, unnecessary and annoying information should be avoided regardless of the type of user interface. A example is the useless and annoying dialog boxes (i.e., small windows) that pop up on the display screen with with surprising frequency on some operating systems and programs. These dialog boxes contain some obvious, cryptic or unnecessary message and require the user to click on them in order to close them and proceed with work. This is an interruption of concentration and a waste of time for most users. Such dialog boxes should be employed only in situations in which some unexpected result might occur or to protect important data. The rule of silence originated because UNIX was originally developed prior to the availability of high quality video displays. Most output was sent to slow printing terminals, and each line of unnecessary output was a significant drain on the user's time. Although that constraint is long gone, excellent reasons for terseness remain. As is the case with so much else in the Unix philosophy, the rule of silence can apply to much more than just computers. For example, controls for products should be designed to by default just to provide the information that is most likely to be necessary or interesting for most users in order to minimize distractions and possible user errors. But it should be easy for users to make adjustments so that additional information can be provided if desired. A key to the ability to apply the rule of silence is to make the operation of computers, industrial controls and other products as intuitive as possible so that dialog boxes, windows with explanations, tooltips, buzzer sounds, etc. are rarely necessary by default (but can be easily turned on if and when desired). This is also a key to good documentation for products, i.e., minimize the need for it in the first place, but then make it readily available for providing information beyond what most users need or want to known most of the time. Some people might feel that the rule of silence could also be applied to ambient noise. For example, announcements over loudspeakers and the prerecorded music which is continuously played in some stores, restaurants, hotel lobbies, elevators (and is often referred to as elevator music) is providing information (if music can be considered information) that some people enjoy. However, others find it distracting or even extremely annoying, including many people who truly like music. Thus, the rule of silence would imply that silence should be the default situation and those people who want to listen to music can use personal audio devices or go to special locations for listening to it, rather than requiring that some percentage of the people be annoyed, have to complain and/or have to wear earplugs. Likewise, announcements over loudspeakers should be saved for true emergencies rather than being the default means for providing what is often trivial or unnecessary information.









Created January 5, 2006.

Copyright © 2006 The Linux Information Project. All Rights Reserved.