I think the article's explanations for button-ordering are good but I wish their examples didn't violate other dialog design principles in the process. One mis

I think the article's explanations for button-ordering are good but I wish their examples didn't violate other dialog design principles in the process. One mistake their examples make is to include an "X" (close) button in dialogs that contain button choices. The "X" action is ambiguous in dialogs and is especially bad if all actions are equally probable (e.g. "Don't Save", "Cancel" and "Save" all seem likely to map to "X"). GUI toolkits don't seem to force any consistent interpretation of "X", and in fact the programmer might forget to wire up the "X" to any action at all. It's preferable for the "X" button to not be there so that the user can focus on the action buttons. Another (admittedly minor) issue is the spelling "Ok". It's not pronounced "awk" or "oke"; it's both spelled and pronounced "OK". It does have a whole-word form and that word is "Okay". So it can either be "OK" or "Okay" but it should not be "Ok". In dialogs it is very conventional to use the short form of "OK".