Clarity Conf Day 2 Notes

Here's my notes from day 2 of Clarity Conf. Again, apologies to the speakers whom I'm certain I misquoted and probably misrepresented. These are very incomplete. Please send me a message or say 'hi' in person with any changes.

Jina Anne

  • designsystems.herokuapp.com <- get invited to the Slack channel!

Chris Coyier

  • Jina has years of experience with this. "Design Systems Empress"
  • Thanks to Jina who basically organized this entire thing
  • Recap of yesterday's events
    • "Dangers of silos"
    • "Measure that your style guide is successful"
    • "Maybe a style guide is a CSS API"

Rachel Nabors

  • She's basically done everything with animation ever. like, all of it.
  • "Any Bronies in the audience?"
  • Hand-drew all her slides
  • This isn't a talk about how why to use animation. it's about how to wrangle it.
  • When you put animation in a system it's important to keep it consistent.
  • Animation sits at the intersection of design, dev, product..
    • Communication issues, inadequate deliverables, lack of respect(for people or just for animations)
  • Hard to find universal examples of animations
  • Designers want thematic, theory, educational, guidance...
    • IBM's motion guide
  • Developers want granular, components, fixed numbers, instructional, maintainable code..
  • Documentation, defaults, unity.
  • There is no one size fits all
  • The best place to start is at the end. start with deliverables.
  • Easing used to be called "cushioning" or "slowing"
  • Just like her website, "we want custom easings that reinforce our brand"
  • You'll want a few: acceleration, deceleration, something subtle(like linear but not exactly linear because it sucks) and a bounce.
  • Fades and color changes look best with more linear changes.
  • Bounces are fun but use them with caution.
  • Stay within 70 to 700ms
  • 200 - 300 is a sweet spot for animation duration.
  • Shorter durations for fades and color changes.
  • Longer durations for animations.
  • CSS opacity and transform are the most performant properties right now.
  • John Lasseter - "The art challenges the technology and the technology inspires the art."
  • It's okay to use things that don't perform well sometimes.
  • Creating an "animation language"
  • Hilariously, "people hold their vowels longer with onomatopoeias to indicate duration"
  • Combine animations to create animation patterns. fade + pop + slide = notification/dismissal pattern.
  • Storyboards were created by disney to make long animations clear.
  • Blue and orange are the most visible colors to most people.
  • Fancy storyboards are a great way to demo animation to clients.
  • Storyboarding tools:
    • postits, index cards, paper
    • her storyboard template.
    • boords.com
  • Storyboard can't tell you how an animation is going to feel
  • "An animation is worth a thousand meetings"
  • An "animatic" is kinda like a gif with some animations in the middle. It's a rough sketch.
    • They're like mood boards or doodles, not deliverables
  • Animatic tools - keynote aftereffects, principle, animatics
  • Stephanie Rewis - "what developer doesn't want a good copy-paste?"
  • Prototyping tools - principle, pixate, invision, ux pin, foundation, framer.js
  • Verbal + animatics + prototypes = good documentation.
  • Generating buy-in
    • Let people contribute! especially to the documentation
    • Group index-card sketching of animations
    • Animations need champions in every company. but have a co-conspirator.
  • Sarah Drasner, also Ben Folds, also also Brad Frost - "Do it anyway."
  • There is no 'right way' but you can create a culture that supports animation.
  • webanimationweekly.com
  • slack.animationatwork.com

Conversation after

  • Fabulous unicorn horn
    • "Unicorns"(in context of the talk) are designers who grok code.
  • We have an innate anticipation of how physical systems work.
    • If you break your own rules the site seems sketchy or unfinshed.
  • "It's like wearing a really cheap suit to a wedding"
  • Justify your animations! -not just animations but have a reason for everything you do.
  • "Because it looks good" is not a justification for anything.
  • Sometimes too much animation is a bad thing.
  • "Baby-friendly animation" because some animations are hard to watch for babies/the tired..
  • "Browsers throughout history have only ever had to animate one thing: scrolling."
  • Web animations API opens up the animation internals! you can create your own performant animation library.

