Session 7

Interface Design in the Design Process

810:171

Software Systems

Exercise 10: The Role of Interface Design in the Design Process

Context

You have read and thought about principles of good interface design, including Shneiderman's eight Golden Rules (Section 2.5 in Designing the User Interface). You have read about design processes and how they can be guided (through Section 3.4 in Designing the User Interface).

Goals

1. To consider the points at which software designers ought to pay attention to interface design during the system development process.

Tasks

Work in teams of three or four people based on the number in the upper right hand corner of this page.

The Three Pillars of Design are features of the design process that "can help user interface architects turn good ideas into a successful system. They rest on established foundations. How can they help us to achieve the eight Golden Rules that characterize good interfaces?

1. Classify the eight golden rules according to which pillar of design best helps the interface designer achieve that rule. You should probably place each rule in exactly one category. If you feel that you must place one of the rules in more than one category, then you must give a substantial reason for doing so.

2. Next, classify the pillars of design according to which steps in the software life cycle best use that pillar as a tool. Use the LUCID methodology as the source of your categories. You may place each pillar in more than one category. Justify each classification by identifying specifically how that pillar plays a role in that phase of the life cycle.

3. List three ways in which LUCID is similar to Beck's Early Development, and three ways in which LUCID differs.

At the End

1. Your group submits its classifications.
2. We will discuss some of your group's conclusions among the class.

Summary from Exercise 10

Nothing is as obvious as it seems! When one group proposed that a particular pillar (say, expert reviews and usability testing) best supported a particular golden rule (say, be consistent), another group offered an alternative argument (for, say, guidelines documents and processes).

What exactly is the problem in Task 1? What are the pillars? How can we support a goal?

Which is what each golden "rule" is: a goal. As rules for how to act, they are distinctly unhelpful! The task is to answer this question: Which pillar do you want to rely on as your primary means for achieving the goal? If you could use neither of the other two, which of the three would you choose?

What are "user interface software tools"? Tools that allow programmers to create the interface elements of a program in terms of the interface (menu, window panel, dialog box), not those of a programming language (loops, selections, lines). They allow a sort of consistency among components, as well syntactic features such as short-cut definition.

Of course, all three pillars can and should support each of the golden rules. Answering the 'false question' of which one to use forces you to confront the strengths and weaknesses of each pillar and to identify the relationship between a pillar's support and the goal being achieved. Such "Mission Impossible" tasks can be great learning exercises, even if at the end you realize that the task was impossible. (You may even realize this up front!)

Some ideas to consider:

• Interface concerns should be addressed up front in the development process, and then throughout.

• Few systems (and even fewer interactive systems) can be defined so completely that architecture prototypes suffice for very long. Some examples include nuclear power plant control software and the scheduling tools being developed in 810:162 course projects.

• You can mandate all you want, but guidelines only work if programmers buy into them. (Think about variable naming and indentation guidelines from your early programming courses.) One of the goals of this course is that you understand why certain kinds of guidelines are important and when guidelines can be reasonably developed.

• Design is organic. If that sounds too "new age" for you, then I ask you to keep in mind that I am not a "new age" kind of guy. Maybe then you will give the claim so real thought. Design starts and stops. It grows. It can be guided but not mandated.

• All of this means that it is hard to ensure that any particular goals are met when they cannot be formally specified to the "tee" -- and that is almost everything. The DTUI material is important because it will help you to bring certain concerns to all of your projects. And that is the only way that we can hope to build good software.

• "Design is organic" leads to the motivation for Kent Beck's patterns.

Several of you liked the emphasis that Beck places on listening, and in particular on deferring thought about how to build the system.

What else did you think of the patterns? Did you agree or disagree with the content? Did you like or dislike the form? Kent is a guy who claims to be "just a programmer" despite being a world-renowned analyst and designer. His patterns are a way for him to share what he has learned--even the obvious parts--in a way that newbies can become developers of good systems sooner.

By now, you should know the golden rules pretty well. Apply the same diligence (and maybe even some of the same exercise ideas!) to study the other material in Chapter 1-2...

Exercise: 11 Uncertainty in the Design Process

Context

You have read several news stories on the case of the killer robot, including a discussion of some of the behind-the-scenes issues in the development of the robot's software.

Goals

1. To understand better the role of uncertainty in system development.

Tasks

Work in teams of three or four people based on the number in the upper right hand corner of this page. If yours is an odd number, your magic word is for. If yours is an even number, your magic word is against.

Construct a convincing argument <your magic word> Ray Johnson's Ivory Snow theory. Be sure that your argument...

• describes the kinds of software systems for which your argument makes the most sense, and

• attempts to counter potential opposing arguments, which will be based on other kinds of software systems.

I realize that you may be put in the position of arguing for a position that you do not personally hold. Make that a part of the fun!

At the End

1. You argue your case in class.
2. Your group submits its write-up.