[Design] Gloabl UI Design

[Brad Lauster]

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