I'd like to echo Alec's sentiments about heuristics. I think
oftentimes, we take them too literally, when in reality, heuristics
must be considered in the context of the design they are being
applied to.
For example, the heuristic that confirmation dialogs are a bad idea
is perhaps more often than not true, but I think heuristic is perhaps
more nuanced than that?
If the user can undo their action OR if their action is not of great
consequence OR if it's something the user does all the time, (ie.
dragging an item into the trash), then confirmation dialogs just get
in the way.
However, there are instances where users complain the lack of a
confirmation dialog. (ie. when using mass mailers to send out
thousands of emails at the click of a single button.) In such cases,
users actually want even more onerous workflow roadblocks than just
an Okay, Cancel. They want a timed confirmation dialog that gives
them 10 seconds to hit cancel even after they've selected Okay.
This is why I think we have to take the middle-road on the issue of
following platform guidelines. It's simply too hard for any human
being or group of human beings, not matter how experienced or how
bright to think of every single design context that may or may not
come up. As a result, the guidelines should be respected as much as
possible, but also taken with a grain of salt and considered within
the specific context of the design.
Mimi
On Nov 18, 2005, at 3:40 PM, Alec Flett wrote:
Brad Lauster wrote:
Hi Nick,
I'm struggling to find the best way to respond because the fact
is, good software shouldn't have confirmation dialogs in the first
place.
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.
Heuristics are guidelines, best practices, not law. (Though to be
fare, every good XP project has to have this same debate at least
once in its lifetime...:))
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
On Nov 18, 2005, at 10:21 AM, Nicholas Bastin wrote:
Button placement may be visual design, but it should be immutable
based on the platform you're on, because it figures significantly
into the 'feel' of the application. On Win32, the cancel button
is the rightmost button, and the OK button is to its' immediate
left. On MacOS, the OK button is the rightmost button, with the
Cancel button immediately to its' left. Application designers
who care about 'feel' have no latitude on the placement of these
buttons. Flipping them because you like it 'visually' isn't
going to help the user who has been trained to their position
through every other application on their platform. Button
placement has a lot more to do with 'feel' than 'look'.
--
Nick
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
