Dialog Buttons - Primary, Secondary, Disabled

[Scott González]

The new CSS framework supports primary, secondary and disabled buttons.  However, there is currently no way to set these properties on buttons added to dialogs.

The current implementation is:

$(el).dialog({
    buttons: {
        foo: function() {},
        bar: function() {},
        baz: function() {}
    }
});

We should probably expand this to allow you to set additional properties on the buttons:

$(el).dialog({
    buttons: {
        foo: {
            priority: 'primary',
            enabled: true,
            callback: function() {}
        },
        bar: {
            priority: 'secondary',
            enabled: true,
            callback: function() {}
        },
        baz: {
            priority: 'secondary',
            enabled: false,
            callback: function() {}
        },
    }
});

We would have defaults:
type: secondary
enabled: true

We could also support the current and new syntax simultaneously:

$(el).dialog({
    buttons: {
        foo: {
            priority: 'primary',
            callback: function() {}
        },
        bar: function() {},
        baz: {
            enabled: false,
            callback: function() {}
        },
    }
});

Questions:
Should there always be a primary button?
Should pressing enter on a field that would normally submit perform the primary button's action?
Should we support differentiating between primary and default?  I personally find this behavior extremely annoying in OS X.

[Todd Parker]

I'm glad we're plumbing this in now. This morning Scott has started a
overview of the API here in the wiki:
http://jqueryui.pbwiki.com/UI-CSS-Framework

>
> Questions:
> Should there always be a primary button?

We've created this distinction between primary and secondary mainly to
provide visual emphasis when we have more than one button in a dialog
(Save/Cancel). If there is only a single button (Ok) as is the case in
an informational dialog, it would not necessary be marked as primary
unless we wanted to implement your idea of the Enter key mapping.

> Should pressing enter on a field that would normally submit perform the primary button's action?

This should definitely be an option because it is a common convention.
For example, a normal alert() dialog would be so annoying if you
couldn't use the Enter key to close it. It would be nice to be able to
turn this on or off globally for all dialogs, then override for an
individual instance or type of dialog as needed. By default, maybe
this should be on.

> Should we support differentiating between primary and default?  I personally find this behavior extremely annoying in OS X.

Really? You're annoyed that the cancel button is less prominent than
the positive action? At this stage, it's a best practice in UI design
and is used in Vista, OS X, Umbuntu, etc.

http://msdn.microsoft.com/en-us/library/aa511327.aspx#taskdialogs
http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGControls/chapter_19_section_3.html#//apple_ref/doc/uid/TP30000359-TPXREF186
http://blogs.zdnet.com/Bott/?p=496

Luke W, who is now Yahoo's UI guru and author of a book on form design
has a really good writeup on the theory and user testing behind this
principle:
http://www.lukew.com/resources/articles/psactions.asp

[Scott González]

On Tue, Dec 9, 2008 at 11:18 AM, Todd Parker <fg....@gmail.com> wrote:

> Should we support differentiating between primary and default?  I personally find this behavior extremely annoying in OS X.

Really? You're annoyed that the cancel button is less prominent than
the positive action? At this stage, it's a best practice in UI design
and is used in Vista, OS X, Umbuntu, etc.

It's not the differentiation between primary and secondary that annoys me.  It's the fact that in OS X the primary action is not always the default action.  For example, in a dialog that has Save and Cancel, Save may be the primary action, but Cancel is the default action.  That drives me nuts.  If a dialog pops up and one button is solid blue, one button is silver, and one button is silver with a blue border, my attention jumps to the solid blue one and I think that if I press enter, that action will occur.

The problem stems from Apple's choice of how to highlight primary and focused, but the problem wouldn't occur if the default was not allowed to be something other than the primary.

[Richard D. Worth]

On Tue, Dec 9, 2008 at 10:59 AM, Scott González <scott.g...@gmail.com> wrote:

We should probably expand this to allow you to set additional properties on the buttons:

$(el).dialog({
    buttons: {
        foo: {
            priority: 'primary',
            enabled: true,
            callback: function() {}

what about

click: function() {}

instead of

callback: function() {}

click might be the only event we need for a dialog button, but calling it callback doesn't seem like a very flexible convention across other plugins/elements.

- Richard

[Todd Parker]

I see your point. I believe they are doing this in a destructive
confirmation situation to make it harder for you to accidentally
delete something without using the tab key or mouse to consciously
select the positive (delete) action. In a save confirmation, I believe
that the primary button with focus is actually Save, not Cancel
because they are always skewing towards minimizing accidental loss of
data. It's the inconsistency that you're annoyed by, but it may have
saved your neck at one time or another.

In any case, it is the developer's choice on what is primary in any
given UI and these new styles will help them out.

I wanted to mention that we need a more flexible way to dealing with
alignments for the button grouping (left vs right) and the buttons
within. Right now in the dialog, the button group is aligned right but
buttons are in the order of primary | secondary like Windows. On a
Mac, they use secondary | primary so the primary is the rightmost
button.

I don't want to tell people how to build their buttons (I sometimes
use left aligned buttons, with primary to the left) but we should
support different group alignments (left/right) and control of the
sequence and priority (primary/secondary) for the individual buttons.

Ideally, this would be driven off css. For a default, I might want to
recommend the Apple style button order, but our example pages should
show a range of options. It all depends on the larger UI system the
designer is building.

On Dec 9, 11:43 am, "Scott González" <scott.gonza...@gmail.com> wrote:

[Richard D. Worth]

For simplicity I think we should put the buttons in the order the user specifies. POLS (Principle of Least Surprise), and it allows them to easily build to either convention/system type/audience. Do you have an idea of how we would do it otherwise? In terms of API/css?

- Richard

[Todd Parker]

I think that is fine, so essentially the button group is right aligned
by default (and changeable via css) and the buttons will appear in the
order listed, from left to right?

On Dec 9, 12:11 pm, "Richard D. Worth" <rdwo...@gmail.com> wrote:
> For simplicity I think we should put the buttons in the order the user
> specifies. POLS (Principle of Least Surprise), and it allows them to easily
> build to either convention/system type/audience. Do you have an idea of how
> we would do it otherwise? In terms of API/css?
>
> - Richard
>

[Richard D. Worth]

Yeah, that's what we've got now. Seems to work alright.