200 Tips for Build a Website (2019)

website

How to improve a Website; 200 Tips to Build a Website-2019

Building a responsive website is in many instances an opportunity to assess and improve existing processes. When you are retrofitting an existing fixed-width website, the considerations are different than when you start a project from scratch.

 

But you will still want to make sure you improve the way your website is built and maintained as much as possible. Ideally, you began thinking about the build of your responsive website at the same time you started planning and designing it because all the different disciplines can and will impact on each other. 

 

This blog looks at a few strategies you can apply to build, releasing, and maintaining your responsively retrofitted website. These strategies will save your team time and do away with any fear that may come from experimenting with new technologies and processes as part of a responsive state of affairs. Schedules, wireframes, sketches, copy documents, images, illustrations, and mockups are all pointless if they are not turned into reality by markup and code.

 

In this blog for Build a Website-2018 you learn the following:

  • The importance of trying things out in small projects
  • How to consider accessibility in your code
  • How to work with a performance budget

 

  • How to start converting your grid and typographic scale into being responsive
  • How to begin using media queries
  • Useful solutions for dealing with images in a responsive world

 

  • How to consistently test your responsive website across different devices
  • How to start considering improvements to your writing and publishing processes
  • How to measure success after release

 

Experiment on Smaller Projects

mobile

When responsively retrofitting your website, in addition to simply making it responsive, you probably want to take the opportunity to introduce new technologies and ways of coding and building the website that can improve it and benefit your team’s processes. But, many times, making those changes on a project of considerable size can seem like a daunting prospect. If this is your case, consider trying and testing new things on smaller projects.

 

It is less scary to try something new in less conspicuous and less complex projects, rather than jumping straight into the main website. When you try out new ideas and assumptions on smaller projects, it is easier to take a step back if something does not work out as planned. It is easier to revert changes, fix bugs, or try something else entirely. And if something goes wrong, it is also likely to affect a smaller number of people.

 

The things you can test on a smaller project do not necessarily have to be code related. However, it is on the building and coding side of things that have to deal with a bigger website and code base usually makes trying new things more complicated.

 

Here are a few things you can consider testing on smaller projects:

  • Using scripts you have not used before, like Modernizr
  • New image solutions, such as moving to SVG images
  • New responsive typographic scale
  • Modern CSS techniques, such as flexbox
  • New design and interaction patterns, like a new navigation menu pattern
  • Improvements to the build process, such as the addition of minification and concatenation of stylesheets
  • New testing procedures, including automated tests
  • A/B testing

 

There are countless more things you can consider trying on a smaller scale before you commit to them on your larger website. The key idea to keep in mind is that a change in the way you code and build your website does not have to be tested in its final location—the main site—and that smaller projects can serve as a playground for trying cool new techniques.

 

Focus on Accessibility

code

As I have mentioned in previous blogs, making sure your website is accessible should not merely be a step at the end of your project. Accessibility considerations begin with your content, whether it is in the form of words, images, videos, or any other format that communicates a message to someone or allows them to do something.

 

 Accessibility thinking should also be ingrained in the design process: considering alternative ways of displaying the same message, and making sure designs and layouts do not get in the way of people accessing your content or completing a task. But in the same way that mockups and wireframes are pointless without markup and code, great content and accessible design will not suffice if that same markup and code do not respect accessibility considerations. Andrew Hoffman sums up this idea very clearly:

 

Here are some of the key aspects to consider when coding your responsive website accessible:

  • Use clean, semantic markup as much as possible.
  • Use WAI-ARIA landmark roles, if needed, to extend the semantic capabilities of your markup.
  • Provide a skip-navigation link at the top of your website.

 

  • Make sure non-decorative images include alt tags but do not simply repeat text that is already mentioned elsewhere on the page.
  • If you use JavaScript, provide fallbacks in navigation elements, because broken navigation can hamper access to content.
  • Consider how people with touchscreens will use your website.

 

  • Consider how someone with only a mouse or keyboard will navigate your website.
  • Make sure someone using a screen reader can navigate your website.
  • Consider how game console and TV users will navigate your website.

 

  • Add accessibility tests to your build process to test things such as color contrast and the existence of alt tags.

 

This list should be a starting point for you to think about accessibility and to focus on making sure your website is accessible if you do not do so already. This is by no means a comprehensive list, but rather a way for you to see how some small shifts in thinking about how you build your website can have a positive impact on its accessibility.

 

encourage you to explore this topic in more depth, particularly in the areas that you feel least comfortable or knowledgeable about. Sometimes techniques that may sound complicated or cumbersome are not. You will only be able to advocate for and focus on accessibility in your code if you understand the true complexity of implementing such changes and are able to explain it to others. 

 

Focus on Performance

performance

Converting an existing fixed-width website that was originally designed to fit medium to large screens is not just a case of shrinking images and removing floats from your CSS. One of the main secrets to making sure your website provides a good experience on any device, of any screen size, is to make it lighter and faster.

 

The classic idea of the mobile user who is moving from one place to another is task-focused, and is on a slow connection is not accurate in many cases. Most of us can think of moments when we slouched on our sofa, browsing aimlessly on our phone while on a fast broadband connection, just a few feet from our laptop or desktop computer.

 

Conversely, what about that time the usually fast connection on the desktop computer at the office was incredibly sluggish, and every website took ages to load?

 

It is important that you avoid making assumptions about the context in which users will visit your website. You cannot assume that visitors will be accessing your website on only the fastest, low-tariffed Internet connections.

 

responsive website enables people to access from an almost infinite number of devices, anywhere around the world. For this reason, it is key that you aim to build a responsive website that not only is visually responsive, but that also responds quickly to the user—and that respects the fact that they may be paying through the roof for any unwanted or unexpected downloads.

 

The nature of a responsive retrofitting project, where the scope can be incredibly restricted, may mean improvements toward a performant website have to be made in stages. There are a few aspects you should bear in mind as you make strides toward a more performant website, and some things you can do quickly that will bring you closer to a super-fast website.

 

Work with a Performance Budget

Work with a Performance Budget

 

Performance considerations should begin early in the design stages, but the bulk of the work that needs to be done still falls into development. One aspect that should be determined from the get-go is what level of performance is deemed acceptable—this can form the basis of a performance budget.

 

performance budget works just like your household budget, but instead of money, your currency is time or megabytes. You begin with a defined, finite amount, and you distribute the resources with thrift and prudence. Just as you have to cut down on restaurant visits when you really want that new Eames chair for the living room, you may have to cut down on your JavaScript libraries if you really want that large hero image on the website.

 

Setting the initial budget for your website is an exercise where you can and should involve team members with both design and development expertise. Start by looking at your own website and two or three competitor sites with the development tools in your browser open, and measure how long they take to load. Make an informed decision about where you want your website to land.

 

You can also use a purpose-built tool like WebPagetest (www.webpagetest.org), which allows you to test and analyze your website’s performance. The website gives you a plethora of useful information about your website and helps you identify and rectify particular bottlenecks.

 

