Buttons and Toggles for Desktop and Mobile Devices
#Button Basics:
Before anything else, buttons should be consistent with the style and layout of the page they are being placed on, as well as keeping in the spirit of the page's branding. Buttons should stand out in a page, but not at the cost of detracting from the page's content. They should complement the color scheme and tone of the page. On mobile, there might be call to make them particularly emphasized as buttons, but on a desktop view there is a little more wiggle room in terms of emphasis.
Buttons should stand out from the rest of the page, and be given the appropriate weight they require. This can be achieved with color and shape as well as a variety of blending effects. A shadow, stroke, or bevel effect can serve as a clear separator between button and page, but these are not umbrella solutions. Shadows are most effective when used with dark buttons on lighter backgrounds, while stroke is a better choice for the converse.
Following the contrast principle, a UI needs to have some sort of stylistic ordering when it comes to its UI elements. It is rare that a UI will have only a single type of element, and most incorporate multiple tiers of each kind. Buttons alone can often have several categories such as main nav, breadcrumb nav, in-page actions, etc. Thus, it is important to be able to keep a consistent yet distinct hierarchy. This can be achieved by keeping the overall style the same between different subcategories of UI elements, but with changes in effect intensity and color. Secondary and tertiary UI elements such as dropdowns or segmented controls should follow the general format but have their own distinctive style that does not allow them to be confused for any other element.
Aside from the text on a button to indicate function, consider additional elements to improve functional mapping. For example, a chevron arrow facing sideways like so: >. This indicates that the button will take the user to a new page if pressed, or at the very least a new subsection of the current page. The same icon facing downward indicates that the button will open a dropdown menu, while the reverse of the icon will indicate a backwards navigation control.
Aside from the icon to indicate action, it is also important to keep button placement consistent with conventions. Creative navs and buttons can make a site, but they can far more easily break it and render it confusing. Established convention can limit creativity, but it is far more important to have a usable navigation section than an ingeniously artistic one. As such, nav menus should be accessible and obvious. This usually means placing them at the top or left of a page, but this is not set in stone.
For individual buttons, it is important to place directional navigation buttons near each other so the user doesn't need to remember different locations for the same task. If there is only a forward or only a backward button, it should be placed at the right or left side of a page respectively, to match the theoretical direction of movement across the site. Conventionally, sites move from left to right, and this is the reflected in the browser's forward and back buttons. Users will expect a button with an arrow facing to the left to take them back, and one facing to the right to take them forward. It is important to keep these predisposed mappings in mind and take advantage of them whenever possible.
##Standard Buttons
Buttons have three default states, along with a fourth to indicate if/when they are disabled and unavailable to the user, and potentially a fifth to indicate that the function is being processed. Buttons also usually include either an icon or text to communicate its function to the user. The function can also be hinted at by the shape of the button itself, following certain conventions such as the standardized iOS back button. Certain buttons such as those used for navigation can be clear enough to the user without needing any additional icons or text.
The button should appear to stand out from the page, whether through bevel and shadow effects, distinct borders, or a specific icon that indicates interactivity. The most common and iconic "button" effect is achieved by creating a separate shape for the button and layering it over a background, then adding effects to simulate depth such as bevel, drop shadow, and a lighting gradient that mimics the highlights from a light source.
The button should dynamically react upon the user's mouseover, prompting them to want to click it. The exact way this is to be achieved depends on the style and layout of the page, but one of the conventional methods is to have the button 'light up' upon hover, replacing the underlying colors with lighter versions of the same hue and adding a glow effect to the inlaid text or icon.
This state does not exist on mobile devices or tablets due to the inability to 'hover' without a mouse.
Another way to handle buttons and their hover states is to take a minimalist approach to their design, such as seen on Expensify's dashboard. BZC also incorporated this technique for the Goldilocks project Dashboard. The style has for button outlines and icons with inner whitespace that matches the background, and upon hover the two color sets inverse to create a 'fill in' effect.
The purpose of this state is to provide visual and simulated tactile feedback to the user, making the process of the button interaction feel more real and visceral. A button should feel like a real object that can be touched and manipulated in space. One of the ways to create this effect is to inverse the gradient from the button's default state, switching the light and dark highlights to create a depth effect as if the button was being pressed into the background and past it. This should be supplemented with an inner shadow effect along the top (or side closest to the global light source) that replaces the drop shadow of the default state.
If the default state of the button is in an outline-centric style like those on Expensify's dashboard, then the pressed state should be much like the hover state, indicated a dynamic and engaging inversal of colors to draw the user's eye. The pressed state could be lighter than the hover to indicate action, or darker to simulate depression. The style can vary greatly, as long as the states are consistent with one another.
###Disabled Buttons
The fourth potential state of a standard button is Disabled, shown when the current state of the user's activity flow does not allow for the button's function to be carried out. This is usually achieved by dulling the buttons colors and shading to a gray matte, creating a faded effect that does not draw the user's attention. Some shading and highlights are still present to indicate that the object is still a button, but the grayed out text is universal for 'this function is not available'.
###Busy Status
Sometimes, a button corresponds to an action that requires some time to process. In these cases, it is best to provide the user with some sort of feedback that whatever action they have just initiated has in fact been started and is currently in progress. The user can click the button, and if there is no 'busy' or 'working' state then it is not clear whether or not the function went through, prompting the user to click multiple times and possibly causing the process to occur multiple times (or simply restart every time, delaying the user further and causing frustration). The user needs to know that their commands are being processed, and this can be achieved by creating a state that changes the button text to reflect that. The addition of a processing icon is also helpful, with animation if possible as the motion serves to give the user a direct sense of progress that is not possible with a static message. The icon can vary, but a basic spinning arrows symbol or hourglass is perfectly appropriate. The only real criteria for the icon is that it must somehow indicate progress. It is generally not necessary to indicate the exact degree of progress on the button itself, but depending on the style and action it may be appropriate. If the action is something major for the page, it is more fitting to have a separate progress bar somewhere else.
##Toggles
Toggles can differ from standard buttons in that they are used to move between multiple persistent states of a particular function rather than linking to a single-instance action such as navigation. Toggles rely on many of the same mechanics to indicate activity vs. inactivity as standard buttons, such as shading and highlights to simulate tactile stand-out or depth. Some examples of toggle usage are:
The simplest of toggle buttons, involving only two states. These can usually be replaced with a regular button with little loss of content or function, thus the choice to use them is mainly stylistic. A toggle can provide a level of retro interactivity that a single button cannot-- furthermore, it allows for simple movement between two states with visual distinctiveness. Use of color or inner shading can indicate an active state (i.e. a 'popped in' button) while a state similar to a standard button's default state can be used for the inactive ('ready to be pressed') side of the toggle.
Toggles are commonly used for media controls due to the common states that need to be grouped for coherence: Play, Pause/Stop, Rewind and Fast Forward. Only one of these states can be active at a time, and so they are grouped along a single 'track' and often stylized to appear as being part of a single button that has been divided into sections. Alternatively, the buttons can be grouped together but rather than being physically connected, shaped like the common icons that are mapped by convention to the media functions. These symbols are so familiar that they warrant no further explanation.
Differentiating between up and down states on a multi-state toggle is achieved in much the same way as a two-state, the difference being that shadows from adjacent upstates must be accounted for in the event of an angled global light source. The same conventions for pressed and default buttons still apply.
#Providing Assets for Developers
Assets should be cut to the appropriate size, starting with the @2x resolution for retina graphics (when applicable) and then scaled down to 50% for regular views. For web views, the distinction is not necessary. Assets should be provided in .PNG format and attached to the pivotal tracker story that requests them.
Button assets should be held to a naming standard, prefixed with btn- and sufficed with the state and size. For retina assets, the @2x tag is required. Thus the standard format is btn-NAME-STATE, or btn-NAME-STATE@2x for retina. For example, a Facebook connect button would have the three standard states: default, hover and pressed. This would translate into btn-facebook-default, btn-facebook-hover, and btn-facebook-pressed.
All assets should be saved for web as PNG through Photoshop (shortcut Cmd + Opt + Shift +S) unless specified otherwise. Retina buttons should be designed at @2x size and then scaled down 50%.
In most cases, the text part of a button does not need to be provided as part of the asset, as it can be superimposed by the developer. However, they will require text specs for the button in addition to any other text on the page.