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.

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.