Here's an example of this using VSCode (a free code editor), but should work the same in any other editor (such as Atom or Sublime - you'll need to find the relevant extensions for those editors) or if these don't work for you, you could look into a desktop app such as http://livereload.com/ though those tend to be paid while the editor ones are generally free.

In VSCode we can find & install extensions by pressing Ctrl+Shift+P and typing install and then finding the package in the list, or by clicking the extensions link on the left side menu.

For FTP in VSCode i'm using the SFTP extension:
https://marketplace.visualstudio.com/items?itemName=liximomo.sftp

& i've installed the LiveReload extension for VSCode too:
https://marketplace.visualstudio.com/items?itemName=ziishaned.livereload

Then, i'm using Chrome as my browser so I've installed the LiveReload extension for Chrome:
https://chrome.google.com/webstore/detail/livereload/jnihajbhpnppcggbcgedagnkighmdlei?hl=en

With these installed I'll setup my site's livereload to have a delay. In the settings UI (Ctrl+Shift+P and type settings) search for livereload.delayForUpdate and enter 500. This is a short half second delay that shouldn't be too noticeable but should also give ftp enough time to upload the file.
You may later find you have to save twice if it didn't update the first time, if you run into this a lot you could try increasing this setting.
Also if you want to work with sass/scss files, you'll need to add these to LiveReload's list of file extensions, find livereload.exts and add ,scss after css.
Also if you want the scss changes to work like css changes without a full page reload, for other editors there may be a setting but in vs code I forked the repo to build a version that does this for scss files too: https://github.com/stilliard/livereload-vscode/releases/tag/0.2.5 - hope to have this merged to the main extension soon.

Next I'll setup the FTP connection for my site:
Ctrl+Shift+P to open the command prompt and then type SFTP and click to init.
This will give you a JSON object where we can setup the FTP connection, I made a couple changes to this, the following should work:

{
    "name": "My site",
    "host": "xxxxxx.co.uk",
    "protocol": "ftp",
    "port": 21,
    "secure": true,
    "secureOptions": {"rejectUnauthorized": false},
    "username": "xxxxxx@xxxxxx",
    "password": "xxxxxx",
    "remotePath": "/",
    "uploadOnSave": true,
    "downloadOnOpen": false,
    "ignore": [".vscode", ".git"]
}

In the above I've set it to ignore ssl issues so we can connect to dev sites easily, as well as uploadOnSave to upload when you save / ctrl+s the file and the very useful downloadOnOpen (disabled in above config but set to true for this to work) which helps make sure you don't override other peoples changes by having VSCode auto download the latest version of the file each time you open the file.

Next we need to download the latest files, again with Ctrl+Shift+P in VSCode we can type Sync and select SFTP: Sync Remove -> Local, this will download all files over ftp to your machine.

Now we can test this out, first let's make sure FTP uploading on save is working. Try editing a file & check it uploaded.

If that all worked, let's now enable live reload. First we enable this in our editor (Ctrl+Shift+P and type in LiveReload and click to enable), then in Chrome, click the reload icon & the small circle in the middle should turn to a solid dot.

Then back in your editor, try editing a file & click save and watch it refresh in your browser. Best is when you edit a CSS file as it wont even reload the page, but the change should suddenly appear, I tend to test that by making something's background color red or similar.
If you have any trouble with this let me know either leave a comment below or feel free to contact me directly.

Lastly, with all this working, I always take a minute to quickly commit to version control. If you haven't used it before it's a great life saver.

Version control systems such as git allow you to keep revisions of your code and even back them up to a remote private location like GitHub or BitBucket.
Using your terminal, if you already have git installed, it's as easy to commit this to version control by first cd'ing into the folder you're working in & then run git init to start git (only needed once in the project), then to add the files, we'll add all this time to get started: git add . and then we can commit this by saying git commit -m 'Initial commit'

There's plenty tutorials for git online & on YouTube, worth checking one out. Here's a great guide I stumbled across recently that helps simplify it: http://rogerdudler.github.io/git-guide/

Thanks for reading & hope this helps you build awesome sites.

But sometimes you might need something more advanced, like a mega menu.

Luckily, REC's menu can be easily switched out and replaced by changing our nav.css file and nav.js files which handle the navigation design, and optionally you can replace the menu.html.twig file that renders the html for the menu, which is brought in on both the header.html.twig file and footer.html.twig files by default though you can easily style differences between these 2 menus.

Mega menus offer users a more interactive experience and require more thought than simple menus. Not all sites would require a mega menu and doing so on some sites might even get in the way of the sites UX.

In terms of mega menu designs available, a great collection of ideas are available here:
http://freefrontend.com/css-mega-menu/

We've taken the megamenu.js example from this and setup a test site for it: http://www.mega-menu.recds12.co.uk/
- Here you can see the mega menu in action working within a standard REC instance.

The code and instructions to create this are available here: https://github.com/ReallyEasyCart/responsive-snippets/tree/master/mega-menu

This demo shows using the menu to replace both as a mega menu & with a simple dropdown version.

Inside the mega menu, we've leveraged content blocks to bring in those images. Check out the README on GitHub for more info on how this works.

How does it work?

