Buttons - Revision history

Kirabug at 20:43, 10 June 2022

2022-06-10T20:43:43Z

← Older revision		Revision as of 13:43, 10 June 2022
Line 45:		Line 45:
	== Additional resources ==		== Additional resources ==

	* [https://medium.com/alistapart/color-you-responsible-33fc780b495b#.e13icz31w Color You Responsible] - an A List Apart article on button colors		* [https://medium.com/alistapart/color-you-responsible-33fc780b495b#.e13icz31w Color You Responsible] - an [[A List Apart]] article on button colors
	* [https://www.smashingmagazine.com/2016/05/an-ultimate-guide-to-css-pseudo-classes-and-pseudo-elements/ An Ultimate Guide to Pseudo-Classes and Pseudo-Elements] by Smashing Magazine		* [https://www.smashingmagazine.com/2016/05/an-ultimate-guide-to-css-pseudo-classes-and-pseudo-elements/ An Ultimate Guide to Pseudo-Classes and Pseudo-Elements] by [[Smashing Magazine]]
	* "[https://www.smashingmagazine.com/2016/06/improving-ux-for-color-blind-users/#7-form-placeholders Primary Buttons"] in Adam Silver's Improving UX for Color Blind Users article on Smashing Magazine covers how to draw more attention to buttons through more than just color.		* "[https://www.smashingmagazine.com/2016/06/improving-ux-for-color-blind-users/#7-form-placeholders Primary Buttons"] in [[Adam Silver]]'s Improving UX for Color Blind Users article on [[Smashing Magazine]] covers how to draw more attention to buttons through more than just color.
	* "[https://uxplanet.org/button-ux-design-best-practices-types-and-states-647cf4ae0fc6 Button UX Design: Best Practices, Types, and States]" by Nick Babich on UX Planet.		* "[https://uxplanet.org/button-ux-design-best-practices-types-and-states-647cf4ae0fc6 Button UX Design: Best Practices, Types, and States]" by [[Nick Babich]] on [[UX Planet]].
	* [https://www.mockplus.com/blog/post/okkey-and-cancelkey-which-one-should-be-set-up-on-the-left/ "OK-Key" and "Cancel-Key", which one should be set up on the left?] by Chloe at Mockplus reviews many of the thoughts behind the order of buttons in a button bar. '''It does not take accessibility into account''' but does cover a more, we'll call it "historical" view of the thinking around these two buttons.		* [https://www.mockplus.com/blog/post/okkey-and-cancelkey-which-one-should-be-set-up-on-the-left/ "OK-Key" and "Cancel-Key", which one should be set up on the left?] by [[Chloe]] at [[Mockplus]] reviews many of the thoughts behind the order of buttons in a button bar. '''It does not take accessibility into account''' but does cover a more, we'll call it "historical" view of the thinking around these two buttons.
	* [https://adrianroselli.com/2021/01/multi-function-button.html Multi-Function Button] by [[Adrian Roselli]] covers cases where you want the button to reflect the state of something by changing the button name, and how to do so accessibly.		* [https://adrianroselli.com/2021/01/multi-function-button.html Multi-Function Button] by [[Adrian Roselli]] covers cases where you want the button to reflect the state of something by changing the button name, and how to do so accessibly.

Kirabug at 20:42, 10 June 2022

2022-06-10T20:42:35Z

← Older revision		Revision as of 13:42, 10 June 2022
Line 50:		Line 50:
	* "[https://uxplanet.org/button-ux-design-best-practices-types-and-states-647cf4ae0fc6 Button UX Design: Best Practices, Types, and States]" by Nick Babich on UX Planet.		* "[https://uxplanet.org/button-ux-design-best-practices-types-and-states-647cf4ae0fc6 Button UX Design: Best Practices, Types, and States]" by Nick Babich on UX Planet.
	* [https://www.mockplus.com/blog/post/okkey-and-cancelkey-which-one-should-be-set-up-on-the-left/ "OK-Key" and "Cancel-Key", which one should be set up on the left?] by Chloe at Mockplus reviews many of the thoughts behind the order of buttons in a button bar. '''It does not take accessibility into account''' but does cover a more, we'll call it "historical" view of the thinking around these two buttons.		* [https://www.mockplus.com/blog/post/okkey-and-cancelkey-which-one-should-be-set-up-on-the-left/ "OK-Key" and "Cancel-Key", which one should be set up on the left?] by Chloe at Mockplus reviews many of the thoughts behind the order of buttons in a button bar. '''It does not take accessibility into account''' but does cover a more, we'll call it "historical" view of the thinking around these two buttons.
			* [https://adrianroselli.com/2021/01/multi-function-button.html Multi-Function Button] by [[Adrian Roselli]] covers cases where you want the button to reflect the state of something by changing the button name, and how to do so accessibly.

Kirabug at 20:28, 21 August 2019

2019-08-21T20:28:12Z

← Older revision		Revision as of 13:28, 21 August 2019
Line 39:		Line 39:
	# Be consistent.		# Be consistent.
	# Don't disable a button unless you absolutely have to; it's better to remove a button the user will never use (due to security, etc.) than to expose the button and make it unclickable. [https://axesslab.com/disabled-buttons-suck/ Disabled buttons suck].		# Don't disable a button unless you absolutely have to; it's better to remove a button the user will never use (due to security, etc.) than to expose the button and make it unclickable. [https://axesslab.com/disabled-buttons-suck/ Disabled buttons suck].

			==Accessibility==
			* [https://www.deque.com/blog/accessible-aria-buttons/ Building accessible buttons with ARIA: A11y Support Series] by Dequeue describes what needs to be added to non-buttony buttons to to make them accessible.

	== Additional resources ==		== Additional resources ==

Kirabug: /* Best Practices */

2019-08-21T18:46:24Z

Best Practices

← Older revision		Revision as of 11:46, 21 August 2019
Line 38:		Line 38:
	# Label buttons with what they do.		# Label buttons with what they do.
	# Be consistent.		# Be consistent.
			# Don't disable a button unless you absolutely have to; it's better to remove a button the user will never use (due to security, etc.) than to expose the button and make it unclickable. [https://axesslab.com/disabled-buttons-suck/ Disabled buttons suck].

	== Additional resources ==		== Additional resources ==

Kirabug: /* When to use */

2019-08-07T20:10:14Z

When to use

← Older revision		Revision as of 13:10, 7 August 2019
Line 10:		Line 10:
	** Saving or cancelling an order form		** Saving or cancelling an order form
	** Moving elements up or down on a list.		** Moving elements up or down on a list.
	* When navigating in a paginated ~~set of data~~. ~~We could use links to do this (arguably~~ the ~~user's going to a new set of~~ data~~) but because we AJAX~~ the ~~data into~~ the ~~page~~, ~~to the user~~ it ~~looks more like an action than a transition~~ to ~~another place~~.		** Launching an in-page dialog.
			* When navigating within a container such as a wizard or a paginated table. Essentially, if it looks like you're AJAXING the data in and the framework and context are staying the same, it's OK to use buttons.

	== When not to use ==		== When not to use ==

Kirabug: /* When to use */

2019-08-07T20:04:07Z

When to use

← Older revision		Revision as of 13:04, 7 August 2019
Line 7:		Line 7:

	* Whenever triggering an event or action. Examples:		* Whenever triggering an event or action. Examples:
	** Refreshing ~~the~~ page ~~on the [[#0\|Reporting form]]~~		** Refreshing a page.
	** Saving or cancelling an order form		** Saving or cancelling an order form
	** Moving elements up or down on ~~the [[#0\|Prioritization Display]]~~		** Moving elements up or down on a list.
	* When navigating in a paginated set of data. We could use links to do this (arguably the user's going to a new set of data) but because we AJAX the data into the page, to the user it looks more like an action than a transition to another place.		* When navigating in a paginated set of data. We could use links to do this (arguably the user's going to a new set of data) but because we AJAX the data into the page, to the user it looks more like an action than a transition to another place.

Kirabug: /* Best Practices */

2019-07-22T16:44:36Z

Best Practices

← Older revision		Revision as of 09:44, 22 July 2019
Line 33:		Line 33:
	## Per Measuring UX, [http://www.measuringux.com/SubmitCancel/index.htm if the buttons are far apart as in a wizard], the expectation is for the cancel to be on the left. Otherwise it doesn't matter.		## Per Measuring UX, [http://www.measuringux.com/SubmitCancel/index.htm if the buttons are far apart as in a wizard], the expectation is for the cancel to be on the left. Otherwise it doesn't matter.
	## Per Luke Wroblewski, putting the submit button on the far right caused more errors in a usability test than having the submit button on the right. Grouping the buttons together, whichever order they're in, yields fewer mistakes. However, grouping the buttons on the left side with the Submit button on the leftmost edge, was most successful.		## Per Luke Wroblewski, putting the submit button on the far right caused more errors in a usability test than having the submit button on the right. Grouping the buttons together, whichever order they're in, yields fewer mistakes. However, grouping the buttons on the left side with the Submit button on the leftmost edge, was most successful.
			## [https://uxdesign.cc/buttons-placement-and-order-bb1c4abadfcb Buttons on the web, placement and order] by Artem Syzonenko runs down all the options and their pros and cons, with lots of examples and screenshots.
	# Ensure that design puts emphasis on the primary or most important action.		# Ensure that design puts emphasis on the primary or most important action.
	# Label buttons with what they do.		# Label buttons with what they do.

Kirabug: Created page with "Category: Components
Links go places. Buttons do things. ~anonymous
Buttons are components that allow use..."

2018-04-22T04:49:47Z

Created page with "Category: Components <blockquote>Links go places. Buttons do things. <span style="text-align: right;">~anonymous</span></blockquote> Buttons are components that allow use..."

New page

[[Category: Components]]

<blockquote>Links go places. Buttons do things. <span style="text-align: right;">~anonymous</span></blockquote>
Buttons are components that allow users to navigate between states or actions. They're different than links, because links move users from location to location within or outside the system.

== When to use ==

* Whenever triggering an event or action. Examples:
** Refreshing the page on the [[#0|Reporting form]]
** Saving or cancelling an order form
** Moving elements up or down on the [[#0|Prioritization Display]]
* When navigating in a paginated set of data. We could use links to do this (arguably the user's going to a new set of data) but because we AJAX the data into the page, to the user it looks more like an action than a transition to another place.

== When not to use ==

* When the user is navigating to another location. We have links for that, and they've got better accessibility built in for it.
* In place of other form fields such as toggles or radio buttons. They're difficult to code to behave accessibly, look dated (hello 2005!), and are more difficult to understand.
* Just to draw attention to a call to action on the page. There are ''lots'' of ways to get a user to a CTA and a big red button isn't always the answer.
* In place of a tabset. Don't use buttons instead of tabs - we invented tabs for that.

== Best Practices ==

# Make buttons look like buttons: affordances of shape and color.
## Rectangles or rectangles with rounded corners are the usual style. Some research suggests that rounded corners enhance information processing and draw eyes to the center of the element. Circular buttons, triangles, custom shapes, can all be troublesome.
## Raised buttons (shadow underneath) indicates the button can be clicked. They add dimension to mostly-flat layouts.
## Flat buttons that fill with color on press minimize distraction from content.
## Ghost buttons (border is different but fill matches the background) are good for secondary or tertiary content
# Think carefully about target size and padding. Larger buttons are easier to use.
## Per Luke Wroblewski, [https://www.lukew.com/ff/entry.asp?571 visual distinctions are key] for separating primary and secondary tasks. The difference between the buttons can slow users down slightly, but the users indicated that they liked it because it helped them be sure they were clicking the correct button. (In these examples, Submit was to the left and Cancel to the right.)
### It's worth noting that UX Movement advocates for OK buttons on the right in dialog boxes because the user will look over the secondary action and then end on the primary action to finish the task... essentially the argument that the last thing you look at should be the last thing you do. It's notable that this is a good heuristic analysis but there's no testing cases cited to back it up.
# Mind the order and position of buttons, especially pairs like "previous" and "next".
## Per the Nielsen/Norman group i[https://www.nngroup.com/articles/ok-cancel-or-cancel-ok/ t doesn't matter whether the positive is to the left or the right] as long as the app is consistent. The default and emphasis matter more.
## Per Measuring UX, [http://www.measuringux.com/SubmitCancel/index.htm if the buttons are far apart as in a wizard], the expectation is for the cancel to be on the left. Otherwise it doesn't matter.
## Per Luke Wroblewski, putting the submit button on the far right caused more errors in a usability test than having the submit button on the right. Grouping the buttons together, whichever order they're in, yields fewer mistakes. However, grouping the buttons on the left side with the Submit button on the leftmost edge, was most successful.
# Ensure that design puts emphasis on the primary or most important action.
# Label buttons with what they do.
# Be consistent.

== Additional resources ==

* [https://medium.com/alistapart/color-you-responsible-33fc780b495b#.e13icz31w Color You Responsible] - an A List Apart article on button colors
* [https://www.smashingmagazine.com/2016/05/an-ultimate-guide-to-css-pseudo-classes-and-pseudo-elements/ An Ultimate Guide to Pseudo-Classes and Pseudo-Elements] by Smashing Magazine
* "[https://www.smashingmagazine.com/2016/06/improving-ux-for-color-blind-users/#7-form-placeholders Primary Buttons"] in Adam Silver's Improving UX for Color Blind Users article on Smashing Magazine covers how to draw more attention to buttons through more than just color.
* "[https://uxplanet.org/button-ux-design-best-practices-types-and-states-647cf4ae0fc6 Button UX Design: Best Practices, Types, and States]" by Nick Babich on UX Planet.
* [https://www.mockplus.com/blog/post/okkey-and-cancelkey-which-one-should-be-set-up-on-the-left/ "OK-Key" and "Cancel-Key", which one should be set up on the left?] by Chloe at Mockplus reviews many of the thoughts behind the order of buttons in a button bar. '''It does not take accessibility into account''' but does cover a more, we'll call it "historical" view of the thinking around these two buttons.

Buttons - Revision history

Kirabug at 20:43, 10 June 2022

Kirabug at 20:42, 10 June 2022

Kirabug at 20:28, 21 August 2019

Kirabug: /* Best Practices */

Kirabug: /* When to use */

Kirabug: /* When to use */

Kirabug: /* Best Practices */

Kirabug: Created page with "Category: Components Links go places. Buttons do things. ~anonymous Buttons are components that allow use..."

Kirabug: Created page with "Category: Components
Links go places. Buttons do things. ~anonymous
Buttons are components that allow use..."