第135页 | The Art of UNIX Programming | 阅读 ‧ 电子书库

Chapter�營nterfaces

User-Interface Design Patterns in爐he燯nix Environment

Table of Contents

Applying the Rule of Least Surprise

History of Interface Design on Unix

Evaluating Interface Designs

Tradeoffs between CLI and Visual Interfaces

Case Study: Two Ways to Write a Calculator Program

Transparency, Expressiveness, and Configurability

Unix Interface Design Patterns

The Filter PatternThe Cantrip PatternThe Source PatternThe Sink PatternThe Compiler PatternThe ed patternThe Roguelike PatternThe ‘Separated Engine and Interface’ PatternThe CLI Server PatternLanguage-Based Interface Patterns

Applying Unix Interface-Design Patterns

The Polyvalent-Program Pattern

The Web Browser as a Universal Front End

Silence Is Golden

The interface of a program is the sum of all the ways that it communicates with human users and other programs. In Chapter�/a>, we discussed the use of environment variables, switches, run-control files and other parts of start-up-time interfaces. In this chapter, we'll untangle the history and explain the pragmatics of Unix interfaces after startup time. Because user-interface code normally consumes 40% or more of development time, knowing good design patterns is especially important here in order to avoid a lot of false starts and time-intensive rewrites.

In the Unix tradition of interface design, we encounter two themes over and over again. One is anticipatory design for communication with other programs; the other is the Rule of Least Surprise.

Unix programs can give you extra power from being used in synergistic combinations; we discussed various methods for hooking together such combinations in Chapter�a>. The ‘other programs’ part of Unix interface design is not an afterthought or a marginal case as it is under many other operating systems. Rather, it is a central challenge that has to be balanced and integrated carefully with the demands of interface design for human users.

Much of Unix-community tradition about program interface design may seem odd and arbitrary — or even, in the age of the GUI, downright regressive — when you encounter that tradition for the first time. But in spite of various blemishes and irregularities, that tradition has an inner logic to it which is worth learning and understanding. It reflects heuristics accumulated over Unix's long history about ways to do effective communication both with human beings and with other programs. And it includes a set of conventions which create commonalities between programs — it defines ‘least surprising’ alternatives for a wide range of common interface-design problems.

After startup, programs normally get input or commands from the following sources:

 

 

Data and commands presented on the program's standard input.

Inputs passed through IPC, such as X server events and network messages.

Files and devices in known locations (such as a data file name passed to or computed by the program).

Programs can emit results in all the same ways (with output going to standard爋utput).

Some Unix programs are graphical, some have screen-oriented character interfaces, and some use a starkly simple text-filter design unchanged from the days of mechanical teletypes. To the uninitiated, it is often far from obvious why any given program uses the style it does — or, indeed, why Unix supports such a plethora of interface styles at all.

Unix has several competing interface styles. All are still alive for a reason; they're optimized for different situations. By understanding the fit between task and interface style, you will learn how to choose the right styles for the jobs you need to do.

 

 

 

Prev  Up Next

On Breaking These Rules  Home 燗pplying the Rule of Least Surprise