Quotes About Design

When we're creating sites, we act as though people are going to pore over each page, reading all of our carefully crafted text, figuring out how we've organized things, and weighing their options before deciding which link to click. What

The problem is there are no simple "right" answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed, and tested. That

CLARITY TRUMPS CONSISTENCY If you can make something significantly clearer by making it slightly inconsistent, choose in favor of clarity.

Too-subtle visual cues are actually a very common problem. Designers love subtle cues, because subtlety is one of the traits of sophisticated design. But Web users are generally in such a hurry that they routinely miss subtle cues.

Get rid of half the words on each page, then get rid of half of what's left. —KRUG'S THIRD LAW OF USABILITY Of

Designing, building, and maintaining a great Web site or app isn't easy. It's like golf: a handful of ways to get the ball in the hole, a million ways not to.

Nothing important should ever be more than two clicks away.

One way to look at design—any kind of design—is that it's essentially about constraints

My fear represented the failure of the human system. It is a sad truth of our creation: Something is amiss in our design, there are loose ends of our psychology that are simply not wrapped up. My fears were the dirty secrets of evolution. They were not provided for, and I was forced to construct elaborate temples to house them.

Another good reason to create a class is to model an abstract object—an object that isn't a concrete, real-world object but that provides an abstraction of other concrete objects. A good example is the classic Shape object. Circle and Square really exist, but Shape is an abstraction of other specific shapes.

Levels of Design Design is needed at several different levels of detail in a software system. Some design techniques apply at all levels, and some apply at only one or two. Figure 5-2 illustrates the levels. Figure 5-2. The levels of design in a program. The system (1) is first organized into subsystems (2). The subsystems are further divided into classes (3), and the classes are

Keep Your Design Modular Modularity's goal is to make each routine or class like a black box: You know what goes in, and you know what comes out, but you don't know what happens inside.

The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket.

Object-Oriented Design Heuristics (1996), Arthur Riel

If a class contains more than about seven data members, consider whether the class should be decomposed into multiple smaller classes (Riel 1996). You might err more toward the high end of 7±2 if the data members are primitive data types like integers and strings, more toward the lower end of 7±2 if the data members are complex objects.

Design Is a Wicked Problem Horst Rittel and Melvin Webber defined a wicked problem as one that could be clearly defined only by solving it, or by solving part of it (1973). This paradox implies, essentially, that you have to solve the problem once in order to clearly define it and then solve it again to create a solution that works.

The picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen. — David Parnas Paul Clements

One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked.

Programming assignments in school are devised to move you in a beeline from beginning to end. You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. But that very process is an everyday reality in professional programming.

Design is sloppy because a good solution is often only subtly different from a poor one.

Design is also sloppy because it's hard to know when your design is good enough. How much detail is enough? How much design should be done with a formal design notation, and how much should be left to be done at the keyboard? When are you done? Since design is open-ended, the most common answer to that question is When you're out of time.

Notably, the core of NASA's approach to creating reusable classes does not involve designing for reuse. NASA identifies reuse candidates at the ends of their projects. They then perform the work needed to make the classes reusable as a special project at the end of the main project or as the first step in a new project. This approach helps prevent gold-plating—creation of functionality that isn't required and that unnecessarily adds complexity.

Formal city parks have a longevity to them that can exceed that of castles or cemeteries or forts.

Dunbar's generative conference room meetings remind us that the physical architecture of our work environments can have a transformative effect on the quality of our ideas. The quickest way to freeze a liquid network is to stuff people into private offices behind closed doors, which is one reason so many Web-era companies have designed their work environments around common spaces where casual mingling and interdepartmental chatter happens without any formal planning.