 |
« | Week of Nov 16 | < | Individual Entries | > | Week of Nov 30 | » |  |
 |
 |
A Splintered Psyche
personal, psychology
November 29, 2003, 02:57 PM
This entry is private. Forgot the password? Ask the Keymaster!
A Naked User Interface
design, software development
November 27, 2003, 01:40 PM
Dave Thomas, one of the Pragmatic Programmers, has an interesting ramble on his weblog that covers a variety of topics of interest to user-centered designers. His analysis of Raymond's discussion of X windows and its lack of imposition of a standard look-and-feel versus the Windows / Mac approach of imposing lots of constraints and standards on interface design is quite interesting in its own right. I'll leave it as an excercise for the reader to reflect on whether the X windows framework is truly independent of human factors and interface design, as Raymond claims (given my writings on the impact of software architecture on usability, you might be able to guess where my feelings lie...).
What I want to focus on, however, is Dave's discussion at the end of "Naked Objects". Naked Objects are a pattern for structuring a software application that has huge implications for interface design but which hasn't gotten much press in the interface design community. As some of you may already know, most software code is structured in terms of objects, software modules that aggregate data structures and the procedures that operate on those data structures. Some of these objects appear directly in the domain the software is being developed to support; for example, a web storefront system will probably include objects like "Product", "Customer", and "Order". Other objects are more esoteric and relate more to technical implementation considerations than the domain itself, but for our purposes we can ignore these and concentrate on the "domain objects".
In a Naked Objects system, the "user interface" of the application as it is commonly conceived is stripped away; instead the system provides a minimal UI that allows users to create, destroy, and manipulate domain objects directly. Now I know many of you are thinking this sounds crazy, but there are a few advantages:
- Exposing the object model to the users ensures a match between the development team's metaphors and the users' metaphors, which provides a shared language for both stakeholders. I've advocated this in the context of XP, but it's important regardless of the development methodology. This has the additional benefit of allowing for user feedback on the domain model as well as on the interface design; most interfaces hide away the domain model which prevents users from commenting on it except in the context of abstract engineering diagrams.
- In a way, Naked Objects is the ultimate minimalist user interface. The designer provides only the bare essentials, fleshing out the tasks is left up to the users themselves.
- Since the user experience design is intimately tied to the internal software design, this approach ensures close collaboration between the interface designers and the software developers, something that doesn't happen often enough in practice.
- Naked Objects eliminates lots of user interface code, which leads to lower cost (less code must be developed, requiring less expensive developer time) and higher reliability and maintainability (less code is easier to test and modify).
- Naked Objects potentially allow for much greater user control over the system than conventional interfaces. In a Naked Objects system, the user defines the ways the objects work together to accomplish her tasks; the tasks aren't "pre-canned" for her by the interface designer. This also allows her to work in ways that the designers did not forsee or intend. Note that this is the basic problem confronted by designers of interfaces that support creativity.
- This level of user control transforms the user from a follower of a proscribed process into a solver of problems. This is the difference between mechanism and policy that Dave's post focuses on. In some domains, this may lead to greater user satisfaction since people prefer to actively solve problems rather than mechanically follow algorithmic task flows.
- It's potentially easy to create both a Naked Objects and a conventional interface for the same application, to provide more power for experts while still giving guidance to novices. Dave mentions the difference between the Mac Aqua interface and Darwin's command line shell as a similar approach.
One might wonder if a Naked Objects system really requires an interface designer, since it appears to have so little "interface" to design. I'd guess that it would, however, both to ensure that the interactions used to create and connect objects are simple and intuitive and to ensure that the naming and behavior of the objects themselves are appropriate. So given that designers are necessary, what techniques would they use to design such systems? And what systems might a Naked Objects approach be appropriate for? My guess is that experts would benefit more than novices, since Naked Objects gives very little task guidance and assumes a great deal of familiarity with the domain. As I mentioned above, perhaps interfaces that support creative tasks are a good candidate. In a way, the direct manipulation paradigm found in Photoshop and other graphics packages is a similar approach.
I'd encourage designers to seriously consider these questions, for I think this approach is interesting and may be more applicable than it initially appears. It also shows that sometimes interesting interface ideas come out of the software development community as well as the usability / interaction design community.
Email Rob:
Zen and the Art of Interface Design
design
November 23, 2003, 12:37 AM
I've recently been reading "Zen and the Art of Motorcycle Maintenance", a fascinating, deeply insightful novel that delves into such philosophical areas as the nature of thought, reason and emotion, the role of technology, and the definition of quality. Midway through the book, the narrator is discussing a set of assembly instructions that begin with "Assembly of Japanese bicycle require great peace of mind".
Peace of mind isn't at all superficial, really," I expound. "It's the whole thing.... What we call workability of the machine is just an objectification of this peace of mind. The ultimate test's always your own serenity. If you don't have this when you start and maintain it while you're working, you're likely to build your personal problems right into the machine itself.... The test of the machine is the satisfaction it gives you. There isn't any other test. If the machine produces tranquillity it's right. If it disturbs you it's wrong until either the machine or your mind is changed. The test of the machine's always your own mind. There isn't any other test.
If that doesn't speak to the aims of human-centered design, then I don't know what does.
Posted by Dan on November 23, 2003 at 09:40 AM
He's talking about human-centered design, just not user-centered design because he is approaching the problem from the viewpoint of the designer and the end-user. It's really all about Ontological Design
http://www.odannyboy.com/blog/cmu/archives/000731.html
That is, creating things that affect the whole system of human experience.
I need to go smoke some pot now.
Email Rob:
Email Rob: