Alec Flett wrote:
I feel like we're walking down the path of trying to apply all
heuristics as law, and apply them all the time. The above statement
("good software shouldn't...") is an opinion, not a fact.
True. "Good software" implies a qualitative judgement on my part.
What I should have said was:
At the level of keystroke analysis, using the GOMS model, software
without confirmation dialogs is *always* more efficient than software
with confirmation dialogs, if the software is also designed such that:
1. Users can't do things that would cause them harm
and/or
2. Any potentially harmful action is readily reversible
Relating this back to Chandler and other OSAF designs: If you really
want an innovative interface, then getting rid of the confirmation
dialogs seems like a good place to start, for a few reasons:
1. It'll be less work than other interface innovations that come to
mind (zoomable UI, for instance)
2. Along with less work it likely won't even require the development
of new widgets, just a different flow for the parts of the
application that use dialogs (and probably a more robust Undo feature)
3. We can already prove that it'll result in a more efficient interface
No matter how the OSAF chooses to innovate in the area of user
interface, I like Alec's recommendation:
if we're going to break from the standards of any platform, lets
throw caution to the wind and break it everywhere...
You can't innovate by copying what's already been done and frankly,
it just doesn't make sense to follow design guidelines that you
already know are flawed.
Cheers,
Brad Lauster
The simple "fact" is that I never notice that the "Ok" button is on
one side or the other on one platform or another. I always click
with my mouse on whatever button says whatever I want. Does that
mean that nobody cares about that? No, because clearly Nick and
many many other people do. But flipped around, does the fact that
Nick pays close attention to where Ok and Cancel mean that every
user is going to get up in arms if we screw that up? No. And
ultimately, is the placement of Ok and Cancel a hard problem? I
would hope that for the sake of this argument, that's a No as well.
The real issue here is not the placement of Ok and Cancel, the real
issue is how closely to the platform do you write your XP app? I
think an orthogonal, but perhaps more important question is, how
much do you break ANY platform's heuristics in order to create new,
innovative UI. And if you're breaking the Mac's heuristics to try
an innovative UI, does it really matter if you're going to break
windows and linux as well?
I think the perfect example of this, that we're all familiar with
now, is the back/forward buttons in browsers. When Netscape 4 (or
was it 2/3?) came out, it had these funky buttons in the toolbar
that when you clicked once they did one thing, and when you held
down the button, a dropdown history list appeared. They did this on
all 3 platforms and it didn't follow the heuristics of any of these
platforms. It got mixed reactions. Microsoft iterated on this
behavior and added an actual dropdown arrow to the right of each
button, and it turns out users prefered that. But in any case both
of these designs were obviously breaking the heuristics of
Microsoft's own platform. This new design However, Netscape's
initial innovation spurred development of this new button-dropdown
hybrid. This is now standard fare for most browsers on all three
platforms. In fact it has become part of the defacto heuristics for
writing a browser.
So my point is this: if we're going to break from the standards of
any platform, lets throw caution to the wind and break it
everywhere... and not be afraid of where the Ok/Cancel buttons are
going to land.
Alec
UI designers should be able to either:
1. Make sure users can't do things that would cause them harm
or
2. Ensure that any potentially harmful action is readily reversible
Following either of these paths makes the issue of Ok/Cancel
button placement a moot point. But let's say a case arises where
you absolutely must have a confirmation dialog...
In this case, putting the buttons in the same place every time
merely creates another problem. That is, the consistency
encourages the user to form bad habits.
I have six SSL certificate warning dialogs that appear every time
I start my email program. These dialogs are useless because I no
longer read them; I just keep clicking Continue until they all go
away. If a new message were ever to appear in one of those
dialogs, I'd never know because of the habit I've developed.
Of course, if we step back, we can find places where consistency
in interface design can help create good habits, like always
putting the Send button in the same place on the "compose a new
message" window.
I guess my point is that it's more important to understand the
phenomenon of habit formation as it relates to interface design,
than it is to blindly follow the norm. Many applications are as
terrible as they are because they've copied the terrible designs
that came before them without understanding the underlying phenomena.
...and now for some Friday fun. A truly useless dialog:
http://www.flickr.com/photos/bubbahotep1/64547469/
Have a great weekend!
Brad Lauster
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
