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 9:10 AM 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 | » ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Extreme Programming vs. Interaction Design Posted: Dec 5, 2006 8:00 PM
Reply to this message Reply
Advertisement
From the horses' mouths
http://www.ftponline.com/interviews/beck_cooper/

Kent Beck is known as the father of "extreme programming," a process created to help developers design and build software that effectively meets user expectations. Alan Cooper is the prime proponent of interaction design, a process with similar goals but different methodology. We brought these two visionaries together to compare philosophies, looking for points of consensus—and points of irreconcilable difference.

John Roth

Posts: 8
Nickname: johnroth
Registered: Jan, 2005

Re: Extreme Programming vs. Interaction Design Posted: Dec 5, 2006 10:10 PM
Reply to this message Reply
> From the horses' mouths
> http://www.ftponline.com/interviews/beck_cooper/
>
> Kent Beck is known as the father of "extreme
> programming," a process created to help developers design
> and build software that effectively meets user
> expectations. Alan Cooper is the prime proponent of
> interaction design, a process with similar goals but
> different methodology. We brought these two visionaries
> together to compare philosophies, looking for points of
> consensus—and points of irreconcilable difference.



that was a singularly useless reference. It can be boiled down to:

Cooper: You've got to have this separation of professions, and the interaction designers have to do their work before the programmers can get to work.
Beck: No, they don't.
Cooper: Oh, yeah?
Beck: It doesn't work that way for me.
Cooper: I don't believe it.

John Roth

unmesh

Posts: 15
Nickname: unmesh
Registered: May, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 6, 2006 2:12 AM
Reply to this message Reply
>>Agile has a poor history of being patient or of dealing with long-term stable structures

Can having separate refactoring phases at the end of the project (or even after the code is deployed in production) help in this? I was discussing this at
http://tech.groups.yahoo.com/group/agilemultisitedevelopment/

Darryl Mataya

Posts: 9
Nickname: dmataya
Registered: Nov, 2004

Re: The Interface is the Program, and it ain't Agile Posted: Dec 6, 2006 9:12 AM
Reply to this message Reply
I agree with James' comments, especially when he reminds us that an interface is a metaphor (really a collection of them).

What is missing from software development education, as well as most developer's skill sets, is the recognition that user interface is primarily a human language issue. Lots of us discovered this the hard way when we realized that using icons in the early graphical user interfaces did not assure usability.

Human languages are purely analog. I have a varying chance of expressing a useful concept to you with words. I have no guarantee how you will process or react to it. As the old saying goes, "I can explain it to you but I can't understand it for you". We all know this intuitively, but we fail to act on its importance when designing computer interfaces.

When we have been most successful using agile practices is when the following steps align well:

1. The conceptual basis of what the tools will do is well understood and believed by users to be useful. To put this another way, the fitness for purpose has already been established.
2. The soft components of the system, which include database entities and roles as well as objects, are true to the conceptual tool's goals.
3. The mechanical and visual components one sees on a screen or report, while rapidly changing, continue to iterate towards a better expression of the original purpose.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Extreme Programming vs. Interaction Design Posted: Dec 6, 2006 10:41 AM
Reply to this message Reply
> > From the horses' mouths
> > http://www.ftponline.com/interviews/beck_cooper/
> >
> > Kent Beck is known as the father of "extreme
> > programming," a process created to help developers
> design
> > and build software that effectively meets user
> > expectations. Alan Cooper is the prime proponent of
> > interaction design, a process with similar goals but
> > different methodology. We brought these two visionaries
> > together to compare philosophies, looking for points of
> > consensus—and points of irreconcilable difference.

>
>
> that was a singularly useless reference. It can be boiled
> down to:
>
> Cooper: You've got to have this separation of professions,
> and the interaction designers have to do their work before
> the programmers can get to work.
> Beck: No, they don't.
> Cooper: Oh, yeah?
> Beck: It doesn't work that way for me.
> Cooper: I don't believe it.
>
> John Roth

John, please go beyond the put-down and explain which of those conflicting viewpoints you agree with and why.

Maxim Noah Khailo

Posts: 25
Nickname: mempko
Registered: Nov, 2004