Cordelia McGee-Tubb

  • Baking accessibility in
  • Accessibility is creating experiences that everyone can use regardless of their abilities
  • You've made these really great muffins. but your mom is like "your nieces favorite is blueberries!" so you start just shoving blueberries into the muffin and it looks awful and it's not the same as a blueberry muffin.
  • "As system designers, you are creating the cookbooks that everyone else reads."
  • If you learned to do stuff by reading other people's code and copying and pasting it...
  • It's about creating really comprehensive systems.
  • Foundational ingredients
    • Semantic HTML - a screen reader relies on elements being marked-up correctly.
  • Write code samples that are accessible by default so that when people are copy and pasting that code they are copying good code.
  • An anchor elements without an href is not keyboard-accessible.
  • Make sure that your buttons are actually
  • Form fields: use visible, explicit labels! - low-contrast is a huge issue for people with low vision, cognitive impairments...
    • Make sure that example form fields have labels with a for attribute to connect the label to the input.
  • Give images alternative text.
    • Icons should also have alt text if they're meaningful or readable by a screen reader
    • Use alt="" or aria-hidden="true" to hide images from screen readers.
  • Include a dash of ARIA when necessary.
  • Components that should be aria: modals, menus, accordions, tabs,
  • Resources: wcag 2.0 guidelines, heydon's practical aria examples, web accessibility slack community
  • MAKE KEYBOARD INTERACTIONS AS RICH AS MOUSE INTERACTIONS
    • Create an animation that happens both on hover and on focus
  • Don't forget about focus halos
    • People navigating with the keyboard need focus indicators because they don't have a mouse.
    • Don't get rid of the focus indicator, just change it to be more attractive.
  • Colors
    • Use reasonable color ratios
    • colorsafe.co
    • Just make sure to use dark colors for text and use the light colors for whatever else.
    • Use more than just color for meaning(use the text 'required' instead of just highlighting a box in red)
    • Yellow is an extremely difficult color to get to pass wcag 2 guidelines
  • Pinterest fails are the best.
    • What often happens with design systems is the opposite. people will make a website that looks good but tastes awful.
  • INCLUDE ACCESSIBILITY NOTES IN YOUR DOCUMENTATION
  • Component documentation: remind people to constantly remember accessibility. spread best practices. discourage people from accidentally removing accessible aspects/ARIA attributes.
  • General documentation: encourage holistic thinking about inclusive design.
  • Does the need to code accessible markup the "right way" provide a barrier to entry to writing accessible code?
  • Think about ways you can make things fun for all users.

Conversation after

  • Improving voice and tone is a great way to make fun for everyone.
  • "Accessibility mode" is actually really bad for people who need it.
    • It's a great way to create a second-class experience that gets neglected.
  • Adding keyboard shortcuts is actually more fun for everyone and not just people who need them.
  • button.button is a great way to force people to only use button styles on buttons. instead of spans and divs and all that.
    • Does that limit us from having links that we want to look like buttons?
  • Most modals are inaccessible.
    • "The incredible accessible modal"
    • Trigger focus on the first element in a modal to keep tab focus in the right place.
  • Don't make custom select elements. they're not accessible. just don't.
  • tenen.io?
  • People start out afraid of accessibility but once they're done they like it more than the original
  • Accessibility is not just for blind people with screen readers.
    • Minor or temporary impairments.. reading a screen in bright sunlight.. migraines with aura..
  • Voiceover apple has good documentation.

Jeremy Perez-Cruz

  • I wanted to do a slide that doesn't say hello.
  • It's awesome how warm and welcoming everyone is.
  • It's humbling to be around all these smart, thoughtful people.
  • "The future of branding is in-house"
  • Branding is fun and doesn't include a lot of acronyms :P
  • @hat is brand?
    • Name, packaging, price, history...
    • Intangible
    • Marty Neumeier - "A person's gut feeling about a company/product."
    • Brand is psychology, design and magic.
  • "Startups don't realize they need a brand until they reach some sort of scale."
  • A great brand definition needs to be a living. breathing document.
  • We shouldn't be afraid to go back and edit once our work gets into the hands of others.
  • There's no such thing as bulletproof brand design guidelines.
  • "A logo might live for decades. ... If we're lucky."
  • Experience is the brand and experiences live in people.
  • Brand in the context of people's human lives.
  • Create your brand out of sympathy.
  • Systems should always be a work in progress.
  • Brand design guidelines:
    • Breathe. Sometimes we need to make things look good even if it makes breaking a guideline.
    • Grow. "Salesforce defaults to clarity over brevity".
    • Learn. We have to learn the essentials of being human. You won't know if something works until you try it and learn.
    • Feel. Get happy.
    • Fear. "The most innovative ideas scare the crap out of everyone." - Neumeier
    • Age. Everything new will become old and will eventually become new again.
    • Socialize, explore, create, share
  • "Human The Movie" - This speaks to the optimism and the humanity that we should all be striving toward.

