Frontend Checklist

Contents

• 1. Before development
• 2. During development
• 3. After development

1. Before development

1.1. UX Output

Frontend developer should see the design before it goes to the client for approval. In this way we can prevent asking the client for repetitive approvals, if we have to change the design because of some technical issues, design issues etc.

1.1.1. Graphic sources

The quality of the source files is important for the collaboration between FE developers and designers.

• Designer should keep consistency in colors, font sizes, paddings, margins etc. among all the files and components.
• Designer should avoid using decimal numbers, e.g. 20,45px

Outcomes

• Consistency in design makes consistency in the code. The latter results in smaller source size, proper reusability and stable QA testing.

1.1.2. Responsive design

• Start and follow mobile-first design.
• Ensure component's consistency. When simple list of items becomes tabbed carousel on mobile it is most likely a wrong solution. However, this problem is self-eliminated when following mobile-first approach.
• Designer has to provide design in all predefined viewports.
• Designer should use Sketch pages as actual web pages and artboards as different viewports of the pages. It makes it easier to see the differences between mobile/tablet/desktop versions of the page in one screen.
• For default grid, designer can use Bootstrap grid for Sketch. In case design requires a custom grid, it should be acknowledged and aligned with the developer before development process begins to prevent unnecessary implementations.

Default Bootstrap 4 grid

	Extra small <576px	Small ≥576px	Medium ≥768px	Large ≥992px	Extra large ≥1200px
Max container width (with padding!)	None (auto)	540px	720px	960px	1140px

When creating grid, beware that the basic .container width has padding included!.

For example: gutter = 30px (15px each side) so .container width on Extra large screen is 1140px - 30px = 1110px

1.1.3. Styleguide

We prefer Atomic design, based on Bootstrap framework Styleguide describes all elements and components, their behavior, style, usage and code snippets.

• Colors
  • with examples where used, e.g. text-color, link-color, body-bg-color, primary-color, etc.
  • provide hexadecimal code: #4285f4 or RGBA: rgba(34, 34, 34, .3) for transparency
  • if possible, use lowercase hexadecimal code #fff instead of #FFF
• Buttons
  • include all button states: :hover, :focus, :active, :disabled
  • if you're using outline buttons with border, use border position outside, don't use inside or center in your graphic editor
• Typography for all viewports!
  • headings – h1 to h4 (h5-h6 - if applicable)
  • paragraphs and links
  • line height, margins - possibly following a vertical rhythm
• Form elements
  • :focus state
  • validation with errors
• Lists (ordered, unordered, definition) – 3 levels
• Tables - if applicable

IMPORTANT - Setup line-height on all elements (form, button, headings, etc.), because then the real spacing/margins of elements can be different from that in your graphic editor

Outcomes

• All elements are defined and reusable, without need for additional development.

1.1.4. Forms

• Avoid styling of the following elements: checkbox, radio, select on mobile (touch) devices. The native implementation is the best for the user experience.
• Provide validation states (valid/invalid states, error message placement - animation if applicable)

Example

• If the custom style is required, then all of the following styling must be defined:
  • default state
  • checked (radio, checkbox) state
  • open state (select)

1.1.5. Design

