The format is like so:

[ ] Checkbox 1
[ ] Checkbox 2
[ ] Checkbox 3

There's a couple ways you could approach this but I've gone with regular expression.

The pattern to match this is: ((\[[ x]].*?(\r\n|\r|\n)){INDEX})\[[ x]](.*)
Where INDEX is the nth we want to match -1. If we want the first, the index would be 0. 2nd would be 1, 3rd would be 2 etc.
E.g. to match the 2nd, the INDEX would be 1: ((\[[ x]].*?(\r\n|\r|\n)){1})\[[ x]](.*)

Then we can use $1[x]$4 as the replacement.

Replacing the 2nd would result in:

[ ] Checkbox 1
[x] Checkbox 2
[ ] Checkbox 3

But let's break this pattern down. The first half of this is in brackets representing the first captured group as $1 for the replace statement. In this we have \[[ x]] which matches square brackets an empty space or x inside, then .*? matches any content after it till the end of the line, followed by (\r\n|\r|\n) which detects the end of the line. This then get's repeated for the INDEX {INDEX} or {1} for matching the 2nd checkbox. The INDEX is 1 less than the value we are looking for as it starts at 0 rather than 1. This ends the first capturing group. We then we look for the checkbox again \[[ x]] as this is the one we will be replacing and grab all the content after it in a last capturing group which in the replace is $4.

Try this out at http://regexr.com/3dqac
Use the original empty checkboxes text above and the regex, then click to replace and enter the replacement script. Then try changing the index between 0, 1 and 2 to see if live replace whichever checkbox.

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

At work we have some application servers on AWS with an ELB in front, which we wanted to migrate it to HTTPS. It needs a wildcard subdomain so Cloudflare my normal go to is out for now. Let's encrypt would work, but I'd need to have a bit more complex setup to have it auto renew from one node and distribute between the nodes or send the cert to the ELB via the API maybe?

Anyway, after searching I stumbled onto some new AWS posts talking about the Certificate Manager. It allows you to request SSL certs for domains, verify them via email and once setup you can add HTTPS listener to your ELB with the generated certificate, so HTTPS traffic comes in, and HTTP traffic back to the instances securely within your VPC.

A very simple setup provided free on top of our existing architecture, supports wildcards and everything we needed.

More details here:
https://aws.amazon.com/blogs/aws/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/

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.

You may ask, why not just run the commands separately, which obviously works, but you need to remember all those commands and the order of which you run them, or write them in a README or similar. Instead, Makefiles offer a simple way to build repeatable commands for a single or series of other commands in a way that you can quickly run when you come to a project. Especially useful when you have new people take over a project, or when you yourself come back to a project a few months or so later.

You use them via the terminal / command line like so:

cd ~/projects/my-project  
make do-something-cool  

Where do-something-cool is the command you want to run in the file.

Many people use Makefiles in different ways, I often don't use many of the more complex features Makefiles have and a number of the tutorials start with a steep learning curve using them.
Instead I'll show you a simple example file from a real project I have.

In this example, I have a project where I need to build / minify some javascript and css for performance. I want to run a linter over some files to be sure the sytnax is a-ok, and then I have written some tests for the code and need to be able to run them quickly after i make changes.

Here's an example of this in a Makefile file.

build:  
    jsmin js/app.js > js/app.min.js
    cssmin < css/app.css > css/app.min.css

test: lint unit-test

lint:  
    find . -name \*.php | xargs -L1 -P4 php -l

unit-test:  
    phpunit .

If you copy this code, make sure you use tabs instead of spaces as Makefiles require them.

Let's break down the above.

1. make build runs 2 commands, jsmin and cssmin. These are npm modules i have installed globally. They minify my js and css code.
2. make test runs 2 other commands but these are other make commands. First it runs lint (which could separately be run as make lint, this checks the syntax of my php files for the project, using find to find all the php files, piped to xargs which then allows me to run php -l for each file. Then it runs unit-test, again this could be run on it's own as make unit-test which runs my phpunit tests. But having a single make test command allows me to run both with ease.

There's plenty more resources out there for learning more about Makefile's, but hopefully this will show how simple and useful they can be.

It's pre installed on Linux & Mac OSX, and on windows you'll need to download something like MinGW to get it installed.

(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.