When the BBC developed its responsive news website half a decade ago, the stated goal was to have a working website in 10 seconds over GPRS (the mobile data standard that has since been superseded by EDGE, 3G, and 4G, but that is still the fastest available option in many places around the globe).

 

By setting a goal like this, you can work out a few baselines: for instance, GPRS averages out around to a download speed of 100 Kbps, meaning you can download 125 KB in 10 seconds. Your goals will likely be different, but the approach is the same. On the basis of this information, you can make decisions about which and how many assets you can allow on each page.

 

Having a benchmark to work with that is easy to understand and communicate also helps in discussions with other team members and stakeholders. You have decided on a maximum page weight and set that as your maximum spending.

 

If for any reason you or someone in another department deems it necessary to add images, banners, scripts, or video to the page, the discussion should always include the performance budget, and stakeholders should be made aware that it is an integral aspect of a successful design.

 

performance

Because this is a retrofit, many design decisions that impact performance have already been made. By setting a goal, however, you can do several things under the hood to improve performance. Optimizing the way your website requests its resources is one of the key ways to speed up the website. This is a science unto itself and deserves its own dedicated book, but the following checklist is a good starting point:

 

  • Size matters. This may sound obvious, but a lighter page will download faster than a bloated one. It goes without saying that this becomes even more evident on a slow connection.

 

  • Minimize requests. Every time the browser has to go fetch a resource, your page gets slower. Fewer requests mean a faster-loading page. One of the easiest improvements you can make is to ensure that you are loading as few stylesheets and JavaScript files as possible.

 

  • Put things in the right order. Keep CSS in the HTML head element, before any linked JavaScript. That way, your browser can begin rendering the page before dealing with anything else.

 

  • Keep it lean. The browser needs to download and parse both your HTML and all of your CSS before it can start rendering your page. Yes, size matters—it is worth repeating.

 

  • Scripts are slow. As the browser parses your page’s HTML, it has to stop when it encounters a script. Then it has to execute the script to check whether the DOM has been altered. If the script is external, it has to fetch the resource, download it, and execute it. This can cause significant delays. If you can, let your page render before fetching and executing your JavaScript asynchronously.

 

These are only a few things you may want to consider improving on your newly retrofitted responsive website that can make it considerably faster. But sometimes speed only needs to be skin deep, as you see in the next section.

 

Understand Perceived Performance

Understand Perceived Performance

Page weight is not everything. A user does not know whether your website has too many HTTP requests or is this or that many megabytes. Their experience is based on what they see. And you do not perceive that something is faster or slower in a vacuum; you can only tell that something is fast if you can compare its speed with something else.

 

When trying to improve your site’s performance, aiming for it to be 20% faster than before is usually a good goal. This value has its root in how human perception works. According to Weber’s Law, “the just-noticeable difference between two stimuli is proportional to the magnitude of the stimuli”; this means there is a point at which humans can perceive that there is a difference between two states, and a smaller difference than that will not be detected.

 

This rule can be applied to anything from discounts to increases or reductions in how many potato chips are in a bag. It can also be applied to software development and user experience. The value of 20% is regarded as the baseline at which someone will perceive any difference in stimuli, so this number can be used to your advantage when assessing and determining performance-improvement goals.

 

Depending on how much earlier work and focus has gone into making your website performant, this performance gain may be achieved just by looking at some easy wins.

 

Here are some things that can make a website feel faster:

  • Having touch/hover states on buttons and links
  • Optimizing time to first byte/time to render
  • Including critical CSS inline

 

  • Loading the most important above-the-fold content first
  • Considering progressive/lazy loading, meaning you only load content that is visible in the viewport
  • Avoiding spinners if you have to reload content, and using an animation instead

 

  • Avoiding repaint, because pages that jump around as they load feel slower
  • Considering loading fallback fonts before fetching web fonts to avoid a flash of invisible text (FOIT)

 

It is important to note that these tips and hints should be used in addition to the under-the-hood performance enhancements that reducing page weight, HTTP requests, and so on will bring.

 

Large Screens Like Lean Sites, Too

mobile

You should make sure your content has plenty of room to shine, and you should provide a comfortable reading experience for your user. There is only so much you can include in a small-screen view of your website, so you will probably be quick to do away with decorative elements and effects.

 

If you do, stop to think about whether they add anything to the large-screen views, too. If your mobile users can live without that parallax effect on the background or that hijacked scrolling effect, are you sure it is necessary at all? We have a tendency to want to decrease page weight on mobile devices, but the benefits of doing so will improve the experience for every user, across all devices.

 

Consider the job your website is there to do. More often than not, a design is successful if you do not notice it. When reading a book, becoming engrossed in the characters and storyline is preferable to paying constant attention to the typography and layout. Similarly, if your website is there to provide content or a service, you should consider your priorities.

 

Simple, unobtrusive, fast, and efficient is often better than complicated, noticeable, or even innovative and remarkable. As luck would have it, most people will love your fast, boring-looking website more than a slow, striking one.

 

Trim Down Your Web Fonts

fonts

Another simple thing you can do to shave some kilobytes off your website is to remove unnecessary character sets and font weights from your web font if you are using one. Check whether you are using variants such as italics and bold—there may be design guidelines in place that restrict their use, and emphasis can be added to the text in other ways.

 

The gains of doing this can be in the hundreds of kilobytes. If you are hosting your web fonts externally and the licensing of your fonts allows it, you can also consider self-hosting your fonts, because doing so cuts out the reliance on an external service. This allows you more fine-grained control of how and when to serve your fonts, and how to implement your caching strategy.

 

A downside to using web fonts is that some browsers (I am looking at you, iOS Safari) display no text at all until the entire page, including the web font assets, has loaded fully. This means you sometimes have to wait up to 30 seconds before seeing any text on the website. There aren’t any simple solutions to this problem, apart from ensuring that your website loads fully very quickly, but there are a few tricks you can use to make the experience better.

 

One of these techniques, introduced by Filament Group, is to serve a fallback font the first time someone visits your website, load the web font asynchronously after the page has rendered, and serve the web font from that point on. Another, far more drastic approach is to remove the web font and rely on the fonts installed on your visitors’ operating systems.

 

In a recent website update for a small side project, replacing a single hosted web font with a system font saved 3.5 seconds in load time and a half-megabyte download. This technique is certainly worth at least considering when page weight is at a premium.

 

 Removing web fonts is not possible for all projects, of course; but when you are reviewing design visuals hot out of Photoshop, remember that looking great is not the only way in which your website will be evaluated by users. You have to provide a good experience as well.

 

Some Handy Tools

tools

Various tools can help you improve your site’s performance. The ones listed here are some of my favorites and are popular among front-end developers because of their reliability. Make sure you take them for a spin.

 

WebPagetest

You have already been introduced to WebPagetest in this blog. It is an open source tool supported by Google that aims to make the Web faster by providing metrics on all things related to page speed. It allows you to test your sites on real browsers across the world so that you can see how your website performs in different areas, which is great if you have a global audience.

Speed Index

