Best Practices

Working with Sitecore

    • Always have a POC as an HTML file in initial output
        -Preferably shown at page level based upon designed composition
    • Stay in sync with Sitecore developers to avoid confusion and re-work
    • All project files are shared between Sitecore and UI developers
    • Avoid creating new components if possible
        -Utilize option of adding classes to SCORE components
        -If a new component must be introduced, talk to Sitecore developer
        -Any new component styles should be saved in "site" folder
        (custom-component-name.less)
    • Keep HTML sandbox files up to date with production
    • Use browser extensions to test local CSS on production pages
        -CSS Inject, CSS Reloader, Web Developer, etc.

Where to start?

    • Two approaches to begin project development
        -Front end first, back end last (you write HTML)
        -Back end first, front end last (you are given HTML)
    • Determing factors:
        -Budget
        -Time contstraints
        -Resources
        -Team preference
    • Decide whether to build whole pages with components or build stand alone components

Pros and Cons: Front-end First

Pros:

      • Solid POC from beginning (show progress to clients, designers, team members)
      • Point out design flaws early in the process
      • Sitecore devs have a good foundation to start their development
      • Design assets are implemented from the start (image cropping, scaling, saving to project folders)

Cons: 

      • Potential re-work after page is built in Sitecore
      • Potential wasted file space with unused styles
      • More pressure on front-end for usable markup

Pros and Cons: Back-end First

Pros:

      • Back-end devs have total control over markup
      • Saves time and effort from front-end perspective
      • Limited front-end involvement at the beginning of the project

Cons:

      • More pressure on back-end for usable markup
      • Sitecore devs have limited visibility with design
      • Potential for HTML re-work after it reaches front-end stage

Code Organization

    • Keep Less files organized and tidy
        -Prevents code bloat and allows code to be easily understood or worked on by another team member
    • Stay DRY!
        -Do your best not to repeat specific styles or blocks of code
        -Use global variables and mixins that can easily be updated and maintained
    • Keep nesting under control
        -Maximum of 4 levels deep if possible
        -Styles under highly specific selectors are hard to override in other places
    • We recommend NOT changing any Bootstrap LESS files