12 SOFTWARE QUALITY $1.2 Software designers preoccupied with ease of use will also be well-advised to See WilfredJ. consider with some mistrust the precept most frequently quoted in the user interface Hansen,“User literature,from an early article by Hansen:know the user.The argument is that a good Engineering Princi- ples for Interactive designer must make an effort to understand the system's intended user community.This Systems”,Proceed. view ignores one of the features of successful systems:they always outgrow their initial ings ofF/CC 39, audience.(Two old and famous examples are Fortran,conceived as a tool to solve the AFIPS Press, problem of the small community of engineers and scientists programming the IBM 704, Montvale(NJ), and Unix,meant for internal use at Bell Laboratories.)A system designed for a specific 1971,Pp523-532. group will rely on assumptions that simply do not hold for a larger audience. Good user interface designers follow a more prudent policy.They make as limited assumptions about their users as they can.When you design an interactive system,you may expect that users are members of the human race and that they can read,move a mouse,click a button,and type(slowly);not much more.If the software addresses a specialized application area,you may perhaps assume that your users are familiar with its basic concepts.But even that is risky.To reverse-paraphrase Hansen's advice: User Interface Design principle Do not pretend you know the user;you don't. Functionality Definition:functionality Functionality is the extent of possibilities provided by a system. One of the most difficult problems facing a project leader is to know how much functionality is enough.The pressure for more facilities,known in industry parlance as featurism (often "creeping featurism"),is constantly there.Its consequences are bad for internal projects,where the pressure comes from users within the same company,and worse for commercial products,as the most prominent part of a journalist's comparative review is often the table listing side by side the features offered by competing products. Featurism is actually the combination of two problems,one more difficult than the other.The easier problem is the loss of consistency that may result from the addition of new features,affecting its ease of use.Users are indeed known to complain that all the "bells and whistles"of a product's new version make it horrendously complex.Such comments should be taken with a grain of salt,however,since the new features do not come out of nowhere:most of the time they have been requested by users-other users. What to me looks like a superfluous trinket may be an indispensable facility to you. The solution here is to work again and again on the consistency of the overall product,trying to make everything fit into a general mold.A good software product is based on a small number of powerful ideas;even if it has many specialized features,they should all be explainable as consequences of these basic concepts.The"grand plan"must be visible,and everything should have its place in it.12 SOFTWARE QUALITY §1.2 Software designers preoccupied with ease of use will also be well-advised to consider with some mistrust the precept most frequently quoted in the user interface literature, from an early article by Hansen: know the user. The argument is that a good designer must make an effort to understand the system’s intended user community. This view ignores one of the features of successful systems: they always outgrow their initial audience. (Two old and famous examples are Fortran, conceived as a tool to solve the problem of the small community of engineers and scientists programming the IBM 704, and Unix, meant for internal use at Bell Laboratories.) A system designed for a specific group will rely on assumptions that simply do not hold for a larger audience. Good user interface designers follow a more prudent policy. They make as limited assumptions about their users as they can. When you design an interactive system, you may expect that users are members of the human race and that they can read, move a mouse, click a button, and type (slowly); not much more. If the software addresses a specialized application area, you may perhaps assume that your users are familiar with its basic concepts. But even that is risky. To reverse-paraphrase Hansen’s advice: Functionality One of the most difficult problems facing a project leader is to know how much functionality is enough. The pressure for more facilities, known in industry parlance as featurism (often “creeping featurism”), is constantly there. Its consequences are bad for internal projects, where the pressure comes from users within the same company, and worse for commercial products, as the most prominent part of a journalist’s comparative review is often the table listing side by side the features offered by competing products. Featurism is actually the combination of two problems, one more difficult than the other. The easier problem is the loss of consistency that may result from the addition of new features, affecting its ease of use. Users are indeed known to complain that all the “bells and whistles” of a product’s new version make it horrendously complex. Such comments should be taken with a grain of salt, however, since the new features do not come out of nowhere: most of the time they have been requested by users — other users. What to me looks like a superfluous trinket may be an indispensable facility to you. The solution here is to work again and again on the consistency of the overall product, trying to make everything fit into a general mold. A good software product is based on a small number of powerful ideas; even if it has many specialized features, they should all be explainable as consequences of these basic concepts. The “grand plan” must be visible, and everything should have its place in it. User Interface Design principle Do not pretend you know the user; you don’t. Definition: functionality Functionality is the extent of possibilities provided by a system. See Wilfred J. Hansen, “User Engineering Princi￾ples for Interactive Systems”, Proceed￾ings of FJCC 39, AFIPS Press, Montvale (NJ), 1971, pp 523-532