That isn't the "delete contact" button. Did he even try it? The "delete contact" button is in the toolbar, which makes perfect sense. The trash can next to the name field simply clears the name field. So why not always show it? This is not just the "edit contact" screen, it's also the "view contact" screen, and cluttering it up with trash cans next to every field would absolutely detract from the scannability of the page when you're not editing. Why not have separate pages for viewing and editing? That's bad for usability too; it invites mode errors.
And right there you define where you should and shouldn't use roll-over based UI elements: if a UI element is only useful as part of interacting with another, then hiding it in other situations makes sense (e.g., clearing a text field as part of editing the text in the field).
Context sensitivity is a great justification for hidden elements. Litter your page with visible edit buttons and, in a poorly designed UI, you might forget what part of the page each edit button binds to.
It makes sense to show only some controls when your mouse or cursor is focussed in the right place, because then you know those controls are relevant to what you're doing.
What I think was overlooked with the two examples - Github and google - is the replacement of text-based controls with icon-based ones. Github's top nav is now just tiny icons, the Google pages are all icons. You can barely tell what these are unless you hover over them long enough to see an explanation. This is the real problem, I think.
Comments
That isn't the "delete contact" button. Did he even try it? The "delete contact" button is in the toolbar, which makes perfect sense. The trash can next to the name field simply clears the name field. So why not always show it? This is not just the "edit contact" screen, it's also the "view contact" screen, and cluttering it up with trash cans next to every field would absolutely detract from the scannability of the page when you're not editing. Why not have separate pages for viewing and editing? That's bad for usability too; it invites mode errors.
And right there you define where you should and shouldn't use roll-over based UI elements: if a UI element is only useful as part of interacting with another, then hiding it in other situations makes sense (e.g., clearing a text field as part of editing the text in the field).
Context sensitivity is a great justification for hidden elements. Litter your page with visible edit buttons and, in a poorly designed UI, you might forget what part of the page each edit button binds to.
It makes sense to show only some controls when your mouse or cursor is focussed in the right place, because then you know those controls are relevant to what you're doing.
What I think was overlooked with the two examples - Github and google - is the replacement of text-based controls with icon-based ones. Github's top nav is now just tiny icons, the Google pages are all icons. You can barely tell what these are unless you hover over them long enough to see an explanation. This is the real problem, I think.