Originally Posted by Flight Safety
The very fact that all primary control inputs are feed into and processed by a computer makes Jef Raskin's Human Interface Design Rules for computers extremely relevant in my view.
The reason I keep harping on about this is that there seem to be quite a few people on this forum who think that they can design and analyse HCI to control systems, without showing that they have any interest in the rather large engineering literature on such things. So we see the same sophomore-level arguments. Your suggestion is not one of those, however; it actually references the literature. And is therefore worth thinking about.
Its weakness is that it has a simple refutation, which I indicated.
There are a few hundred researchers, and a few thousand HCI professionals, in the world who spend their time thinking about such things. They hold conferences. If you think that your view has merit, and that it has been somehow missed by the HCI community (most of whom are very well aware of Raskin's work), then I suggest you write it up and submit it to one of those conferences for peer review. It will go to someone to be refereed who knows about interfaces to control systems.
It will probably come back with a two-sentence refutation similar to mine (unless it comes to me, in which case it will be identical with mine).
There are also some things wrong with your further chain of reasoning.
Originally Posted by Flight Safety
While "modes" can be made to exist in mechanical controls, they are primarily the creation of computer programs, where the programmer determines what the control inputs mean, and how they are processed.
There is an equivocation hiding in here.
A mode is exhibited when a control action results in one function F in environment A, and a different function G in environment B. The values of the environmental parameters A and B define the mode under some suitable way of saying what parameter settings are equivalent.
When you command thrust reverse on a B767 in flight, you don't get thrust reverse. So a mode is exhibited: let us call them "GROUND" mode and "AIR" mode. This mode change is accomplished through an interlock. Interlocks have been around since whenever, and in mechanical systems this is one of the words that is often used; there are others.
But "mode" itself is a word which came into use to describe the different sets of environmental parameters which were sensed to determine what function F was executed, when digital computation started replacing mechanics and analog-electrical control. So people tend to think that "modes" come with digital computation, whereas they were around long before. It is, however, true that modes became more prevalent with the advent of digital control. This is because (to say it again) they are how one controls the complexity of the state space.
In software design for other uses, one speaks of "hierarchical decomposition". There is no other known way of controlling the complexity of the state space. Some control-system specification methods, such as Statecharts, which has been prevalent in the aviation industry since David Harel proposed it a couple decades ago for use by IAI, actually rely on modes as the main design function. Statecharts specify hierarchical state machines, and that word "hierarchical" means that you have modes, at least in the innards of the design. Since the user of such systems also has a complex state space, modes bubble through inevitably to the user interface. Other systems such as Lustre, the basic specification instrument for SCADE, also involve hierarchical state machines.
So modes are basic. You don't have to like them, but if you are advocating that people drop them, it becomes incumbent upon you to suggest how the systems can be designed without them.
If you want a flat state space, you could always just go back to B727-like controls but implement them electrically, such as in the back-up direct-law control to the B777 FCS. But no one would buy your airplane. They wouldn't just not buy it because it was old-fashioned. They wouldn't buy it because the generation of airplanes with digital control systems has by and large a statistically significantly better safety record than older generations, and most people who buy these airplanes think it has something to do with the digital control and flight management systems.
without the disciplined guidance of design rules, a programmer could write anything (from good to terrible) as a control interface.
That suggests an inappropriate view of how these systems actually become implemented. Crudely put, modern control systems are written by designing state machines on your screen and "pressing the button" to have code come out. No programmer using these systems can just "write anything". And programmers don't write control interfaces. Control interfaces are designed by HCI specialists or engineering psychologists or whatever you want to call them, and are evaluated directly as well as derivatively through many thousands of hours with test pilots in simulations. And then these designs are passed on to the design engineers who put them into the CAD system and then "press that button" to get the object code.
One is free not to like modes, but there is no better alternative for these applications. If you want to give up modes, you will also give up functionality. That is a hard technical constraint, and is the reason why no control system design engineer will listen to you if you try to persuade himher to go modeless.
PBL