Regarding Isaac's point: Asylum is only partly right. What is true is, as Raskin says, that the interface is the program. That does not imply that the interface comes first.
This is a three-way alignment of architecture, domain knowledge and glyphs. You can rarely start with one and then derive the other two. But it is also difficult to do all three at once. You can start with the interface, but you can't really get a leg up on the interface until you have the domain knowledge -- at that point, you already have most of what you need for the first iteration of an Agile architecture. Successful projects start with that much knowledge of the domain (either on the part of the implementers or on the part of the usability people) before they start slinging code.
Laurel talks about this problem in depth in Computers as Theatre. If the GUI designers build something to present the program model to the user, you have the first leg of a strange loop. Then the programmers write their code to try to portray the program's data to the GUI. But if the GUI is already anticipating the program, you have a strange loop. The way to break these loops is to find the fixed point -- and that's what the direct manipulation metaphor is about. That's why I said that you need the GUI gal, the code guy, and the architect working together -- all in the context of end-user test drives.
The second related problem is the tendency to create procedural archtiectures. If you build the interface first and then put code behind it, there is a tendency to build the code using global, procedural thinking. You no longer "think like an object" in the CRC card sense. You end with hierarchical procedural architectures that are somewhat wrapped in object clothing. First, that really hoses your ability to maintain the system. Second, you can't easily refactor your way out of it, because in general it requires moving things between class categories quite a bit, and it's difficult to argue that doing so preserves behavior. Third, it ultimately affects the interface, because it's easy to introduce mismatches between the interface and the underlying domain model. Trying to build the code from the interface alone is like trying to build a 3D rendition from a 2D model. You need additional domain information.
The third related problem comes in engineering issues such as performance. I just worked with a client who had designed the interface without much regard to the implementation -- because the user comes first -- and found that the distribution of functionality across the client and server made it impossible to support their intended style of interaction in anything approaching realistic or predictable performance.
Burying all of these behind the "convention" of a look-and-feel does little to help; in fact, most standard look-and-feel practices prevent you from building a humane interface. I maintain a graphical RADitor and social network editing tool. To build a productive interface that minimizes keystrokes (an important consideration for this interface, as it is used for real-time data entry during intervies), I have to go beneath the API of the GUI-builder and common APIs. A look and feel is not an interface. An interface is a protocol. Try making some changes to your favorite interface, and then do a GOMS analysis on the change, as well as a field measurement of how long it takes the user to learn the change. You need a deeper level of consistency than the look-and-feel frosting provides. And that brings us to the second point.
Regarding Andy's post, I may or may not agree depending on the specific example. The concept of "intuition" is bogus: what is intuitive to one is not intuitive to another. It comes down to habit formation. (Being a Mac user I just again ran afoul of another Windowsism this morning that violates some design principles that go deeper than the Windows/Mac look-and-feel debate.) Furthermore, what Andy calls "chunks" play out in the interface through neuropsychological sequences called "gestures." It is true that you shouldn't change gestures; you're fighting pretty deep neurological wiring if you do that. (For example, typing "t-h-e" is a chunk that goes deeper than typing the three letters. Don't believe me? Try typing it backwards. Also, homing to the pointing device and a translation of the pointer to a button, followed by a click, is a gesture.)
I remember one year that MacinTax changed their interface, including some of the gestures and idioms of interface use. It made it all but unusuable for me for the first few hours of use. I'm sure they thought the changes fell into Andy's category of being minor refactorings.
I think we should get rid of the word "refactoring." The industry doesn't have enough discipline to use it right, and it's become a license for arbitrary hacking.
Agile helps here because of people and interactions; it hurts by encouraging too much change in the wrong places.
James O. Coplien wrote This is a three-way alignment of architecture, domain knowledge and glyphs. Are you conflating GUI design with interaction design? Perhaps the term information architect gives a better feeling for what is required.
James O. Coplien wrote ... tendency to create procedural archtiectures ... That seems to be a problem of programmers not meeting program design goals, which really is something the programming team should accept responsibility for - 'the interaction design made me write procedural code' is really lame.
James O. Coplien wrote ... the distribution of functionality across the client and server made it impossible to support their intended style of interaction... And I've worked on systems designed by programmers which were failures for the same reason. And as described it would be a clear example of the designers failing to meet their responsibilities.
"... the interaction designers have some very significant responsibilities. ... The interaction design team's mandate includes designing a feasible-to-build ... product What's more, the interaction designers must describe in exhaustive detail, in writing, a specification from which the programmers can reasonably be expected to build the design."
Of course, the interesting thing about Alan Cooper is that he has been both a successful programmer and a successful interaction design consultant.
> Of course, the interesting thing about Alan Cooper is that > he has been both a successful programmer and a successful > interaction design consultant.
I know he has a successful consultancy and gives lots of lectures. I wasn't aware he was a programmer of any kind, successful or not.
He is also particularly poor at giving other people credit, tends to rename concepts so they are a Cooper-branded item and Inmates is the only book I've ever thrown across a room in sheer anger at his pandering to management by labelling the nasty programmers as the root of all evil, including most of the product decisions that (in reality) usually come from either VIP p*ssing contests or Marketing.
I was in a Compuserve book discussion group when About Face 1.0 came out and that generated by far the longest, and most polarized discussions of any book we'd covered. (I still have fond memories of our discussion of Cope's Advanced C++:Programming Styles and Idioms in which the author was a highly-valued participant.)
One of the interesting divisions in the polarised reading group was between people who had a moderate or better HCI background and those who had only read Cooper or, worse, been to one of his lectures.
> James O. Coplien wrote This is a three-way alignment of > architecture, domain knowledge and glyphs. > Are you conflating GUI design with interaction design? > Perhaps the term information architect gives a > better feeling for what is required.
As someone who works with architects, let me say that I think we have raped and pillaged the term architect enough already :-). In my post I talked largely of interaction design in general; in the sentence you quote, I appeal to GUIs in particular, because the applicabilitly of the direct manipulation metaphor is easier to understand. It is equally applicable in an interface such as, say, my kitchen stove. Unless you have a mental model of which knobs on the front connect to which burners, you have an interface that creates errors.
I think the only reason our interfaces survive at all is that people are better at forming habits than designers are at designing interfaces. The cost, I think, is a high error rate. (I think the oft-cited issue of the "intuitiveness" or "learnability" of the interface is a red herring. There is nothing "intuitive" about the interface to a car, yet hundreds of millions of people use it.)
> James O. Coplien wrote ... tendency to create > procedural archtiectures ... > That seems to be a problem of programmers not meeting > program design goals, which really is something the > programming team should accept responsibility for - 'the > interaction design made me write procedural code' is > really lame.
The phrase "not meeting program design goals" is certainly curious. My program design goals are to satisfy the user, and that includes building a good interface, doesn't it? You are partly right. But the rub goes back to the original premise of my article: those folks who roll out Agile with TDD think that their team has accepted responsibility for meeting design goals, because that's how the high priests of TDD have told them to do it. Also, because the nascent throes of TDD were about testing and not about design, and because most TDD is technology facing rather than business facing, and because most TDD works at the level of a unit, and that unit is almost always a class, the natural consequence is that you think in terms of individual member functions. If indeed that TDD perspective does drive your design, it takes a lot of work to avoid building a bottom-up procedural architecture. The solution? Frame out an architecture up front that guides you through the TDD activities. Then TDD is shaping just the flesh of the code, whereas its skeleton comes from domain knowledge.
> James O. Coplien wrote ... the distribution of > functionality across the client and server made it > impossible to support their intended style of > interaction... > And I've worked on systems designed by programmers which > were failures for the same reason. And as described it > would be a clear example of the designers failing to meet > their responsibilities.
But that response is a cop-out; you can lay all software problems at the feet of the designers, so the statement really carries no information. What I'm saying is that the liklihood of getting right increases if you build a vertically incremental system. Start with a little bit of back end and a little bit of front end, rather than building the entire back-end, testing it, and then slapping a GUI on it. No matter how well-intentioned such a GUI is, it can't work -- in Raskin's sense of "work".
Holy cow. I've got to read this thing (never have). My only regret is that, if it is as you say (and you have high credibility with me) I will have helped fill his coffers should I buy the book. But it's good to know the enemy.
Why is there so much stuff in this general area that is so popular, and so bad? It sounds even worse than OO ever became.
Thanks for the mini-book review. I think there's a place here on Artima for posting book reviews. Maybe this one is worth it.
James O. Coplien wrote The phrase "not meeting program design goals" is certainly curious. ... Let me make it clearer for you. You put forward "The second related problem is the tendency to create procedural archtiectures. If you build the interface first and then put code behind it, there is a tendency to build the code using global, procedural thinking. ..."
That there's a programmer talking about programmer concerns - not someone talking about the quality of user interaction or the userfulness of a product.
Alan Cooper thinks that products should be designed by people whose first concern is the quality of user interaction and the userfulness of the product.
In particular, we're talking about a convergence of the user's mental model and the running model.
I haven't had time to read much more of Naked Objects or think about this but I have a strong suspicion it is another double-edged sword.
As Agile development can be either an engaging mutual progression or an excuse for hacking, I suspect Naked Objects will yield some enterprise systems with cleaner models but also be an excuse for quicker delivery of some convoluted, unusable spaghetti.
I do wonder what it will do to the economics of outsourcing and the associated software factories. It seems at first glance that the Naked Objects framework will replace a substantial part of what they produce.
> > In particular, we're talking about a convergence of the > user's mental model and the running model. > being a relationalist first, foremost, and always; allowing this to happen is why most software (business applications, certainly) are such a mess. Not that users are, a priori, stupid. But they are ignorant about things Data.
To be explicit: users think that an Excel spreadsheet is the bee's knees of sophistication. It isn't. It's a hash of flat-file, redundant, contradictory data. The only reason they think it's mahvelous is that the OrderNumber is on the same line as all of the OrderLines and LineItems. And to do that, the number of each is fixed. Well, we only need 10 OrderLines. A few months pass...well, maybe 15.
Codd had a hissy fit 35 years ago, and devised the Relational Model. What hasn't happened, in fact gotten worse, in the years passing, is the wrenching of data structure specification from users.
Really, the View is fungible. It must not specify the data structure.
The user's mental model is always naive, parochial, and narrow (Me! Me! Me!). A data storage model is always catholic (by the real meaning of the word), and deep.