The Speed Index is one part of the WebPagetest suite. It measures how quickly your page content visually renders. It can be particularly useful for before-and-after comparisons when doing optimization work because it gives an indicator of the site’s perceived loading speed.

 

To keep up your team’s morale, make a habit of noting the speed index before and after you make any changes that you think will have a performance impact, so you can see concrete, measured improvements as you go through the drudge of improving things behind the scenes.

 

What Does My Website Cost?

What Does My Site Cost

When carrying out a responsive retrofit, you will naturally have mobile use of your website in mind. The What Does My Website Cost? website (https://whatdoesmysitecost.com/), which forms one of the metrics of the WebPagetest, tells you how much mobile network users across the world have to pay for the data required to download and use your website.

 

Discussions about performance often focus on reducing the number of requests and rendering pages as quickly as possible, so page weight often gets pushed into a corner. This tool serves as an important reminder that if your website becomes bloated and overweight, it costs people real money. These tools form only a small subset of those available to analyze and improve performance. You can find more in the appendix.

 

Fluid Grids and Type

Fluid grids, along with media queries and responsive images, are one of the three tenets of a responsive website, according to Ethan Marcotte’s seminal A List Apart article “Responsive Web Design.” When converting a website to being responsive, one of the most important and visible tasks you will perform is making your grid and your typographic scale responsive. These changes do not have to be complicated, but it is important that the code you create is robust and that it provides a solid foundation for your content to live in.

 

Fast Track to a Fluid Grid

Fluid Grids

There is a quick test I like to do on sites that are not yet responsivewhich can quickly provide you with a good idea about how much work you will have to put into making your grid responsive. All you need to do is remove float and width rules from your CSS to see how your website behaves in a linear format.

 

This can be done quickly by using Firebug or another inspector and resizing your browser window, but it is even better if you can create a prototype that can be tested across a selection of real devices and that the team can huddle around and discuss.

 

You may be surprised by how good your website looks in this simplified attire, and by the small number of changes you would have to make to achieve a passable responsive experience. But fiddle with your prototype for long enough, and you will begin to find numerous ways in which you can massively improve the small-screen experience of your users. List these, prioritize them, and make yourself a plan.

 

Improve your Markup

markup

Ideally, your website was built following the principle of separation of concerns, where the HTML gives your content a consistent and logical structure, the CSS describes style and layout, and JavaScript adds behavior and other enhancements. If this is not your case, you should give serious consideration to refactoring your markup to better reflect these ideas before you delve any deeper into your retrofitting work.

 

This is obviously much easier said than done, but remember that when you are working with messy HTML, you will more likely than not end up with messy CSS. Your responsive retrofitting project, although tight in scope, should still provide you with a venue to make some much-needed improvements to the foundations of your website. In his article “Responsive Retrofitting,” Ben Callahan makes this very same point evident: Avoid doing retrofit work when the website doesn’t have a solid foundation of clean, semantic HTML.

 

There are some things to look out for when you are considering improving your markup:

semantic markup

  • Use semantic markups such as headings, paragraphs, lists, and HTML5 sectioning elements to describe your content.
  • Keep your markup consistent by making sure everyone follows the same guidelines.

 

  • Keep divs and other elements that do not describe content structure to a minimum, especially when they are used to describe layout
  • Use the HTML5 doctype if you do not do so already.

 

  • Validate your markup: there may be things you did not catch that a validator will.
  • Consider making the HTML improvements suggested by Google Webmaster Tools for your website.

 

In some cases, it may be possible (or necessary) to leave the existing HTML untouched. In this situation, it is likely that your CSS will have to work harder to be able to target the HTML you need to style.

 

You can also consider using CSS flexbox to reorder content at different breakpoints, independently of the order of the content in the markup, if it is not possible for you to edit the HTML. Although not necessarily recommended for full-scale grid-layout design, flexbox can come in handy to reorder smaller bits of content in your pages.

Let’s imagine you have a row that, on a large screen, shows on its left half a heading and a paragraph of text, and on its right half an image.

  • <section>
  • <h2>Down  the  Rabbit-Hole</h2>
  • <p>Alice was beginning to get very tired of sitting by...</p> <img class='lazy' data-src="image.jpg" alt="A rabbit"> </section>

 

If you simply reflow and stack this content in a smaller screen view, you will have the heading, followed by the paragraph, followed by the image. However, you may think the image should come after the heading on a small screen. Flexbox can solve this:

section {
display: flex;
flex-direction: column;
align-items: flex-start;
}
h2 {
order: 1;
}
p {
order: 3;
}
img {
order: 2;
}

First, you define that the children of the parent container, section, use flex. Second, you define the order (or axis) in which you want to lay out content: in this case, in a column.

 

Third, you define whether the items should take up the entire width of the column or be aligned another way along the axis. In this case, you want to keep the items’ left alignment, so you define flex-start. If you did not add this property, the elements would try to fill the entire width available, and the image might get distorted in the process.

 

Finally, you define a different order than the one in the markup, in which you want your items to be arranged: first the heading (order: 1), second the image (order: 2), and third the paragraph (order: 3).

 

As you can imagine, there is much more to flexbox than this simple example. But now you know that even when you cannot touch the markup, there is the possibility to reorder some elements within it. The global support for flexbox is just over 94%, with Internet Explorer only supporting the property from version 11 onward. So, make sure you consider how non-supporting browsers will render your website.

 

Remove Inline Styles

inline

It is not uncommon for inline CSS to creep its way into your markup. Sometimes things need to be built that do not follow any existing patterns and that are enough of an exception that adding a single style tag is the simplest way to achieve the intended effect. But once you make your website responsive, these inline styles may come back to bite you.

 

Before you move too far into your development, you may want to sweep your website to find any pesky inline styles, including those added via JavaScript, so that you can then make the decision to either leave them or remove them, case by case. Depending on how many styles you have let sneak into your markup over the years, this decision-making process may be a quick task or something more involved; but it is something you do not want to remember at the last minute or after the website has gone live.

 

Some tools online can help you with this task, such as HTML-Cleaner (https://html-cleaner.com). While you do this, you should also search for instances of inline JavaScript and consider refactoring those before they become a problem.

 

CSS

When going through these frameworks’ code, remember that their target audience is in many cases, everyone. This means their markup and CSS are made to be much more malleable than yours probably needs to be. This need for malleability can and does cause bloat and unnecessary classes and markup, so remember that this is not necessarily your case.

 

Another thing you may want to do is to look at well-designed responsive sites that have a solid grid, check how their grids are built, and see how the CSS was written and how the markup works with it.

 

Look at how your competitors have solved the same problems, and think about whether you can come up with a better or cleaner solution that is more adapted to your needs. This is, and always has been, the beauty of the Web: the ability to view source. Use it to your advantage.

 

Abandon Absolute Units

units

Depending on how your stylesheets have been created in the past, you may have to convert the way you created your grid and font sizes from using absolute units of measurement, such as pixels and points, to using relative units, such as em and percentages. When you define a column to be a certain width in pixels, that is the width it will always be, regardless of whether you are looking at the website on a small or large screen.

 

The goal of making your website responsive is that it can adapt to any screen size and allow the content to use the space available as well as possible. You cannot do this with absolute units.

 

Bear in mind that design guidelines and pattern libraries can be defined in pixels because this is the unit in which measurements are generally computed, but that does not mean you should be using pixels in your CSS. In a responsive retrofit project, you will most likely be converting some sort of absolute unit to percentages to have a fluid grid.

 

You may run into trouble when you need to mix percentages with absolute units for things like gutters and sidebars—for instance, you may want a sidebar on your website that takes up only 200 pixels in width, and the main content should take the remaining width depending on the viewport. In this case, consider using the CSS function calc(), which allows you to do exactly that type of math:

 

 style="margin: 0px; width: 971px; height: 162px;">aside  {

width:  200px;

}

main  {

width:  calc(100%  -  200px);

}

It sounds like magic, right? Bear in mind, though, that this function’s support is less than 80% globally at the time of writing, so make sure to add a fallback for non-supporting browsers. 

 

Scalable Type

scalable

 The main change in making sure you have a responsive typographic scale is usually the conversion of a unit such as pixels into something more flexible. The unit of choice tends to be the em. However, because em is relative to the inherited font size of the target element, compounding issues may arise.

 

If you wish to avoid the problems that can come with using em units as your font-size unit, you can use rem units instead. Rem means “root em,” and it is relative to the root element (the HTML element in this case) instead of being relative to its parent.

 

Rem browser support is quite good, with almost 95% global support at the time of writing. It is supported by Internet Explorer from version 9, with the caveat that IE 9 and 10 lack support for styling pseudo elements and require you to specify the font-size values separately instead of in the shorthand format throughout. You may want to look at the REM unit polyfill if you want to provide rem support for older IE versions (https://github.com/chuckcarpenter/REM-unit-polyfill).

 

Something else to keep in mind when building your typographic scale is that if you specify a unitless value for the line-height property (instead of one with a specific value, like me), that value will multiply the font-size value by the defined amount.

 

So if the font-size is 1 rem, the computed value is 16 pixels, and the line-height value is 1.5, it translates into the computed line-height value being 24 pixels (16 pixels × 1.5). This means you can set a line-height across all breakpoints, instead of defining one for each breakpoint, which will make your type even more responsive.

 

Media Queries

Media Queries

Media queries are the second of the three technical tenets that form the basis of a responsive website. The purpose of media queries, as specified by the W3C, is to allow you to tailor your page “to a specific range of output devices without changing the content itself”.

 

According to the W3C specification, a media query is made up of one “media type and zero or more expressions that check for the conditions of particular media features.” Let’s take a look at a simple example and break down this statement down:

  • @media  screen  and  (width:  500px)  {
  • ...
  • }

The first part, @media, is what is known as a conditional CSS @rule. It contains a statement that can be evaluated to true or false. If true, the declarations following the rule are evaluated.

 

Next, screen specifies the media type. Other supported types are all, print, and speech. Although previous revisions of the media query specification included more media types, these are now deprecated in favor of media features, which offer more fine-grained control.

 

Finally, (min-device-width: 500px) is an example of a media feature. In this case, it checks that the width of the device is equal to or larger than 500 pixels. If the conditions after @media are true, the declarations in the curly brackets ({...}) are executed. 

 

With the power of media queries, you can tailor the design and experience of your website as precisely as you feel is necessary so that it adapts to different screen sizes. There are a few things to bear in mind when transitioning from a media query–free state of affairs to using media queries.

 

Mobile First, and Enhance Progressively

mobile

As part of the work you do on your CSS, consider refactoring it to work in a mobile-first way. This means the initial CSS rules are the ones designed for small screens, whereas the rules in media queries target larger screen sizes. 

 

If you currently use any type of media query in your CSS, it is likely following the opposite approach: the default styles target large (and perhaps medium) screen sizes, and separate rules are added in a media query to target smaller-screen devices. The notion behind this approach ties deeply with the principles of progressive enhancement.

 

When following the mobile-first principle, you usually start with a more linear representation of your content. This simplified layout is likely to work well in old browsers and devices, as well as for screen readers and other accessibility aids, and it will form a good foundation on which more complex layouts can be built.

 

The process of simplifying your layout to work in a mobile-first kind of way falls mostly in the disciplines of design and user experience. But you can also apply this principle to your stylesheets independently.

 

Consider spending some time turning your CSS upside down. Depending on the scale and complexity of your existing stylesheets, this may be an easier or more difficult task, but it is worth it in the long run if you can afford it.

 

This exercise consists of moving all the CSS rules that are not relevant to a mobile-sized view into a media query. Let’s look at an example. Say your layout includes a sidebar and an article area:

 

<article>
<h1>...</h1>
<p>...</p>
<p>...</p>
</article>
<aside>
<ul>
<li>...</li>
<li>...</li>
</ul>
</aside>
And your CSS looks something like this:
article {
float: right;
width: 75%;
background-color: #f7f7f7;
}
aside {
float: left;
width: 20%;
background-color: #333333;
}
In a linear, mobile-first world, you can determine that your article area will be stacked above your sidebar, and both will fill the entire width of the container. In that case, your refactored CSS looks like the following:
article {
background-color: #f7f7f7;
}
aside {
background-color: #333333;
}

 

You remove the float properties, because both containers are stacked; and you also remove the width properties, because they take the full width of the viewport.

 

The next step is to add a media query at the breakpoint where you want the original large-screen layout to kick in, and reinsert the float and width properties. Let’s say this should happen at a minimum viewport width of 700 pixels:

 

article {

background-color: #f7f7f7;
}
aside {
background-color: #333333;
}
@media screen and (min-width: 700px)
{
article {
float: right;
width: 75%;
}
aside {
float: left;
width: 20%;
}
}

 

 

This is, of course, a very simplified view of the type of work you will have to carry out, but the principle is always the same: outside of media queries should only live the styles that power a beautiful small-screen view of your website. As with anything else, you should make sure you test a prototype on real devices as soon as possible.

 

The advantage of this approach is not only related to the fact that you are progressively enhancing your layout with media queries. You are also slightly improving the speed of your page render. When your browser attempts to render a page, it loads the HTML first and parses it to build the Document Object Model (DOM)that is, the structure of the page.

 

It also loads all of your CSS and builds the CSS Object Model (CSSOM), informing the browser how to style the page. Importantly, any CSS in a media query is marked as non-render-blocking until the media query has been evaluated.

 

This means although the entire stylesheet is being downloaded, the browser does not have to stop and evaluate anything in a media query that does not apply to the current viewport.

 

In other words, the critical content your browser is parsing first is all being used. For a device with a slower processor, this can only be a good thing, because evaluating, discarding, and re-evaluating stylesheets takes up valuable processor cycles.

 

Browser Support

Browser Support

At the time of writing, the global audience using a browser with media query support is of almost 95%.10 Only Internet Explorer 6 through 9 (released in 2011) and Firefox 2 and 3 (released in 2008) do not support media queries, so you may be tempted to ignore the small percentage of users with no media query support.

 

But 5% of global usage represents a fair number of people, so it is good practice, and important, to also consider the experience you are delivering to visitors using browsers that do not support media queries.

 

If your CSS has been created following mobile-first principles, this means non-supporting browsers show the small-screen layout, even on large screens. This may be acceptable in your case, but depending on the number of users who are still visiting your website on older IE versions, you may have to consider using a polyfill that enables these browsers to understand media queries.

 

Respond.js (https://github.com/scottjehl/Respond) is the most popular polyfill for this effect. It weighs only 1 Kb when minified and gzipped, and it adds support for the media query types that are most relevant to building a responsive website: min-width, max-width, and media types. It is worth exploring it to see if it matches your site’s particular needs. 

 

Whatever way you decide to cater to older browsers, it is unlikely that you will be able to not use media queries on a responsive website, because they are so fundamental to the notion of what responsive is.

 

Responsively Retrofitted Images

Responsively Retrofitted Images

Responsive images are the third tenet of responsive web design, and probably the one that has been the cause of the most headaches and debate among web developers. As much as we would like to think that all we need to do to have responsive images on our sites is to set their width to 100%, it is not that simple.

 

As you saw in the previous blog, each website can have an assortment of different image types that are used in different ways and contexts, all requiring a different type of responsive solution. Let’s look at some of the most relevant solutions you may want to put into practice when converting your website to being responsive.

 

SVG Images

SVG Images

If there is only one thing you change in the way you deal with images on your new responsive website, it should be starting to use SVG images. As I mentioned in the previous blog, user interface icons, logos, diagrams, and illustrations are prime candidates to become SVG images.

 

SVG is not the best format for all types of images, though. More complex images like photos and complex logos are probably better as bitmap images. SVG lends itself to images that were initially created as vector graphics because it best describes lines, shapes, and flat colors.

 

When in doubt, compare the file size of the resulting SVG image with its bitmap equivalent. For complex images, in many cases, even doubling the physical size of the bitmap image will result in a smaller file size than SVG, which compensates for the loss of resolution when the image is sized up.

 

When it comes to browser support, SVG has nearly 95% global support at the time of writing. If you want your images to display correctly on Internet Explorer 8 and below, you may have to rely on a polyfill or another fallback technique. The same is true for IE 9 through 11, depending on how you need to implement your SVG images because these browsers support SVG only if used in certain conditions.

You can use Modernizr to detect whether a browser supports SVG, and serve it a different format image. This will not solve the defective support in IE 9–11, though, because these browsers do support the feature—just not at its full capacity.

 

Regardless of the downsides, the benefits of using SVG images where possible are manifold. The two key benefits are tightly coupled with the goals for which any responsive retrofitting project should be striving: fast and lean experience, and light but perfectly scalable graphics.

 

Picture and class='lazy' data-srcset

picture

The picture element and the class='lazy' data-srcset attribute were added to the HTML5 specification to simplify the creation of responsive images by relegating the responsibility for selecting the best image for the situation at hand to that which knows best: the browser. Let me give you a quick overview of the two before we move on.

 

In simple terms, class='lazy' data-srcset allows you to define a number of images and either their width in pixels or their pixel density so that the browser can select the most appropriate image. It is better suited on its own (without using the picture element) if all you need to do is provide the same image in different sizes for the browser to choose from. Let’s take an example:

 

<img

class='lazy' data-src="small.png"

class='lazy' data-srcset="medium.png  724w,  large.png  1024w,  x-large.png  1600w"

alt="Black  cat">

 

Here you specify a small version of an image in the class='lazy' data-src attribute. This image will also serve as a fallback in case the browser does not support the class='lazy' data-srcset attribute. You then specify a medium-sized image that is 724 pixels wide, a large image that is 1,024 pixels wide, and a super-large image that is 1,600 pixels wide. All the browser needs to do is choose the one that is more appropriate for the viewport at hand.

You can also specify the images’ pixel density instead:

 

<img

class='lazy' data-src="small.png"

class='lazy' data-srcset="medium.png  1.5x,  large.png  2x"

alt="Grey  cat">

 

 

If you need to provide different images for each situation (for instance, if at a smaller size you want to show a cropped version of a larger image), you should use the picture element. Let’s take another example:

 

 

<picture>

<source media="(min-width: 900px)" class='lazy' data-srcset="medium.jpg 900w, large.jpg 1600w" sizes="(min-width: 1400px) 50vw, 100vw">

<img  alt="Lots  of  cats"

class='lazy' data-src="small.jpg">

</picture>

 

Let’s catch our breath and begin from the top:

  • The group of the source and img tags are wrapped in the picture tag so the browser knows how to interpret them.

 

  • If the media query in the source is matched—the viewport has a min-width of 900 pixels—the browser will choose one of the images in source’s class='lazy' data-srcset and skip any elements that follow.

 

  • If the media query in the source’s sizes attribute is a match to the viewport (min-width: 1400 px), the image chosen will be displayed at the defined size (50 views), otherwise, it will be displayed at the default size (100 VW).

 

  • If no other elements match, the image tag’s class='lazy' data-src is used.
  • The image tag is always required.

 

You can have multiple source tags in a picture tag, and you can also have class='lazy' data-srcset and sizes in the img tag, but I did say I was going to be brief. It would easily take as much space as this entire blog to go through all the ways in which the picture element and class='lazy' data-srcset attribute can be used and combined to provide the best image for each situation. I encourage you to dig into the current spec for yourself and experiment with different solutions.

 

At the time of writing, global browser support is just over 60% for the picture element and just over 66% for the class='lazy' data-srcset attribute but growing quickly. And remember that if the browser does not support either of them, there is always a fallback image to rely on.

 

If you are wary of using this type of cutting-edge technique, remember what I mentioned at the start of this blog: you can always experiment on a smaller project to test the waters, and if it does not work for you, find another solution. This could also be a way to test the feasibility of existing polyfills, such as Filament Group’s Picturefill.

 

Even if you decide that these are not appropriate for your website right now, it is important that you look into them carefully: they will become ubiquitous at some point in the future, and learning them is key.

 

Image Caching

image

Good responsive images are not just ones that scale up and down with the viewport. They are also responsible images: they should not be larger than necessary and cause users to download more than they need to render the website on the device of their choosing. If your website uses the same images in more than one place, you should make sure you are always using the same instance of the image.

 

If you display on your website logos from partners or products, or user interface icons for things like search, shopping cart, and so on, anyone working on the website should never have to create a new instance of the same logo or icon. And similarly, a user who visits your website more than once should not have to download these assets twice.

 

You can create logo packs and icon packs that live in a central location where someone working on new designs can download them. Ideally, every time you need to reference them in your website, you should use the same source file in the same location. You should also ensure that your site’s server is set up to cache the images appropriately if you are not doing so already.

 

Compress Those Bitmaps

Compress Those Bitmaps

Often, when deadlines are looming, content and image creators are not necessarily paying much attention to the size of the images they upload onto content management systems—and many times, CMSs are not great at cleverly compressing images when they are unnecessarily large.

 

Another of my favorite exercises that you can follow when making your website responsive is to go through the website with a tool like YSlow (http://yslow.org/) to pinpoint the location of the worst offenders, so you can resize them for better performance.

 

Once you have a list of where the extra-large images are hiding—they tend to hide in the plain website, though—compress the bitmap images that do not need super-high quality or a transparent background. This is a quick, simple way to reduce the file size of the images across your website.

 

A neat trick you may want to try when you want crisp images on Retina displays but still want to save on file size is to export the JPEG at twice its size using a high compression rate. Because you will not display the image at its original size, the fact that it is a little blurry will not be noticed.

 

Even though you are using an image that is twice as large as necessary, the file size you save with compression makes the resulting file size smaller than if you had exported the same image at the correct size with little or no compression. Always make sure the balance between the resulting file size and image quality passes a visual inspection, though, because in some cases the quality of the compressed image may not be what you are looking for.

 

Optional Images

Optional Images

Optional images are ones that are not crucial for the experience of your website. All decorative images fall into this category. If an image is simply adding a little flourish to the page to liven it up, you may want to consider loading it only on larger screen sizes, making sure users on small screens are not unnecessarily downloading the image.

 

In theory, decorative images should be added via CSS as background images. If you do this, the background image can be added in a media query that targets larger viewports, and you avoid the extra download on smaller screens. If the image is added directly into the HTML, however, it will be much more difficult, if not impossible, to stop the unnecessary download.

 

It would be nearly impossible to cover all possible solutions for responsive images that are currently in circulation; but now you have a good overview of some things you can test and try on your retrofitting project, along with some key techniques to consider. Bear in mind that, depending on your site’s needs and the types of images you are using, you may well have to apply more than one technique to build a solution that is best for your users.

 

Testing

testing

Making sure you test your website and prototypes on real devices as soon as you begin working on your responsive retrofit is without a doubt one of the key ingredients for a successful project. If you leave testing for later, you run the very real risk of getting too far into the build and the decision-making process before you spot big mistakes and bugs that could have been more easily and cheaply fixed at earlier stages of the project.

 

What to Test On and What to Fix

What to Test On and What to Fix

It is a good idea to define which browsers, devices, and operating systems you are going to test your website on. By doing this, you are not determining that you will not fix bugs or make improvements on anything else; this simply serves as a guide for your team, and other teams, to ensure that testing is conducted in a systematic and unambiguous manner.

 

Having a document and process that everyone follows, no matter who is testing or what is being tested ensures that your website will always comply with certain standards. Determining what to test on depends greatly on your existing users.

 

A good starting point is to analyze your analytics numbers and see which devices are the most popular ones that people try to access your website with. The key word here is trying. If you do not have a good mobile experience, it is unlikely that your analytics will reflect the same usage as if you did. Repeat visits would probably be higher, and the devices used most frequently might be different, too. Regardless, you have to begin somewhere, so existing numbers are perfectly acceptable.

 

Do not focus simply on mobile device data, though. You want to make sure your new responsive website has been tested across a wide range of browsers and operating systems, and that includes desktop-like environments.

 

I cannot tell you what the minimum threshold should be for your team to determine whether an issue should be taken care of; that is up to you and your special circumstances. It is not possible to say that you should not fix any bugs for browsers with fewer than 1% of visitors, because 1% can mean an enormous number of people for high-traffic websites.

 

If your website gets 100,000 visitors per month, 1% translates into 1,000 users. If your website gets 10,000,000 visitors per month, 1% means 100,000 people. Is it worth improving the experience of 1,000 people? What about 500? Or 100? That is a question that only you, your team, and your company can answer.

 

You should also check the most popular current devices and combinations of browsers and operating systems. Your own analytics may not reflect the current state of affairs, but that does not mean it will stay like that once you release your beautiful new responsive website.

 

BrowserStack has created a very convenient list of devices and operating systems that you should be testing on, based on global trends.. This list is updated frequently, so it is a useful resource when determining which devices to add to your testing guidelines and keep on hand. Remember to add tricky operating systems and browsers to your testing protocol, too.

 

Make sure you do not just test on easier ones, like the latest iOS phone and tablet and the latest Android release. Test on older versions of these operating systems, and on non-default browsers, such as Opera Mini and UC Browser, which are popular in China and India and have an expanding user base.

 

Build Your Device Lab

Build Your Device Lab

The idea of having your own set of devices to test on can sound like an expensive endeavor. But you can build up a device suite, even if you are on a tight budget, by considering your analytics and which devices your visitors are using. Building your own device lab should be something you do early in the project because you want to start testing as soon as possible.

 

Just as I recommended in the previous section, fall back on your site’s analytics data to see the devices on which people are using your website. This will give you a better idea of which devices are more of a priority for your team to get access to.

 

Once you have a wish list of devices you feel are important for you to own, there are a few things you can do to put together your own lab:

  • Use auction sites like eBay to get a better deal on new or like-new devices.
  • If you decide to not spend on more expensive devices like iPhones and iPads, there is money left in the pot to buy a larger number of other devices.

 

  • Ask if anyone in your company and your team has old devices that they do not use anymore that they would like to donate. People tend to forget about these at the bottom of their drawers, so it is always worth asking.

 

  • Set up a dedicated testing machine that runs several instances of Windows and Linux with different versions of Internet Explorer and other browsers that may be relevant for you to test on.

 

As the project evolves, your device suite will likely grow as your needs change. After you release the first iteration of your website, whether you are doing it in a closed way, internally, or open to the world, people will begin to access your website from devices that you may not have tested on. An easy-to-follow strategy to expand your device lab is to acquire devices with operating systems from which you receive a fair number of bug reports.

 

As I said before, ideally, you will be testing on your own set of real devices; but you can also consider using a public device lab if there is one in your area. In some cities across the world, there are Open Device Labs, which are open for designers and developers who wish to test their sites across a multitude of real devices but do not have a suite of their own

 

Emulators and Other Tools

test

Even if you build the ultimate device lab, you will not be able to physically have all the possible devices people may use to browse your website on. Several tools can help you fill in the gaps when the real deal is not available or if you are working from another location but still need to do testing.

 

BrowserStack is a popular testing tool among designers and developers because it provides cloud access to an incredible array of operating systems and browsers without the need to install virtual machines on physical devices.

 

One of the biggest advantages of using BrowserStack is that it provides access to operating systems that are harder to find in real life. Older versions of popular operating systems can sometimes be tricky to locate, so it is handy to be able to test a specific bug that may only be reported on a less-common platform.

 

It also lets you securely test sites that live on development and staging environments, which is extremely useful particularly in the early stages of the project.

 

Another useful tool to have in your arsenal is Ghostlab (www.vanamco.com/ghostlab/). It performs a different purpose than BrowserStack: Ghostlab makes it possible to test simultaneously on various browsers and physical devices. So if you are testing a certain interaction pattern on a specific page, whatever you are doing on your computer also happens on all the other connected screens at the same time.

 

You can even inspect the CSS and markup on one device, make changes, and see them reflected in all other devices. Very neat, right? Ghostlab also supports Sass, Less, Haml, CoffeeScript, TypeScript, Jade, and Stylus, and testing on development environments.

 

Finally, Percy (http://percy.io/) is a visual regression tool that integrates with your continuous integration. If you already have CI set up, this is a great little addition. Percy takes screenshots of your website before and after you make changes to the CSS and push them to the server. It also, gloriously, allows you to test your responsive designs.

 

You can give the service a list of breakpoints, and it takes and evaluates browser screenshots to check how the CSS changes have affected your website on the desktop as well as mobile devices.

 

Regardless of the number of devices you have, or whether you need to use emulators, testing is a vital part of any responsive design project and should be performed constantly and consistently throughout.

 

Whether you have a very small or a sprawling suite of devices to test on, or you rely mainly on emulators and other tools, make sure to instill on your team the need to test early and often in a responsive world.

 

Improving Your Process

markup

It is well beyond the scope of this book to go into any kind of detail about the many and varied options available to development teams today. But there are a handful of principles you may want to strive for as you think about how to improve your team’s processes and workflow. 

 

As I hinted earlier in this blog, undertaking a responsive retrofit is a great opportunity to take a look at your working processes when writing, publishing, and maintaining code. Let’s dive in.

 

Writing Code and Markup

Writing Code and Markup

When working in a team, you can follow a few core principles to make writing HTML, CSS, and JavaScript a more pleasant experience for everyone. Focusing on the quality and robustness of the code is important, but almost as important are the factors that matter most when you are knee-deep in stylesheet declarations or buried to the nose in HTML: consistency, readability, and predictability. Establishing a few rules and guidelines will help everyone collaborate and contribute consistently.

 

Have a Markup and Code Style Guide

It makes sense to formalize the conventions you are using. Write them down, share and use them, and do not forget to update them, too. If you do not already have a style guide covering markup and code conventions, there are several good examples you can use as a starting point. For instance, the guidelines for Primer (http://primercss.io/guidelines/), the framework that powers GitHub, are a good, open source example to take inspiration from.

 

Have a Markup and Code Style Guide

So, what best practices should a style guide cover? The answer depends on how you work, the projects you are working on, how many people are on your team, and other individual factors. The key is ensuring that your guidelines help you avoid confusion and conflict within your team and make things clear for new starters. Consider including guidelines about the following:

 

  • How to format HTML markup.
  • How to use indentation and spacing consistently.
  • How to mark up specific elements, like forms and tables.

 

  • Class-naming conventions. The use of prefixes, capitalization, and underscores can help identify what type of class you are dealing with.
  • How CSS declarations should be formatted. This removes doubt when writing your stylesheet, and makes reading and updating it easier, too.

 

  • How to use whitespace in your documents to aid readability.
  • Whether to use tabs or spaces.
  • How and when to write comments.

 

  • Documentation practices in general.
  • How to write tests, what to test, and when.

 

  • Source-control workflow, including best practices for commit messages and pull requests.

 

If you are using Sass, your guide should also cover best practices regarding things like how deeply you should nest declarations, which helps to limit specificity issues that result from a too-deeply nested stylesheet. The key is to have guidelines that work for your situation, are consulted and updated when conventions change, and help your team work together with less friction.

 

Using Sass Responsively

SASS

As you are toiling away in your text editor, one of the things that can cause more agony is having to repeat yourself unnecessarily. Typing #ff69b4 over and over is not much fun; and if you grow tired of hot pink, having to find and replace all instances over several stylesheets will seem like a chore. This is the kind of problem preprocessors exist to help you with.

 

Simply put, preprocessors are scripts that take a file in one format, manipulate it in clever ways, and output the converted result at the other end. Although there are preprocessors for HTML and JavaScript, I am focusing on CSS in this section because it is likely the one most relevant to the process your team will be undertaking during a responsive retrofit.

 

Sass also fills in and makes some of the shortcomings of CSS easier to deal with: it provides variables, nested declarations and properties, mixins, functions, and much more. If Sass’s only feature was variables, it would still be worth using. By defining all of your site’s colors, measurements, and grid layout in one place, you can abide by the Don’t Repeat Yourself (DRY) directive and save countless tears, both when writing and when maintaining your website.

 

One example of how variables can help in creating a responsive stylesheet is in the definition of the grid. Let’s say you want to define a simple grid with a set number of columns and a defined max-width. Keeping these values in a central location means you know where to go looking for them.

You can name the file anything you like, but _variables.scss has a nice ring to it. If you are curious, the underscore prefixing the filename tells the Sass compiler that the file is partial: it will not compile this file into CSS, because the file’s purpose is to be included in other Sass files using the @import directive. Put your grid and column definitions in this file:

 

  • Defining our grid and columns $grid-max-width: 55em; $col-num: 12;

 

As you will have noticed, Sass variables are prefixed by a dollar sign ($), making them easy to spot when used in the stylesheet. When you enter the variables to use, they look like this:

  • We need to include the part in our SCSS  stylesheet.
  • Note  that  we  do  not  need  to  include  the  underscore  prefix
  • or  the  file  extension  in  the  import  declaration:

 

@import  "variables";

.container  {

max-width:  $grid-max-width;

}

When this is compiled and output into CSS, the result looks like the following:

.container  {

max-width:  55em;

}

 

Usually, variables are used several times throughout a stylesheet, saving repetition when you have to change or update values. There is a case to be made, however, for keeping values that you only use once in a stylesheet as a variable too; doing so gives you one central point—your variables partial—where you can go to find all the relevant, crucial definitions for your website, such as color, grid measurements, typographic scale, and more.

 

Organizing Your Stylesheets

CSS

There are several considerations when writing CSS; and as often is the case, these considerations can be conflicting. You want to write lean, efficient CSS, and you want your CSS to be performant; but you also want CSS that is easy to maintain. The good news is that with a few tricks and tools, you can have your CSS cake and eat it too. It just requires some thinking ahead.

 

It probably makes sense for you and your team to split the site’s stylesheets up into several files dealing with distinct areas of your website. This is not required, and some teams prefer to work with one or two larger stylesheets; but separating your CSS into different files may provide some flexibility in your workflow and make your styles more manageable, as long as everyone knows the structure and follows the conventions.

 

When serving the website, however, having several stylesheets is a bad idea, because each request slows down the website. Luckily, our great web developer community has already solved this kind of problem with the introduction of build tools.

 

These tools let you maintain a working environment where your stylesheets are logically separated and well commented, and rules are spaced out and easy to read, maintain, and contribute to. When it is time to ship, the build tools take care of all the grunt work, such as

 

  • Combining separate CSS files into one
  • Ensuring that the caching for CSS assets is set correctly so they do not have to be fetched again when you return to the website
  • Replacing the notoriously slow @import directive with link tags

 

  • Ensuring that your CSS is always placed before any script tags in your document head
  • Inlining layout-critical CSS to really turbo-boost the initial rendering of the page

 

Depending on the particular stack you are working with, the best tools to use will vary, but the key objectives remain the same. The beauty of working with Sass, or other tools with similar functionality, is that you can break up your stylesheets into as few or as many separate files as you like.

 

When it comes to testing or making the website live, the separate stylesheets will be concatenated, which is another way of saying they will be combined. This reduces the number of time-consuming requests the page is required to make to the server, thereby speeding up your website.

 

How you break up the stylesheets is a matter of taste, but common wisdom dictates that keeping common variables in one place is a good idea. You can then consider breaking up specific items by theme:

  • Typography
  • Grid and layout
  • Color
  • Buttons
  • Forms
  • Tables
  • Reset styles, and so on

 

You can also add separate stylesheets for CSS needed for components from third-party sources, like a date picker library or a slideshow plug-in. It usually makes sense to keep these in a specific folder, perhaps called the vendor, to differentiate them from the in-house styles you developed. This also makes it easier to find that particular piece of CSS when you need to remove or update a third-party resource.

 

The amount of work involved in adding consistency to your markup and your code can be substantial and perhaps unfeasible within your time constraints. It is, however, something that is worth investing in, because robust, flexible code can save you considerable time and effort in the future.

 

Publishing Your website

publish

 

The process of publishing your website is an area where you can make tremendous improvements with a few lines of code. Several tedious tasks can benefit greatly from a sprinkling of automation.

There are some things you should consider adding to your build process:

  • Minifying your documents
  • Removing comments
  • Concatenating stylesheets
  • Ensuring that your assets are cached appropriately and perhaps served from an asset server

 

Forty years ago, Bell Labs developed Make (https://en.wikipedia.org/wiki/ Make_(software)), a program for the Unix operating system. Still widely used today, Make works by taking instructions from a text file to transform source code files into working software.

 

Most of the build-automation tools in use today, which help you through the process of publishing HTML, CSS, and JavaScript, work on the same principle: they run through a list of tasks, doing what computers do best repetitive, predictable chores. 

 

Most of the deployment tools used today can be tied into the version control system of your choice and are based around a workflow that assumes the existence of version control. If you are not using version control for some reason, this is the time to set that straight. In his pocket book Version Control with Git, Ryan Taylor has outlined how to get started with Git, and version control. It is worth a read for the uninitiated (https://gumroad.com/l/rXch).

The build tools, sometimes referred to as task runners, can help with repetitive chores relating to development, testing, optimizing assets, and deploying your website to the server. Here are some of the popular tools you can use to help you automate the most tedious tasks:

 

  • Rake (http://guides.rubyonrails.org/command_line. html#rake) is a Ruby implementation of Make. It is most commonly used to create a list of tasks that need to be completed in a specific order, much like a recipe. Although it is associated with Ruby on Rails, you can use Rake to help automate any manual build process.

 

  • Grunt (http://gruntjs.com/) is another build tool that can help with the chores involved in building a website. It has its roots in JavaScript and Node.js (https://nodejs.org/) development, and you write the list of tasks you want it to run in JavaScript. It has a solid reputation and community around it, meaning most of the tasks you will need are available as plug-ins.

 

  • Gulp (http://gulpjs.com/), a challenger to the Grunt throne, has features and requirements very similar to Grunts. Gulp can run several tasks at the same time, giving it a reputation for speed.

 

  • Brunch (http://brunch.io/#why) is a lean, fast, simple tool for the most common build tasks. Like Grunt and Gulp, it uses Node, and its recipes are written in JavaScript.

 

  • CodeKit (https://incident57.com/codekit/) differs from the other tools on this list in that it does not require you to use the terminal—it is an app with a nice-looking GUI. Like the other tools on the list, it allows you to compile and optimize your assets, check the quality of your code, and more.

 

Most of these tasks sport a command-line interface (CLI), meaning you invoke and run them through the terminal. There are many tools on offer, and they all do a good job of relieving you of the type of tasks a computer does much better than any human. If you are not sure which tool is the best one to pick, choose one, try it, and keep on trying until one fits your needs. All the tools on this list will free you to concentrate on more important—and more creative—matters.

 

There are many things you can do to your writing and publishing processes that can save you time and effort. They all require some initial investment as you investigate the best tools for you and change the ways in which you are used to working. If you are reading this book, time probably is not your most abundant commodity, so take it one step at a time.

 

Measuring Success After Release

sucess

The feeling of accomplishment after you finally get to release your new responsively retrofitted website is terrific. But even if you managed to make as many changes and improvements as you wanted, work should not stop there.

 

You need to make sure the hard work has paid off in a positive way, so it is important to have defined ways to measure success post-release. You can do this in simple or in extremely complex ways. Here I give you a few ideas about what you should keep an eye on before and after you publish your new website to get you started if you haven’t done so already.

 

Once your website is up and running, you want to make sure it keeps running smoothly and that you are alerted when something goes wrong. In addition to monitoring the health of your site—uptime, server capacity, and database connections, for example— you should gather insights on your site’s visitors.

 

One metric you should keep an eye on is the number of users visiting your website on mobile devices. Remember that the numbers after release can be a bit skewed, because previously the user experience of your website on small-screen devices may have been too painful to navigate. But an increase in mobile visits is nonetheless something to celebrate, if not to be expected.

 

You also want to make sure you are tracking the following before and after release:

  • Drop-off rate
  • Session duration
  • Repeat visits
  • Key journeys, such as logins, signups, and checkouts

 

Each website and organization will have different ways of measuring success. Page views, shares on social media, advertisement revenue, active users, new signups, number of successful checkouts, visit length, number of pages per visit, repeat visits, and even how fast the visits are (the faster the better, on some government websites, for instance) can all be good indicators of how well, or not, your website is doing.

 

The most important takeaway is that whatever metric you have determined defines success for your website should be tracked before, throughout, and most certainly after release.

 

Also consider how visitors to your website can provide feedback if they wish to. This is particularly important in the first few weeks after release, when the website is new and people are more likely to comment on anything they think may be wrong with it; but it is important to consider doing this in the long term, too.

 

If you make it easy for users to submit feedback and bug reports, your users will provide an important and invaluable layer of testing that you would not be able to replicate on your own.

 

There are a few relatively simple and, most important, inobtrusive ways in which you can do this:

  • Create a form (like a Google Form) to capture visitors’ feedback, and add a link to it on your website
  • Include a feedback button on your website
  • Include a mini-survey directly on your website, with one or two key questions you want to know more about
  • Add a link to submit a bug report directly to your issue tracker, ensuring that there are guidelines on how to do so
  •  

You can also consider something more sophisticated, like using a product such as Intercom.io (www.intercom.io/;, which allows you to engage with your users in a much more targeted and customized manner.

 

Do not let the momentum die down. Your team’s schedule is probably fully packed for the weeks and months after the release of your newly responsively retrofitted website. But if you planned subsequent stages into your schedule, and if you have captured all the other things you want to improve in your backlog, you should be able to keep on improving.

 

The next phases of your project may be much smaller than the first push to go live. You may want to divide the subsequent work into smaller projects that tackle a specific problem or enhancement. And this list of projects is probably never going to be completely finished because you are sure to see the potential for improvement in many areas of your website. But that is the nature of our work.