{"action":"created","issue":{"url":"https://api.github.com/repos/18F/web-design-standards/issues/813","labels_url":"https://api.github.com/repos/18F/web-design-standards/issues/813/labels{/name}","comments_url":"https://api.github.com/repos/18F/web-design-standards/issues/813/comments","events_url":"https://api.github.com/repos/18F/web-design-standards/issues/813/events","html_url":"https://github.com/18F/web-design-standards/issues/813","id":110523894,"number":813,"title":"Discussion: sustaining design consistency","user":{"login":"WestonThayer","id":709153,"avatar_url":"https://avatars.githubusercontent.com/u/709153?v=3","gravatar_id":"","url":"https://api.github.com/users/WestonThayer","html_url":"https://github.com/WestonThayer","followers_url":"https://api.github.com/users/WestonThayer/followers","following_url":"https://api.github.com/users/WestonThayer/following{/other_user}","gists_url":"https://api.github.com/users/WestonThayer/gists{/gist_id}","starred_url":"https://api.github.com/users/WestonThayer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/WestonThayer/subscriptions","organizations_url":"https://api.github.com/users/WestonThayer/orgs","repos_url":"https://api.github.com/users/WestonThayer/repos","events_url":"https://api.github.com/users/WestonThayer/events{/privacy}","received_events_url":"https://api.github.com/users/WestonThayer/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/18F/web-design-standards/labels/To%20be%20triaged","name":"To be triaged","color":"f7c6c7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-10-08T19:21:44Z","updated_at":"2015-10-09T21:06:28Z","closed_at":null,"body":"...following up from [twitter](https://twitter.com/18F/status/652111938353295361?cn=cmVwbHk%3D&refsrc=email).\r\n\r\nThe [U.S. Web Design Standards](https://playbook.cio.gov/designstandards/) is an awesome and noble effort that touches so many Americans. It attempts to solve the problem of design consistency at a scale rivaling or surpassing major design studios like Google or Microsoft. Design consistency seems to be a nearly universal issue in our field (heck there's practically a [whole site](http://styleguides.io/) dedicated to it), so I'm hoping that this discussion will benefit everyone.\r\n\r\nAchieving design consistency can be broken into two main areas:\r\n\r\n* **Initial effort** - agreeing on standard guidelines and components, then implementing them consistently across many endpoints\r\n* **Maintenance effort** - as time passes, constraints change and components occasionally must adapt to ensure continued success\r\n\r\nWhile both of these come with their own challenges, I'm primarily interested in talking about the technical details of the second. The U.S. Web Design Standards take a Boostrap-eque approach to component distribution. Styles are consolidated and abstracted, but the HTML architecture of components (a.k.a. `<div>` soup) must be copy/pasted into each endpoint. An alternative approach that abstracts *both* style and HTML architecture can be found in the [Web Components](http://webcomponents.org/) spec, or libraries like [React](https://facebook.github.io/react/), [Angular](https://material.angularjs.org/0.11.2/#/), or the many others created by the JavaScript community\r\n\r\nThere are pros and cons to either approach that have large impacts on a design team's ability to maintain consistency. How did everyone at 18F go about choosing their approach? What advantages do you see to the Boostrap-ish path? What are you worried about in the future?"},"comment":{"url":"https://api.github.com/repos/18F/web-design-standards/issues/comments/146986085","html_url":"https://github.com/18F/web-design-standards/issues/813#issuecomment-146986085","issue_url":"https://api.github.com/repos/18F/web-design-standards/issues/813","id":146986085,"user":{"login":"carodew","id":10144074,"avatar_url":"https://avatars.githubusercontent.com/u/10144074?v=3","gravatar_id":"","url":"https://api.github.com/users/carodew","html_url":"https://github.com/carodew","followers_url":"https://api.github.com/users/carodew/followers","following_url":"https://api.github.com/users/carodew/following{/other_user}","gists_url":"https://api.github.com/users/carodew/gists{/gist_id}","starred_url":"https://api.github.com/users/carodew/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/carodew/subscriptions","organizations_url":"https://api.github.com/users/carodew/orgs","repos_url":"https://api.github.com/users/carodew/repos","events_url":"https://api.github.com/users/carodew/events{/privacy}","received_events_url":"https://api.github.com/users/carodew/received_events","type":"User","site_admin":false},"created_at":"2015-10-09T21:06:28Z","updated_at":"2015-10-09T21:06:28Z","body":"@msecret Great points! I agree on all the framework decisions. I just want to clarify a few things that came up in the user research:\r\n\r\nWe found that developers, when asked to consider whether they would use a specific component in their project, went through three primary steps: \r\n\r\n1. **Kick the tires of the component.** In this phase they would play with the component itself and see if it behaved in the way they desired or expected. \r\n\r\n2. **Examine the code.** After playing with the component, developers would look at the code and look for things like, \"is this HTML clean and semantic? Does the CSS make sense to me? What can I modify here and not break the component?\" This is why we needed to display at least the HTML on the page itself. They wanted to do this process before committing to downloading something. I think in future iterations we should explore also showing some of the SCSS and possibly JavaScript, but I'm listing those in decreasing importance, and more research needs to be done in this area. \r\n\r\n3. **Download the code.** The last phase is downloading the code, and we actually found that instead of copy/paste, having a download package for the entire component was the easiest. When we make users copy/paste the HTML and then link up the CSS and JS files, all sorts of problems and difficulties come up. The files aren't linked correctly (they aren't linked at all), they didn't have the entire line of CSS or JS that they needed, etc., or they would have to add in the HTML header and footer accoutrements to make everything work correctly.  Some users want to download everything in a package, but most users also expressed a desire to pick and choose what components they wanted to use, and didn't want to be forced to download something in it's entirety (adding a lot of extra weight to their code). \r\n\r\nThe question came down to feasibility within the MVP and what was the minimum we needed to include prove the concept. There were a lot of questions we had yet to resolve, including, what do you do if someone downloads the header and footer separately, both of which rely upon the same CSS styles? Does the user download duplicate files in that case? What if a user downloads a footer and accordion separately, while the accordion is actually contained in the footer? Do you have to download both? Does the footer break if you don't download the components it contains? \r\n\r\nAs we move forward into the next phase I think we can address a lot of these questions through more research and iteration, and provide more options for downloading the code. Build, measure, learn. :) \r\n\r\ncc-ing @colinpmacarthur on this response in case he has anything to add. "}}