 |
« | Week of May 18 | < | Individual Entries | > | Week of Jun 1 | » |  |
 |
 |
Comparing Complexities: Interface Designs and Code
design, software development, usability
May 30, 2003, 11:21 AM
I was reading Jacob Nielsen's Alertbox yesterday, and noticed he made an analogy I've frequently used myself; he compared interface design to software development to demonstrate the folly in assuming that good designers shouldn't have to user test their interfaces. The argument goes that you wouldn't make the claim that "good software developers should be able to write perfect code on the first try, so why should they have to waste time writing and running tests", would you? Interface design is just as complicated as software development, so why would you assume good interface designers should be able to pull perfect interfaces out of their butts without testing and iterating on the design?
This got me thinking about whether it would be possible to make this argument stronger by semi-objectively comparing interface design complexity with code complexity. Obviously the standard code-complexity metrics (lines of code, function points, etc.) don't apply to interfaces. But what we really want to measure here is "how many things could you potentially screw up?", i.e., could fail in testing. I'll call these things "complexity points" for lack of a better term.
For code, an example of complexity points in a function might be "null pointer passed in and dereferenced" or "array accessed out of bounds", basically, any state that would violate the preconditions, post conditions, or invariants if you were using Design by Contract. For interface design, example complexity points might be violations of Nielsen's heuristics, failures in a Cognitive Walkthrough (interface elements that aren't visible, labels that don't describe the function, etc.) or potential violations of a Think-Aloud critical incident. Obviously no objective procedure could hope to turn up all the complexity points either in source code or interface designs (it'd be great for humanity if we could, although all the software developers and interface designers in the world would get replaced by computers), but perhaps there is some way of approximating the complexity point count for interfaces and source code for the sake of making a rough argument.
As a side note, I'd read Jacob's column more often if he had an RSS feed...
On Cooperation and Understanding Others
society & sociology, systems
May 29, 2003, 03:50 PM
An important skill to cultivate if you wish, like me, to make a difference in the world is the ability to put yourself in the position of the people you must work with so that you can understand clearly what their motivations are, what external forces are influencing them, and why they act the way they do and make the choices they make. Here's why.
Psychologists have known for a long time that although we humans have a tendency to blame our own failures on external forces beyond our control ("I bit Bill's head off because I had to sit through rush hour traffic this morning, but I'm not an irritable person", "I did a bad job on the paper because I didn't get enough sleep last night, but I'm still an excellent researcher"), we have a tendency to blame other people's failures on their personal character ("Jack's a jerk; he yelled at me for a friendly joke!", "This is the third crappy paper Jill's put out; she's a lousy researcher!"). But this tendency blinds us to the fact that all people work within systems; they are all part of a larger whole that includes the other people they work with, the physical environments they live in, the technologies they use, etc. These systems define what these people must do (if they wish to maintain social and material standing), what they want to do (if they wish to improve their lot in the system), and what they cannot do (if they wish to avoid censure or some other punishment).
When someone opposes your goals you might be tempted to think that person is uncaring, or incompetent, or evil, when in reality they simply have external influences affecting them that you may be unable to see. More often that you might think, people with good intentions are hamstrung by systems that are not designed to support those intentions, or even designed to actively oppose them. It takes careful thought and empathy to fully understand such a situation; a surface analysis never turns up everything.
If you can't understand the larger systems that exist behind the people you encounter and how these systems are influencing them, you will be quick to demonize the people around you, to write them off as foolish because that's simpler that trying to understand the complex reality. But when you must work with these people, this only serves to foster a competitive environment where everyone is out for themselves. The only way around your coworkers is through them.
On the surface, this may seem faster. Surely fighting for what you know is right is faster than talking and compromising and working together (at least if you win). But the assumption here is that your ideas will work "out of the box", that the world would be a much better place if only everyone listened to you. This is patently false, no matter who you are. No one's ideas will work right off the bat because no one is in a position to see the whole world for what it is. There will always be complications, always a need to iterate and improve. Cooperation seems slower only because you are actually seeing these iterations in progress; you're constantly making small mistakes and small corrections as everyone checks and balances each other. But if you chose to compete, then each iteration requires a whole process of taking sides, building armies, fighting, killing (hopefully metaphorically), etc., just to have a bunch of new ideas put in place that frequently turn out to need just as much iterative improvement as the old ones did. If you think long term, if you keep your eyes focused on the ultimate goal, then antagonism is almost always an unnecessary distraction that gets in the way of real progress.
All this isn't to say that people's values are not important, but values alone don't tell the whole story. I can value intellectual openness, but if my bread and butter is coming from selling my work by the copy then I'm not going to embrace eliminating IP laws. I can value saving the environment, but if I feed my family with money I earn from a logging company, I'm not going to support stricter deforestation regulations unless you can convince me my needs will be taken care of. If you refuse to see the system people must work within, then you won't win them over to your side. You don't understand them. And no cooperation can occur without understanding.
In the end, all real progress occurs through cooperation. If you can't understand the needs of the "other side", then everyone's goals will suffer, regardless of the outcome.
Posted by Geoff on May 31, 2003 at 02:13 AM
Well shit, bro. You just solved all the world's problems. Take an extra coffee break today. No, I'm serious. This is one of those obvious ideas that isn't actually obvious, because while most people will listen to it and say, "Well of course that makes sense," (and if they don't, they haven't paid any attention to the world around them) they won't ever sit and think critically about how this might apply to their own actions. If everyone in the world read this short blog entry and really critically applied it to their own lives, then... Well, to be honest, I don't know precisely what that would mean. It's 2 AM on a Friday night and it's been a very long week. But something good. Metaphorical fuzzy bunnies and rainbows. The rainbows are metaphorical too, like the bunnies.
For more on understanding the needs of the "other side," I recommend The Lexus and the Olive Tree, by Thomas Friedman. He doesn't talk about this specifically, but it's the view he takes throughout the book as he tries to understand what's best for the world and why nations act the way they do, among other things.
(Please note that I blame my incoherency on lack of sleep. I'm actually a very coherent person.)
Posted by Rob on June 01, 2003 at 02:12 AM
Yo bro,
Yeah, I know it sounds good on paper, but doesn't seem to get implemented too often. I wanted to say it anyway though.
I remember you mentioning "The Lexus and the Olive Tree" before. I really wanted to read it then, and I want to read it even more now. It's officially on my reading list (come to think of it, maybe I really should keep a reading list so I don't forget about all these great books I keep hearing about).
Posted by Rob on June 01, 2003 at 02:14 AM
Just to tack it on, Micah commented on this post over on his weblog: http://www.alpern.org/weblog/2003/05/31.html#a700
Think of this as a manual trackback. Sadly, it's probably easier than doing an automatic trackback...
Email Rob:
Prescriptive Interfaces Explained
design, processes & methodologies, usability
May 27, 2003, 02:16 PM
A couple days ago I mentioned that I was interested in "normative interfaces" as part of the single-sourcing paradigm idea. I've thought it through some more and decided I liked "Prescriptive Interfaces" better as a monkier (best practices frequently aren't very normative since they're often not the norm...) and that I'd like to expand on some of the points I made in that post.
In a way, the term "prescriptive interface" is a tautology; all interfaces are technically prescriptive since they necessarily predefine some method of interaction with the system. The interface defines what commands the system understands and what form it can present information in, and thus any interface dictates some method or range of methods the user must use to perform their tasks and accomplish their goals. Techniques like CI/CD help us design interfaces that prescribe methods of interaction the user is already familiar with through their existing work, while improving on the existing methods by fixing the breakdowns identified by the design team.
The interesting question, however, is how do we design interfaces that encourage users to work in the smartest way possible, as defined by the techniques developed by long-time experts in the field who have applied them successfully in many different situations. In the software engineering world, these are known as "best practices". One best practice in software development is unit testing your code. One best practice in technical writing is writing an outline before starting the document, as I mentioned before. One best practice in HCI is low-fi prototyping your interfaces to elicit real user test data as early as possible.
A prescriptive interface, then, is an interface designed to encourage the use of best practices, to make it easy (or at least easier) to solve the problem in the "right" way. One example of an interface that did this well is the original Apple GUI toolkit. At the time, there were no high-level GUI toolkits available so programmers wrote the code to implement all their own widgets, thus the buttons, text boxes, menus, etc. in every application looked different, which proved confusingly inconsistent to the user. Apple's genius was in providing a toolkit that not only enforced a consistent look and feel on their platform, but actually made the application programmer's job easier as well. This encouraged programmers to use Apple's toolkit instead of rolling their own, and thus Apple wound up with a remarkably consistent-looking and usable platform for the day. An example of an interface design that does this poorly is Microsoft Word's styles support. Writing a document using styles is hard; the user must first know that styles exist and what they are for, then must go into the styles dialog to edit these styles to make them look the way they want, consistently apply them where they are appropriate, etc. The interface makes it much easier to just hit the "Bold" button up in the toolbar to define a heading than to try to do it with styles.
Ideally, prescriptive interfaces should make it easier to solve problems the right way than it is to solve them the wrong way. Failing that, they should try to make the right way as convenient as possible, and may even consciously make the wrong way just a little bit more difficult. If done right, this approach has potential benefits for both novice and expert users. The interface helps novices learn the best practice approaches to solving their problems in the context of doing their work, which is much more effective than formal training. The interface helps experts by making the best practices they already know much easier to follow; even though I know styles are an overall better approach I frequently don't use them in Word simply because it's such a pain in the butt.
So now that you're convinced that prescriptive interfaces are a good idea (I hope), the question becomes, "How do we design these things?" Here's my thoughts on a rough process:
- Identify the best practice approach to solving the problem. This may require reviewing relevant academic or trade literature in the domain, but I would guess that the most important practice would be to ensure you have one or more domain experts on the design team who have experience applying the best practices and can advise your design accordingly.
- Research how users currently solve the problem in their day to day work by using a requirements collection method like Contextual Inquiry. Merely understanding how users ought to work is useless if you don't understand how they really do work and why.
- Design your interface to define clear transitions and adaptations between how users currently work and the best practice solutions. The interface may need to have a sizable teaching component; collaboration with the learning technologies people may help with this part. Unfortunately I don't have much more guidance to provide here; this is definitely the hard and unexplored part of this technique.
- Allow users to circumvent your best practice processes, but discourage this as much as possible. Be mindful that your ideal solutions may not fit all situations, but make sure the users don't decide to deviate from the best practices idly.
- As always, do lots of user testing to make sure it works! Testing is particularly important when you're trying to impose a new way of working. Your assumptions will probably be wrong at first; they'll need to be tested and refined even more than normal interface designs before the concepts are nailed down. Low fidelity testing is probably particularly important since drastic changes in the design may be necessary to fix the breakdowns.
So those are my thoughts as they stand. In conclusion, the goal of prescriptive interface design is to produce products that afford best practices within their domain just as they afford proper use of themselves. A good prescriptive interface builds the experience of experts into the system itself so that even novices can experience that benefits of expert-level productivity "out of the box".
Email Rob:
Single-Sourcing, Outliners, and Normative Interfaces
design, processes & methodologies, usability
May 25, 2003, 09:18 PM
I've posted before about the single source paradigm and the separation of presentation from semantic content. I've been working with Word's outline mode a lot recently and have started to see how using an inherently structural view like an outline to edit content could be the key to providing a usable presentation-agnostic content management system like I described before.
When you create an outline for a document, a presentation, etc. you are basically considering only the structural and semantic aspects of the work. Your purpose is just to lay out the content and get a sense of how your thoughts decompose into supporting points, how your arguments fit together, etc. After you've finalized the outline, you'll worry about making sure the document flows well and looks good by defining the appearance of headings, putting in figures and messing around with how the text flows around them, changing the pagination, etc.
The important part about this process is that the entire time you're focused only on the structure of the work, deferring the definition of the presentation until later. And this is an example of a natural human workflow that people engaged in long before they had computers, so it makes a nice metaphor for the computer-supported single-content paradigm. So the question becomes, can we design interfaces that build on this metaphor to encourage semantic definition of documents, rather than only providing a WYSIWYG style interface that encourages tying content to presentation? And can this metaphor be extended even to such vastly different presentation decisions like whether to publish a printable document, a web page, or a slideshow presentation?
When I brought this up to Micah, he mentioned that Dave Winer, the creator of Radio Userland, has been interested in outliners and the single-source paradigm for years. I'll have to set aside some time to read Scripting.com to see what his thoughts on the subject are.
This whole concept ties into another area I'm interested in; how do we as software designers develop interfaces that encourage our users to follow predefined best practices? Basically, the idea is that certain workflows can be inherently more productive than others, but users may be following a less-than-optimal work flow in their current practice. For example, most technical writers agree that creating outlines before working on a final document produces better-structured prose than just sitting down and writing (I even try to sketch out "mini-outlines" when I toss together these weblog entries). But many users of Word don't do this; they just sit down and start typing. How can we encourage people to follow the superior practice by making it easier than the alternative? In essence, how can we design "normative interfaces"?
Most HCI techniques help us get at the ways our users think and determine what would be intuitive for them, but don't help us design interfaces that help teach users a better way of working. Solving this problem may prove to be an important component of getting people to think structurally so the full benefits of the content-presentation separation paradigm can be realized.
Email Rob:
Email Rob: