Style guides and UI implementation: Part 2

User and Social Experience Design

A sequel to my previous article on style guides with some principles, checklists and examples of how to write a good style guide to ensure implementation of a higher-quality user interface.

A few weeks ago I wrote the article Style guides and UI implementation that looked at the importance of style guides in design specification, wireframe interpretation and user interface development.

In this blog post I want to take that further and look at some examples of web user interface elements, widgets and screens and what I believe would be a good accompanying style guide.

As I mentioned in that previous post something I’m passionate about as a user experience designer is ensuring that I apply UX principles both outwardly on applications I design but always inwardly on the development and project team – mainly through the quality of documentation. So when it comes to UI specs, wireframes, interaction diagrams and style guides the key is readability and ease of consumption by the people who have to implement the interfaces.

If the documentation doesn’t make sense to developers it’ll be reflected in a high defect rate and poor quality product. This also extends to document change control and document distribution plus other elements of SDLC project management but I just want to look at the quality of documentation here. In fact you should have style guide for your style guide and other project documentation to optimise information retrieval.

Part from just having a nicely laid out document the main point I want to make with good documentation is that you need to get the right mix of abstraction if you’re following a decompositional approach to UI specification versus minimising the amount of cross-referencing developers need to do in order to bring together all the relevant pieces of information in order to understand how a particular interface component should look and behave.

You also need to understand how the document is going to be used. Will a CSS specialist convert your style guide to selectors and declarations prior to any HTML being written? Will the HTML developers be coding the CSS on the fly? Will content authors be referring to this post-launch?

It’s tricky because with full abstraction you only need to specify each requirement in one place and it minimises the risk of unspecified or conflicting requirements … but it can mean a developer will have to piece together the spec for windows, for dialog boxes, for text, for buttons and colour schemes from different places just to figure out whether a button on a specific box should be grey or blue with bold or normal text. Either way abstract thinking while planning your style guide will result in greater consistency and thus reduced user interface recognition and target acquisition times.

We’ll start with a simple generic archetypal dialog box that includes some common elements that all dialog boxes will share. It has header text, dialog body text and one or more buttons in the bottom right:

Specific instances of dialog boxes might have just one button, three buttons or additional form elements in the dialog body. Those would be handled in the specs for those instances … but all of them will inherit certain requirements – both interactive (specified in the UI spec) and visual (specified in the style guide).

While the UI spec may have a generic dialog box the style guide may not neccessarily duplicate the same structure. There are advantages in having a complementary document structure but it may result in under- or over-specification of styles. For example your styling for buttons may be the same across the entire site so it wouldn’t make sense to re-specify the styling of buttons for every wireframe with buttons. However getting back to the point on cross-referencing documentation you may decide you want to integrate your UI spec and style guide into a single document.

Dimensions

So let’s continue with our example dialog box and specify some styling:

Here we specify some dimensions for the header of dialog boxes. We state they should be 450 pixels wide but due to our requirement for header text not to wrap (fixed height) we will permit the extension of the dialog width to incorporate longer headers. Obviously somewhere else in our data model and UI specification we’d state the format and maximum characters permitted for the value of the dialog header.

It’s important to state requirements like no wrapping and “pushable” dimensions up front because it’ll affect how the HTML and CSS is implemented. Failure to do so will result in visual defects and significant rework.

Text and font specification

I just want to make a quick observation about fixed vs relative font sizes because it’s one of the points of contention between graphic designers who’v come from a print design background and developers who implement their designs. It is true that browsers are starting to adopt the zoom approach rather than font resizing but it’s not ubiquitous. So for flexibility and accessibility it’s good to keep using relative font sizes for now. Remember that relative sizes inherit so the best way is to define the font size in the style guide as “equivalent to fixed size of __” as the value in the CSS will be different depending on the text’s position in the DOM.

This goes for other relative dimensions including widths, heights, margins and padding.

Form feedback

The design of form feedback is often neglected because it is typically not present on the initial page load and many wireframes focus on the primary page state.

The wireframes should highlight where feedback should be displayed and the style guide should define what it looks like. The style guide should not define what the feedback or help messages should be – those should either be in the UI spec or as an appendix thereto.

For unsuccessful operation feedback you might also want to highlight the form fields that require the user’s attention. Depending on the styling you can either describe it with words, provide and example or exhaustively define the styling of every type of form element – but it could be as simple as “#BA1C1C 1px border around text fields, text areas, and selects and #D04848 background on checkboxes and radio buttons“.

Animations

The style guide needs to specify more than static states. If you’re using fades, drags etc then you need to specify the start, end and transitional state … for example semi-opaque states on boxes during a drag-and-drop operation.

Perhaps you don’t have specific elements in mind that these styles and behaviours should map to in which case you might want to just have a catch-all clause like “All text nodes dynamically inserted into the DOM should have a #E6E861 background that fades to white three seconds after insertion“. As you can see, it does help to have some knowledge about HTML, CSS and JavaScript in order to write a useful style guide.

Implementation

With the right project management the code that handles such styling and animation should be written just once per style guide requirement. Whoever prepares the CSS and JavaScript will then generate a guide with CSS class names and JavaScript methods to refer to when implementing the interface. The alternative is the faux-agile all-hands mashup approach which results in the same style being implemented five different ways in the stylesheet with different class names plus additional inline styles in the HTML to override or extend bad CSS. Debugging and maintenance nightmare.

When defining a style here is a checklist of things you should consider defining as part of the style:

• Dimensions (height, width and font-size)
• Colours (text, background and border)
• Icons and graphics
• Margins and padding
• Indenting
• List styles
• Alignment
• Font family

An for animations:

• Timings
• Delays
• States (start, end and transitional)

And then some permutations and scenarios:

• What if the user agent can’t execute animations (JavaScript disabled)
• What if the browser is set to less than or greater than optimal width range
• What if there’s too much or too little content inside this element (such as postcode form fields)
• Does the state of this element change on focus or select?
• Does this element have a disabled or inactive state?

You can leave some things up to the CSS developer. For example instead of specifying 0.5em, 1em and 2em margins you could just use small, medium and large margins and trust them to translate it to equivalent numeric values. Might make the document a bit easier to read and less exacting.

Generally you shouldn’t need to worry about layering – developers should be able to figure out when an element overlays another, for example if you expand a menu it’s pretty obvious it should be rendered over the top of everything else on the page.

When it comes to inheritance of styles do not, for example, bother having a global hyperlink style when your content text hyperlink, your sidebar hyperlink, navigation hyperlink and footer hyperlink styles all deviate significantly from that base style. As an aside though, if you are deliberately implementing what should be a generic style many different ways then perhaps you’re introducing unecessary confusion for users who still need to be able to identify each type of hyperlink as a hyperlink with the same expected behaviour and schema as all hyperlinks … so I just pose the question that if you are unable to define abstract base style definitions for windows, dialog boxes, feedback, forms, text and sidebars then perhaps you should think about why and make the concious decision that doing so has benefits in other ways that are more important than consistency and excise-reduction.

Finally, don’t forget your print and aural styles!

// purecaffeine.com is a user interaction and UX design, social media and Government 2.0 blog run by professional Canberra, Australia web user interaction designer Nathanael Boehm, licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia License.

Related posts:

1. Style guides and UI implementation
2. Neglected social media
3. Balsamiq Mockups: UI screen design tool