At REC we provide base parent templates that get upgraded over time with new features and content. This also provides a base 960 and responsive template.
Then you can override the files from this template in the site template folders.
Files at the same location in a child template will override those in the parent template.
That's pretty much it.
You can do some more fancy things in the html twig files by extending specific blocks of a page. (I'll come back to this later). Bus aside from this, template inheritance for us is, here's a base template. You have site templates that are child templates of those base parent templates. But you can also make you own child templates off of the the other child templates. This allows you to layer a sites themes. E.g. some sites may have a Halloween or Christmas theme that just changes a couple files and adds some css. In this case, responsive-base is the parent theme to the child-responsive site which is the current active theme. But when Christmas rolls around, the Christmas theme is switched on, and it is a child theme of the responsive-site theme.

So what are shadow files?

Now you know ow the inheritance works with child files overriding the parent ones. You also know that a child folder will only have the files that are overriding the parent inside.

However, wouldn't it be great if you could see the folder structure how the system does? That's where shadow files come in.
When showing the template folders and files for the current template, in admin we also show the parents files where the file is not overridden. These are shadow files. They are shadows of where the real file would be from the parent template.
Via admin you can click to view or extend this file into the child template to work with.

Why not override them all?

When we push updates in REC we sometimes make changes to the base template files. We try to avoid anything major to keep your live sites from changing, but we'll happily add new functionality or fix.
When you override the file, you loose these updates to that file. In most cases that's fine as your site is staying in the state it was and you can always get a diff of what has changed and apply changes if wanted. But if you're not making any changes to the file, you might as well leave the file not extended and then get automatic new features & fixes applied.

This is not a new topic btw, it's one since the dawn of time - internet time.

"Why will this lead to spam?" Robots, that's why.

Robots as we call them, or crawlers, or harvesters, or just scripts can be coded to search round the internet and gather email addresses from sites.

Sometimes it's just for the sake of gathering random emails, while other times they can be looking for sites in specific industries etc.

You might be thinking this doesn't happen much, but likely it's happening right now on your site... and again... and again. Many people are running these automated crawlers, and why, because it's easy to do and they can profit from it.

"How easy is it?"

Here's a quick bash script I wrote in about 5 minutes and it's far from perfect. It searches google.co.uk for "web designers" using curl and returns the first 100 results. Then it uses a combination of grep and awk find all the sites returned. Then it uses xargs to execute curl again to request each site and grep to look for any email addresses. At the end it prints out all the email addresses it's found.
Go ahead, try this in your terminal now: (Tested on mac & linux/ubuntu)

curl -s "https://www.google.co.uk/search?q=web+designers&num=100" --user-agent "Chrome" \  
    | grep -oE '<a href="\/url\?q=(https?:\/\/.*?\/)' \
    | awk -F'=|&' '{print $3}' \
    | xargs -L 1 bash -c '\
        curl -s $0 --user-agent "Chrome" \
        | grep -oE "\b[A-Za-z0-9._%+-]+(@|\[at\])[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b" ' \
    | uniq

That 2nd to last line matching the email addresses comes from Shell Hacks btw.

For ease of copying here it is as a single line:

curl -s "https://www.google.co.uk/search?q=web+designers&num=100" --user-agent "Chrome" | grep -oE '<a href="\/url\?q=(https?:\/\/.*?\/)' | awk -F'=|&' '{print $3}' | xargs -L 1 bash -c 'curl -s $0 --user-agent "Chrome" | grep -oE "\b[A-Za-z0-9._%+-]+(@|\[at\])[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b" ' | uniq  

As I said this isn't perfect by far, but it shows how quick you can knock up a script to do this type of thing.
At the time this was built this gave me 54 email addresses.

Many crawlers out are often more detailed in the way they request sites, crawl their pages and the way they search for email addresses. The above script may not work in a month or so. But that's fine as I wrote it to prove it works now.

"Ok, I get it, how do i fix this?"

If you want to help save your clients email spam boxes a bit then you're going to want to make the job a little harder for these robots.

Email obfuscation is a technique of encoding the email so it's not clearly shown in the source, but instead it's shown as html entities which the browser decodes or it's added through the use of javascript on to the page.

Some systems may come with simple ways to obscure email addresses.

Working in Wordpress?
You can use <?php echo antispambot('email@address.com'); ?>
Ref: https://codex.wordpress.org/Function_Reference/antispambot

Working in REC?
You can use {{ "email@address.com" | safe_email }}

Other systems often have similar techniques or plugins to help.

In fact some CDN services such as Cloudflare offer this as a setting enabled by default.

But if you're looking for a manual way to do this, there's plenty tools out there to help.
Here's a few that seem good:

• Online Email Obfuscator - Encodes an email to html entities
• Email Obfuscator - Encodes the email with javascript

Here's a straight forward process cycle you can follow that's worked for me.

The flow here starts with the idea and ends only when the client has signed off on the project. Everything in between is a loop of design & development shortly followed by testing & feedback from the client. The more you work in iterations this way, the better you'll get at working out good logical places to break each sprint. You can even plan them in advance.
You'll want to strike a balance between keeping the client updated and getting their feedback, but avoiding showing the client much broken / unfinished code.
Generally the faster you get feedback though, the easier the process will be later on.

Idea stage

• Before starting changes, engage with the client and review the brief of exactly what is needed. This is important to make sure you know what they are looking for. Sketches and simple mockups are very useful here to assure the client and yourself that you are both on the same page.
• Is the site fully responsive? Or does it have a mobile only view? Make sure consideration to this is given in any mockups and estimates for the work.

First iteration

Depending on the changes, the first iteration may be designing a mockup. Following the above image you would design the mockup and then contact the client for feedback. This could then go through several iterations before moving into development.

Following iterations

Each following iteration involves a sprint of work followed shortly by a review by the client. These are not formal reviews, more to keep the client informed that work is happening. It's also useful as clients often change their minds or can only work out what they truly want when they see it. This way you'll find out quickly if you're going the wrong way.

I wont intrude much into your design / development process here, I have another post that does this already, but make sure you're regularly involving the client for feedback.

Tips while developing

• Try not to copy content directly from legacy templates into responsive, but instead apply a fresh design over the responsive-site.
  E.g. if this is a responsive redesign it's tempting to copy say a product page template file from legacy, but this likely wont work. Instead use the existing design as a mockup, you can reuse imagery but coding new css and additional html structure will be less work than you'd think.
• Keep track of new features you've added, you'll want this for testing later, and for your support documentation.

Testing

• Browser test main site + special new features that the client may have requested!
• Google Analytics > Check browsers bringing in most visitors & enquiries or orders. Check out my other post on Modern web design.

Things to look out for especially while testing:

• Check your site's performance and mobile friendliness with Google's new tool.
• Do the changes affect ecommerce? E.g. a responsive redesign? or changes to products etc. You'll need to test the full cart process: finding a product on the site, add to cart, registration, checkout page, payment processor (no need to pay, but at least get it into paypal or wherever to check the order values) and thanks page, this will help you spot anything weird or broken. Best to do so with the browser console
• Any specific custom functionality already on the site? Such as a custom app. Make sure this is still working, or brought through into the new design.

Getting useful feedback

Try to make sure the client actually looks at the design of all changed pages. Sometimes they can just load the homepage up and that's all, later after release they then may complain that other things are not right. It's also easy for them to miss stuff too :).
Set expectations during early iterations about exactly what functionality is loaded up and therefore for review.
Get their feedback, make any changes, re-browser test the changes, etc. repeat! You can send them a link to a dev site if that's where you're working, or a preview link if working on the live site but in a different template folder.

Release

• Get written proof of client sign off on entire site before making it live.
• Finally you're ready to go live, but wait it's Friday, DONT! DON’T DO IT! NOPE NOPE NOPE.

Related articles

If you're interested in a more in-depth look at workflow and processes, I recommend Redesign the Web - The Smashing Book #3, chapter 10 is on workflow redesigned and really worth a read.

• Modern web design
• CSS structure & anti patterns

Browser support is browsers you're willing to support.

While browser testing is the act of testing and maintaining support.

Browser testing need not involve testing the full browser support list. In fact I find a graded view browser support makes this a bit clearer.
Testing every combination would take far too long and the client likely wont be paying for that extra time.

But why is this important?

When a client calls you up and says:

"There's a bug on OSX Firefox 23, why wasn't this picked up during browser testing?!"

You'll need to let them know the difference to explain clearly to the client why this was likely untested but assumed working (which is perfectly acceptable).

Eloquently put back to the client:

"It is not practical to test every combination of Browser, version and OS as there are so many. Instead we follow standard industry practice of testing the latest range of browsers, plus typically those which make up the majority of your traffic and sales. "

Depending on the browser support level, It's an a A or B grade browser, this would generally followed by:

"We'll take a look into this right away for you."

However in the case of a C grade browser, you would need to work out if this is a style tweak or core functionality.

"Unfortunately this is an older browser where fixing it can lead to complications. The cost of working on these older browsers is often not worth the return. If you'd still like us to work on it we can but we will need to quote for the time involved."

You could also then offer a service to the client of checking and testing the current highest converting traffic browsers. This could even be an ongoing / regular process you could offer.

Graded support

Inspired by Yahoo, we use A, B and C grades for our browser support, here's an example of this:

"A" grade support
These browsers should be actively tested on, along side browsers that bring in higher amounts of traffic and sales on the site:

• Google Chrome Desktop ~ latest
• Google Chrome Mobile (Android) ~ latest
• Firefox Desktop ~ latest
• EDGE Desktop ~ latest
• IE 11 Desktop
• IE Mobile 11 (Windows Phone)
• Safari Desktop (Mac OSX) ~ Latest
• Safari Mobile (IOS / iPhone / iPad) ~ Latest

"B" grade support
Though not actively tested on, these browsers should work fine, and bugs can be fixed when reported:

• Google Chrome ~ previous recent versions
• Firefox ~ previous recent versions
• IE 10
• Opera ~ any modern version
• Android browser version 4+
• Mobile versions of the above browsers in recent versions, such as on IOS, Android and Windows Phone

"C" grade support
Core functional support only. These browsers may not offer all the same effects and may visually look different, however any issues that cause functional issues will be fixed, such as an issue that hides or makes it impossible to click a call to action button.

• IE 8 & 9
• Older browser versions than mentioned.

Related posts

• Modern browser testing
• Reading list for modern web design
• CSS structure & anti patterns

How to structure your css.

This is not to say this is the perfect way to work. But it's the way I've been working for years and has really helped me. Inspired by others and by the book SMACSS.

Thinking in modules.

Modular design for me means to separate logical pieces of code for maintainability and reuse.

If everything you do is in one big file, no comments or anything separating parts, all code is very specific and cannot be easily re-used, then it'll be difficult to maintain.

Working in modules you'll find you work faster and more precisely: you'll become a ninja at making quick changes for the client and the client will love you, or at least you'll be happier with your own code.

Example time:

Here's some CSS maybe you've written before. Some text node colors, some buttons have a fancy style (I'll call that fancy-button for later), some text content areas with minor changes between them and a couple minor tweaks on a larger screen.

This will be a long code example but feel free to comment if you have any questions about it/

Original code / what not to do:

# File: site.css

h1 { color: #444444; }  
h2 { color: #444444; }  
h3 { color: #444444; }  
p { color: #000000; }

.header-search .button {
    background: orange;
    color: #FFF;
    padding: 1em;
}
.sidebar-filter #submit-button {
    background: orange;
    color: #FFF;
font-size: 20px;  
    padding: 1em;
}
#contact-form-button {
    padding: 1em;
}
.home-page-content {
  padding: 1em;
  *padding: 15px;
  border-top: 5px solid red;
}
.home-page-content h1 {
   color: red;
}
.about-page-content {
  padding: 1em;
  *padding: 15px;
 border-top: 5px solid blue;
}
.about-page-content h1{
color: blue;  
}

@media screen and (min-width: 35.5em) {
  h1, h2, h3 {
    border-bottom: 1px solid #CCC;
  }
  .home-page-content {
    margin: 0 1em;
  }
  .about-page-content {
    margin: 0 1em;
  }
}

To me, you can work with it, but it's not ideal, and as that grows it will get unmanageable. Lets separate it out to more modular files: (The following files would be included/imported into your site.css file)
I'll comment above each part with the file name, and then under it will be notes on what changed and why its better.

# File: base.css

/* ===== Base styles for site ===== */

/* --- main font colors --- */
h1,  
h2,  
h3 {  
    color: #444;
}
p {  
    color: #000;
}

/* --- default button style --- */
button,  
input[type="button"],  
input[type="submit"],  
.button {
    padding: 1em;
}

/* first breakpoint */
@media screen and (min-width: 35.5em) {
    h1,
    h2,
    h3 {
        /* add a clean border under headings */
        border-bottom: 1px solid #CCC;
    }
}

The above shows base styles for making the page, e.g. fonts, button styles etc..
Separating out the base styles like this helps you quickly find default style applied to all elements. It should be fairly simple, anything more complex should be it's own module or layout file.

# File: modules/fancy-button.css

/* ===== fancier designed buttons ===== */

.fancy-button {
    background: orange;
    color: #FFF;
}

/* --- fancy button mods --- */

/* larger text version (could be abstracted further) */
.fancy-button-large {
    font-size: 160%;
}

This module for the fancy-buttons assumes you have access to change the HTML, if that's not the case you could make the same module file, but instead of .fancy-button and .fancy-button-large you can comma separate the selectors like so:

/* ===== fancier designed buttons ===== */

.header-search .button,
#submit-button {
    background: orange;
    color: #FFF;
}

/* --- fancy button mods --- */

/* larger text version (could be abstracted further) */
#contact-form-button {
    font-size: 160%;
}

This keeps it modular in it's design, it's only the name of the selectors used that isn't as organised so that's still awesome.

Also notice .sidebar-filter #submit-button has been changed to #submit-button as an ID should be unique and the class prefix is therefore redundant.

# File: modules/page-content.css

/* ===== Page content areas styling ===== */

.page-content {
    border-top: 5px solid;
    padding: 1em;
    *padding: 15px; /* slight IE hack needed to account for a margin bug */
}

@media screen and (min-width: 35.5em) {
    .page-content {
        /* space out the content a bit when available */
        margin: 1em;
    }
}

This offers a generic module for page content, which could quickly be applied to all pages without need for copy and paste. As the design grows, this would be much more important.

# File: pages.css

/* ===== Specific page mods ===== */

/* --- home page (red theme) --- */

.home-page-content {
    border-top-color: red;
}
.home-page-content h1 {
    color: red;
}

/* --- about page (blue theme) --- */

.about-page-content {
    border-top-color: blue;
}
.about-page-content h1{
    color: blue;
}

This layout file for specific pages offers per page differences, which are now very minor and get down to exactly what is different, making maintaining and debugging much easier.

Once you've written your code like this, go back over and review it. Spending a little time re-reading, improving and re-factoring your own code is worth it. You'll learn more about the way you write code, patterns you could reuse.
Using dev tools, you can look over some of your code too, specifically you can inspect the elements you've been working on and view the style tab. Here if you see that code is being overridden a lot of the time with large amounts crossed out then you could probably re-write the code, or re-think the way that element works and the css modules you have selectors to it.

Check out these resources on truly making your css skills awesome!

• https://smacss.com/book/
• http://maintainablecss.com/

Also I've previously wrote about a reading list for modern web design.

Some best practices to take away.

• Think in modules.
• Take pride in your code, format it well.
• Understand what your code does and why and avoid magic.
• Use comments and files to organise code and additional comments to explain why some things are needed.
• Avoid specific browser hacks.

My closing comment is: invest in your knowledge now, your future self will thank you.

If you have any questions? Or found a bug ;), please leave me a comment and I'll try to reply as quick as I can.

"CSS is quick to learn, but takes years to master".
- Not sure where I first read this but it's still true today.

It's difficult to give years of experience as training. People expect designers to know things after a day of training that you'd normally learn with months or years of experience. Some patterns I'll talk about in this post only reveal themselves as bad decisions later on. The best I can do is show you mistakes I've made, and other designers have made. Hopefully you can learn from where we went wrong ;).

Anti-patterns.

Anti-patterns explained: What not to do and why.
Found something controversial? Leave me a comment and we can discuss it further :).

1. Avoid separating styles for the same things.

A case of this I've seen before is separating into different device groups, e.g. mobile.css, tablet.css, desktop.css.
Similar used to be done on sites with a ie7.css file etc.

On the face of it, it sounds like a good idea. Everything is separated out, but it's separated in the wrong way and ultimately it's a naive approach. It often encourages duplication because the blocks of style are separated. This makes it difficult to track down specific styles for an element as they then span multiple files, which often ends in code being copied for each file as it's forgotten it's already set and inherited.

Instead my advice is to build specific module css files, we'll come back to how you do this later in the post.

2. Don't copy paste chunks of code.

This one seems obvious when thinking about most coding languages, but maybe not so with your css.
While working on your css, think about how some styles can be joined together. Remember you can join css selectors with commas so code such as:

.banner p {
  margin: 0 0.5em;
  color: #222;
}
.banner h3 {
  margin: 0 0.5em;
  color: #444;
}

Can become this, which is much easier to maintain and keep consistent:

/* ===== Banner module ===== */
.banner h3,
.banner p {
  margin: 0 0.5em;
}
.banner p {
  color: #222;
}
.banner h3 {
  color: #444;
}

Yes the above code is longer but maintainability is what we are aiming for.

3. Avoid naming classes just by their current properties

Such as .red, because what is red? Will it always be red, what if we change to green... Do we go round everywhere changing the class name to green, or do we change the property and will red now mean green.
Ok this one seems obvious especially with my example, but often when designing more modular css you can get carried away and go too abstract to the point of classes for everything like .red, .font-serif, .text-align-right which leads to even worse code.

Instead, try to think of what the element is, such as a block on the sidebar for latest news. you could have a module called .latest-news, but then you could go further and make that a generic .sidebar-block which can be reused for all your sidebar blocks. On top of this you could then still have .latest-news or .sidebar-block-latest-news for specific extra changes on top of the default .sidebar-block, but consider how this could be shared with other blocks on the page too.

4. Don't just slap !important on it ;)

I find !important is very rarely needed, but too often designers try a selector, find it doesn't work and is somewhere overridden. So they give up and slap an !important on it.
Learn about how selectors and inheritance works!

The topic of CSS specificity deserves its own post, luckily there's several out there that do great jobs. Specificity Wars is a fun introduction to it, along with articles on CSS-Tricks, Smashing Magazine and the Mozilla Developer Network

Tools such as Specificity Calculator are also helpful for you to work out why a selector is more specific.

If you don't bother to learn about it, you'll be forever doomed to fight your forest fire of !importants later.

5. Read the source code!

While you're working in systems or you have build scripts that generate a main/master css file from all your other files, don't be afraid to jump in and take a look to work out why an issue is happening or to check your code is being built the way you expect.
Systems sometimes also have to place some css in page, maybe because of their current module architectures, whatever the reason, if that's the system you work within, you'd better be confident you can find where some css comes from. (Luckily dev tools will tell you if css is from a file or on the page). CSS like this deserves care and attention to override. The source code wont lie to you.

6. Dev tools is your best friend, know it inside out!

Better than reading the source code (though that's still important) is using dev tools.

You need to learn dev tools for the browser you're working on. No two ways about it, go learn them now, at least the inspector :).
Here's a link for Chrome and Firefox.

The inspector will save you minutes, hours, days, weeks and more in trial and error.

7. Avoid fixing height & widths when you can.

This often happens when you have a mockup in photoshop and then you try to match the exact dimensions, which is great, except that this likely wont work as the screen size decreases.
Try to make your modules fluid, then they can fit into a grid or take the widths of the container. Patterns like this are core to responsive design.

8. Designing for desktop down or mobile up?

Instead try to think of mobile and up where you can. Often this will lead to simpler css breakpoints and less cruft around content. With this you can think about what's really needed in the design, without too much extra that on mobile wouldn't make sense.
Read more on Mobile First here, or check out Luke Wroblewski's Mobile First book

9. Clearfix the containers of your floats.

The clearfix class is somewhat magical, but really it's very simple. There's a few implimentations of it, but generally the practice involves adding a hidden pseudo element at the bottom of the content that clears the floats.
Sometimes you'll find this called ".clearfix", or ".cf".
Read more about one great example of this here

10. Avoid magic.

Maybe this seems weird when I just said clearfix is magic. But clearfix is simple when you understand how it works. Try to avoid code that seems to magically make things better if you don't understand why. Otherwise, how can you trust it will always work? How do you customize around it without breaking it?
Clearfix is a great example of this as if you did not understand how it works, you may try and add a pseudo element after it in your own css and find the clearfix no longer works.

11. Use the appropriate method for layout.

Often grids or inside blocks instead of floats for layout.
E.g. if you have 3 columns of evenly sized text next to each other, a grid is perfect. If you have a navigation list or boxes next to each other that are sized by their content, normal grids would be a terrible solution. Inline blocks are best for that as they are sized based on the content. If you have a title with a link to the right, float the link to the side, grids again are not really the best for that. There's no one way of doing things right, don't just follow one specific method, think about how it looks and what would really make the most sense. It may take a little longer to stop and think about each part. But if you do it will save you so many headaches later.

12. Don't style every thing as unique.

Try to reuse modules, again this is not to copy and paste, instead create a generic look for basic elements within content, and then create re-usable classes / modules for applying different styles.

13. Opt for relative measurements over fixed when you can.

Simple one, relative measurements such as em, %, rem etc. are more flexible and will often work better with your responsive design than px.
Not that you should cast aside px as a dirty relic, instead, consider the best measurement for the use case. Often in responsive design this will be relative measurements though.

14. Remember not all interactions require jQuery.

:hover, :active, :focus and more. Learn them, wield them like the awesome tools they are.

You probably already use these and know them well. But if you're working on something in javascript, it's easy to forget and use jquery or similar to do it instead.

15. Combine properties

Properties such as font and background can be combined. It's worth using the combined versions for simplicity such as:

background-color: rebeccapurple;  
background-image: url(/images/logo.png);  
background-repeat: no-repeat;  
background-position: top left;  

Could be:

background: rebeccapurple url(/images/logo.png) no-repeat top left;  

16. Avoid unnecessarily long selectors

Sure, referencing body #content .sidebar a works, but would .sidebar a work just as well?

17. Always test your ideas.

Developer tools allow us to test our ideas live, why wait to compile or ftp a file to a server to test your idea for a fix. Change it live in the developer tools and you'll have instant feedback.

18. Browser test too!

With complex modules, check ideas for them as you're going in browsers you think may be problematic, this will make things a lot easier when you return to fully browser check it later.

I've written more about browser testing here.

You can also use Can I Use... to find out browser support for new CSS properties etc. to find which browsers are likely problematic to start with.

19. Avoid specific browser hacks.

Try to find the cause of the problem, rather than a quick fix that may lead to further problems. You may find it's a problem in your CSS and you can work around a problem easier than just hacking it.
If you have to use a hack, explain why in a comment, make sure that in a month when you return to this project you'll know why you added it in.

20. Format your CSS in a clear and uniform way.

This one is a somewhat personal preference, but I try to always write CSS in the same way. I use 4 spaces for indentation (some people use tabs), I separate each selector onto a new line as I believe selectors are kind of the most important part of the css definition, and each property onto a new line.

You can see more of my style choices for CSS in the following post.

Can you expand this list past 20? Leave a comment with your own anti patterns or advice.

Enough with what not to do...

Continue to Part 2 for how to structure your CSS and more tips.

If you disagree with this list or do you have your own suggestions? Leave a comment below and I'll try to reply quickly.

These books are fairly up to date but the methods used are solid and still valid into tomorrow.
By no means am I saying "read these and you're ready", or a definitive list of books I've read or think you should read. But if you're looking for books to tune your skills, this list may help.

I'd also encourage you to leave comments below to share books on web design you've enjoyed and have helped you too.

Books

In case you've not stumbled onto this gem before, A List Apart is a great source of useful information. Their series of short books on A Book Apart offer great core skills such as:

HTML5 for web designers by Jeremy Keith.

Looking to get up to speed on HTML5? A core skill of modern web design is being able to use these new HTML elements with purpose.

CSS3 for web designers by Dan Cederholm.

Also a core tool on your belt is CSS3. Techniques such as rounded corners (with border-radius) and background gradients and more are all common place in modern design. These are made simpler with this book.

Responsive web design by Ethan Marcotte.

A brilliant intro to responsive web design, very useful techniques from the guy that coined the term "responsive web design"!

The above are just 3 of their books, it's worth checking out more. Hopefully this is a nice taste of books they offer and should help you learn the core skills needed to get started with modern web design.

On to other ranges of books, the following focus more on techniques, patterns, usability and inspiration.

Scalable and Modular Architecture for CSS (SMACSS) by Jonathan Snook.

Another short book but front to back a great read full of useful info on writing and structuring css.
The patterns he talks about are simple and easy to follow, but make all the difference in creating maintainable css designs.
I can't recommend this book enough.

Any from the "Smashing Book" series.

Full of the latest modern techniques, inspiring articles and more.
Personally read books 1 & 3 but I'd bet the 2nd is worth wile too.
The Smashing Magazine website has been a constant source of useful info and inspiration for years.

Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug.

If being able to build a site is the first step, then building it right is the second. This book goes over common web usability and is definitely worth the read.

Ready to dive into Javascript?

Eloquent JavaScript: A Modern Introduction to Programming by Marijn Haverbeke.

This book came out around 2011 but I wish it had been there back in 2008 when I first started Javascript. It's useful for getting started with Javascript, or fine tuning your skills and filling in any blanks.

JavaScript: The Good Parts by Douglas Crockford.

Douglas Crockford gives a great run through of the language and the syntax to give you a solid understanding of programming with it.

Looking for something a bit deeper? Something for improving your developer skills?

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas.

If you're interested in levelling up your skills then this book may be for you. It covers patterns, methodology, solid ideas and tools to take your code to the next level. It's also surprising easy to follow as it's often ultimately about common sense.

Newsletters

I like a good newsletter or 10 for keeping up to date on the modern web. They're one way that's really helped me stay up to date especially over the past year. Maybe they will work for you too.

Sitepoint's Versioning newsletter is worth subscribing to if you're interested in a daily digest of latest web news.
Though this can be too frequent, Web Design Weekly, or Responsive Design Weekly are 2 great weekly newsletters also.
There are many others like this such as HTML5 Weekly, CSS Weekly, Javascript Weekly and eWebDesign newsletter.
My advice is to pick one and see if you like it. If not you can always un-subscribe :).

If you're working on an REC, here's some more links that may be of use for keeping up to date: http://design.reallyeasycart.co.uk/up-to-date.html

Please leave comments with books or posts online you'd recommend :), I'd love to hear about books that you've read and have helped you, along with inspiration for what I should read next.

Contents

1. Tips while coding
2. Selecting browsers to test
3. Why BrowserStack
4. Testing like a pro

Tips while coding to make your browser testing easier

1. Don't focus too much on making your designs pixel perfect in every browser.

   "While some designers strive for cross-browser pixel perfection, proponents of fluid design do not think that layouts have to look identical across all platforms and screen resolutions."
   - The Smashing Book (Chapter on the Art & Science of CSS Layouts)

   Often clients (or our own OCD's) will want a design to be pixel perfect across multiple browsers and sizes, but there's very little need for this. I'm not saying make them drastically different in each browser, but if they have minor differences then this is good enough for me. The important thing is the design is able to adapt to the available screen size, and look good enough in browsers where support for some features isn't easily available. E.g. rounded corners with border-radius, these days it's pretty much all browsers, but if you go back to IE8 it doesn't support border-radius. Though if you look at your design, does the fact it doesn't have rounded corners cause any problems? no? great, leave it, no fancy polyfills etc needed. Which nicely brings me to my next point.

2. Don't fear vendor prefixes, but also don't fret about them either.
   That sounds confusing, I probably could word that better.
   What I mean is, feel free to use vendor prefixes in your code. But make your own decisions of when to and not to use them. E.g. flexbox is a great case of where it's needed, especially because of IE10's alt syntax. But css gradients, if you set a fallback background-color then this will likely be fine if you don't bother adding the vendor prefixed versions too as they will use the fallback.
   There are many sites out there that offer automatically adding prefixes to your code. But simpler than this, you can get editor plugins (for Sublime, Atom, etc.) which can run right in your editor with a single command. One rule to remember with these new css properties & vendor prefixes is, always use the real property too, don't just style for webkit prefixes, make sure you style for all and then add prefixes for added support. Also, think about browsers that don't even have prefixes. Make sure your design degrades gracefully without them, or better yet, build without them where you can and add them on top after, so you know the base is already nice and this progressively enhances the design in newer browsers.

3. Avoid browser specific hacks.
   Ok yes, very unlikely if you're supporting IE7 or 8 maybe. But 9+ and most other modern browsers, do you really need that hack? In the case that you super need a hack, browserhacks.com is a great resource for it. But is it needed?

4. Avoid adding lines of code you don't understand.

   Sure use libraries and snippets, in fact I encourage it, but try to look and learn how they work. Especially if it's a few lines in your own css. Sometimes when you copy other peoples code you can be left with properties that don't appear to make sense. Best case is if they are not explained somewhere, try taking them out, does it break, if so you'll learn why they were added, and if not, maybe you can remove them to simplify the code. You can always add them back in later if needed. But try to avoid seeing some code as magic. Magic hides reality, and often I've found magic can lead to bugs.

5. Resize your browser often while developing.
   This is one of the fastest ways to quickly catch problems fast, and to prove your designs adapt to the screen size available.

6. Learn to master your browsers dev tools
   Each of the major browsers have developer tools that help you build sites. Its really worth investing time in learning these tools. Most of them offer some sort of emulation for browser modes, screen sizes, user agents etc. So this is useful for browser testing. But the tools are also useful during testing because you can use them to inspect elements style to see exactly why something isn't working. Rather than the old methods of try this property, refresh browser maybe it'll work. Instead you can try your ideas live!

   Spend some time familiarising yourself with the top browser tools: Chrome, Firefox, Opera, Safari, IE, Edge.

   Here's a free course on the chrome dev tools, really worth a watch.

Selecting browsers to test

Always test the latest browsers, versions & platforms.
Chrome latest, Firefox Latest, IE11, Edge Latest. Android Chrome latest, IOS Safari latest etc.
This is the quickest way to be extra safe with your design.

Working with an existing site

If your existing site has analytics, this is the perfect place to start to make sure you cover it's most used devices, browsers and versions.
For example, just because you've tested on the latest IOS safari version, doesn't mean that's the version that's currently most in use for this site.
It's really worth checking the browsers that bring the most visitors and importantly the most conversions.

Login to Analytics > Audience > Technology > Browser & OS.
Then you can also click on a specific browser to then find a tab to see specific versions of that browser.

Be sure to set the date range for last month, and then also compare to last 6 months.

You can check out device/browser sizes if you click the Screen resolution tab at the top, though my personal recommendation is to make your design adapt to all screen widths rights down to 320px (or 240px if you can but not always so easy).

If it's an ecommerce store & revenue is stored too then you can see which devices, browsers and versions generate revenues. This is important, as if a specific older browser is bringing in thousands, maybe a couple big customers use it, it may not even be a popular browser but if it brings in the bucks, you'd better be supporting it ;).

Find out more details on using Google analytics to find browser support here.

Browser testing with BrowserStack

Ok, I cannot stress the importance of this tool: BrowserStack

This may sound like an advert for BrowserStack, I just really love their tool.

Here's my 5 favourite features it has!

1. Test on all the major browsers & versions,

2. On all the major platform versions of Windows, OS X, Android, IOS & Windows Phone. - It's not just about the browsers, its also about the different versions of them, and the different platforms they are on.
   When a client calls up saying they have a problem on IE 10 on Windows 8, you can fire up BrowserStack and test the same as them.
   Speaking of which, tools like Findmebyip.com offer urls you can share with your clients to find out what browser they are currently using as often people don't know.

3. These are not emulators, real browsers on real platforms! I've had designers tell me before they don't trust services like this because it's not the real device, which i understand, but with BrowserStack you really have access to real instances of windows and OS X with the real browsers installed. Also for mobile they have "Physical Devices" which are real devices in a device farm BrowserStack have so you're really on the device testing! They also offer emulators for some mobile devices they don't have, but the physical devices cover most cases.

4. Their mobile features are top notch. Access to dev tools on mobile devices is more important than I can express! This one feature really is worth the subscription on it's own.

5. Zero setup & it boots up super fast! Starting up a test laptop or VM can take longer and on a good connection BrowserStack feels fairly smooth!

Bonus feature: Built in issue tracker, I haven't used this feature much but on a project where you're testing but not the developer, you can use this to keep screenshots as a list of issues for the designer/developer to fix.

Aside notes on testing apps

I'll mention here BrowserStack is not the only tool out there for this, It's the one I use most and personally I believe it's the best tool for the job. It's worth knowing about other similar tools such as: Browsershots, turbo.net/browsers and Browserling

It's no replacement if you already have the device in front of you, but you wont have all the different versions in front of you. You may have a couple iphones in the office, maybe even different models. But are they on different IOS versions and therefore different mobile safari versions? Don't forget about people who haven't upgraded their phones yet, and no, saying "they should just upgrade" is not an excuse! (Something a friend once said to me with his design after I pointed out an IOS 5 issue, sighs).

Also worth noting, if browserstack is not available to you, or it's too slow, you can use VMs for windows / IE / Edge debugging, in fact Microsoft provides these free.

For mobile device debugging, you can use dev tools with chrome's remote debugging feature. Follow this tutorial on how to set this up.

Testing like a pro

These are some brief tips to testing, but all this boils down to using the site like a real user.

1. Resize in and out on every page.
2. Scroll up and down while resizing, don't just load it on small screen and assume because the top of the page is ok that the rest will be too.
3. Click every link, to the point of trying to break the site.
4. Following on from the previous tip, try to break the site! Don't just test the things you already know work, try to think outside the box, your users certainly will.
5. Pay special extra attention to custom interactions you've added to the site. Just because it looks nice, doesn't always mean it works.
6. When you do find bugs, use the browser dev tools like mentioned above, especially the console if it's an interaction / javascript issue.
7. After testing, accept that you can't test everything perfectly, over time your testing skills will be better, but it's important you’re aware reports of bugs will come in. You need to be ready for those reports, ready to find out which browser has the issue if possible like we talked about above, and try to reproduce it in the same browser version.

Additional testing for bonus points

1. Test performance with Google Page Speed.
2. Test mobile friendliness using Google’s tool.
3. Check the SEO of pages, such as title tag, meta tags, single <h1> tag, alt tags on images etc. Moz offer some great information on this.

I hope this has been useful, please leave a comment below with any of your own tips on browser testing to help improve this resource for others.

(UPDATE: Newer post (2019) for vscode & live reload now available too)

In this tutorial we'll quickly get setup with Atom, it's is a newer editor from the guys at Github. Completely open source, free and built in javascript which makes it pretty interesting (to me at least).

Steps to get started for REC site development:

1. Visit Atom.io, download and install

2. Now we have the editor installed, lets start installing some packages to begin development.

   We need to head to the settings view, you can open this by navigating to Edit > Preferences (Linux), Atom > Preferences (OS X), or File > Preferences (Windows). It's worth exploring some of the available settings, keybindings/shortcuts and other areas.

   To install the package we want click on the "+ Install" tab on the left.

   The first package we'll install if for Twig syntax highlighting. Search for "php-twig" and hit enter.

   It's also worth setting up your theme as you'll spend a long time stairing at the screen, you'll want it to be nice :). Click the "Themes" tab on the left. e.g. I've chosen to use "One Dark" for the UI Theme, and "Atom Dark" for the Syntax Theme. You can also view and install other Themes from the "+ Install" tab, by clicking the Themes toggle next to the search input.

3. Back to installing packages, lets also install an FTP package to work with the REC files.
   I've chosen to use remote-sync for this demo, but there are several other ftp packages that may work well for you too.

4. Create a new empty folder for this project
   (However you normally create folder, e.g. via a file manager program on your computer, or via the terminal using mkdir myproject)

5. Add project folder to Atom, "File" > "Add Project Folder..." and select the folder

