The Artima Developer Community
Sponsored Link

Weblogs Forum
The Interface is the Program, and it ain't Agile

45 replies on 4 pages. Most recent reply: Dec 25, 2006 12:10 PM by Tom Flaherty

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 45 replies on 4 pages [ « | 1 2 3 4 | » ]
James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 11, 2006 4:59 AM
Reply to this message Reply
Advertisement
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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 11, 2006 1:21 PM
Reply to this message Reply
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.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: The Interface is the Program, and it ain't Agile Posted: Dec 11, 2006 4:35 PM
Reply to this message Reply
> 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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 11, 2006 5:55 PM
Reply to this message Reply
Andy Dent wrote I wasn't aware he was a programmer of any kind, successful or not.
I guess you didn't read the dust-cover of Inmates before you threw it across the room :-)

http://www.cooper.com/alan/father_of_vb.html


... most of the product decisions that (in reality) usually come from either VIP p*ssing contests or Marketing
It's always someone else's fault.

... people who had a moderate or better HCI background and those who had only read Cooper ...
It's always someone else who lacks knowledge.

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 12, 2006 3:47 PM
Reply to this message Reply
> 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".

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 12, 2006 3:50 PM
Reply to this message Reply
Andy,

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

Posts: 40
Nickname: cope
Registered: May, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 12, 2006 3:54 PM
Reply to this message Reply
> Andy Dent wrote I wasn't aware he was a programmer of
> any kind, successful or not.

> . . . .
> http://www.cooper.com/alan/father_of_vb.html

Visual Basic?

I'm confused: are you disagreeing with Andy's point, or substantiating it?

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: The Interface is the Program, and it ain't Agile Posted: Dec 12, 2006 7:41 PM
Reply to this message Reply
> Holy cow. I've got to read this thing

It's on Safari.

http://safari.oreilly.com/0672326140

I buy a lot of books second-hand from Amazon, if you want the hardcopy but don't want to reward the author ;-)

(Not that I buy second-hand to normally avoid rewarding authors but I've been building up my back-catalog of classics, eg: some of Weinberg & Page-Jones stuff is still very relevant.)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

programmer talking about programmer concerns Posted: Dec 13, 2006 12:41 PM
Reply to this message Reply
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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 13, 2006 12:48 PM
Reply to this message Reply
> > Andy Dent wrote I wasn't aware he was a programmer
> > of any kind, successful or not.

> > . . . .
> > http://www.cooper.com/alan/father_of_vb.html

James O. Coplien wrote

> Visual Basic?
>
> I'm confused: are you disagreeing with Andy's point, or
> substantiating it?

I suppose that's intended to be a sneering dismissal. Do you mean to suggest that Visual Basic was not successful?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Holy cow Posted: Dec 13, 2006 12:52 PM
Reply to this message Reply
James O. Coplien wrote Holy cow. I've got to read this thing

From the confident way you wrote "Asylum is only partly right" we might have imagined you already had read "The Inmates Are Running The Asylum".

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Naked Objects Posted: Dec 13, 2006 8:14 PM
Reply to this message Reply
It seems to me this thread has a fair degree of relevance to the Naked Objects movement, see http://www.theserverside.com/tt/articles/article.tss?l=NakedObjectSeries_1

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.

Hmm.

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.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Naked Objects Posted: Dec 14, 2006 3:54 PM
Reply to this message Reply
>
> 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.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Naked Objects Posted: Dec 15, 2006 12:12 AM
Reply to this message Reply
> 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.

Or it (spreadsheet) is the most successful example of a declarative programming environment in existence, depends on your viewpoint :-)

>The user's mental model is always naive, parochial, and narrow

I didn't say to put the user in charge of developing the system!

SOA's are having an interesting effect in (re?) emphasizing the need for a coarse-grained set of components as one system model, which may well be implemented by more finely-grained objects.

I don't see how it's a bad thing for one level of design detail to be a model which conforms to the user's model.

This could be one of the themes which helps restrain agile development from thrashing. I'm struggling for a cute term here, Consistency Boundary? Maybe Plausibility Seam?

Whatever.

Anyway, Naked Objects could be employed as a smarter technique to provide basic CRUD access to data, much like quick form generators of past years, bundled in 4GL's like FoxBase and 4th Dimension.

As these are Objects, however, rather than a set of screen definitions, they could also be used by a more intelligent interface to provide a richer, more supportive UI.

This may also support GUI testing, being very close to the http://www.martinfowler.com/eaaDev/PresentationModel.html as discussed toward the end of Martin Fowler's essay on UI Architectures: http://www.martinfowler.com/eaaDev/uiArchs.html

wenatorlre wenatorlre

Posts: 5
Nickname: wenatorlre
Registered: Dec, 2006

Re: The Interface is the Program, and it ain't Agile Posted: Dec 17, 2006 5:52 AM
Reply to this message Reply
popular WMV to Zune Tools Free Download
For more information see

Flat View: This topic has 45 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: The Interface is the Program, and it ain't Agile Previous Topic   Next Topic Topic: Issues, ThoughtChunks, Variations and Requirements Traceability


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us