design governance and code standards.! ! What we mean by that is:! ! • No more rogue agents, shooting from the hip with unique snowflake designs, or developers building one-off widgets in code. • Everything in a project should exist for a reason, and its purpose should be documented accordingly. • This allows for easier and quicker onboarding, where someone can refer back to established patterns and code conventions. • It gives you a defensive point reference, in case implementation goes awry. It's a "last known good" state of UI development.! ! (Design coworker Brandy Taylor coined the term "Design Governance.")
expectations, with a tie-in to SEO to "sell" it.! ! • AJAX does not mean "Accessibility Just Ain't eXciting."! ! • Browser requirements (January 12, 2016 = R.I.P. IE8).! ! • Best practices: • Responsive design, explanation and breakpoints. • What we will or will not attempt to achieve outside of CSS. • Border-radius, box-shadow, gradients, opacity, etc. • Non-native form controls. Styling is okay, but recreating something the browser gives you "for free" is not.
third party library or framework (that is half our job), assuming that… ! • The library or framework that you are using solves a problem you actually have. • You are not "solutioneering," attempting to use a tool designed to solve other people's problems.! ! • You are using it as a "tool," not a "crutch."! ! ! The more invested you are in a "kitchen sink" framework, especially if it lacks extensibility, the harder it is to adapt to change over the lifetime of a given app or product.
Before a Presentation! ! September 25th, 2015! ! Nathan: "When you get back from Burning Man, let's start working on our Front Porch slides."! ! Mundi: "Actually, why don't we go ahead and rewrite it using React on the client and server."! ! Nathan: O_o
for task automation removes the need to use a task runner like Grunt or Gulp.! ! • However, chaining together commands with NPM scripts can get hairy. There are tradeoffs either way.! ! • Closer to the metal, but more manual curation.
needs, using Grunt or Gulp can help ease the burden of automation.! ! • Ultimately, both Gulp and Grunt use Node under the hood anyway.! ! • Using NPM scripts is like an "API" to your build automation. Even if you are using Grunt or Gulp, you can map tasks to package.json too.
we are using React is…! ! • ES6 classes, transpiled to ES5 (via Babel).! • JSX ("HTML" in JS), which Nathan thought he would dislike.! • "Standard" for our JS linter.! • ASI: Automatic Semicolon Insertion – Don't kill us!! • Otherwise, it has generally agreeable conventions.! ! Note: ES6 and JSX feel different enough that going ASI (too) was not actually that big of a stretch. MAKE NEW ALL THE THINGS.
"universal" – aka "cool kids" • Create JSX "layout" components. • Then, using Node… • Use webpackRequire() to load the template and resolve dependencies: CSS, Markdown, images, etc. • Use ReactDOMServer.renderToStaticMarkup() to process the template and return HTML. • Save the rendered HTML output to disk.
PhantomJS script to iterate through a list of paths, taking a screenshot of each at mobile, tablet, and desktop widths.! ! • We generate a list of full-page screenshots that are linked to each actual "application" screen.
phantom to be able to access the pages you want to screenshot. Keep your server on!! ! • We wanted to use the awesome PageRes library. However, it ships with PhantomJS 1.x which uses an old version of WebKit. This has poor support for CSS3, making our screenshots look less than ideal. https://github.com/sindresorhus/pageres
via NPM (in our experience).! ! • You have to manually download and install PhantomJS yourself, which makes automation difficult. It is not as easy as: "npm install ..."! ! • Activity on the project seems to have slowed.! ! • In the future, we may look at using SlimerJS (based on Firefox).
the document, so that approaches like having a "sticky footer" don’t jack with the page's natural height. Basically, forcing something other than the <html> tag to scroll will confuse Phantom.! ! You can manually add this to the HTML tag (or via console) as you build pages, to check what PhantomJS will "see" when it goes to screenshot each page. This approach allows you to (de-)target Phantom via CSS.