The Development Lifecycle

Adecco employs an agile development process. The Functional and UX team write "stories" that contain "user acceptance criteria" which explain in detail what is needed from the development team. The global team is required to ensure the software functions as expected, while our task, depending on the story requirements - is to create a basic, usable interface with not much more than the containing grid.

Business Units

At Adecco, we support many Business Units around the world with their own specific website requirements of design, style, colors, images, page structure, components and more. There are two main style sheets required – a global team cms.css and rollout team theme.css files. In order to effectively markup components for so many separate BUs' websites, there are a few things to keep in mind: Do not markup CSS with the brand-specific colors, spacing, font-size, weight, family etc. Create strong, intentional, highly targetable HTML modules and elements. It is recommended that every individual element (such icons, inputs, text etc) to be in their own container and every related group of elements should also be in a uniquely named container using BEM for consistency.

At the time of writing, we are in the process of developing a “vanilla” site that is gray and white with no BU specific styling. We are doing this to create a clear distinction between the teams responsibilities. Testers and functional teams can accept stories without concern for style issues reducing bugs and confusion. After user stories are accepted by the functional team (Isabelle Gerard,) the Rollout team (Sourabh Khatri, Sumesh Srivastava) will have separate stories and mockups that address styling and proprietary functionality for each BU.

Back

Toolbox

Bootstrap, BEM, Sass and Gulp are the main technologies used for UI development. If used correctly, in most cases there should be minimal styling and CSS required to maintain a responsive layout and meet functional requirements. All of the stylistic aspects including CSS, JavaScript, images and fonts can be found in the Design Solution and will affect every BU website.

Back

Install NPM, Node, Gulp

The version numbers may be different during install, but you can follow the instructions on the "Getting started... pdf. Gulp compiles the CSS and JavaScript into the public folder as CSS and JS files. Warning! For ease of process, while working in the Design solution, keep the Global solution open. Build the Design solution first, and then the Global solution for complete compilation.

The team works out of the Design Solution, within Includes > Developer > Software > CMS -- those SCSS files are what you will be working on. When you build it will compile into Includes > Public > Stylesheets > cms.css - we never edit .css files.

Back

Browser Support

Use BrowserStack for testing.
ID: aaa.bbb@ccc.com
PWD: 0000000
We support the last three versions of Chrome, Firefox, Safari, IOS, Android and IE9+. Use Adecco’s Browserstack account to test on a minimum number of devices and browsers, including iPhone, Android, Mac, and PC environment.

Back

Current State of Development and Old/New Functionality

Adecco is going through a BU rebranding process. You will notice that our Adecco UK/FR websites in development are radically different from the other BU websites you see in production. This difference also includes a host of new functional features or pages (technically known as controllers) which makes our job more challenging and rewarding. We are faced with the task of maintaining old and new styles, and keeping old and new functionality intact. This is why unique selector naming is important.

For instance, Similar Jobs is an old controller whereas Branch Locator is new. With new controllers we have some freedom to create the HTML structure and new CSS. For old controllers, we cannot change the html at all because they are used in production across many BU’s and the existing theme CSS files are targeting a specific element whose document hierarchy cannot be altered. This is why creating a strong HTML structure is so important.

Best practice is to place every element (like icons) in a container and every related group of elements should also be in a relevant and uniquely named container using BEM for uniqueness, target-ability and system wide consistency.

Back


SPECIFIC CSS WRITING STANDARDS

Bootstrap Grid

All components should be built without widths and heights. This means that we can let the grid provide the layout and the component can be reused throughout the site in different areas without breaking. The grid system should be separated from all components. The grid is only used for layout. For example:
// Incorrect
...
// Correct
...

Back

BEM CSS Selector Naming

Please follow this easy to read Sass formatting, spacing and naming style. If you need more information please read the BEM website, or just ask.
.branch {

  &__maps-link {

    &--text {
      margin: $margin;
      padding: $padding;
    }
    &--icon {
      margin: $margin;
      padding: $padding;
    }
  }
}
    
The above compiles to a unique semantic selector name that’s easily target-able for rollout team:
.branch__maps-link--text {
  margin: 10px;
  padding: 10px;
}

.branch__maps-link--icon {
  margin: 10px;
  padding: 10px;
}
    

Back

HTML Structure

Let the grid provide the layout so component can be reused throughout the site in different areas without breaking. The grid system should be separated from all components. The grid is only used for layout.

// Keep Bootstrap columns on their own divs

Back


GENERAL CSS WRITING STANDARDS

!important

We discourage the use of !important. Don’t use !important tags to trump specificity. If needed for hot-fixes, include all CSS in the _shame.scss partial and refactor the right way when time permits.

Back

Commenting

As a best practice, comment everything in your HTML and CSS. Use comments to make maintaining and editing code easier, and also to denote information to make it easier for others to edit your code.

      

This is a paragraph tag.

This is another paragraph tag.

Back

Section Titles

Each section should have a corresponding section title. Prefixed with a double hash (##) sign, this makes searching for sections easier. Use the following format for titling sections:

/*------------------------------------
  ## CARDS
------------------------------------ */

.card {
    background-color: #ffffff;
}
    

Back

Grouping Declaration Sets

When grouping together multiple declarations sets within a section, use the format:

/* ------------------------------------
  ## CARDS
------------------------------------ */

.card {
  background-color: $white;
      
  /* Typography */
  &__title {
      color: $primary-font-color;
  }

  &__subtitle {
      color: $secondary-font-color;
  }

}            
    

Back

Single Declaration Comments

Oftentimes we want to comment on specific declarations (i.e. lines) in a ruleset. If the comments are short, use them inline.

box a:hover {
  overflow:hidden;  // to clear floats - internal comment
  height: 30px;    /* external comment */  
} 
    

If there are multiple, longer comments in a declaration set, we use a kind of reverse footnote.

/**
* 1.  delegate  layout to wrapper element
* 2. positioning context for us to lay our  nav and masthead text in
* 3.  Faux-fluid- height technique
*/

.page-head--masthead {
.wrapper {                /* [1] */
      position: relative;   /* [2] */
      padding-top: 56.25%;   /* [3] */
}
    

Back

Multi-line CSS

CSS should be written across multiple lines, placing one declaration per line in a declaration block. However, in very specific circumstances, such as similar rulesets that only carry one declaration each, you may place CSS on single lines if it increases readability. For example:

.icon {
  display: inline-block;
  width:  16px;
  height: 16px;
  background-image: url(/img/sprite .svg);

.icon--home      { background-position :   0     0  ; }
.icon--person    { background-position : -16px   0  ;  }
.icon--files     { background-position :   0   -16px; }
.icon--settings  { background-position : -16px -16px; }
    

Back

In multi-line CSS each selector should be on its own line, ending in either a comma or an opening curly brace. Property-value pairs should be on their own line, with one tab of indentation and an ending semicolon. The closing brace should be flush left, using the same level of indentation as the opening selector.

//CORRECT
#selector-1,
#selector-2,
#selector-3 {  
    color: gray;
}

//INCORRECT
#selector-1, #selector-2, #selector-3 {
color: gray; }
    

Back

Nesting

Only nest selectors that will compile up to three levels deep. When using & in sass, you may nest more than three levels deep if the compiles CSS results in less than 3 levels. For example:

// Correct
.pipeline {
  &__stage {
    .is-active {
      .count {
        padding: 10px;
      }
    }
  }
}
.pipeline__stage .is-active .count {
  padding: 10px;
}
    

Back


Resources

Back