Solidus: Investigate button styles

Created on 18 May 2016  路  12Comments  路  Source: solidusio/solidus

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

UI

Most helpful comment

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.

All 12 comments

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?

@graygilmore for example in http://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?

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.

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.

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.

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?

@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.

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?

I'm fine with this. 馃憤

I think it works @mandily

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

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ericsaupe picture ericsaupe  路  4Comments

cdrage picture cdrage  路  3Comments

merlielmag picture merlielmag  路  3Comments

jhawthorn picture jhawthorn  路  5Comments

tudorpavel picture tudorpavel  路  3Comments