Re: The Interface is the Program, and it ain't Agile Posted: Dec 6, 2006 10:52 AM
Reply to this message Reply
We are certainly trained to look at the customers perspective which usually equals features. What they WANT and not HOW they want it. The problem as you pointed out is they probably don't know how, and probably can't tell you. This implies, at least to me, that to get something usable requires some kind of planning and thought. Thought. This word is important because having to think, versus react, implies design. Because interfaces are fuzzy, they require thinking, planning, understanding.

To be successful at thinking, planning, understanding requires experience and discipline. I particularly liked your metaphor "You must be fit to be Agile. Getting into shape, developing the right architectural posture."

I work for a small company and we have a very short iterative cycle for our product. We have started really focusing on testing (Our cycle is 1/3 planning, 1/3 programming, 1/3 testing). However, a very very small part of this processes deals with usability. Because there is not one person exclusively doing usability, various parts of our software are not consistent (strange as the parts have a lot of similarity with each other, not much symmetry breaking going on there ;-)

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: The Interface is the Program, and it ain't Agile Posted: Dec 6, 2006 11:37 AM
Reply to this message Reply
> A good start, but, if we have a programmer and a UI
> designer working independently from an external set of
> requirements, we are not talking about anything
> resembling an Agile process ;-)

Some how you seem to think that Agile not only says that people work together and communicate, but they actually do work together and communicate.
:-)

I think the only way to enforce this is to have a programmer working with the UI designer on the UI design. Call it pair programming if you want. Which means that the programmer, to some extent, is doing the UI design, contrary to various pontifications on this thread that they should never do that.

James Tikalsky

Posts: 12
Nickname: jt2190
Registered: Dec, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 6, 2006 2:15 PM
Reply to this message Reply
> UI development is similar in that software developers see
> it in terms of the mechanics required to generate it. A
> large part of their emphasis is on those mechanics and
> getting them working. Users (often also UI designers) are
> largely unaware of the mechanics and their limitations.
> All their awareness is focused on usage and getting the
> e job done. It is this emphasis that make the difference
> between the design of a working interface and a "winning"
> interface.

Ignorance of the mechanics of programming does not make one a better UI designer. I've seen far too many designs that are either impossible to implement (meaning the the designers time was completely wasted) or that introduce a huge amount of complexity to the code (meaning that lots of development time is wasted by developers trying to make the UI work.) The best UI designers are programmers that care about UI issues. Period.

Parag Shah

Posts: 24
Nickname: parags
Registered: Mar, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 6, 2006 10:46 PM
Reply to this message Reply
Hello Jim,

You mentioned

"You must be fit to be Agile. Getting into shape, developing the right architectural posture, takes time and effort. (That was the first point I emphasized in my keynote, referenced in one of the links above). Too many Agile practitioners ignore this foundational discipline because they confuse Agile with instant (programmer) gratification, under the excuse of rapid customer delivery (which is a good thing) and quick feedback from the customer (which can also be a good thing)."


I think the reason for a project failing after a few iterations is not because of a weak architectural foundation, but the inability to refactor appopriately. When we create a design there is always a chance of over engineering for flexibility that may never be needed. Agile programming suggests that we do not build the flexibility based on percieved requirements, but add it when the need arises by "merciless refactoring".

What follows is a very simplistic example, but it explains the concept. Let's assume that a customer wants to make a simple Jukebox that can play a selected tune with a Guitar. Now we can either create a Guitar class and invoke it directly from client (Jukebox) code, or design for flexibility by creating a MusicalPlayer superclass and a Guitar subclass that overrides the play method. If we were to create the latter, it would be based on percieved requirements, ie the cuctomer might come back and ask us to add another musical instrument. If I understand correctly, designing using Agile principles will mean creating a simple Guitar class and calling it directly from the client code. But the moment we have a need for another musical instrument we create the MusicalInstrument superclass with a Guitar and let's say Piano subclasses. We also refactor client code to use MusicalInstrument and perhaps also introduce a creational method responsible for instantiating the appropriate subclass of MusicalInstrument. But very often in the rush to complete code, developers will not perform these refactorings. They will introduce a Piano class, add an if...else to the Jukebox and invoke either the Guitar or the Piano based on the selection.

So based on the initial requirement, this is appropriate design:
public class Jukebox {
    public void play(Tune t) {
        Guitar g = new Guitar();
        g.play(t);
    }
}
 
public class Guitar {
    public void play(Tune t) {
        //play the tune
    }
}


