Creating A Living Style Guide - A Case Study - Smashing Magazine PDF

5/17/2016
Creating A Living Style Guide: A Case Study Smashing Magazine
We use ad-blockers as well, you know. We gotta keep those servers

running though. Did you know that we publish useful books and run friendly
conferences crafted for pros like yourself? E.g. upcoming SmashingConf
New York, dedicated to smart front-end techniques and design patterns.
Creating A Living Style Guide: A Case Study

ByStevenLambert
Published on May 16th, 2016 in Design Systems,
Style Guides
2 Comments
with
Living style guides are an important tool for web development today,
especially in large, complex web applications. ey help document styles
and pa erns, keep designers and developers in sync, and greatly help
to organize and distill complex interfaces. Indeed, living style guides
remain one of the best ways to communicate design standards to an
organization.
Recently, our company went through the process of creating a living style guide. This is
the story of how we developed our living style guide, the mistakes we made along the
way, and why the current landscape of style guide generators did not suit our needs.
https://www.smashingmagazine.com/2016/05/creating-a-living-style-guide-case-study/
1/23
5/17/2016
How We Came to Need a Living Style Guide

FamilySearch1 is a worldwide genealogy site that is built and maintained by multiple
teams, each dedicated to a dierent section of the site. Four years ago we had a site
redesign which resulted in a more unied brand. However, after three years the
separate teams had created their own unique styles and we realized that the site was no
longer unied.
We had over 200 unique colors across the site. Most colors were very close to
each other in hex value. We discovered that this was due to developers using the
eyedropper tool to extract the color the designer had used in the mock-up.
Common styles, such as buttons, were copied from one style sheet to another, or
worse, recreated with variations in the same style sheet.
Styles on a single page were inconsistent with themselves.
UX patterns were widely dierent across the site, leading to user confusion.
We decided that it was time for a change. Our current practice was neither sustainable
nor scalable. What we needed was a style guide.
2/23
5/17/2016
A small portion of the myriad of colors being used throughout the site. Notice how many similar
shades of grey there are. (View large version3 )
Making a style guide wasnt a new idea. It had been tried and done before and failed.
The result of the last eort was a PDF style guide that was several years out of date and
rarely brought up. Most designers and developers didnt even know it existed. We knew
that if we wanted this new style guide to be successful, it had to always be up to date,
otherwise it would fail like the last one.
Our Humble Beginnings

I joined FamilySearch as a web developer at the beginning of 2014. After the rst month,
I began to notice that the section of the site my team worked on had a lot of CSS bloat.
We didnt have a common style sheet that every page used, so any common styles or
patterns had to be copied and pasted for every page. A lot of times those styles would
contain variations, leading to an inconsistent look even between the common styles.
3/23
5/17/2016
I began discussing with one of the designers on our team about how we could
consolidate all of the inconsistent and common styles into a single style sheet that all of
our pages could use. During our free time, we would take inventory of our section of the
site, looking for styles or patterns that we could add to our common style sheet. Within
a month we had aggregated the most common styles into a single style sheet and
released a small style guide just for our section of the site.
Our sections style guide, inspired by the GitHub style guide at the time. (View large version23105 )
Building up to the release, we both made sure to inform the other developers, designers
and managers on our team about what we were doing. This facilitated discussions about
why a style guide would be helpful and allowed everyone to get behind the project.
Thus, when the style guide was released, everyone on the team began using it and we
were able to clean up a lot of the CSS bloat in our codebase.
Word spread about what we had done and soon other teams were interested in having
a style guide as well. We got in touch with the sites lead designers to discuss the idea of
extending the style guide to the entire site. As it turns out, they had been working on
creating a style guide for the marketing team just a few months prior to our eort. We
quickly combined our eorts and started working on creating a style guide for the whole
site.
4/23
5/17/2016
Creating the Style Guide

