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.
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.
> 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.
On Tue, Dec 9, 2008 at 11:18 AM, Todd Parker <fg.t...@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.
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.
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:
> On Tue, Dec 9, 2008 at 11:18 AM, Todd Parker <fg.t...@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.
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?
On Tue, Dec 9, 2008 at 11:56 AM, Todd Parker <fg.t...@gmail.com> wrote:
> 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:
> > On Tue, Dec 9, 2008 at 11:18 AM, Todd Parker <fg.t...@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.
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
> On Tue, Dec 9, 2008 at 11:56 AM, Todd Parker <fg.t...@gmail.com> wrote:
> > 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:
> > > On Tue, Dec 9, 2008 at 11:18 AM, Todd Parker <fg.t...@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.
On Tue, Dec 9, 2008 at 12:32 PM, Todd Parker <fg.t...@gmail.com> wrote:
> 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
> > On Tue, Dec 9, 2008 at 11:56 AM, Todd Parker <fg.t...@gmail.com> wrote:
> > > 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:
> > > > On Tue, Dec 9, 2008 at 11:18 AM, Todd Parker <fg.t...@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.