and this would be over engineering
public class Jukebox {
    public void play(Tune t) {
        MusicalPlayer mp = createMusicalPlayer();
        mp.play(t);
    }
}

If the change request to add another instrument does not come, then the effort we put into adding flexibility will be wasted.

Now let's assume that we took the first approach and the customer does come up with a request to add another instrument. The incorrect (quick fix) way of coding would be:
public class Jukebox {
    public void play(Tune t, int selection) {
        if(selection = GUITAR)
            Guitar g = new Guitar();
            g.play(t);
        }
        else if(selection == PIANO) {
            Piano p = new Piano();
            p.play(t);
        }
    }
}
 
public class Guitar {
    public void play(Tune t) {
        //play the tune
    }
}
 
public class Piano {
    public void play(Tune t) {
        //play the tune
    }
}


Unfortunately, this is what happens under the name of Agile. People forget that they always have to work towards an appropriate design, and the change request warrants certain refactoring. The code should have actually evolved like this:
public class Jukebox {
    public void play(Tune t, int selection) {
        MusicalInstrument mp = createMusicalInstrument(selection)
        mp.play
    }
    
    private MusicalInstrument createMusicalInstrument(int selection) {
        //create an appropriate instance of MusicaInstrument
    }
}
 
public abstract class MusicalPlayer {
    public abstract void play();
}
 
public class Guitar extends MusicalInstrument {
    public void play(Tune t) {
        //play the tune
    }
}
 
public class Piano extends MusicalInstrument {
    public void play(Tune t) {
        //play the tune
    }
}


Very often Agile practitioners do not refactor their code and as a result it becomes unmanageable.

I am sorry if this post is at a slight tangent. Perhaps the crux of Jim's post was "usability and agile", and the bit on architecture was more on the side. But I thought I'd share my perception of "Agile and Architecture", since I believe that agile methodologies do not promote bad architecture, but suggest that we create "appropriate architectures".

--
Regards
Parag

s m

Posts: 2034
Nickname: sashika
Registered: Jul, 2005

Re: The Interface is the Program, and it ain't Agile Posted: Dec 7, 2006 1:31 AM
Reply to this message Reply
I am an interaction designer and I work in a very agile environment, so the problem of UI quality and usability testing is something we deal with every day

Some time ago I read Don Norman's article and think he's right :)
http://www.jnd.org/dn.mss/why_doing_user_obser.html:

"Usability testing is like Beta testing of software. It should never be used to determine "what users need." It is for catching bugs, and so this kind of usability testing still fits the new, iterative programming models, just as Beta testing for software bugs fits the models. I have long maintained that any company proud of its usability testing is a company in trouble, just as a company proud of its Beta testing is in trouble. UI and Beta testing are meant simply to find bugs, not to redesign."

Sasa Milenkovic

Posts: 3
Nickname: littlesal
Registered: Nov, 2004

Re: The Interface is the Program, and it ain't Agile Posted: Dec 7, 2006 3:27 PM
Reply to this message Reply
That it is a problem, I agree.

I think that truth is somewhere between (oh no, not again!:)) Agile and oldfashion plancentric behaviour of programmers.

Of course the programmers should do UI design, but not in graphical or in artistic manner. It would be too mouch to expect it from someone focused on fundamental sciences, but if they could do it it may be great, but better not to try because it could be very hard to convince them that it doesn't worth the effort. Graphical design should be done by graphical designers, under ideal circumstances.

Yet, programmers should know something of the subject. I have read an genuine book about UI design couple years ago(sorry, I have forgot the Headline and author name), and it helped me a lot to understand the mystery of UI. There are 3 simple rules explained in the book:

- Users can't read (do not write Bible on dialogues)
- Users can't use mouse (make it simple and huge)
- Users can't see colors (it is very interesting - don't use colour for key differences recognition)

Maybe there is a wider set of rules, but it worked very good for me. Sadly there a problem of providing industrial or graphical designer, or even an artist, to the project and UI if too often under rough hand of engeneers chiseling, just like in early industril age.

The idea of providing knowlage of art history and art skills to new generation of programmers may not be so impossible now because the whole burdon of planing upfront, and project management is smaller.

Ron Ruble

Posts: 10
Nickname: ronr
Registered: Aug, 2004