We started by printing o large screen captures of every page of the site and hung them
up in a room. This not only served as a great way to see inconsistencies, but also served
as a conversation starter as to why a style guide was important. Being able to see all the
pages of the site side by side made it extremely easy to see the eects of not having a
style guide, which then led to discussions about how a style guide would solve those
problems. We encouraged as many people as we could to visit the room and see the
problems we were trying to solve.
Once all the pages of the site were printed, we went through each page and identied
any inconsistencies in the styles and patterns. We wrote down our ndings and put them
on sticky notes and attached them to the corresponding page so that we could easily
see what and where the inconsistencies were. Using the information from the sticky
notes, we were able to gather a list of all common patterns and styles used across the
site.
A wall in the room where we hung all the screen captures of the site. We nicknamed it the room of
inconsistencies. (View large version7 )
5/23
5/17/2016
Over the course of six months we consolidated everything into a single unied set.
Since we were still using our free time to create the style guide, there would be some
weeks where we werent able to make any progress.
During that time, we conducted questionnaires with developers and designers to better
understand what information both groups would want from a living style guide. From
those interviews, we were able to determine what to include and not to include in the
style guide.
We also had quite a few intense discussions, especially over colors. Im not joking I
think it took us four months to decide whether or not we should have a color palette,
what colors it should consist of, and how you cant programmatically generate buttons or
alert dialogs from a single base color because the end result couldnt be guaranteed to
look right.
At rst, the designers felt we shouldnt enforce a color palette as it would restrict their
creativity. However, the more we talked about the importance of unifying our brand
colors, the more they realized that we needed one. We settled on dening a set of
primary colors and accent colors that designers could use. To help designers not feel
too restricted about their color choices, we set a guideline that any of the colors could
be lightened by any percentage, giving the designers plenty of room for creativity.
After that discussion, I tried to convince the designers that generating colors
programmatically for alerts and buttons would save a lot of time. If I could use a single
base color and then lighten or darken it by a set percentage to create border,
background and highlight colors, then we could easily create new styles when needed.
However, after a lot of discussion, they convinced me that doing so wouldnt always
work. Depending on the base color supplied, the end colors couldnt be guaranteed to
pass contrast ratios or produce an aesthetically pleasing result.
Halfway through the project we released a prototype of the style guide. This allowed
interested teams the opportunity to try it out and see how it worked for them. It also
helped to show those teams how a style guide would save them time and eort.
6/23
5/17/2016
At the end of the six months, we were able to release the ocial FamilySearch Style
Guide8 . We were very excited, but we knew that it wasnt the end of our work. We
needed to get designers and developers to use it.
To do this, we created a Sketch template that used up-to-date styles from the style guide
that designers could use to easily create new mock-ups. These mock-ups could then be
given to the developers who would use the style guide and information in the mock-up
to create the nal product.
Our Sketch template with predened Symbols and Styled Text that incorporates the style guide
styles and patterns. (View large version23105 )
7/23
5/17/2016
The Sketch template uses predened Symbols and Styled Text that designers can use in
their designs. The Symbols are broken up by pattern (alerts, buttons, etc.) and provide all
the available variations of the pattern as well. The Styled Text is broken up by type
(headers, paragraphs, lists, etc.) and also provides any variations. The template is
maintained by one of the designers and is updated whenever there is a change to the
style guide.
With the Sketch template and the style guide, designers were able to focus more on
layout and workow rather than on colors, fonts, and button styles. We worked closely
with the designers to ensure that their creativity wasnt stied now that they had to
follow a style guide. We made sure not to create meticulous rules about how modules
and components should be used and instead left it up to the designers best judgment.
This allowed the designers creative freedom while still being able to have a consistent
look and feel in all designs.
Style Guide Architecture

