18F/frontend

FBI front end review

msecret opened this issue · 1 comments

msecret commented

General project

  • What are you planning on building?

  • How will it work with other clients?

  • Is there anything unique about the design of the product?

  • How will the project be passed off after 18F has finished it?

  • Who are the users?

  • Are there analytics for the current users?

CSS

  • Will a CSS methodology/framework be employed. example: BassCSS, Atomic CSS?

  • What will the CSS class naming convention be. example BEM?

  • Will the project use the US WD standards?

  • Will there be a design system or pattern library?

  • How will visual UI or style be tested?

  • Use Hook classes for JS and Testing, like js-*, test-*.

  • Will there be a coding style guide? If so, will an existing style guide be used?

  • How will a CSS linter be set up? When will it run? What happens when it fails?

  • Will you use a CSS processor such as Sass or PostCSS?

  • How will icons be done?

  • How will images be done?

Javascript

  • What will the backend be?

  • Is there an API built for this?

  • Does the site need to work without Javascript?

  • Will a JavaScript framework be used?

  • Can web components be leveraged?

  • What JS style guide will be used? Will there be modifications made to the base 18F styleguide setup?

  • How will a JS linter be set up? When will it run? What happens when it fails?

  • What tool will be used for dependency management?

  • When and how will dependencies be upgraded?

Build

  • What is the build process?

  • How will JS files be sent to browser? Just one file? Multiple files?

  • Will you ever want to split up the JS files into multiple bundles?

  • Will this be continuously deployed?

  • What language dependencies? Ruby, Node, Python? Can we keep it to just 1?

  • In what cases should the build fail?

Testing

  • Structure: integration / unit / functional, the mix between them, methodology

  • Decide when tests should be written, or coverage amount?

  • How will it fit into code review process?

  • How will JS unit tests be run?

  • Will they require DOM? Will they test the DOM?

##Devices

  • What browsers will be supported? This should likely be based on user analytics if any are available.

  • What is the usage percentage cut-off? For example, if (using analytics) there are 2% of users with IE6 will you support that browser?

  • What device sizes will the site support? What device sizes will be focused on?

  • Will it be mobile first? If not, why not?

  • How will accessibility be ensured? How will accessibility testing be done, if it is?

  • What accessibility standard does the site have to conform to?

Performance

  • What metrics should be tracked? ie: page load, speed index, custom events, number of requests, total request size, etc.

  • When should performance be measured? ie: on live staging site, locally during test runs.

  • How should performance be measured? ie: with what tools

  • What should performance budgets for decided metrics be? ie: faster then 1000 for speed index, faster than 1s for certain custom event, total request size below 2mb.

  • How should performance metrics and budgets be incorporated into workflow? Going over a budget requires re-implementation, or issue.

jseppi commented

Pretty old and can be closed?