Uxpin the Critical Components of Web Ui Style Guides
Hello!Full description
Guides LCPC
Hello!Descripción completa
Hello!
Anna sweety
recetas de anna olson y otros
Seleccion
Descripción: Lab Sistema Tienda Creacion Del FrontEnd Thirsa
Anna Perenna
sheet music
justification de la psicologia Del yoDescripción completa
Anna KareninaFull description
aws
Descripción: Bla
MeseFull description
Full description
Full description
Descripción: Anna Coulling-Forex for Beginners-Anna Coulling
Anna Coulling-Forex for Beginners-Anna Coulling
Contents Preface
An Introduction to Style Guides Embracing Systematic Web Design Why a Front-end Style Guide? Building Your Own Front-end Style Guide Front-end Style Guide Examples and Tools The Future of Front-end Style Guides
This book was originally published by Five Simple Steps in 2013 before they closed their doors. My thanks go to Emma and Mark Boulton, and everyone who worked on producing the original, including Owen Gregory, Paul Robert Lloyd, Jo Brewer, Nick Boulton, and Colin Kersley. This edition was edited by Cennydd Bowles and tech edited by Paul Robert Lloyd. Geri Coady designed the beautiful front cover. I am so grateful to be able to work with such talented people. Thank you, Cennydd, for your love and support while writing this.
4
My first encounter with a style guide came during one of my first client projects. I was working with an agency, writing the HTML and CSS for some new pages on a corporate intranet. I was given a style guide – a monster PDF covering details like logo positioning and what colours to use. The pages had already been designed but didn’t match the guidelines, so I was asked to make sure the final site did. Since the document I was given was intended for print projects, the colours were all Pantone colours that I had to convert to hex values, and the measurements were all in points that I had to convert to pixels and ems. I spent hours reading the document, struggling to follow the guidelines while translating them for the web. I felt it was strange that I was given so much documentation about making something for print, but none about making something for the web. It wasn’t until I started an internship at Clearleft that I encountered style guides that were built for the web and integral to client projects. Clearleft’s team was the first I worked with that designed templates – article templates, product detail templates, product list templates – rather than pages. They thought about websites in a modular way. Natalie Downe, one of Clearleft’s front-end developers at the time, referred to these webbased style guides as “pattern portfolios”, each pattern relating to an individual module on the site. A pattern portfolio held, on a single HTML page, every module on the client’s website, and was produced as a developer deliverable to help the client integrate the markup Clearleft had written into the client’s content management system (CMS). Style guides for the web have come a long way since then. They’re not just intended to be used as documentation – they are also systems used for prototyping. Since I wrote the first edition of this book in 2013, I produced the Style Guide Podcast with Brad Frost. We interviewed a number of people about the types of style guides they’d built for clients or within teams at their organisations. Many of the lessons I took from those discussions have found their way into this updated edition. 5
An Introduction to Style Guides Style guides set a precedent, demonstrating how a designer or developer expects the site to be maintained and built upon going forward. Style guides are useful tools for communicating intent between designers and developers, but they can also help those with jobs that don’t necessarily involve design, such as copywriters, editors, and product owners. Armed only with a Word document, some stock images, a style guide, and perhaps a set of customisable templates, employees and contractors can ensure the organisation’s message will remain on-brand rather than look sloppy or inconsistent. The UK’s National Health Service (NHS) is a giant organisation that benefits from having design guidelines, and for good reason: patients need to feel not only comfortable when they’re treated, but also well informed. Guidelines explaining how to make signage clear and consistent, text in leaflets readable and accessible, and tone of voice trustworthy and straightforward help meet these goals.
Types of style guide There are lots of different types of style guide, online and offline, and I like to incorporate aspects of these into mine. Some style guides are stricter than others. Brand style guides can be very strict (“Thou shalt not use less than 2cm of white space around a logo”); others are more relaxed. I like those that are in-between, because there are often cases when you have to bend the rules.
6
CONTENT AND EDITORIAL STYLE GUIDES An editorial style guide ensures consistency in the content used throughout a publication or website. It may include rules around grammar, preferred spellings, date formats, and capitalisation. A marketing department might produce tone of voice documentation to ensure all messaging to the user – such as microcopy, email notifications, and tutorials – sounds like it’s written by the same person. MailChimp’s Voice & Tone is one such resource, and it’s fantastic. Full of examples of how MailChimp gives feedback to users, it provides educational explanations of why something should be written in this way.
It’s good to capture a site’s tone of voice to avoid inconsistency when several people write content. Content Management Systems have made it easier for anyone to publish content, but without proper guidance, using the wrong tone can mean you come across as unprofessional or even rude.
BRAND IDENTITY GUIDELINES
7
Brand guidelines, also known as corporate identities, are documents that describe how an organisation wishes to be perceived by the public in their communication methods, from advertising to customer support interactions. They vary in depth and complexity. They can be quite lightweight, such as Dropbox’s, which sets out the corporate colours and how to use the logo.
Other brand guidelines are more rigid and provide a lot of detail, like The Scout Association’s visual identity guidelines (PDF), which cover every conceivable aspect of the brand. Big organisations often have substantial guidelines because the larger they are, the more challenging it is to control their identity. Strictly enforced guidelines remove ambiguity and help maintain the brand’s desired values. After all, minor inconsistencies can have a bigger negative impact when operating at scale. Some brands don’t translate well from print to the web, so it’s important to take into account the differences between media when putting a style guide together. For example, typefaces in print guidelines will often be
8
optimised for print rather than screen, and logos and iconography may be unsuitable for conversion into SVG.
CODE CONVENTIONS Code conventions are useful when several people are working on the same codebase. Code conventions mention things like whether to use spaces or tabs for indentation, and underscores or camelCase for variable names. These conventions keep code maintainable and make it easier for people, often working remotely, to collaborate. GitHub has its own Ruby and CSS guidelines. These contain advice about file organisation in projects, naming conventions, and formatting guidelines. As the guidelines are extensive and open source, hundreds of people who don’t work at GitHub have forked their CSS guidelines for use in their own projects. This is good for GitHub because it means potential hires may already be familiar with the code standards they follow. Good guidelines tell you what to do: “Keep selectors as short as possible.” A great set of guidelines tells you why: “Keep selectors as short as possible, to keep specificity down and performance up.” An excellent set of guidelines goes further and backs up the reasoning with further reading. I particularly like Harry Roberts’s CSS guidelines because this is exactly how he writes his. If you write guidelines in this way, it will be invaluable for new developers as it helps them learn best practices. There are tools that will help you maintain consistency in your guidelines, such as Hound, which creates a pull request on GitHub if your code doesn’t meet your team’s code conventions, or JSHint, which can be integrated into your code editor or build process to flag up style violations in your JavaScript.
HUMAN INTERFACE GUIDELINES 9
As new input methods such as speech and gesture become more popular, interaction guidelines have become more important. These guidelines are not just matters of visual style but also cover interaction. Human Interface Guidelines (HIGs) seek to standardise these interactions within a particular product’s ecosystem, so as not to confuse a user with inconsistent responses to interaction. Apple first published its influential HIG decades ago, and continues to develop them for macOS, iOS, and its other platforms today. These are written for people building apps for Apple’s platforms. I particularly like Microsoft’s HIG on designing for the Kinect for Xbox (PDF), which includes examples on the nuances of designing an interface that can be controlled via voice, gesture, or using a controller.
FRONT-END STYLE GUIDES In 2005, Dave Shea wrote a markup guide for his projects. It’s a basic page with headings, lists, and paragraphs, and one of the first documented examples of a front-end style guide. Since then, front-end style guides have become broader and deeper. Some include colour swatches, like a branding style guide; others include coding standards. Front-end style guides come in many forms, but they share a purpose: to make building and maintaining a website easier. Unlike a print style guide, a front-end style guide uses real code and works in a browser. It’s not a PDF or a series of screenshots: it’s HTML that demonstrates a site’s main styles, suggests how and when the styles should be used, and offers example markup. A front-end style guide grows organically with a site throughout its lifetime, acting as a reference and preventing duplication of code and design patterns. The style guide references the same main CSS file as the 10
site it’s built for. As new features are added or designs tweaked, site owners update the style guide. If the style guide is truly living, it will pull in new components automatically, so it is always up to date. Front-end style guides excel at encouraging collaboration between designers and developers. I love sitting down with designers and going through the guide, making tweaks straight in the CSS. This collaboration saves a lot of time that I used to spend switching between mock-ups and live sites. It also preserves sanity, and prompts great conversations about responsive design, such as “How should this table of data work on narrow screens?” or “Should we reduce the height of this masthead when the viewport is short?”
Terminology I find terms like ‘styleguide’ and even ‘patterns’ to be quite problematic in the generic sense that they are often used. The word ‘styleguide’ has so much baggage attached to it relating to its use over the years as a static design deliverable that I generally try and avoid it altogether. —Mark Perkins, “On Building Component Libraries”, 28 April 2016 You’ll notice in the examples that follow that many people use different words to describe the same thing. Front-end style guides are still in their infancy, and a lot of terms exist. Just make sure the name you choose for your style guide makes sense based on what you’re building, and use the terminology you’ve chosen consistently.
ELEMENTS, PATTERNS, AND COMPONENTS Elements, patterns, and components are the distinct parts of your interface, such as a news teaser with an excerpt, date, and image, a header 11
for a blog, or even a simple ordered list. In his article Atomic Design, Brad Frost uses the term atoms for basic building blocks that are not particularly useful on their own, such as a button for a search box, an input field, or a label. Atoms combine to create molecules that perform a specific function – for example, by combining the aforementioned button, input, and label we make a search form. Organisms are groups of molecules combined, such as the search form in a site header, alongside some navigation.
A visual explanation of atomic design principles from patternlab.io.
Thinking of design patterns in an atomic way makes what we build more flexible. We assume that the same atoms and modules could be combined in many ways, in combinations we might not have imagined when building them. Splitting things up in this way helps users of an atomic pattern library understand how modules are assembled. Separating the modules from the layout helps make a site more maintainable: if the layout changes, such as increased column width, modules can simply expand to fill it. While I like the Atomic principles and I think about them when I’m writing front-end code, my preference is to stick with the word “component”. I find the Atomic terminology too rigid – it’s not always obvious whether one of these building blocks is an atom, molecule, or organism, and I don’t want to pass on this confusion to the client.
12
STYLE GUIDES, DESIGN SYSTEMS, PATTERN LIBRARIES, AND COMPONENT LIBRARIES The term pattern library is sometimes used when discussing style guides. A style guide explains how things are going to look, whereas a pattern library tends to focus on how they are assembled. Style guides are a fantastic tool for designers, and pattern libraries are generally more useful for developers, but there will be some overlap. The term design system is frequently used as an overarching term covering core principles, language, design, and tools used to implement these. Its application may be similar to a component library, but with more emphasis on behaviour and interaction.
Google’s Material Design is an example of a design system. It describes the overall goals of a design across all of its web and app products.
Design systems are a particularly useful tool for creating a common design language for an organisation’s many different products, from websites to mobile apps. In Brad Frost’s book Atomic Design, he describes how style guides are a key part of design systems: “The cornerstones of good design
13
systems are style guides, which document and organize design materials while providing guidelines, usage, and guardrails.” Be careful when using the term “style guide” on its own, as it can have connotations of print media. The terms “pattern library” and “component library” are more accurate, but can be confusing for clients, so I tend to use them only when I’m talking with web teams. “Pattern library” and “component library” can also be restrictive, as your style guide may also contain things like branding and content guidelines. This is why I like the term “front-end style guide”. Your front-end style guide could contain a pattern library, but it could also have a section on tone of voice. It’s a useful all-encompassing term. Front-end style guides aren’t just for developers. The people I’ve worked with who have been most excited by them are designers who are familiar with using or producing print style guides. There are plenty of tools and techniques for building front-end style guides for those who don’t code, which I’ll go into later.
14
Embracing Systematic Web Design The various types of style guide come into their own at different stages of a project. Some are most appropriate during design exploration, others at the end of a project. The options vary in depth and focus, from design to development. Some are good for prompting discussion, others are better as handovers to other developers – but they’re all useful approaches to different challenges.
Common processes Not all web style guides are what I would call front-end style guides, which are written in the same markup and reference the same CSS that is used on the real site. Some style guides are more tools for promoting discussion between designer and client. The technique you choose should depend on your preferences, your skills, the project, and the client.
STYLE TILES During the design exploration phase, producing mood boards can feel too abstract, but jumping straight in and producing a mock-up can be premature. Samantha Warren’s style tiles sit between the two. In the early design stages, Samantha recommends creating a series of graphics files that have different styles, and presenting these – rather than 15
full mock-ups – to the client. These style tiles encourage clients to focus on appearance rather than layout. Quicker to produce than a detailed mockup that can can be easily dismissed, style tiles are great starting points for discussion.
Three style tiles Samantha created for The Examiner to help them decide upon a design direction.
Although the intention is to design style tiles using graphics software, they’re also easy to include in a front-end style guide. There is even a Compass extension that lets you do this, and a marked-up equivalent if you want to produce a web-based style tile. Style tiles are particularly helpful if the client or product owner doesn’t know what they want, or doesn’t have a visual direction figured out. They’re not throwaway deliverables – you can use a chosen tile as the foundation of your front-end style guide, before most of the design work has even started.
ELEMENT COLLAGES Dan Mall takes style tiles a step further. He describes element collages as “an assembly of disparate pieces without specific logic or order”. I often have ideas for pieces of a site in bursts. A full comp often requires ideas to be fully realized. An element collage allows me to document a thought at any state of realization and move on to the next. —Dan Mall, “Element Collages”, 13 November 2012 16
Like style tiles, element collages are tools to facilitate conversations, but they arrive further along in the design process, or even straight after a style tile has been selected. The most valuable thing element collages do is focus the client on how a particular feature will work, independent of surrounding layout. Now we have a seemingly infinite number of devices, screen sizes, and resolutions to worry about, breaking out of the canvas helps the designer and client think more about how a component is going to work in context of the site as a whole, rather than on a specific page.
An element collage produced by Clearleft for Code for America. Here, the elements were placed on a horizontal rather than vertical canvas to avoid it looking too much like a page mock-up.
Element collages are perfect for designers who aren’t yet comfortable putting their designs straight into code, but want to move away from full mock-ups. Both style tiles and element collages are intended as discussion pieces. There’s a sensible trend away from grand reveals towards experimentation and showing little and often. Although element collages are intended to be displayed in the browser, they are static images, so each interaction state has to be illustrated with a separate visual.
17
STYLE PROTOTYPES Digital agency Sparkbox’s style prototype is similar to an element collage, but is displayed in the browser and is interactive. A style prototype is a web page containing some of a site’s typographic elements, button styles, and photographic styles. One problem with presenting static mock-ups is that fonts and colours can look unexpectedly different in a browser and on different devices. Style prototypes help solve this problem and, since they are responsive, can be tested easily on different devices. One of the greatest challenges we all face in this era of responsive web design is achieving a balance between efficient workflow and effective client deliverables. It was with this in mind that the Style Prototype was born. —Jeremy Loyd, “Our New Responsive Design Deliverable: The Style Prototype”, 6 August 2012
Jeremy Loyd of Sparkbox states that style prototypes are not intended as branding mood boards, and are best suited to projects that have an existing brand: “In a sense, it is a safety measure intended to avoid rehashing (or completely scrapping) site designs in which hours of time and budget have been invested.”
18
Style prototypes help demonstrate how different styles feel in the browser. They capture things like button hover states and interactions on a detailed and granular level.
COMPONENT LIBRARIES Component libraries are collections of all the components on a site, displayed in one place. They act as deliverables for other developers rather than as design conversation pieces. The first component libraries I encountered were Natalie Downe’s “pattern portfolios”, which she produced as a developer at Clearleft. These were long pages that contained all of the components she’d built for a site. These components sat between the site header and footer as though they formed a single template, but holding all the site’s content types.
19
This component library was a lot like Dan Mall’s element collage, which came later, except that rather than being a static image, it was written in code. One of the reasons Natalie created pattern portfolios was to prove that components didn’t have to be tied to a specific page, and that they were like bricks: distinct from one another, but able to be stacked and slotted together to form a page. Dimensions aren’t rigidly enforced, so the modules are flexible enough to live in a narrow sidebar or at full width in an article. In fact, the component library shown was not responsive to start with, but was adapted to be responsive later with little effort, as all the components were originally built to fit any width. Some time later, as part of his process of building a responsive site, Jeremy Keith extended Natalie’s concept into a “pattern primer”, which presented components alongside their markup. This pattern primer acted like an encyclopaedia of all the components on the site, how they looked, and how to reproduce them. Unlike a component library, the page itself didn’t look like the final site: each module was shown on the page at 100 per cent width.
20
The code for Jeremy’s pattern primer is on GitHub.
That’s the way I’ve been starting most of my projects lately: beginning with the atomic units of content and styling them first before even thinking about layout. This ensures that those styles are extremely robust—because they don’t depend on any particular context, they can be safely dropped into any part of a page. —Jeremy Keith, “Pattern Primer”, 19 November 2011 The documentation for front-end frameworks like Bootstrap and Foundation share a similar format. Examples of components are presented alongside their markup, with explanations of how to use the modules. In his article “Responsive Deliverables”, Dave Rupert suggests that customised, small, Bootstrap-like systems could become “self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web.” Component libraries are ideal for the development and testing phases. Since the entire site’s components are in one place, it’s easy to view a library on multiple devices to check everything works and confirm that 21
styles or interactions don’t contradict each other. Components should be flexible and work as expected even if they live on different pages. I’ve found component libraries most effective as deliverables after the site has been developed, particularly if there’s any additional work to be done. Component libraries have been especially useful to me when I’m writing markup and CSS but handing over my work to developers who will integrate it with their CMS. Having patterns alongside the corresponding markup makes life easier for these developers – it means they don’t have to pick through my code to find what they need.
22
Why a Front-end Style Guide?
Benefits of front-end style guides A front-end style guide is a declaration of an agreed and tested way that a site’s owner wants it to be maintained. The more accessible this documentation is, the easier it’ll be for other people to use. If the documentation isn’t there, people are going to have a hard time maintaining the site. Preparing a style guide improves standards: you’re likely to be more thorough in your decision-making.
INCREASE INTEGRITY If it’s comprehensive enough, a style guide will reduce the likelihood of naked (unstyled) elements. Elements that often get missed out in design mock-ups include styles for the different list types, tables, form fields, block quotes, and hover, active, and focus styles on links. Rather than asking the designer to style every possible element, create something the designer can refer to and tweak. A basic stylesheet, complemented by a style guide showing how elements look, makes it easy to sit down with the designer and work through it. Creating a basic boilerplate stylesheet means you don’t have to start from scratch for every project. If you often add the same CSS to every project (say, removing bullet points from lists within a