During the six months of development, we also decided on how to organize and present
the style guide for both developers and designers to consume. We did a lot of research
into dierent ways to organize large CSS projects and eventually stumbled on Brad
Frosts amazing article discussing the atomic design11 methodology. We immediately
connected with it and knew we wanted to organize our style guide using the principles
he discussed.
One thing that we liked about atomic design is how it encouraged creating LEGO-like
pieces that would allow us to build on them to create more complex components. We
decided to name the stages dierently from Brad Frost in order for them to make more
sense to our teams. Atoms became elements, molecules became modules, and
organisms became components. Brad Frost wrote in his book12 that renaming the stages
is perfectly acceptable since its the concept thats the most important.
8/23
5/17/2016
at being said, naming things is hard and imperfect.
e names I ve chosen for the stages of
atomic design have worked really well for me and the teams I ve worked with. But maybe they
] By taking the time to establish an agreed-upon vocabulary, [a] team [is]
don t work for you [
able to get on board with the concept of atomic design and work together e
ectively by speaking
Brad Frost
the same language.
After we had agreed on the names of the stages, we organized our directory structure
around those names. We created a directory for each of the stages, and then created a
le for each of the patterns inside of those stages. This worked well to organize our
patterns, but it didnt leave us a place to store our preprocessor variables and functions.
To compensate, we also created a directory we called helpers that anyone could import
to gain access to all of our functions and variables.
Once the structure was set up, all that was left was knowing where patterns belonged
and what to name them. We created a simple set of rules that would allow us to quickly
determine where a pattern should go:
Elements consist of tag name selectors or single class name selectors that aect
a single element. This allowed us to group elements like inputs and buttons
together with single class name selectors to create simple things like badges or
icons.
Modules are any pattern that requires more than one HTML element to create.
This helped us clearly dene the dierence between elements, which could only
have a single HTML element. Patterns such as alert messages and cards t well
into this stage.
Components were a bit tricker to classify. We rst tried to classify them as any pattern
which used a module, but we quickly discovered that owing to the building block nature
of atomic design, you could easily have a card include an alert message if the card had a
form. This didnt feel right to us since something as simple as a card didnt feel like it
should be component. We then remembered that atomic design classied organisms as
relatively complex, distinct sections of an interface. But what would make a clean and
simple denition of a distinct section of an interface?
9/23
5/17/2016
We decided that components should be any pattern which could be represented as any
of the HTML5 sectioning elements: <main>, <header>, <footer>, <aside>, <nav>,
<article>, <section>. This made classifying them easier since we could always refer to
how those elements should be used in an HTML page to understand when a pattern
was large enough to become a component. Patterns such as a site header and footer or
a mobile drawer navigation would cleanly t into this stage. So far, we havent run into a
problem with that denition, but we also havent created very many components just yet.
css
elements
buttons
forms
typography
modules
alerts
cards
modals
components
header
footer
helpers
functions
mixins
variables
An example of our directory structure.
Once we knew how to classify patterns, we could then start creating and naming them.
For the most part, naming a pattern was relatively simple, especially in the elements
stage, as we just named them what they were (e.g. buttons, forms, alerts). Other patterns
we didnt have a name for and so we looked to what the web called them (e.g. cards).
Some patterns, however, were harder to name since they didnt have a concrete identity,
even on the web. For example, we had to spend a month deciding on the name of the
pattern for a mobile drawer navigation. The pattern has many names, such as o-screen
navigation, o-canvas navigation, a tray, a drawer, or a slide-in. In the end we had to just
sit down and make an executive decision.
Whats nice about having a style guide is that once a pattern has been documented,
everyone will start referring to that pattern by the name used in the style guide. So even
if someone didnt agree with the name we chose, they had to use it if they wanted to
10/23
5/17/2016
communicate the pattern to someone else.

The last piece for organizing our style guide was guring out how to write our CSS
selectors. We wanted to create component styles that could be overridden without
trying to win the specicity wars. If youve ever used Bootstrap and tried to override its
base styles, you can understand how annoyingly dicult it can be to override something
like .nav>li>a. We discovered BEM CSS13 , which helped us to write single class
name selectors for everything. This allowed developers to override the base styles by
just adding their own class and then use a single class name selector of their own.
For example, a card module creates a rectangle with a box shadow and adds padding to
the child content. If a developer wanted to remove the padding from the children, all
they would have to do is add their own class and use a single class name selector to
remove the padding. Because the style guide only uses single class name selectors, the
developers selector will always override ours.
<divclass="fscard">
<h4class="fscard__title">CardTitle</h4>
<divclass="fscard__bodynopadding">Thisisacard.Ithasaslightborderradiusandboxsh
</div>
<style>
.nopadding{
padding:0;
}
</style>
How BEM CSS makes style overrides simple.
Our Mistakes
Throughout the creation of the style guide, and after its release, we made several
mistakes that hindered developers and designers from using or adopting it. Some of the
mistakes were easy to x, others not so much. As the saying goes, If youre not making
mistakes, then youre not doing anything.
11/23
5/17/2016
R E L E A S I N G T O O E A R LY
One of the earliest mistakes we made was releasing the style guide too early, namely
the prototype. Even though it helped to kindle interest and excitement about using a
style guide and helped us get our bearings, problems arose when the ocial style guide
was released and teams had to switch o the prototype.
Developers and managers had already invested a lot of time converting their pages to
use the initial styles. When they found out that they would have to spend more time to
convert to the new styles, they were understandably less than thrilled. We had changed
so much from the prototype in both the look and the class names that we essentially
made them start from scratch. Not only that, but a full page conversion required a
manual page-by-page inspection by both a designer and a developer to ensure that
they hadnt missed anything.
To help remedy the situation, I created an auditing tool14 that could be run from a
bookmarklet to identify and highlight where on the page styles were overriding the style
guide. The tool greatly sped up the time it took to convert a page as well as ensured
that all of the applicable elements were using the style guide. And since it could be run
from a bookmarklet, even the designers could use it and help the conversion process.
I recommend that if you are creating a style guide, dont release the prototype or an
early version that is bound to see major changes. Its no fun having to do the same work
twice and it might hurt your adoption in the end.
M I S U N D E R S TA N D I N G W H AT A B R E A K I N G C H A N G E M E A N T F O R C S S
Another mistake we made came after we released the style guide. As we observed how
developers and designers used the style guide, we noticed that our button names
werent well understood. We had used the names primary button, secondary button,
and tertiary button, but it wasnt clear as to when they should or should not be used.
12/23
5/17/2016
We reworked the names and the descriptions to better convey their meaning and ended
up with recommended action button, button, and minor action button respectively.
These names described the buttons purpose instead of prescribing an order in which to
arrange them. This added clarity to when and how each button should be used.
However, since we changed the names of the buttons we also had to change the BEM
modier class names used to style the buttons.
15
Buttons styles before and after the change.
Each of the buttons used a modier class to change the look. A developer would add
the base class fsbutton to get the basic button styles, and would then add the
appropriate modier class to style the button the way they needed, such as fsbutton
tertiary to get the tertiary button look. With the button name change, the modier
name changed with it. So instead of fsbuttontertiary, a developer would need to
use fsbuttonminor to get the same look.
When it came time to release the change, we agged the release as non-breaking since
it didnt break the base button styling, only the modier styling. We thought the change
wouldnt break anything, but we were quite wrong.
Soon after we made the release, we started receiving complaints that we had broken
the styles. It turned out that most developers felt that a non-breaking change meant that
it was safe to upgrade to a newer version and no code changes would be required.
When they made the upgrade and discovered that their buttons looked dierent and
that they would have to change their modier class names for every button, they werent
very happy.
13/23
5/17/2016
After that little incident we made sure that any release which would cause a pattern to
look dierent than before or which would require a class name change would be
considered breaking.
AT O M I C D E S I G N O R G A N I Z AT I O N
When we adopted the atomic design methodology, we also adopted its way of
organizing the style guide by elements, modules, components, templates, and pages.
We designed the style guide with multiple pages where each page focused on one of
the classications.
After a while we kept getting asked about where certain styles were documented and
kept having to point them to the other pages of the style guide. We soon found out that
designers and developers didnt even know that there was more than just the rst page.
They were expecting all the styles to be on a single page.
We decided to adhere to everyones expectations and moved all the styles onto a single
page. Internally we kept the organization of the les the same, but just changed how the
style guide presented the information.
Our decision to not strictly adhere to atomic design presentation felt somewhat like we
had abandoned what we tried so hard to establish. However, our decision was validated
earlier this year when Trent Walton wrote an article about ensuring that conventions
work for your team16 when using atomic design. We realized that it was more important
to organize styles where people expected to nd them rather than organize them
according to the underlying methodology.
M A K I N G T H E S T Y L E G U I D E BY H A N D
When we rst started the style guide, it was a handcrafted HTML page with a lot of
duplicate code. Any change to the look had to be applied to every section of the style
guide by hand. At rst the changes werent hard to make, but as the style guide grew, so
did the amount of work required to make them. We soon realized that making changes
to the style guide was more work than actually creating new styles for it.
14/23
5/17/2016
Our rst attempt at automating the style guide was to create a Handlebars template that
used a JSON le that we maintained by hand. Each section of the style guide was
generated using a combination of nested objects, strings with HTML, and an associated
HTML le that had the example output. For a time this proved much easier to maintain
than the single, large HTML page. However, this too was not scalable, and in the end we
knew we needed something more automated.
17
A mock-up of the style guide that turned into the ocial design. (View large version18 )
We began looking into style guide generators as a solution to our problems. They
promised easier and more automated maintenance for creating living style guides. As
we were looking at the dierent options available to us, we created a list of
requirements that a style guide generator had to meet for us to use it.
Allow us to create a custom structure/template for the style guide. We wanted to
be able to dene the entire output and not just a small portion.
If it didnt allow us to create our own structure, then it had to have the ability to
output a JSON object that we could then use for our own template.
Have a separate code output from the example output. Some of our examples
15/23
5/17/2016
required some additional structure for setup or a completely dierent structure

than what was shown in the example. For instance, showing a modal in a
conned area for the style guide required some additional structure and styling
since they normally take up the whole screen. We didnt want to show that in the
code output since it wasnt pertinent to how a developer would normally markup
a modal.
Create a hierarchy of sections and to sort those sections how we wanted.
Parse comments using Markdown. After having maintained HTML in JSON
strings, we knew it would be easier to just write in Markdown.
Put examples in the comments if we so desired instead of a separate le.
Sometimes its just easier to see and edit the example right next to the code that
its for.
If the style guide generator used tags in comments, we needed the ability to
dene custom tags for colors and icons.
If we couldnt dene custom tags, it had to be able to parse any key/value pair
tag.
And lastly, the generator had to still be maintained so we could get help with any
issues we had and get them xed.
As a bonus, we preferred if the generator was written in JavaScript so if need be
we could hack at it to get it to work for our needs.
COLUMNS: SWIPE
CUSTOM
TEMPLATE
JSON
OUTPUT
KSS
CUSTOM
CODE
SECTIONS
EXAMPLE IN
COMMENTS
KSS-node
Hologram
DSS
The Living Style

Guide
Styledown
16/23
5/17/2016
Styledown
Styledocco
SC5 Styleguide
x
x
Note:
This table explains how style guide generators met our requirements. All highlighted
style guide generators use tag-based comments (and are all based on KSS) and so
needed to meet the last two additional requirements. x means it met the requirement, !
means it partially met the requirement.
For custom templates, most of the style guide generators only allowed you to modify the
header/footer or how the code was rendered; only one allowed you to pass in your own
template.
Building Our Own Style Guide Generator

As we looked at the current landscape of style guide generators, we found that most of
them did not meet even half of our requirements. Only one came close, but it still didnt
allow us to create our own template, nor output a JSON object for us to use. After weeks
of researching and trying dierent style guide generators, we came to the conclusion
that if we wanted one that did everything we needed, we would have to make it
ourselves.
Building your own style guide generator is not new. In fact, its been written about twice
before on this very site, where the creators of SC5 Styleguide19 and SourceJS20 talked
about why they did just that. Each of them went through the same process that we did
and came to the same conclusion: the current landscape of style guide generators do
not meet our needs.
For us, we really wanted the ability to completely customize everything about the
generated style guide. We had a custom theme that we wanted to design that would
match our branding. Our code examples would start collapsed so the UI wasnt cluttered
17/23
5/17/2016
with code that designers didnt care to see (nor developers most of the time).
Sometimes our code would be dierent than the examples, and sometimes we wouldnt
show the code at all.
And so we spent two months and built a style guide generator that could do all of these
things.
e LivingCSS Style Guide Generator

We built a style guide generator21 in Node.js that could parse JSDoc-like comments in
the styles and use that information to generate a living style guide. We decided to use a
tag based system because Markdown alone couldnt trigger dierent states for
individual sections as easily as a key/value tag could.
/**
*Ashortdescriptionorlengthyexplanationaboutthestyle.Will
*beparsedusing`markdown`.
*
*@sectionSectionName
*@example
*<divclass="myawesomeclass">Example</div>
*/
Example comment block for LivingCSS to parse.
What makes LivingCSS dierent than other tag-like comment parsers is that it doesnt try
to impose a strict tag ruleset on you. Instead, it denes a few basic tags for you to use,
but any tag will be parsed so long as it follows the @tag{type}namedescription
format (where type, name, and description are all optional). Moreover, if you need
special functionality for a tag, you can also dene custom tags that can run functions.
Comment descriptions are parsed using Markdown, which combined with tags, meaning
you have complete control over how the contents of any given section are rendered.
The parsed comments are passed into a Handlebars template which generates the style
guide. You can use a custom template if you dont want to use the default one, which
18/23
5/17/2016
nalizes the ability to customize the style guide for your needs. If you dont want to
use Handlebars, you also have the option to just output a JSON object that can be used
as you see t.
To use LivingCSS, you just pass it a list of les you want to parse that have the
appropriate comment markup and the output directory for the generated les. Any
additional options can be passed as the last parameter. The nal output is a static HTML
le that is the living style guide.
22
Example output of a style guide generated using LivingCSS. (View large version23105 )
In the end, we built what we needed: a exible style guide generator. If you are looking
to build a living style guide using a generator, I recommend you gather your own list of
requirements and compare them against the current landscape. Each style guide
generator has their strengths and weaknesses, nding the one that works for you is the
best thing you can do when automating your style guide.
Maintenance
19/23
5/17/2016
Now that the style guide is released, we continue to meet weekly to discuss new
patterns and if our current patterns suciently meet our needs and the needs of our
users. We also allow anyone to suggest new patterns or changes to existing patterns,
and during our meetings we discuss whether or not to implement the suggestion. This
has helped everyone to feel a part of the style guide process and not think of it as
something being forced on them that they have no control over.
When a style needs to be changed or added, we typically design it out in Sketch rst,
especially if we need to analyze the style against dierent states. Sometimes though,
when we are consolidating an inconsistent pattern already used on the site, we just
choose one of them to be the ocial pattern and skip the Sketch design.
We then build the pattern into the style guide, trying to reuse as many previously
dened styles and patterns. Then we use LivingCSS to automatically update the style
guide with the new pattern. Next, we push the new style guide to our beta environment
so developers and designers can test the new styles before they go live into production.
We typically push the style guide from beta to production after a month or so to allow
ample time for all the teams to do testing. Finally, we update the Sketch template so all
new designs will use the latest styles.
Recently we were informed that our users felt that the font on our site was hard to read.
We did some digging and decided to improve our typography by using a more legible
font, increasing the font size and line height, and implement a baseline grid and modular
font scale. We feel really good about our changes and are planning to implement them
within the next few months after some user testing.
Because we have a living style guide, a site-wide change to typography will be trivial
compared with what it would have taken to get all the teams to update the typography
manually by a specic deadline. All we have to do is add the styles to the style guide
and everyone will automatically get the updated styles.
Being able to easily update styles across the whole site to improve the user experience
is probably one the of greatest benets of using a living style guide.
20/23
5/17/2016
Conclusion
Creating a living style guide was a long but worthwhile process. We made a few
mistakes along the way that prevented developers and designers from adopting it
sooner or using it eectively. However, we pushed through and eventually made it to the
end.
Even though its released, we still have a long way to go. There are still more styles and
patterns that can be added, more pages that need to be converted, and we are planning
to expand the style guide to include animations24 and accessibility guidelines in the near
future. We hope youve learned some valuable lessons and that what weve done
proves useful for your own style guides.
(vf, jb, og, ml, il)
FOOTNOTES
1 https://familysearch.org/
2 https://www.smashingmagazine.com/wp-content/uploads/2016/03/01-colors-opt.png
3 https://www.smashingmagazine.com/wp-content/uploads/2016/03/01-colors-opt.png
4
5
6 https://www.smashingmagazine.com/wp-content/uploads/2016/03/03-the-wallopt.png
7 https://www.smashingmagazine.com/wp-content/uploads/2016/03/03-the-wallopt.png
8 https://familysearch.org/reference/styleguide/
9
21/23
5/17/2016
10
11 http://bradfrost.com/blog/post/atomic-web-design/
12 http://atomicdesign.bradfrost.com/chapter-2/#whats-in-a-name
13 http://getbem.com/introduction/
14 https://github.com/straker/css-style-guide-audit
15 https://www.smashingmagazine.com/wp-content/uploads/2016/05/buttons-beforeafter-change-preview-opt.png
16 http://trentwalton.com/2016/02/26/atomic-classication/
17 https://www.smashingmagazine.com/wp-content/uploads/2016/03/04-styleguidemockup-opt.png
18 https://www.smashingmagazine.com/wp-content/uploads/2016/03/04-styleguidemockup-opt.png
19 https://www.smashingmagazine.com/2015/03/automating-style-guide-drivendevelopment/
20 https://www.smashingmagazine.com/2015/04/an-in-depth-overview-of-living-styleguide-tools/
21 https://github.com/straker/livingcss
22
23
24 https://24ways.org/2015/animating-your-brand/
Hold on, Tiger! Thank you for reading the article. Did you know that
we also publish printed books and run friendly conferences crafted
for pros like you? Like SmashingConf New York, on June 1415, with
smart design patterns and front-end techniques.
22/23
5/17/2016
Steven Lambert
Steven Lambert is a lead web developer and accessibility advocate at
FamilySearch.org. He has over 7 years of industry experience and specializes in
design systems, performance, and accessibility. On the side, he is a hobbyist game
developer and freelance web developer.
With a commitment to quality content for the design community. Founded by Vitaly Friedman and Sven Lennartz. 20062016. Made in Germany. http://www.smashingmagazine.com
23/23

Creating A Living Style Guide - A Case Study - Smashing Magazine PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Creating A Living Style Guide - A Case Study - Smashing Magazine PDF

Hochgeladen von

Copyright:

Verfügbare Formate

5/17/2016

Creating A Living Style Guide: A Case Study Smashing Magazine

We use ad-blockers as well, you know. We gotta keep those servers

Creating A Living Style Guide: A Case Study

Creating A Living Style Guide: A Case Study Smashing Magazine

How We Came to Need a Living Style Guide

Creating A Living Style Guide: A Case Study Smashing Magazine

Our Humble Beginnings

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating the Style Guide

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Style Guide Architecture

Creating A Living Style Guide: A Case Study Smashing Magazine

at being said, naming things is hard and imperfect.

e names I ve chosen for the stages of

] By taking the time to establish an agreed-upon vocabulary, [a] team [is]

don t work for you [

the same language.

Creating A Living Style Guide: A Case Study Smashing Magazine

An example of our directory structure.

Creating A Living Style Guide: A Case Study Smashing Magazine

communicate the pattern to someone else.

How BEM CSS makes style overrides simple.

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Buttons styles before and after the change.

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

required some additional structure for setup or a completely dierent structure

The Living Style

Creating A Living Style Guide: A Case Study Smashing Magazine

Building Our Own Style Guide Generator

Creating A Living Style Guide: A Case Study Smashing Magazine

e LivingCSS Style Guide Generator

Example comment block for LivingCSS to parse.

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Creating A Living Style Guide: A Case Study Smashing Magazine

Das könnte Ihnen auch gefallen