[Design] Gloabl UI Design

[Mimi Yin]

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