Conversation after

  • Branding not only can evolve but should evolve
  • What is the real brand?
  • How do you know what's good?
  • It's hard to get real data when your company works at huge scale..
  • Think about brand in terms of permanent vs temporary.
    • Intrinsic vs extrinsic.
    • Permanent is like the logo. shouldn't change..
    • Extrinsic is like an ad campaign.
    • A really strict set of guidelines breaks core principles of design.
    • "Good design works without needing to ruin the brand."
  • Do small companies screw up branding because they don't work on it as actively?
  • We as an industry always complain about wanting a seat at the table.
  • We should be proud of CEOs that want to get involved with design. We should support each other and want to get design involved in all our projects. Look at all the massive companies who's greatest value is their brand and their design.

Claudina Sarahe

  • It's awesome that we're all design system enthusiasts.
  • best use of emojis so far.
  • "If only there were some document or resource I could point my junior devs to..."
  • Christopher Alexander - "Patterns are a collective memory of things that work really well in our surroundings."
  • "A pattern language is a method of describing good design."
  • Notes on the Synthesis of Form
  • A Pattern Language -> Towns. Buildings. Construction.
  • Wanted to release it as a binder so you could add or remove patterns as you need them.
  • "Patterns are not dogma."
  • Anatomy of a Pattern
    • Name
    • Context
    • Problem
    • Solutions
    • Related patterns
  • "Naming Pattern"
    • Name: naming
    • Context: a way to identify
    • Problem: people don't know what stuff is.
    • Solutions: give stuff names.
    • Related patterns: documentation, classes
  • A pattern language serves as a way to communicate and educate
  • They're a very useful tool in trying to wrangle a very complicated system.
  • A pattern language forces us to remember that we're working in a system.
  • "A pattern language for front-end web systems"
    • Global patterns
    • Community guidelines
    • Temporary autonomous zones(meetups)
    • Independent disciplines (ui, ux, dev, accessibility)
    • Process patterns
    • Purpose
    • Planning
    • Management
    • Code reviews
    • Cross-functional teams
    • Design Systems
    • Naming
    • Documentation
    • Single origin of truth
    • Workspace patterns
    • Editors
    • CLIs
    • Syntax highlighting
    • Shortcuts
    • Git/Github
    • Version and dep management
    • Configuration and settings
    • Project patterns
    • Build tools
    • Bundling
    • Linters
    • File organization
    • Composability
    • Templating
    • CSS strategy
    • JS
    • Content strategy
    • Shareable data
    • Identifiers
  • Tadao Ando
    • "Purpose should be baked into all of our decisions."
    • Ando - "To change the dwelling is to change the city and reform society."
  • Open Borders - working with people across disciplines and skill sets.
    • Minimal dependencies, static, no db, no migrations, everyone on a team can work on the codebase.
  • Documentation
    • A way to record decisions. Code is not self-documenting. Use automated solutions. Documentation should be easy to find.
    • Sassdoc is based on jsdoc and uses the same style.
  • HTMl Templating
    • A way to create structure and share code across components.
    • Nunjucks, jade, swig, handlebars, mustache..
    • Related: naming, Documentation, directory structure.
  • {% call content_panel({...}) %}
  • Directory structure
    • Traditional - type, view, purpose, file.
    • Component - first designed by nicholas gallegher. view/component, {purpose,} file.
  • Build tools make it easy to ignore whichever structure and just Get work done.

Conversation after

  • Components are especially great for removing old code; You only remove code in one place.
    • Extra good for ie overrides because they all tend to live in one folder.
  • Nunjucks macros are super fun.
  • We're all very concerned with naming.
  • "We want to make sure the language we're using makes sense to everyone."
  • URL and path are different things!
  • "If you don't have solid naming conventions you can't communicate with your team."