Re: The Interface is the Program, and it ain't Agile Posted: Dec 9, 2006 7:21 AM
Reply to this message Reply
> > Programmers should never ever design user interfaces.
>
> I have a lot of trouble with that statement...
>
> I think your blanket statement is wrong and programmer
> education should include the basics of UI design because
> inevitably they will find themselves doing it somewhere,
> sometime.
>
> More importantly:
>
> Programmers should care about usability is not the
> same as saying they are responsible for designing the UI.

Agreed; one good starting point is that programmers should be trained to realize that designing a good UI requires a different sort of discipline than coding up the back-end work.

I do both UI design and UI-free server code. I have to exercise different "mental muscles" in UI design, often changing perspectives and looking at things from a lot of different angles.

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 10, 2006 12:58 PM
Reply to this message Reply
It's been interesting to read the little explosion of replies that have flourished here in the few days since I posted this. Thanks, everyone, for visiting and for your insights. Let me post some summary replies in this posting.

As regard interface desideratæ, Andy hit it on the head: Invisibility and the Smile. Raskin offers the paradox that an ideally productive interface should be usable by a blind person. "Smile" isn't quite right, but Laurel speaks of the same kind of catharsis one experiences in theatre (Computers as Theatre is a noteworthy work).

As regard to programmers designing interfaces, I think the posts here miss the deeper point, which I'll try to highlight with some lateral insights. First, the developer cannot help but design the interface. The objects show through to the interface; if they don't, the interface is unusable. That's the essence of the direct manipulation metaphor.

The deeper question is one of domain expertise, and this gets sticky. It is true that most programmers lack the domain expertise to build either a productive, humane, or intuitive (I hate that word) interface. But then again most programmers also lack the domain expertise to build software in the domains in which they work: finance, telecom, aerospace, and others. They know Java, and pick up a few things about their business before they move on to another, but few programmers ever become experts in anything important. That doesn't stop them from being good sorcerers' apprentices, and the results in the software logic in these domains are sometimes equally bad. It's probably the number one reason that software is as expensive as it is. Human/machine interfaces are just yet another way in which our industry throws care to the wind and takes a brute-force-Java-will-conquer-all approach to development.

Oh, and then there's the Agile angle. I strongly believe that the fundamental underpinnings of an interface relate to domain expertise and, in particular, to the structure of a domain. This kind of stuff usually doesn't show up in project Use Cases. Use Cases -- as most commonly used -- capture the time domain of requirements. Good GUIs in particular are less sensitive to sequencing and ordering than were there old batch-oriented counterparts: that's because the major organizing principles are spatial (things on the screen, which correspond to domain entities) rather than temporal. That's the major idea behind object-based programming, which emphasizes the identity of the domain entities and subordinates the understanding of process (methods) to that structure. This perspective puts interfaces (and GUIs in particular) squarely in the area of architecture and domain analysis. It's about structure, and about structure that remains stable over time. Why? It goes deep into the users' cognitive model of the business.

By the way, there is a way to use Use Cases to gather some of this stuff, but I've seen it very few times. Don't blame Use Cases or its purveyors for the problem.