• Links: hover/focus/active/visited state
• Buttons: hover/focus/active/disabled states
• 404 page and other error pages
• Prepare favicon, touch icons, OG image etc. (see http://realfavicongenerator.net)
• Ajax loading icon (preferably CSS animation, or SVG when it is supported in IE11+)

Outcomes

• Developer does not to need guess/design the missing states and no additional iteration of design process is needed.

1.1.6. Design should contain the real content

• Adjust the text line height for languages with diacritic (Czech), especially in the headlines
• Design for variable text length, prepare a version with longer text, if it's gonna wrap on a new line or it should be truncate text with ... in the end.
• Design for variable images (height/width/ratio) in case of user uploaded image
• Design should be provided for the empty state (example: empty search result; no user profile photo/description)

Example

• Do not use "Lorem ipsum…", if real content is not available, use some real text generator
• It should be specified and clear in the design which containers should have equal heights, and which should be fluid (flexible)

Outcomes

• Decreasing the possibility of broken page layout

1.1.7. Fonts

• Consider how many fonts and variants (bold, black, light,…) to use (for better performance 2-3 types are recommended)
• Custom fonts will increase the page loading time (critical on mobile devices)
• Define the fallback font in case the custom font does not load
• Where the fonts will be hosted? (Google fonts, Typekit, Fonts.com, self hosted - if so, provide the source files and make sure that the correct licence is used)
• Does the font support all the necessary characters?

Outcomes

• Fast page load

1.1.8. Icons - TODO: check https://fvsch.com/code/svg-icons/how-to/#section-styling

• Preferred format: SVG
• Icon system - https://css-tricks.com/icons-and-teams/

1. Icon shapes are grouped semantically.
   • if the shapes have the same fill attribute and it should change e.g. on hover, it should be in one <g> group tag (represents a folder in graphic editor)
   • if the icon shouldn’t change it’s fill, stroke, etc., all the shapes should be in one <g>
   • all groups, paths, shapes, etc. should have semantic/meaningful name (e.g. head, eyebrows, left-arm, right-arm, etc.)
     • more words should be connected with dash -
     • should be in English, no special characters
2. Icon shouldn't have mask
   • if you have an icon inside a circle and the inside shape is bigger, so that it overflows the circle, just use subtract, intersect or difference tool in Sketch or Illustrator, to cut the icon to it’s proper size and then use circle shape for the background

Outcomes

• Icons are crisp sharp on all screen sizes (devices/high screen density)

1.1.9. User interactions

• Define the behavior of collapsing, read more and transitions or animations.
• If there are any more complicated interactive transitions or animations, designer should provide a working prototype, where FE developer can see the actual animation.

Example

• Animations
• UI-microinteractions
• Possible list of prototyping tools

Outcomes

• Better user experience
• Consistency

1.2. Frontend Output

1.2.1. Browser compatibility

Matrix of supported browsers should be defined and agreed on with the client.

Outcomes

• QA engiers know which browsers to test in
• Developers know which features they can use

Example

Device	Platform/version	Browser	Version
Mobile	iOS 8+	Safari	9 and above
	Android 4.4+	Google Chrome	53 and above
Tablet	iOS 8+	Safari	9 and above
	Android 4.4+	Google Chrome	53 and above
Desktop	Windows 8+	MS IE	11
		MS Edge	12 and above
		Google Chrome	53 and above
		Firefox	47 and above
	Mac	Safari	9 and above

1.2.2. Dev Stack

Use the latest versions of the gulp dev stack. In case you need more features, add them within the project. You can also raise an issue on Github and discuss an addition of the feature to the dev stack there.

Outcomes

• Best practices are ensured (structure, linting, …)
• No need to reinvent the wheel

---

2. During development

2.1. Best Practices

• Write the code according to best practices http://intranet/Wiki-Actum/Development/Front-end/Best-Practice/Coding-style
• Use our CSS naming conventions (http://intranet/Wiki-Actum/Development/Front-end/Best-Practice/CSS-Guidelines
• Maintain living styleguide using the dev stack
• Make sure favicon, touch icons, OG images are implemented

2.2. Accessibility

• Write valid code
• Keep the code semantic (use headings, paragraphs, etc. where appropriate)
• Use alt text for images (at least leave the alt attribute empty, read more)
• Focus state for links (accessible using keyboard)

---

3. After development

• Add readme.md with info how to use dev stack etc. Also put this info to the project page in Intranet.

3.1. Browser compatibility

• Test in supported browsers and devices (1.1.)

3.2. Performance

• Aim for the highest score on desktop and mobile in PageSpeedInsights
• Make sure that you serve the minified build of CSS, JS and SVG on production

Outcomes

• The pages load quickly.
• Better user experience.