6. Right click on the folder on the left, > "Remote Sync" > "Configure"

   • Toggle FTP at the top (instead of SCP/SFTP)
   • Set Hostname as the site's domain name or IP if not live on domain
   • Port as 21
   • Target directory as /
   • Username as the ftp user (in the REC site > Admin > FTP Access > User, for the views@... account)
   • Enter password, also given in the admin ftp access area.
   • Tick to upload on save and to delete on local delete (if you'd like these settings)
     
     

7. Right click again on the folder on the left, > "Remote Sync" > "Download Folder"
   (this may take a few minutes as there are many files)

8. Start editing files, (on save it should upload, if not after the first time you may need to restart Atom)
   Also after restarting Atom, the first save/upload can take a while, for me on a fairly fast internet connection it took almost 1 minute for this initial connection. But then all save/uploads after take less than a second so it's just a little wait at the start of each coding session which isn't so bad. You could also try out one of the other ftp packages available for Atom if this becomes too much of a pain.

9. From here you have your project folder ready to start development, and for a walk through on getting started with REC development please see my previous post on this, but just skip over the Sublime Text setup instructions.

I hope this helps you get started with Atom, leave a comment below for any further help.

There's plenty details on using Atom here, along with this video to help you get started.

And even some tools that offer excellent detection of media queries / breakpoints and then automatically create iframes of each so you can quickly view them, such as: http://breakpointtester.com/ and http://re-view.emmet.io/

The 1st set of tools are great, especially when demoing to clients to help them see different specific devices.
While the 2nd set of tools are also really useful when developing to see the different breakpoints built in and to quickly demo them side by side too.
The minor downside to these 2nd set of breakpoint tools however is they are either browser plugins or bookmarklets, which for some clients will not make a lot of sense.

Instead we need a tool like the 1st ones where you can link to it, but with breakpoint detection like the 2nd set of tools.

And so, here's a new tool you can use:
http://responsive.stapps.io/

Like the other tools, this only works on sites that don't block iframe access, e.g. google blocks it's site from being viewed in an iframe.

Also, unlike some of the other tools, it currently only works on sites with css breakpoints / media queries.

It has 2 display modes, the default one is a slider of each display size, you can use the arrows on the side or keyboard to navigate between them.
Then the other display mode is to show all the sizes next to each other, like the other breakpoint based tools, which is useful for quick comparisons.
You'll need to click "run" again to change the display modes.

It's pretty new so message me about any bugs, but enjoy :).

If you're an REC user, you can find a link to this under the preview url in Admin > Templates > Open/Edit Template

Contents

1. Prerequisites
2. Starting a new project
3. First time notes
4. Diving in
5. Next steps

Prerequisites

We'll need an editor to work with the template files, for the purpose of this demo we'll be using Sublime Text 2, although there are plenty others you may prefer such as Brackets, Atom, Dreamweaver, more info on choosing an editor here.

(UPDATE: I have a new post on using Atom, a free text editor, instead of sublime in case you're interested. You can still use this post for getting started if you skip over the sublime references, down to First time notes)

(UPDATE 2: & a newer post (2019) for vscode & live reload)

With which ever editor you choose you'll need to use FTP to transfer files back and forward between your computer and the site, either setup within the editor or you can use a separate ftp client such as the Filezilla Client.
But here we'll use Sublime Text's excellent SFTP package.

Checklist:
1. Sublime Text 2 installed (http://www.sublimetext.com/2)
2. Sublime Package Control installed (https://packagecontrol.io/installation#st2)
3. Sublime SFTP plugin installed (https://wbond.net/sublime_packages/sftp/installation)

Starting a new project

To start we'll want to create a new folder to work in and open Sublime Text with our site files in ready to begin coding. Follow these steps for Sublime Text.

1. Create a folder for us to work in
2. Open Sublime
3. (In Sublime) "Projects" > "Add Folder to Project..."
4. (In Sublime) right click on folder name in sidebar > "SFTP/FTP" > "Map to Remote..."
5. Setup the sftp-config.json file
   
   • set the type as either "ftps" or "ftp" instead of "sftp" (ftps is a more secure choice)
   • set your host, user and password (found in your REC site > Admin > FTP Account)
   • port is 21
   • set file permissions: "file_permissions": "666", "dir_permissions": "777",
   • choose other useful configuration, e.g.
     • "upload_on_save": true, - To always upload back to the server when you save the file
     • "sync_down_on_open": true, - To always re-download the latest version of a file from the server on open
   • Here's an example config for you to compare to if you'd like.
6. Save the sftp-config.json file
7. Now download the current files, (In Sublime) right click on folder name in sidebar > "SFTP/FTP" > "Download Folder"
8. If everything was configured ok it should start to download all the template folders into your folder. If you have any issues try switching from ftps to ftp, but please leave a comment at the bottom if you have any issues.

First time notes

Things to keep in mind when developing within REC.

File Permissions

• The *-base folders are locked, you won't be able to change or delete these files and folders on the site.
• but you can work within the *-site folders, by default you'll want to work in the "responsive-site" folder
• and you can create new folders for new templates or variations on your design, e.g. a Christmas folder for any minor tweaks to promote extra Christmas sales

HTML files

• These are the core template files
• The 0-base, legacy-base and responsive-base are our officially updated themes. Legacy-base is for sites built before responsive-base came out.
• Your files will sit in your template folder, and by default this is the "responsive-site" folder.
• Files in a child template like responsive-site override the parent template files such as responsive-base.
• E.g. When the system renders the middle section of the page (html/layouts/index.html.twig) it first looks for this file in the live template folder, e.g. responsive-site. If that file is found here it will use it, else it will check it's parent folder, responsive-base, if the files found here it will use it, else it will check in the parent of this parent template, 0-base.
• The syntax used in these files in HTML + Twig.
• Twig is a template language we use to allow you access to the system, e.g. to show variables such as a products name ( e.g. {{ product.name }} ) and price on the products page ( html/store/product_info.html.twig )
• Documentation is available on Twig and there's a playground to test Twig ideas outside of REC.

CSS / JS files

• Store your css in css/site.css.twig inside your template folder.
• Same for your js, store inside js/site.js.twig
• You can however include multiple other files into these files with Twig, we'll talk more about this later :)
• The "responsive-base/css/" folder is full of useful css files, mainly in the "modules/" folder, where all the style of the site is stored.
• Like the html files you can place a file in the same location but in your responsive-site folder and it will override it, but if you do you'll loose updates to this file as you'll be overriding it.
• This works well such as for replacing the nav styling entirely, you'd want to remove the default style and you would not care about the upgrades to it, as you'd be using your own custom version.
• But if you wanted to keep using the same nav and only make a minor change to it would be best to make your changes in a separate file loaded from site.css.twig
• The css/main.css.twig and js/main.js.twig files as seen in the responsive-base folder are the main files used to include all the other files we use to build the template. Don't override these files, as you'd loose new files being included and any other updates to it. Instead use the css/site.css.twig and js/site.js.twig files. These site files are included at the bottom of the main files. You can use them to include other files in the same way but we leave these files blank purposefully for you to use.

Javascript / jQuery

• jQuery comes pre-installed in all REC sites.
• We currently use version 1.11.3, and you can change this by overriding the html/sections/head/jquery.html.twig file like all others.
• However in REC $ does not by default reference to jQuery as we have an older javascript lib also included called Prototype.js. In time we'll remove Prototype.js but when using jQuery you'll need to wrap your code so that you $ is jQuery for you. This can be done with:

(function ($) {

// your code... executed immediately, before dom ready

}(jQuery));

Or

jQuery(function ($) {

// your code... executed on dom ready
// same as using jQuery(document).ready(function ($) { ... });

});

Caching

• Our css/js/images etc. all cache in the browser for 1 month.
• This is great for performance, but during development you'll want to always see your latest code changes.
• You'll either want to always use hard refreshes
• or set your browser to not cache (e.g. in chrome's developer tools, on the network tab you can tick to disable cache, this will force hard refreshes for you automatically when)
• Also once you've finished work via ftp you'll want to bump the version for users browsing the site if it's already live. You can do this in REC site > Admin > Templates > "Bump Cache Buster".

Diving in

Currently I'm working on a redesign of Impkids clothing site.
I have a few tasks to work through with you here including:

1. Enable preview mode, as this is a live site currently running the legacy-site template and I don't want the changes to show till I'm done.
2. Move the slider next to the sidebar above the main content, instead of above the entire middle section as it is by default.
3. Style the outer design of the site in css.

Preview mode

First, lets enable the preview mode. REC site > Admin > Templates > Hover over the responsive-site template folder and click "Preview".
This will open a new tab with the site in for you, and you're ready to start work in this folder in a preview that only you can see.

Moving the slider

Now we'll work on moving that slider.
If we look in responsive-base, the default layout file that loads in the slider is at html/layouts/index.html.twig. So we need to create a file at this same path, and the layouts directory it's in.

In Sublime you can create a new folder by right clicking on the parent folder, in our case responsive-site/html/ and then select "New Folder...". Then the same to create a new file except click "New file...".

In this file we'll copy the contents from the responsive-base version and paste into our new responsive-site file.
With this file copied in we can take the slider block and move it down to under the <main> element.

Lines 12 to 17 should be:

{# slider #}
{% block content_slider %}
    {% if page.show_content_slider %}
        {{ page.content_slider }}
    {% endif %}
{% endblock %}

Which is inside the middle div/section of the page, but we want it to the side of the sidebar so if you cut this chunk out and paste onto what is now line 26, just above the {% if page.show_content %} area.
Save the file and with our FTP sync setup previously it should send this file up to the server.

Styling the layout

The existing Impkids site has a nice outer design where the main column has a white background with a shadow over a light orange background.
We can use css to recreate this in our responsive design.
As mentioned above, we will be putting our CSS into the css/site.css.twig file in responsive-site.

The responsive-site directory comes with this file ready and left blank for you.

/* ----- Main outer theme ----- */
body {  
    /* light orange background */
    background-color: #FDC288;
}
/* the layout container is used for the main 3 sections of the page, the header, middle and footer */
.layout-container {
    /* We want the main content on a white background */
    background: #FFF;
    /* with a semi-transparent shadow to the sides */
    box-shadow: 0 20px 20px rgba(0, 0, 0, 0.3);

    /* Add some margin to reveal the box-shadow too */
    margin: 0 15px;
    /* and some padding so content inside the layout is not too close to the edge */
    padding: 0 15px;
}

This gives us the outer design, but lets also talk about the header design.
Impkids logo image is a little unusual, usually the site's logo is uploaded via Admin > Site Setup, however for Impkids it's not and we don't want to upload it now as to not affect the live site in any way.
Instead we will set the logo on the currently blank header-logo element in the header and size it like so:

/* header logo */
.header-logo {
    background: url("/userfiles/impkids/images/IMPLOGO.png");
    position: absolute;
    width: 185px;
    height: 140px;
    left: 32px;
    top: -3px;
    z-index: 999;
    color: #FDC288;
}

This gives us our header logo image, and next we can move onto the navigation...

We want to move the navigation over to the side of the logo on larger screens and style it like the current site.

I won't go through all the css here but you can see we're moving the nav over (leaving space for our logo), making the nav top of the nav transparent by default and the sub links have a white background.
Then the active link and hover links are large orange bubbles around white text.

The difference here is I only want to change this on larger screens, on the phone and small tablet size we want to use the default nav as it's optimised for touch.

We use media queries to change the display as the screen size increases.
The default screen breakpoints we use are: 35.5em, 48em, 64em, 80em.
A great example of this is in responsive-base/css/modules/pull.css

.pull-left { float: left; }
.pull-right { float: right; }

/* same sizes as defined here: http://purecss.io/grids/#pure-responsive-grids */
@media screen and (min-width: 35.5em) {
    .pull-left-sm { float: left; }
    .pull-right-sm { float: right; }
}
@media screen and (min-width: 48em) {
    .pull-left-md { float: left; }
    .pull-right-md { float: right; }
}
@media screen and (min-width: 64em) {
    .pull-left-lg { float: left; }
    .pull-right-lg { float: right; }
}
@media screen and (min-width: 80em) {
    .pull-left-xl { float: left; }
    .pull-right-xl { float: right; }
}

The above is from that pull.css file, it sets up default classes in css we can use in our html templates to pull elements to the left or right but maybe only at specific screen breakpoints.

It's worth exploring the css/modules/ directory in responsive-base as there are plenty files.

Back to this design though, our end navigation style looks like:

@media screen and (min-width: 48em) {

    /* ----- nav ----- */
    #header .nav {
        left: 240px;
        bottom: 0px;
    }
    /* nav background to transparent*/
    #header .nav ul {
        background-color: transparent;
    }
    #header .nav ul ul {
        background-color: #FFF;
    }
    /* active link */
    #header .nav > ul > li:hover,
    #header .nav > ul > li.is-focused,
    #header .nav > ul > li.is-current {
        background-color: #F78F1E;
        border-radius: 10px;
    }
    #header .nav > ul > li:hover > a,
    #header .nav > ul > li.is-focused > a,
    #header .nav > ul > li.is-current > a {
        color: #FFF;
    }

}

Now the outer and header styling is pretty close.
There's still plenty for me to work on but I hope this helps you get started with your own designs.

Cleaning up our work

So far our CSS has all been added to our site.css.twig file, but we can actually separate it into multiple files.

e.g. we could take the outer "Main outer theme" part, the body and the .layout-container and put this into a css/outer-layout.css file, the same for the header styles into a css/header.css file.

Then back in the site.css.twig file you'll need to include the newly created files where the css used to be. We can do this with Twig so that we still end up with a single css file being sent to the browser e.g:

{{ source("css/outer-layout.css") }}
{{ source("css/header.css") }}

This part is up to you as it's your project. It's fine to leave all your style at first in the site.css.twig file, especially on a small project. But as this file grows you may want to look into doing this.

At this point we have a working responsive site, it's simple and though for my Impkids redesign I have much left to work on, this has just been a small dive into what's needed. The most important next step is to try out different designs, use your css skills and you have pretty much free reign over the style of the site.
Feel free to contact me about any questions you may have on this or on anything to help improve this post for future readers, thank you.

Next steps

Where can you go from here?

• Read up on Responsive design (css, designing and workflow ideas)
• Browser testing (e.g. using browserstack or emulators or real devices)
• Version control, it's useful to have a history of your changes e.g. After downloading the files in step 6 you could use git to start a history of the files.