Maya Benari

  • Works for 18f!
  • Gov't website with overlapping content. Many websites. Some of them seem like a scam. Roughly half are impossible to use on a phone.
  • Veteran benefits, immigration services, others are all hard to use...
  • The US spends 86 billion dollars per year on IT projects. 94% of them are over budget and behind schedule. 40% are scrapped before they ever go public.
  • BUYING I.T. IS NOT THE SAME AS BUYING PENCILS AND TANKS
  • These products meet the spec but ignore the person they're service.
  • Can we build easy-to-use tools that serve the public's needs.
  • The gov't has a strong history of good design here and there.
  • The UK does well but they're very different from us.
  • "The great pitch"
  • What was it like to work on federal IT services?
  • We interviewed a whole bunch of different government IT workers.
  • "The clock racer"
    • way too much work, too little time, desperate for solutions.
  • "The master builder"
    • They know systems well and love clean markup.
  • "The lone ranger"
    • Trying to do the right thing but they just makes one-offs.
  • The Macgyver, the newbie, the contract manager...
  • We want our standards to be flexible enough for all agencies and reusable.
  • They need to be accessible!
  • They should be open source since it' a public service.
  • Gov't sites should feel familiar and be intuitive.
  • Doing a survey: do we really need 32 different shades of blue? 70 different button styles?
  • Testing typography pairings across gov't websites.
  • Institutions seemed to think they need to maintain their own history and identity so new design standaards are all suggestions.
  • How can an agency fold parts of the standards library into their existing code?
  • How to use?
    • Our design and our code
    • Our design, different code
    • their design, our code.
  • Flexible code
    • "We should really think about how we write our code because millions of americans will be living with it."
  • Plain html, css, and javascript
  • Component-based structure
  • How to write code so that even junior developers could use it.
  • "We don't want to add more red tape to our already red tape covered jobs."
  • BEM and OOCSS is great with keeping your css modular but it fills your HTML with classes and bloat.
  • Open source all the things!
  • Open source makes your code more secure and maintainable.
  • 22 Contributors in the first week since launch.
  • Help from across the pond, from the products we use, from the iron chef of type design, from the fonts we used.
  • if you want to be a good open source project: respond to an issue in 24 hours and respond to a review in 48 hours.
  • "Always thank a contributor for their contribution!"
  • "Accessibility in't just a nice-to-have; It's the law."
  • Section 508 features.
  • Second most starred project on Github
  • 50 us websites are now using it.
  • "Naming things is hard."
  • Federal employees were afraid that the standard would be forced upon them.
  • Federal front door initiative.
  • "Good civic design at it's core is about access."
  • People can get the right help sooner with less stress.
  • Design can improve the interaction that people have with their government!

Conversation after

  • Should you or can you do research and start building at the same time?
  • It's amazing to see how so much of the target audience is different kinds of people.
  • "Should we BEM or should we not BEM"?
  • Adoptability depends on the complexity of the component.
  • "The most American javascript framework is vanilla JS."
  • We wanted to make a tool that people want to use, not one that they're forced to use.
  • Now we've been able to observe multiple agencies moving over to the new standards.
  • Did you have to make weird tech decisions based on public service constraints?
    • Not really. The website itself is a Jekyll website.

Richard Danne

  • Designing for Earthlings and Astronauts
  • Design director for NASA
  • Had a kickstarter for his original design manual. 9000 backers at 80$ a head.
  • When he started he felt like the US was way behind Europe in terms of design.
  • Introduced the "NASA Manual" detailing how everything should be laid out on paper, uniforms, space machinery...
  • "There's nothing frivolous about it. It's a design document that's meant for the ages."
  • Started out with a staff of 5 in a tiny office.
  • This was all pre-digital and things had to be done by hand.
  • There was a page in the book for how to not use the logo.
  • They didn't have electronic tyesetting so it was all basically hand-made.
  • There were no dedicated designers in any agencies then.
  • There were 5 space education vans.
  • The shuttle went through a bunch of different revisions because at first they didn't know where they could put graphics.
  • They had trouble with the uniform arm patch because of the color and how the patch also had to be flame-retardent.
  • "The idea was that your taxpayer dollars were working..."
  • Apparently all the photos of "rockets and space stations" were mocks?
  • Copy cat culture
    • Saturn, Boeing, "NAPA", ...
    • Tons of other brands have appropriated the original styles to look more space-y because they literally defined the "space brand" that people could recognize.
  • Designed for the FAA
  • Created designs for FIT. Was interesting because FIT insists that things always change so the brochures were completely different year to year.
  • Mendes JĂșnior - Created design guides in English and in Portuguese.
  • "The admiral's piping formed the 'A'"
  • Kid knowledge is a new initiative to teach physics to very young children.
  • Did design for napa valley jazz society but then also outlined promos for performers so their style was mostly congruent with the main design.
  • Get a copy at standardsmanual.com
  • If you are interested in the history of the manual, give him a call!

Conversation after

  • This was really a new effort in creating a style guide.
  • They brought in a panel of experts to audit the agency and try to identify what was needed.
  • Their RFP for the projects was just the crew going in and talking about their experience and how smart they are.
  • At the time NASA was 11 disparate centers that all resented headquarters.
  • It's hard enough to get the person sitting next to you to use your style guide let alone somebody in a different agency.
  • Spaceflight really pulled the nation together and got people interested in collaborating.
  • NASA is full of very smart, very talented people who are resistant to being told what to do.
  • "The fact that you had to push Helvetica through Congress..."
    • It was actually literally Congressional approval for 2 colors.
  • Physical style guides - people can hold it in their hand and they seem to respect it more so it is more effective.
  • "They put so much stuff on the tail it looks like it's disintegrating." You have to keep it clean.
  • "We designed for permanence."
  • What goes around comes around...