What is FA?

Frontend Architecture for Design Systems

• The growing of the Web forced Webmasters to hire new team members or leaving the market
• Content strategy is a concurrent process with designing of website. It is mandatory to treat the content as a critical asset and to have a strategic planning for it.
• Responsive web design (RWD) is introduced as a collection of Fluid grids (% based widths), Flexible images (100% fit to its container), and Media query.
• The role Frontend Architecture is a missed position in projects and you should define it in your company.

What is FA?

It is a collection of tools and processes that aims to improve the quality of frontend code while creating a more efficient and sustainable workflow.

FA characteristics:

• Design: skipping of relying on developers by set of visions and a standard for code and ensuring that all code contributing to that system adds perceivable value rather than just adding lines of bloat.
• Planning: Mapping out the development workflow and what steps will a developer take to write a line of code and see that code through to production (a mechanism of useful feedbacks in terms of Linting, tests, and documentation)
• Oversight: a key talent of FA is the ability to continually make the client’s adjustments by using modern build tools

*. FA is never a “set it and forgot it” proposition.

FA Gambling?

Betting on the former architecture is always a bad gamble for FA, and you should make decision at the beginning of a project either task is difficult to implement later on in development or the cost of making the wrong decision is way too great.

The FA Pillars:

The code pillars: set expectation for HTML, CSS, and JS

Good code never happens by accident and As FA you should evaluate the processes that produce your markup

HTML markups:

• Procedural Markup: 100% automation, 0% control: too much markup, deep nesting classes
• Static Markup: 0% automation, 100% control: too much nesting selectors and spaghetti code
• Modular Markup: 100% automation, 100% control: a modular markup is created, styled and integrated.

Which issues should be solved in CSS Methodology:

• Resetting the colors
• No IDs and change to class names
• Location independency
• Multiple inheritance with freedom of modification
• Further nesting without trouble

Modular CSS Methodologies:

1. OOCSS Approach: Tow main principles are to separate structure and skin, and to separate container and content (e.g. Bootstrap).
2. SMACSS Approach: it breaks the style into 4 categories

• Base: default style for markups
• Layout: dividing the pages into different sections
• Module: reusable part of design
• Theme: visual appearance (optional)

3. BEM Approach

CSS Principles:

• Separating container from content
• Defining roles and responsibilities of layouts versus components
• Single reason and single responsibility for each selector, that should be done extremely well. Defining a single and unique class for every element
• Single source of Truth, no overwrite by parent selector to have easy placement
• Component modifiers

*. As an FA, you don’t need to know all the small bugs in CSS, but you should know the trending in your field and be able to apply in your team.

JS:

The first issue is to select a Framework for your project and keep it simple.

Maintaining clean JS:

1. Keeping your code clean by using linting/hinting tools (e.g. JSHint, ESLint) and add it into your IDE

• Using eqeqeq pattern
• Limited number of nested blocks
• Limited number of params for every function
• Repeated names for function and vars
• Remove unused function and vars

2. Creating reusable code, by breaking your code into smaller components and functions to have more flexible, leaner, cleaner, and testable

The process pillars:

defining the development process from developer’s brain to user’s browsers (e.g. writing all the HTML and CSS before the feature is even implemented)

Workflow is heart of the development process, which includes:

• Requirements for all targeted audiences
• Prototypes for all desired devices
• Development, developer should develop the prototype as a bullet proof with styles, JS, and etc. QA should validate

Frontend workflow:

• Provisioning and installing all the software and tools
• Spinning up local machine
• Story writing (short, describe in great detail the problem, proposed solution and requirements that must met to complete the story), be focused on the components to update the design system, rather than a single page.
• Development, push, review, and merge into master branch
• Distribution
• Committing compiled assets
• Continues integration server (Jerkins or Travis)
• Tagged releases
• Using package manager (e.g. Bower)

5 Benefits of Schema-First Design

• Constrained Development: Schema-first design establishes a constrained development process that prevents development and scope drift.
• Faster Development: Schema-first design reduces many of the elements that result in development lag and slowing of processes.
• Cleaner Development: Schema-first design results in a cleaner codebase, in which expected functionality is presented in a clean manner without duplication of code and effort.
• Generation of Resources: Schema-first design allows for automated generation of key resources to API and application adoptees, and reduces time-to-market in turn.
• Single Source of Truth

The test pillars:

Creating a plan for sufficient test coverage will ensure that yesterday’s code continues to provide the value it did on the day we wrote it. New code can introduce bugs or regression in different ways. All of them have a similar impact: loss of sale, and each one has a similar solution: testing.

Issues must remember at planning test coverage:

• Tests are written when the site is being built, or even before actual code is written
• They are living code, committed with or next to the system repository
• All tests must pass before any code is merged into master branch
• Running the suite on the master branch should always return a passing response

As FA make sure that developers have the tools to be as efficient as possible

Tests in test pillars:

1. Unit testing:

• Scope of Unit: ‘do one thing, and do it well’, break your code down into small functions.
• Reuse the units
• TDD: write test for your functions first then developer should write the desire functions to pass the tests
• Test coverage: fixing gaps (if not enough budgets) which means find a simple valuable test case for start and then looking for critical parts. Also, coverage from the start of any story.
• Performance testing: ‘no excuse for poorly performance’ if you want to have competitive advantage.
• Set a performance budget: which means setting targeted values for each key metric and continually testing them before each code merge or deployment
• Always target 20% ahead of your competitors’ metrics

Raw metrics

1. page weights, set a budget for:

• Images, use <picture />
• Font, just once not second time
• Using inline SVGs, for font
• JS&CSS frameworks gain page weight
• Take advantage of minifications and compressions

2. Reduce the number of HTTP requests, how many assets are there? How heavy are they?

• Concatenate JS&CSS into one file
• Combine images into one map
• No lazy-load asset for landing page
• Increase number of assets retrieval per round trip

3. Timing metrics

• Time to first byte
• Time to start render (see sth in the page)
• Time to document complete

4. Hybrid metrics (instead of measuring a discrete value, score based on the performance indicator

• Page speed score (items p 116)
• Speed index

Tools for performance test before merge (grunt page speed, grunt perf-budget)

Visual regression testing: Why “feature X is changed or totally broken” after a couple of weeks?

• Unknowing developers when they are working on a shared component
• Inconsistent designs, working with different version of PSDs or designs
• Waffling decision makers by over-prototyping of features

Faces of visual regression testing:

• Page based defining (Tool: Wraith)
• Component based defining (Tool: BackstopJS)
• CSS unit testing (Tool: Quixote) and build TDD-style tests
• Headless browser driven (Tool: Gemini and PhantomJS)
• Desktop browser driven (tools: Gemini and Selenium)
• GUI-based comparison and change approval (tools: Diffux)
• Command-line comparison and change approval (tools: PhantomCSS better to implement inside webpack)

The documentation pillars at the same time as the process or artifact begin developed. Documentation is the blueprint of our design system

Documentation forms:

• Static documentation (tools: Hologram, SassDoc)
• Code driven documentation (tools: Pattern Lab library)

Don’t put all of your hopes in a single solution, framework or platform! until it has proven itself to you time and time

[1]. “Frontend Architecture for Design Systems: A Modern Blueprint for Scalable and Sustainable Websites”, Micah Godbolt, January 28, 2016