This leads to some delicious insights. Analyses of domain knowlege and usability concerns are squarely within the provisions of the Manifesto, but probably follow a much different life cycle than Java code does. Usability people start with a lot more DBWA (design by walking around -- see Beyer and Holtblatt's book, Contextual Design), and that takes time and experience. It is little less than an ethnographic study. These considerations were strong in the Xerox tradition and the most recently surviving nests of usability folks usually had ties to PARC. It's not the kind of thing you cycle on a daily basis. Yes, you need customer feedback and user engagement, but you need more planning, science, measurement, and method than I see the practitioners of popular Agile methods talking about. Read Raskin. Unlike the code that we write to meet requirements, which is an art, much of human/computer interface design can in fact be rooted in science. Just understanding models of short-term memory and habit formation instantly discount the usability of a large percentage of the interfaces out there today.

Given today's dysfunctional software cultures, where most programmers are Java wonks and neither good domain people nor good GUI people, I think that Morgan's (or Ron's) suggestion is the best one: pair the usability person and the coder. The only time I'd be worried about that is when the coder drives. Good usability people bring a much broader, valuable, viable package to the table than coders do, since they bring both domain knowledge and expertise on building systems that enhance the user experience. When we sell software, we sell nothing else -- except perhaps the engineering to support these notions. Why do we invest so much in coders and so little in usability people if these are true?

I think it all comes down to the fact that academia utterly fails at conveying the basics. We teach Java and that's about it. Then industry tries to compensate by coming up with ideas that sound good on the surface but which are nothing but rationalizations. If we take Parag's long, Java-laden post as an example, he suggests refactoring. I can take up the foundations of that statement's architetural repercussions in another post; there is nothing about our experience that bears that out, but we in fact find the contrary. As regards evolving the human interface, it's a ludicrous proposition. All effective human interfaces -- except for occasional-use systems (like information kiosks at Disney) -- depend heavily on habit formation for their effectiveness. If you refactor that out from under your user, you're dead. And, by the way, by the extension of Conway's Law that ties together the interface, the architecture, and the organization, the same inertia applies across all three. You need to do up-front investment to get it right: because the interface must be stable to support habit formation, you cannot refactor it while retaining its usability, by definition. This goes to the deepest psychological foundations of interface design. Modern software doesn't understand that, and a typically naive approach to Agile certainly doesn't.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: The Interface is the Program, and it ain't Agile Posted: Dec 10, 2006 3:42 PM
Reply to this message Reply
James O. Coplien wrote First, the developer cannot help but design the interface. The objects show through to the interface; if they don't, the interface is unusable.

Maybe the interface has already been designed and the developer is being asked to implement the interface exactly as designed.

Back in 1999 Alan Cooper's "The Inmates Are Running The Asylum" spelled this out - 'The central recommendation of this book is that the interaction designer should be the ultimate owner of product quality. He must be allowed to determine the content of behavior of the program. He must own the feature list and, to a large part, the schedule. This person is the advocate for the user, and should have the authority to control all external aspects of the product.'

Since "About Face 2.0: The Essentials of Interaction Design" appeared in 2003, others have adopted and promoted Persona based design - "The User Is Always Right: A Practical Guide to Getting and Using Personas for the Web", "The Persona Lifecycle: Keeping People in Mind Throughout Product Design".

Where programmers fit into this picture was spelled out back in 1999 - '... our charter was to make the program easier and more powerful for end users, and that we were fully aware that our design decisions would entail significant additonal thinking at the program level. ... "You are providing me with a significant technical challenge!" ... we brought to him the grail of all programmers: a difficult problem worth solving.'

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: The Interface is the Program, and it ain't Agile Posted: Dec 10, 2006 3:48 PM
Reply to this message Reply
James wrote:
> the interface must be stable to support habit
> formation, you cannot refactor it while retaining
> its usability, by definition. This goes to the deepest
> psychological foundations of interface design.

I just want to enlarge on James' point here and disagree a little.

Firstly, stability in some aspects doesn't mean an interface cannot evolve.

For example, at CSIRO I'm involved in an interface to help modellers describe multi-domain scientific models that will be run using local apps or submitted for grid processing. Much of the UI is auto-generated based on selections of modelling code or other workflow decisions.

The style of the interface is consistent.

The behaviour of some rich elements is consistent and the overall navigation scheme is relatively stable.

The parts that vary are intuitable based on experience with common Windows user interface elements and this application in particular.

The interface can evolve but it should not revolt!. :-)

This is not a big deal.

I don't think people (should?) expect to do Agile development and make radical changes to their overall architecture or other aspects of design philosophy or development environment.

Similarly, change to the user interface should be applied with such a gentle hand that people will argue later that it's always worked like that!.

Secondly, radical refactoring of an interface in the same sense as refactoring a class structure, hoisting methods and renaming items, may sometimes be justified. Rather than talking about bad smells in code, I think a better metaphor in UI is stubbed toes. The reasons for change being really needed are most likely to be people tripping over bits of the workflow, being blocked from achieving their job or generally stressed by using the system.

Even in this case, some consistency should be preserved. Imagine telling the user things work the same but we moved Foo out of the way - it's over here now but it still works the same too.

If you are refactoring a UI, the secret to where to cleave is to think of chunking. Similarly to how you might refactor a set of classes, moving coherent, related methods into a different class, look at how people do their jobs and the information they need at a given point.

The sense of aesthetics you can develop for an elegant software architecture is very close to that for a usable interface.

Note: One of the classic flags to indicate real problems with an enterprise system is the regular entry of dummy values to get through a workflow when you don't have all the data the program requires.

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-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use