CFPB Design Manual & Capital Framework at OSCON

Editor's Notes

• #5: http://www.consumerfinance.gov/
• #6: http://www.consumerfinance.gov/the-bureau/ We were created by the Dodd Frank Wall Street Reform and Consumer Protection Act – which was signed into law on July 21, 2010. We launched our first website less than 7 months later and officially opened our doors in July 2011 …
• #7: which means that yesterday was our fourth birthday! http://www.consumerfinance.gov/blog/four-years-working-for-you/
• #10: Technology is core to accomplishing our mission. We need to develop and leverage technology to enhance our reach, impact, and effectiveness. We also want to serve as a model for innovation within government.
• #12: http://www.consumerfinance.gov/jobs/technology-innovation-fellows/
• #16: https://cfpb.github.io/
• #18: https://cfpb.github.io/design-manual/guides/design-principles.html
• #20: We had traditional design standards in the form of a printed style guide, which went through several iterations from 2011 to 2013. Though it spoke to some aspects of web design – most notably, basic 508 accessibility guidelines– It did not include interactive web patterns.
• #21: The early design staff also made a smart move to prioritize tools for all of our employees -- in the form of Microsoft Office templates -- so everyone at the Bureau could all be part of disseminating our brand. We continually maintain and update these templates.
• #23: consumerfinance.gov on the day that the first fellows started, January 2013
• #24: http://www.consumerfinance.gov/es/
• #25: http://www.consumerfinance.gov/hmda/
• #26: So, by September 2013, we have a landscape that looks like this – and there are still more examples of divergent designs that were live at that time that could be shown. Actually, all three of these designs are still live! Unifying disparate designs across many projects is a long process, and we still have a lot of work to do.
• #30: We weren’t the first to think of this, of course. Many corporations have digital style guides or web patterns, and we were heavily influenced by the UK’s amazing Government Service Design Manual.
• #32: https://cfpb.github.io/design-manual/
• #33: It includes guides like our design principles,
• #34: traditional style guide elements like logo standards,
• #35: our full color palette,
• #36: and our custom icon set. These standards were ripped straight from our printed style guide, and transferred over with little to no discussion.
• #37: But the manual also now includes user interface elements like links
• #38: and buttons. These did require a lot of discussion,
• #39: and we used GitHub to do it. We discuss new standards and changes to existing standards in issues
• #40: so you can hop on anytime and see our open discussions and process.
• #41: In each issue, you can see us discuss and debate: Best practices for design Alignment to our brand Learnings from past usability testing 508 compliance Ease of implementation for our developers https://github.com/cfpb/design-manual/issues/143
• #42: This isn’t the most efficient way to make decisions, but it is collaborative, inclusive, transparent and works for us. The documentation is open and extensive, so new employees (and the public!) can see how and why decisions were made.
• #44: As the Design Manual was off and running and picking up steam, the front-end development team knew that we needed a way to catalogue all of the recommended code needed to produce the web design patterns being standardized there. So, we decided to build our own in-house framework, which we call “Capital Framework”.
• #45: Here’s what it means to us…
• #46: The framework comprises these three things:
• #48: I kid a little bit, but I’m also serious. Maybe not for the reasons you think, though. It’s not that we’re afraid of using third party software. On the contrary, we love standing on the shoulders of open source software, and as mentioned earlier, we even have an official policy that encourages it!
• #49: The real answer is because it’s ultimately better for our users—both the public, who will be using the products that run on the framework, and our developers, who use the framework itself to develop the products.
• #51: What do we mean by modular? Well, this means we break the framework down into pieces, which we call “components”. Each component has a narrow focus, like defining typographical styles, specifying button types and states, or providing icons. We store each component in its own GitHub repository. Breaking it up like this is helpful because by making the framework a set of modular components, versus one monolithic folder (like other frameworks), it becomes easier to update it in bite-sized chunks, rather than all at once, and it becomes easier to share and distribute updates to each project using the framework. This approach was inspired by the Topcoat project from Adobe (shout out to Garth Brathwaite, who just presented here in another room last session), and is now gaining popularity with new frameworks like Basscss.
• #54: A quick rundown of how npm and Bower dependency management works, for those who might not be familiar. In your project’s source code, you can create these two configuration files, package.json for npm, and bower.json for Bower. In these files, you can list dependencies, which are other packages (also called modules or components) that others have written, or maybe you’ve written yourself. Having them listed in these files will tell npm and Bower to look at their package registries and fetch each of these dependencies at the specified version number.
• #55: So, back to the workflow. Here are the basic steps: Clone the project you’re starting to work on to your local development environment. Run `npm install` to get build dependencies installed. Run `bower install` to get front-end dependencies installed. Run `grunt` to build the project. Test it out in the browser. From there, there are two paths of work, so to speak. First to work on project-specific code, following the top loop, you’d edit the project source, build, test again, rinse and repeat. As you’re working on your project, you might find the need to update a Capital Framework component, which will take us down the lower loop path. To update a component, you’d edit the component’s source, push the new version, update your dependency version in the project and reinstall the component. Rebuild and test to ensure the update didn’t break anything. Editing the component and testing it out is a little more complicated than that, and I’ll give an example of that now.
• #63: We use a mixture of milestones, labels, and checklists in GitHub. Process is documented in the ReadMe
• #64: Non-developers can use Prose.io to update the design manual.
• #70: http://www.consumerfinance.gov/your-story/
• #71: http://www.consumerfinance.gov/owning-a-home
• #72: http://www.consumerfinance.gov/eregulations
• #73: http://www.consumerfinance.gov/complaints
• #74: http://www.consumerfinance.gov/complaintdatabase/
• #75: http://beta.consumerfinance.gov/
• #76: We continue to evaluate technologies and consider whether to incorporate them into CF. Gulp? cssnext? ES6? And at a higher level of government, a project partially inspired by our work is taking shape...
• #77: https://pages.18f.gov/govt-wide-patternlibrary/
• #78: https://github.com/18F/govt-wide-patternlibrary
• #80: https://cfpb.github.io/capital-framework/
• #82: Also, we could use your help! If you give it a try, please let us know what you think can be added or improved. Or do it yourself :) We love to receive issues and pull requests from the public.
• #83: Like this one, from our former CFPB colleague and Capital Framework co-creator Mike Morici.