Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate button styles #1162

Closed
Mandily opened this issue May 18, 2016 · 12 comments
Closed

Investigate button styles #1162

Mandily opened this issue May 18, 2016 · 12 comments

Comments

@Mandily
Copy link
Contributor

Mandily commented May 18, 2016

I'd like to make buttons in the admin more intuitive by giving them multiple states. Buttons that submit forms and do in page functions should also have a progress spinner inside as well. The purpose of this issue is to discuss what styles need to be created to do this. This will inform a future issue about creating different visual styles (including a spinner button) for the button states.

Once we're done exploring this issue, I will update the mockups in #520 Admin branding to reflect our decisions here.

Button states (not all buttons have all states)

Each state is distinguished visually different from the others

  • Static no action required (example: download list, filter results, save (when nothing has changed in the page) - things that don't need to be done on a page)
  • Static action required (example: save your edits, cancel edits - when something needs to be done to commit user input)
  • Static no action required: hover
  • Static action required: hover
  • Active
  • Active with spinner
  • Disabled

States could look something like this, with button type styling being applied as colour at a later step:
screen shot 2016-05-18 at 3 57 36 pm

Button types

Should different types look different from each other?

  • Filter/search
  • Create a new ______
  • Edit existing ______
  • Save/update
  • Cancel
  • Clear cache
  • Download list
  • Edit, clone, and delete icons beside tables

Should different types look different from each other?

There's two options for this question

  1. All buttons regardless of their type look the same.
  2. Buttons look different based on their type. (ie negative vs positive actions, or any other way we want to break them down)

The thread in #520 Admin branding was discussing using different colours for positive and negative actions, but we were inconclusive on what defined a negative action and we never reached a resolution.

At this point, after considering all of the various states a button could have, I'm leaning towards a cleaner look with buttons using one colour (blue) throughout, with no emphasis on positive, negative or important to notice buttons. We'll use the Spree Blue now, and when we do our brand overhaul we'll change it to the new Blue Steel palette.

screen shot 2016-05-18 at 3 41 18 pm

I'd like to take it to the community - Do you prefer different styles for different types of buttons or consistency throughout? If you prefer multiple styles, how do you define which buttons get which styles?

@davekiss @tvdeyen @Sinetheta @mamhoff @graygilmore

@graygilmore
Copy link
Contributor

What's the difference between "action required" and "no action required"? I find that a little confusing. Could you provide an example of a major app using this technique?

@kennyadsl
Copy link
Member

kennyadsl commented May 18, 2016

@graygilmore for example in http:https://codepen.io/pen/ when you start typing the save button changes border-top. That's the action required.

@Mandily great work. I like consistency but I also think that using colors to define positive/negative actions are generally a good thing. Maybe even giving more emphasis to the main action of the page could be a good idea? eg the edit button on an edit page is more relevant of the cancel or delete button?

@Mandily
Copy link
Contributor Author

Mandily commented May 18, 2016

I updated the post above as well. This is how I see it:

Static no action required (example: download list, filter results - things that don't need to be done on a page)
Static action required (example: save your edits, cancel edits - when something needs to be done to commit user input)

in the case of action required buttons, nothing in the button itself has changed, it's more of an indicator about what is happening in the page.

@Sinetheta
Copy link
Contributor

Sinetheta commented May 18, 2016

I think I would lean towards most buttons being "no action required". Eg: Update and Cancel are both no-action-required until an input is changed, at which point Update becomes an action-required button (bonus points for window.beforeunload if the page is in that state as well).

I'm interested in @kennyadsl concept of color for "positive" or "negative" actions. I think color-primary (green for github blue for new solidus) is a very upsert color, to be used for all create and update actions.

@tvdeyen
Copy link
Member

tvdeyen commented May 18, 2016

I like the idea of two kinds of buttons.

But we should only ever have one main-action button, so the user isn't confused of having multiple "main" actions on that page. (That would be "save" on form pages and "create new" on list pages, for instance).

I also like the idea of having "action required" states. We could have a little effect on the button that needs action (remember the glow effect of old Mac OSX versions). I kinda like that, but leave the decision to the designers.

window.beforeunload is great, but should be another task, because maybe want to have proper texts dependent of the page viewed.

Disclaimer: Also I like the color-for-state option, I think that's not state of the art anymore and doesn't provide too much benefit for the user and can (think of foreign cultures having different color codes) lead to false effects.

@Mandily
Copy link
Contributor Author

Mandily commented May 19, 2016

I agree with @Sinetheta in that a button isn't an action-required button until something happens.

It looks like we're leaning towards two types of buttons but there's two camps on how to define those types.

  1. Positive vs negative actions
  2. Main/primary actions vs secondary actions.

I'm with @tvdeyen and like the idea of main actions vs secondary actions because it focuses on priority instead of intent. I don't have any user data to back me up on this but I think highlighting actions based on a page's purpose would lend itself to a cleaner look, rather than highlighting all buttons with two different colours.

@kennyadsl and @Sinetheta Do you have any thoughts on why negative vs positive might be better?

@Sinetheta
Copy link
Contributor

Sinetheta commented May 19, 2016

@tvdeyen speaking of window.beforeunload, my main motivation for it just went away no more backspace to navigate back

@Mandily which buttons would you highlight on this page? I think the main action is "Comment", but once I'm editing this comment it's suddenly "Update comment" and that would leave poor old "New issue" at the top looking rather bland. Hence my creating is highlight destroying is not.

@jhawthorn jhawthorn added the UI label May 30, 2016
@Mandily
Copy link
Contributor Author

Mandily commented Jun 30, 2016

I dropped the ball on keeping up with this. I've had some time to mull this over, and had a chat with @Sinetheta to come up with the following:

Ideally I'd like to see our interaction model use button types and icons being determined by priority, with a special case button colour for destroy items.

Primary buttons can happen multiple times on a page, but generally not in the same 'group'. So the 'save' button at the bottom of the page, and the 'new item' button in the header could both look the same because they're regarding two different functions on the page.

First thoughts are primary buttons using blue, secondary grey, and all destroy items red.

This ensures the user can find what we deem to be their primary motivation in any particular area of the page, and we can better warn and prevent them from accidentally deleting something they shouldn't.

How do you all feel about that?

@tvdeyen
Copy link
Member

tvdeyen commented Jun 30, 2016

I'm fine with this. 👍

@kennyadsl
Copy link
Member

I think it works @Mandily

@graygilmore
Copy link
Contributor

Let's also make sure to use the Bootstrap classes for these, cc @jrochkind.

@Mandily Mandily mentioned this issue Jul 28, 2017
4 tasks
@jarednorman
Copy link
Member

The admin UI has been redone since this was suggested and @Mandily is no longer active in the community. While the suggestions here are good, perhaps it's worth closing this as this isn't actionable in its current form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants