|
Re: The Interface is the Program, and it ain't Agile
|
Posted: Dec 10, 2006 12:58 PM
|
|
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.
|
|