Webdesigntuts+

Tuts+ Jobs is Now Free!

Joel Bankhead — Mon, 17 Jun 2013 14:03:49 +0000

Our awesome new job board is now free and full of enticing opportunities!

Tuts+ Jobs is a job board for full time, part time and casual employment opportunities for web and creative professionals. A brand new site to go alongside the Tuts+ Educational Network and the Envato Marketplaces, all run by Envato.

There’s no need to sign up to apply for jobs, and it’s now free to post a job – try it now!

Earn and Learn

Envato is committed to helping people earn and learn online. We provide a wealth of educational material through Tuts+ and Tuts+ Premium, alongside the Envato Marketplaces to help you benefit from the creative skills you learn.

Tuts+ Jobs furthers this vision perfectly. With Tuts+ you can learn the skills you need to become a creative professional, and with Tuts+ Jobs you can find an amazing job that uses those skills. Our goal here is to take the hassle out of finding a job, so we’ve made the process as simple as can be!

Finding a Job

With Tuts+ Jobs we’re committed to making every step of the job-finding process more intuitive, simpler and more efficient. We don’t want to stand between you and a great opportunity.

It’s totally free to sign up and start applying for jobs, and if nothing matches your initial search you can receive notifications when jobs come up that match your criteria. We will have full time, part time and casual listings from all around the world. Check the listing to find out where the job is based, as some jobs may offer remote opportunities.

Posting a Job

Posting a job is now free!

If you have a position that you need to fill, or a great part/full-time opportunity, then Tuts+ Jobs is the best way to find a talented and creative individual to do that job. Each 30-day listing is completely free, regardless of the type of job you’re posting.

Your job listing will be promoted across the entire Tuts+ network. With exposure to our ten million visitors over the course of 30 days, it’s a brilliant way to reach exactly the type of audience you’re looking for.

Sign Up, Explore, and Subscribe

There are lots of great opportunities already on Tuts+ Jobs, and we’ll be posting even more exciting job positions over the next few weeks, so now is the best time to head over to the site and subscribe to a job search that interests you. That way you’ll be the first to know when any new listings show up that match your skill set and requirements.

Check out Tuts+ Jobs

Foundation for Beginners: Buttons and Dropdowns

Matt Pilott — Mon, 17 Jun 2013 12:45:02 +0000

In this part of “Foundation for Beginners” we’ll look at buttons, dropdowns and the “Clearing” plugin.

Buttons

Foundation has a solid set of buttons and they are very easy to implement. Simply add a class of ‘button’ to any anchor, input, div or button element to see it transform into a glorious Foundation styled button. This just gets you the standard box button, but there are a wide range of button styles and types you can use. Here’s a quick example:

<!-- Size Classes -->
<a class="button" href="#">Default Button</a>
<a class="tiny button" href="#">Tiny Button</a>
<a class="small button" href="#">Small Button</a>
<a class="large button" href="#">Large Button</a>
<!-- Color Classes -->
<a class="button secondary" href="#">Secondary Button</a>
<a class="button success" href="#">Success Button</a>
<a class="button alert" href="#">Alert Button</a>
<!-- Radius Classes -->
<a class="button radius" href="#">Radius Button</a>
<a class="button round" href="#">Round Button</a>
<!-- Disabled Class -->
<a class="button disabled" href="#">Disabled Button</a>

This example demonstrates all the preset sizes, styles and states. They each offer quite a lot in the way of flexibility; all presets can be overridden with custom styles meaning you don’t need to build up your buttons from scratch.

Buttons use chained classes to achieve different styles. For instance, start with ‘button’ then add a size, ‘small’, a color, ‘success’ and a radius ‘round’. You could also disable any button by adding ‘disabled’, illustrating just how versatile this styling approach is.

Button Groups

Basic buttons are simple enough to implement and buttons groups are just as easy. They use a simple list structure like so:

<ul class="button-group">
	<li><a class="small button" href="#">Button 1</a></li>
	<li><a class="small button" href="#">Button 2</a></li>
	<li><a class="small button" href="#">Button 3</a></li>
</ul>

This will give you a standard group of three buttons, however you can add radius classes and classes to control the width, ‘even-2’, ‘even-3’ right through to ‘even-8’. These width classes are used to fill the available space with your buttons and are used best when the number in the even class matches the amount of buttons present. For example, if you had four buttons then ‘even-4’ would be the best choice.

Button Bars

Button bars could be described as being a group of button groups. Take a div, add class="button-bar" to that div and place as many button groups as you wish inside it. This can be a real help when it comes to more complex button layouts. Here’s an example:

<div class="button-bar">
<ul class="button-group">
	<li><a class="small button" href="#">Button 1</a></li>
	<li><a class="small button" href="#">Button 2</a></li>
	<li><a class="small button" href="#">Button 3</a></li>
</ul>
<ul class="button-group">
	<li><a class="small button" href="#">Button 1</a></li>
	<li><a class="small button" href="#">Button 2</a></li>
	<li><a class="small button" href="#">Button 3</a></li>
</ul>
</div>

On small screens, each button group within the bar is stacked automatically, allowing for a clean look on any screen. By taking options covered in each of the above sections you can really go to town on your buttons.

Dropdown Buttons

In the latest major revision of Foundation a new JavaScript plugin called dropdowns was introduced, which really comes in handy when layered on top of buttons. The markup essentially requires you to add a ‘dropdown’ class to your button, with the addition of a custom attribute namely ‘data-dropdown’.

Follow this with an unordered list containing an id matching your data-dropdown attribute, for example:

<a class="button dropdown" href="#" data-dropdown="drop1">Dropdown Button</a>
</pre>
<ul class="f-dropdown" id="drop1">
	<li><a href="#">This is a link</a></li>
	<li><a href="#">This is another</a></li>
	<li><a href="#">Yet another</a></li>
</ul>

It’s also important to note that the ‘f-dropdown’ class on the ul is very important so don’t forget to add it.

Note: Don’t forget to include the dropdown js in your download of Foundation.

Split Buttons

The final layer of flexibility you have to play with is the option to add a split in your buttons. This can be used to indicate the availability of a dropdown, a download, whatever you want really. Add it onto your button using the ‘split’ class and a span element that should include the same ‘data-dropdown’ attribute we used earlier in our dropdown example.

<a class="button dropdown" href="#" data-dropdown="drop1">Dropdown Button </a>
</pre>
<ul class="f-dropdown" id="drop1" data-dropdown-content="">
	<li><a href="#">This is a link</a></li>
	<li><a href="#">This is another</a></li>
	<li><a href="#">Yet another</a></li>
</ul>
<pre>

As the dropdown JavaScript is a simple plugin, there is only one option to play with – defining the class name applied to the dropdown when open:

$(document).foundation('dropdown', {
  activeClass: 'open'
});

Clearing Plugin

Clearing makes it easy to create responsive lightboxes with any size image.

Clearing is a super fast lightbox plugin. As you can imagine, markup is dead simple and is very useful when the orbit slider isn’t working for you.

By now you’ll be very familiar with the way Foundation works with list structures, and they’re once again at the heart of this plugin. Build an unordered list, with some content within each list item. Add a ‘clearing-thumbs’ class to the ul, plus an empty custom attribute of ‘data-clearing’.

</pre>
<ul class="clearing-thumbs" data-clearing="">
	<li><a href="path/to/your/img"><img alt="" src="path/to/your/img-th" /></a></li>
	<li><a href="path/to/your/img"><img alt="" src="path/to/your/img-th" /></a></li>
	<li><a href="path/to/your/img"><img alt="" src="path/to/your/img-th" /></a></li>
</ul>
<pre>

If you were to add a ‘clearing-feature’ class to the first li in your ul structure then Foundation would display it as the featured image in your lightbox selection. It’s worth noting that clearing uses the block grid structure we covered earlier in the series. This helps ensure all thumbnails are the same height and evenly distributed.

Conclusion

Following our complete coverage of buttons and dropdowns, we can look forward to covering custom forms and switches. I’ll see you there!

Foundation for Beginners: The Top Bar

Matt Pilott — Thu, 13 Jun 2013 15:20:04 +0000

Let’s take a look at the top bar included within the Foundation framework. As there’s quite a lot to cover we’ll break it down into easy chunks.

Top Bar, or no Top Bar

Foundation’s top bar is a very useful little component, but it’s by no means obligatory to use it in your builds. I’d estimate that I’ve made use of it in around 40% of the projects I’ve built with Foundation. Give careful consideration to whether or not it fits the needs of your project; the top bar component is as easy to style as any other, but the interaction is pretty much set.

The Essential Structure

To begin building up the top bar we need a <nav> tag, with the requisite class of “top-bar”.

Inside that lies a <ul> and two <li>’s, one of which will hold our title/logo the other our “mobile” menu.

Note: you can remove either the class “menu-icon”, or the content “Menu”, if you prefer to have just one of the two showing.

<nav class="top-bar">
    <ul class="title-area">
        <li class="name">
             <h1><a href="#">Top Bar Title </a></h1>
        </li>
        <li class="toggle-topbar menu-icon"><a href="#"><span>Menu</span></a>
        </li>
    </ul>
</nav>

Adding Parent Links

Adding parent links is our next objective, so before our closing nav tag add in a <section> with the class “top-bar-section”. In this section we need to add an unordered list with several list items.

Foundation has a useful class “divider” which can be applied to empty list items, allowing you to separate each menu link with an attractive line. They’re used in the following example to divide our menu links.

You’ll also notice that the ul has the “left” class applied to it, which sends things to the left. You could, for example, have two sets of menu links, one floating left and one (using the “right” class) floating right.

<section class="top-bar-section">
	<ul class="left">
		<li class="divider"></li>
		<li class="active"><a href="#">Main Item 1</a></li>
		<li class="divider"></li>
		<li><a href="#">Main Item 2</a></li>
		<li class="divider"></li>
	</ul>
</section>

All the links we’ve added so far will be displayed horizontally along the bar. On smaller screens they’ll become a dropdown, activated by the Menu button we added earlier.

Adding Submenus

Each list item can contain a nested unordered list for sub menus. In order for this to work and be displayed properly, the “has-dropdown” class must be applied to the parent link, with the class “dropdown” being applied to the nested unordered list:

<li class="has-dropdown"><a href="#">Main Item 3</a>
	<ul class="dropdown">
		<li><label>Dropdown Level 3 Label</label></li>
		<li><a href="#">Dropdown Level 3a</a></li>
		<li><a href="#">Dropdown Level 3b</a></li>
		<li class="divider"></li>
		<li><a href="#">Dropdown Level 3c</a></li>
	</ul>
</li>
<li class="divider"></li>

Note: To mark the current page link active, add an “active” class.

Submenus are displayed as a standard dropdown under “large screen” circumstances. On smaller screens they slide in from “off screen”.

Additional Settings

In spite of being referred to as the ‘top’ bar, you can place this component anywhere in your layout. If you need the bar to stay fixed on the page whilst you scroll, you can wrap the top bar in a div with the class “fixed”. Alternatively, if you want to keep the top bar within your main container you can set the width of the top bar to the grid width by using the “contain-to-grid” class. Happily, you can use both of these classes (“contain-to-grid” and “fixed”) in combination.

Let’s say you want the top bar in the center of the layout, but need the bar to stick to the top of the page when the user scrolls down. This is possible by wrapping the top bar in the “contain-to-grid” and “sticky” classes.

<div class="contain-to-grid sticky">
	<nav class="top-bar">
		<!--nav content-->
	</nav>
</div>

Adding a Search Input

If all those handy features weren’t enough, you might also want to add an input which you could use for search, or a mailing list signup, or anything you want. When adding form elements within a menu list item, we need to add a class of “has-form”. You can see from the code below that we are actually making use of the grid within the top bar. This makes placement of the elements easy – and of course responsive, as the columns shift layout on small screens.

<li class="has-form">
	<form>
		<div class="row collapse">
			<div class="small-8 columns">
				<input type="text">
			</div>
			<div class="small-4 columns">
				<a href="#" class="alert button">Search</a>
			</div>
		</div>
	</form>
</li>

Breadcrumbs

Breadcrumbs are commonplace on CMS-based websites, such as WordPress, where multi-level page hierarchy can get a little complex. These can be used in any Foundation project by simply adding the “breadcrumbs” class to either a <ul> tag or a <nav> tag. When using the unordered list, all links need to be in list items, whereas the links inside the nav element need to be anchor tags.

The only additional classes included in the breadcrumb markup are “unavailable” and “current”.

<ul class="breadcrumbs">
	<li><a href="#">Home</a></li>
	<li><a href="#">Features</a></li>
	<li class="unavailable"><a href="#">Gene Splicing</a></li>
	<li class="current"><a href="#">Cloning</a></li>
</ul>

Coming up Next

The top bar is very flexible and is simple enough to incorporate in any of your foundation-based projects. In the next part of this session we’ll talk about buttons, dropdowns and the clearing plugin.

Presenting Your Web Mockups With Added 3D Flair

Taras Kravtchouk — Tue, 11 Jun 2013 09:00:40 +0000

In this tutorial I’m going to show you how to take your flat design (as in two dimensional, not flat as in the current design trend) and add some life by mocking it up on a 3D plane in perspective. The purpose of this is to present your design in a more dynamic way, giving it more depth and visual appeal. It can be a very effective way to present visuals to clients.

There are a couple of ways to achieve this effect, such as using Photoshop’s own 3D tools and creating 3D layers. I am, however, more comfortable using proper 3D software such as 3ds Max as it offers much more control over the camera, allowing you to rotate around the 3D plane with greater control over the lighting and shading. Initially it may look more complicated, but when you’ve done this once you’ll later be able to mock your work up in a matter of minutes.

If you’re new to 3D we have a plethora of tutorials to get you started..

The principles demonstrated here are application agnostic; you’ll be able to apply them to any 3D software out there. To follow along you should know your way around Photoshop and have at least opened a 3D tool program before.

Anyways, for this tutorial I will be mocking up the design of our latest app called TriplAgent, which seems to be spreading like wildfire on those interwebs. You can see the whole design on my Behance portfolio.

1. Creating the 3D Plane

Step 1

Open up your 3D application. I am using 3ds Max 2012, but as mentioned before you can use just about any 3D tool.

Step 2

I use Vray as the main rendering engine because it offers realistic lighting and shadows. Make sure you turn on Indirect Illumination, but you could also use Max’s default renderer and achieve similar results.

Apply similar settings as those in the screenshots.

Step 3

Now it’s time to create the background. Go to Create > Under Standard Primitives choose VRayPlane. A plane will appear as in the screenshot below. Just drag it to the side, it doesn’t really matter where.

The VRayPlane will be the background of your scene.

Step 4

Alright, let’s create the actual plane where your design will sit. Again, go to Create > Standard Primitives > Box. Under “parameters”, enter the dimensions as stated below (this is the screensize for an iPhone 5).

Obviously, you can enter any dimensions you like as long as your design adheres to the same proportions.

Now we have to apply a UV map, so that the design wraps nicely around the corners of the plane. Go to “Modify” in the panel to the right and choose UVW Mapping from the Modifier List. Make sure “Planar” is selected.

Step 5

Time to apply the materials, so open up the Material Editor in the top right corner of the main toolbar. Create two VRay materials, one for your background (the VRay plane) and one for your box you just created. Drag and drop the material onto each object.

Let’s perform a quick render. Click on the Render Production (the teapot icon)…

Kinda gray and naked, but it’s a good start.

Step 6

Good job, time to put on a nice dress. We need to apply our actual mockup image as a material to the 3D object. Open up the material editor and click on the material that you assigned to the box.

Scroll down until you see the Maps rollout, then click on Diffuse > Maps > Standard > Bitmap and navigate to the folder where you have saved your design.

Note: My file was a .png with dimensions of 1136 x 640 pixels.

You will now see your file wrapped around the sphere in the material slot. Click on the checkered icon and you will see the design wrapped around your box in perspective view. Don’t forget to set the blur value to 0.01 to get a crisp render of your image.

Hit Render…

Voila! The design wraps nicely around your box. Go ahead and save this file as a png or tif. Time to change the background color and spice things up..

Step 7

There are two ways to change the background color. Either you can change the color of the material you assigned to your VRayPlane or you could change the color in Photoshop. I’ll show you how to do this in Photoshop, because it is much easier to change the color without re-rendering your scene.

Let’s move on. Right-click on your VrayPlane and click “Hide Selected”.

We need to hide the backgound so it doesn’t appear in the rendering.

Hit Render and click on the alpha icon as seen below in the screenshot. Save the image as a .png and we are done here.

Time to move on to your best friend, Photoshop.

With the alpha channel we can create a mask and isolate the background.

2. Adjusting Background and Finalizing

Step 1

Take the alpha file you just saved and open it up in Photoshop. Go to Channels and select (CMD+A) the alpha channel on the bottom. Copy it to the clipboard.

Step 2

Open up your rendered image that you previously saved. Again, go to the channels window and paste the alpha channel you just copied. This time we need to select the actual mask, so hold down CMD and click on the mask.

Make sure the mask is selected.

Step 3

Open the layers window. Holding down the CMD key, left click on Add layer mask as seen below. The plane should be nicely isolated from the background.

Removing the background and isolating the plane.

Create a new layer and fill it with any color you like. As long as it looks good. Mkay.

Step 4

Now we are going to add shadows. You could keep the shadow that was in the image but let’s use Photoshop’s shadows this time. CMD+click on your mask again and create a new layer. Fill the selection with a dark color that matches your background. Open Layer Styles and play around with the drop shadow effect until you find something you like.

Make sure the angle of the shadows looks right.

Good job, we’re done! A more pleasing way to look at a 2D design, don’t you think?

This is what you could end up with:

Congratulations! You’re Done

In this tutorial, we’ve walked through how to take a 2D design and transform it into a 3D mockup with perspective. I’m guessing that many of you were a bit intimidated by the whole 3D thing, but it really is quite basic once you get the hang of it.

Some interesting next steps would be to try experimenting with different plane sizes, using different camera angles and also changing the camera lens to achieve a distortion of the perspective. You can see the whole design on my Behance portfolio, and also check out TriplAgent mobile app. Thanks for following along!

Quick Tip: Remember to Style Your ALT Text

Nicole Merlin — Mon, 10 Jun 2013 18:15:13 +0000

The alt attribute within an <img> tag provides alternative content for users who can’t download images, or who have images turned off altogether. We use this attribute all the time to make our content more accessible, but have you ever considered what it actually looks like?

We’re going to use the email template we built in a previous tutorial as an example, but the principles apply just as well to browser-based web design.

<img src="images/h1.gif" alt="Creating Email Magic" width="300" height="230" style="display: block;" />

If we take a look at our file with images turned off, this is what it looks like:

Clearly the ALT text is unattractive — especially the links. We can do a few things to jazz it up.

For the main heading, we’re going to make the text much larger and change it to our dark blue instead of black. We do this by adding styles to the parent element (in this case a cell). These styles will then be applied to the alt tags within that cell.

This is our cell:

<td align="center" bgcolor="#70bbd9" style="padding: 40px 0 30px 0;">
 <img src="images/h1.gif" alt="Creating Email Magic" width="300" height="230" style="display: block;" />
</td>

We’ll add some text styling so it looks like this:

<td align="center" bgcolor="#70bbd9" style="padding: 40px 0 30px 0; color: #153643; font-size: 28px; font-weight: bold; font-family: Arial, sans-serif;">
 <img src="images/h1.gif" alt="Creating Email Magic" width="300" height="230" style="display: block;" />
</td>

And we’ll style our social media links so that they become white:

<table border="0" cellpadding="0" cellspacing="0">
 <tr>
  <td style="font-family: Arial, sans-serif; font-size: 12px; font-weight: bold;">
   <a href="http://www.twitter.com/" style="color: #ffffff;">
    <img src="images/tw.gif" alt="Twitter" width="38" height="38" style="display: block;" border="0" />
   </a>
  </td>
  <td style="font-size: 0; line-height: 0;" width="20">&nbsp;</td>
  <td style="font-family: Arial, sans-serif; font-size: 12px; font-weight: bold;">
   <a href="http://www.twitter.com/" style="color: #ffffff;">
    <img src="images/fb.gif" alt="Facebook" width="38" height="38" style="display: block;" border="0" />
   </a>
  </td>
 </tr>
</table>

Simple as that! Now we can be confident that our email will display well, even with images turned off.

Build an HTML Email Template From Scratch

Nicole Merlin — Mon, 10 Jun 2013 11:40:23 +0000

The best way to understand any process is to carry it out yourself, from the ground up. Today, we’re going to do just that with email design, by building an HTML email template from scratch.

Kick Things Off

To begin with, it’s worth mentioning where I pulled some of the resources from.

The lovely 2D icons are by Pierre Borodin on Dribbble
The typefaces used are Oil Can, Source Sans Pro and Mission Script
The social media icons are from Metrize Icons

Now, as we discussed in the previous tutorial, you’ll need to begin your HTML email document with an XHTML doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Demystifying Email Design</title>
  <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
</head>
</html>

With that sorted, we can commence building the rest of the structure.

Creating the Body and Main Table

First, we’ll add an overall structure for our email, starting with a <body> tag. We’ll set the margin and padding on the body tag to zero to avoid any unexpected space.

We’ll also add a table with a width of 100%. This acts as a true body tag for our email, because styling of the body tag isn’t fully supported. If you wanted to add a background color to the ‘body’ of your email, you’d need to apply it to this big table instead.

Set your cellpadding and cellspacing to zero to avoid any unexpected space in the table.

Note: We’re going to leave border="1" on all of our tables, so that we can see the skeleton of our layout as we go. We’ll remove them at the end with a simple Find & Replace.

<body style="margin: 0; padding: 0;">
 <table border="1" cellpadding="0" cellspacing="0" width="100%">
  <tr>
   <td>
    Hello!
   </td>
  </tr>
 </table>
</body>

If an attribute exists in HTML, use that instead of CSS

Now place a centered table of 600 pixels wide inside the container table. 600 pixels is a safe maximum width for your emails to display comfortably within most desktop and webmail clients on most screen resolutions.

Set this width using HTML instead of CSS, by using the width attribute. The golden rule in HTML email development is: if an attribute exists in HTML, use that instead of CSS.

We’ll replace our little ‘Hello!’ greeting with this table:

<table align="center" border="1" cellpadding="0" cellspacing="0" width="600" style="border-collapse: collapse;">
 <tr>
  <td>
   Hello!
  </td>
 </tr>
</table>

We’ve also added an inline style property that sets the border-collapse property to collapse. If we don’t do this, newer versions of Outlook will add a small space between our table and our border.

Creating the Structure and Header

In our design we can see that the email is divided into three logical sections, so we’ll create a row for each.

Let’s duplicate the single row we already made so that we have three in total. I’ve changed the text inside them so that we can easily identify each row.

<table align="center" border="1" cellpadding="0" cellspacing="0" width="600">
 <tr>
  <td>
   Row 1
  </td>
 </tr>
 <tr>
  <td>
   Row 2
  </td>
 </tr>
 <tr>
  <td>
   Row 3
  </td>
 </tr>
</table>

Now we’ll color them according to the design. As bgcolor is a valid HTML attribute, we’ll use that to set the background color instead of CSS. Always remember to use the full six characters of a hex code, as three character shorthand won’t always work.

<table align="center" border="1" cellpadding="0" cellspacing="0" width="600">
 <tr>
  <td bgcolor="#70bbd9">
   Row 1
  </td>
 </tr>
 <tr>
  <td bgcolor="#ffffff">
   Row 2
  </td>
 </tr>
 <tr>
  <td bgcolor="#ee4c50">
   Row 3
  </td>
 </tr>
</table>

Ok, next up we are going to focus on Row 1. We want to adjust the padding on the cell and then insert our image.

Using Padding

When using padding in email, you must always specify every single value (top, right, bottom and left) otherwise you can get unpredictable results. I find that you can still use the shorthand, i.e. padding: 10px 10px 8px 5px;, but if you are having trouble you may wish to write it out longform, i.e. padding-top: 10px; padding-right: 10px; padding-bottom: 8px; padding-left: 5px;.

If you are having even greater troubles with padding (for example, if your send platform is stripping out your CSS), don’t use it at all. Simply use empty cells to create space. There is no need to use spacer GIFs, just make sure you add style="line-height: 0; font-size: 0;" to the cell, place an   inside and give it an explicit height or width. Here is an example:

<tr><td style="font-size: 0; line-height: 0;" height="10">&nbsp;</td></tr>

Also note that it’s safe to use padding on TD tags but not on P tags or DIVs. They behave a lot more unpredictably.

So, we’ll use some inline CSS to add padding to the cell. Then we’ll insert our image, adding alt text and adding style="display:block;" which is a common fix that stops some email clients adding gaps underneath your images. We’ll center the image by adding align="center" to our td tag. We’ll also add an alt tag which is important for when our email is initially loaded which, in most cases, will be with images off.

Note: If the contents of your header are really important to your message, don’t use an image-only header. Remember, images are blocked by default for most clients, so if there is an aspect of your email that is crucial, never include it as an image. In this example, however, my header is pretty superfluous.

<td align="center" bgcolor="#70bbd9" style="padding: 40px 0 30px 0;">
 <img src="images/h1.gif" alt="Creating Email Magic" width="300" height="230" style="display: block;" />
</td>

Creating the Content Area

First off, we’ll add some padding to the middle cell so that the table inside has some space around it, as per our design.

Now we’ll add a table with three rows for our main content — one for the headline, one for the introductory text, and one for the row with two columns. We’ll set the width of this table to 100% rather than using a pixel value because this will help us further down the track if we want to make our email responsive. If you always have pixel widths on everything, you can end up with a lot of values to override with media queries. If your nested table widths are based on percentages, then when you adjust the width of the parent element, everything will adapt accordingly.

<td bgcolor="#ffffff" style="padding: 40px 30px 40px 30px;">
 <table border="1" cellpadding="0" cellspacing="0" width="100%">
  <tr>
   <td>
    Row 1
   </td>
  </tr>
  <tr>
   <td>
    Row 2
   </td>
  </tr>
  <tr>
   <td>
    Row 3
   </td>
  </tr>
 </table>
</td>

Now we’ll add in our content, and add some padding to the middle cell.

<table border="1" cellpadding="0" cellspacing="0" width="100%">
 <tr>
  <td>
   Lorem ipsum dolor sit amet!
  </td>
 </tr>
 <tr>
  <td style="padding: 20px 0 30px 0;">
   Lorem ipsum dolor sit amet, consectetur adipiscing elit. In tempus adipiscing felis, sit amet blandit ipsum volutpat sed. Morbi porttitor, eget accumsan dictum, nisi libero ultricies ipsum, in posuere mauris neque at erat.
  </td>
 </tr>
 <tr>
  <td>
   Row 3
  </td>
 </tr>
</table>

Now we are going to add our two columns of content to Row 3. Because we want a ‘margin’ in between these two cells, but margin isn’t supported, we’ll create a three-column table with an empty cell between the two outer columns.

As much as I like to stick to percentages, when you have content that is a specific size, it can be tricky to convert it to a percentage (in this example, the columns would be 48.1% which could become confusing). For this reason, since our two images are 260px wide, we’ll create columns that are also 260px wide, with a 20px margin cell in the middle. (This will total 540px, which is the 600px width of our table minus the padding of 30px on either side.) Be sure to zero your font-size and line-height and add a a non-breaking space character   in the margin cell.

We’ll also set the valign to "top" for both cells so that they will vertically align to the top, even if one column has more text than the other. The default vertical alignment is "middle".

<table border="1" cellpadding="0" cellspacing="0" width="100%">
 <tr>
  <td width="260" valign="top">
   Column 1
  </td>
  <td style="font-size: 0; line-height: 0;" width="20">
   &nbsp;
  </td>
  <td width="260" valign="top">
   Column 2
  </td>
 </tr>
</table>

Now let’s add our images and content to those columns. As we need multiple rows, we’ll nest yet another table because we can’t use any colspan or rowspan tags. We’ll also add some padding in between the image and copy in each column.

<table border="1" cellpadding="0" cellspacing="0" width="100%">
 <tr>
  <td width="260" valign="top">
   <table border="1" cellpadding="0" cellspacing="0" width="100%">
    <tr>
     <td>
      <img src="images/left.gif" alt="" width="100%" height="140" style="display: block;" />
     </td>
    </tr>
    <tr>
     <td style="padding: 25px 0 0 0;">
      Lorem ipsum dolor sit amet, consectetur adipiscing elit. In tempus adipiscing felis, sit amet blandit ipsum volutpat sed. Morbi porttitor, eget accumsan dictum, nisi libero ultricies ipsum, in posuere mauris neque at erat.
     </td>
    </tr>
   </table>
  </td>
  <td style="font-size: 0; line-height: 0;" width="20">
   &nbsp;
  </td>
  <td width="260" valign="top">
   <table border="1" cellpadding="0" cellspacing="0" width="100%">
    <tr>
     <td>
      <img src="images/right.gif" alt="" width="100%" height="140" style="display: block;" />
     </td>
    </tr>
    <tr>
     <td style="padding: 25px 0 0 0;">
      Lorem ipsum dolor sit amet, consectetur adipiscing elit. In tempus adipiscing felis, sit amet blandit ipsum volutpat sed. Morbi porttitor, eget accumsan dictum, nisi libero ultricies ipsum, in posuere mauris neque at erat.
     </td>
    </tr>
   </table>
  </td>
 </tr>
</table>

Here we have set the width of the images using HTML at 100% of the column width. This, again, is so that if we make this email responsive, we only have to use media queries to change the width of the parent element. We’ll have to override the height in pixels because using style="height: auto" now won’t work in everything (cough cough, Outlook). So we’ll set it using pixels. This means we’d have to set height: auto!important on those images using media queries to override the pixel value, but we could do that with a single class. As we set the width as a percentage, we won’t need to override that. The fewer things to override, the better.

The Footer

Now we’ll add our padding to the footer row.

<td bgcolor="#ee4c50" style="padding: 30px 30px 30px 30px;">
 Row 3
</td>

Inside that cell, we’ll nest another table to get our two columns.

<table border="1" cellpadding="0" cellspacing="0" width="100%">
 <tr>
  <td>
   Column 1
  </td>
  <td>
   Column 2
  </td>
 </tr>
</table>

We’ll create another little table for our social media icons. We’ll set its parent cell to align="right". Make sure you set border="0" on these image links (to avoid a blue link border) and don’t forget display:block.

<td align="right">
 <table border="0" cellpadding="0" cellspacing="0">
  <tr>
   <td>
    <a href="http://www.twitter.com/">
     <img src="images/tw.gif" alt="Twitter" width="38" height="38" style="display: block;" border="0" />
    </a>
   </td>
   <td style="font-size: 0; line-height: 0;" width="20">&nbsp;</td>
   <td>
    <a href="http://www.twitter.com/">
     <img src="images/fb.gif" alt="Facebook" width="38" height="38" style="display: block;" border="0" />
    </a>
   </td>
  </tr>
 </table>
</td>

Now we’ll add our text and add a width to our cells, just to be safe, even though there is a lot of whitespace between them. We’ll set this cell to 75% and the other to 25%.

<td width="75%">
 &reg; Someone, somewhere 2013<br/>
 Unsubscribe to this newsletter instantly
</td>

And there we have it! Our layout is complete.

Validation

Let’s run this through the W3C Validator to make sure nothing is bad or broken. If you’ve followed along exactly, it will say that it has passed.

Next we’re going to run a test through Litmus to make sure the structure of our email works great. Here’s a summary of my test:

Take a look online

Styling our Text

Our first row is the heading. We’ll use the <b> tag to create bold text because, as we already know, if it exists in HTML, we use that instead of CSS.

<td style="color: #153643; font-family: Arial, sans-serif; font-size: 24px;">
 <b>Lorem ipsum dolor sit amet!</b>
</td>

We’ll also add this inline style to all the other cells of text:

style="color: #153643; font-family: Arial, sans-serif; font-size: 16px; line-height: 20px;"

Next we need to style the footer text, and we’ll also tidy up our unsubscribe link. We’ll style our unsubscribe text link using both CSS and the HTML <font> tag. This doubling up is the best way to ensure that your links never show up in the default blue.

<td style="color: #ffffff; font-family: Arial, sans-serif; font-size: 14px;">
 &reg; Someone, somewhere 2013<br/>
 <a href="#" style="color: #ffffff;"><font color="#ffffff">Unsubscribe</font></a> to this newsletter instantly
</td>

And there we have it! Everything is in. Time to turn off the borders and see it looking beautiful. Go through and replace every occurance of border="1" with border="0".

At this point, it’s looking a little sad floating in white space, so let’s go up to our first 600px wide table and add:

style="border: 1px solid #cccccc;"

Now it doesn’t look like it’s floating anymore. As a final touch, I’m going to add 30px of padding to the bottom of the very first cell, to prevent our email from stopping abruptly at the bottom in some webmail clients (like Apple Mail), and 10px of padding at the top, so that our blue header has a little bit of breathing room.

<td style="padding: 20px 0 30px 0;">

And that’s it! You’re all ready for a final test.

Take a look online

That’s a Wrap!

Before we call it a day, if you have used any comments, get rid of them. Some email clients can choke on comments so it’s wisest not to have any unnecessary code anywhere in your files.

Now is a good time to do a final test, and then, your HTML email is ready to send!

What You Should Know About HTML Email

Nicole Merlin — Mon, 10 Jun 2013 08:50:23 +0000

Email is an awesome medium. It goes straight into the inbox and its ROI is widely reported as being through the roof at 4000%. It’s also perpetually misunderstood and too often it’s done badly. With the recent explosion of smartphones, we’re more often reading our mail on our iPhone or Galaxy, but unfortunately a lot of email marketing has failed to keep up. I see this as a huge missed opportunity because a well executed email can be enjoyable to open and hugely successful.

Coding HTML Email Can be a Challenge

If you’ve already tried your hand at HTML email design and development, you’ve probably already established that it can be pretty difficult. And you’re not imagining it — it is quite hard. Here’s why:

Email Standards Don’t Exist

[We will] continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around.

The Outlook Team

When you code for the web, you can at least count on the fact that all of the major browsers (Chrome, Firefox, Internet Explorer, Safari and Opera) are trying to adhere to web standards for rendering HTML and CSS.

When it comes to email clients, you’re testing on a huge bunch of old and new programs. They range from new phones running on Android and iOS to IBM’s Lotus Notes or Microsoft Office 2007 (which infamously renders your lovingly-created HTML with the Word HTML rendering engine. The previous versions of Outlook used a browser to render their HTML — which is actually logical. Why switch to a word processor to render HTML you ask? Well, for “security reasons“, they say). And none of these programs have to adhere to any standards. They basically all just make it up. You can see what standards support looks like for some of the most popular email clients at the Email Standards Project.

If that isn’t bad enough, couple that with the next fact: there are about a million different combinations of ways that email can render on desktop and mobile.

The rendering possibilities are (almost) endless.

Here’s a list of some of the most common email clients:

Mobile clients:

Android 2.3 & 4.0
iPhone 5 iOS 6
iPhone 4S iOS 6
iPhone 3GS iOS 5
iPad 2 iOS 6
BlackBerry OS 4 & 5
Symbian S60
Windows Phone 7.5

Desktop clients:

Apple Mail 4, 5, 6
Lotus Notes 8.5
Lotus Notes 8
Thunderbird
Windows Live Mail
Outlook 2013
Outlook 2011 for Mac
Outlook 2010
Outlook 2007
Outlook 2003
Outlook 2002/XP
Outlook 2000

Webmail clients:

AOL Mail (on any browser)
Gmail (on any browser)
Outlook.com (on any browser)
Yahoo! (on any browser)

That’s a lot of devices!

If you are already familiar with web development, forget everything you know about it.

To compound all of this, conditional styling isn’t much of an option either. There are some things that you can do with conditional comments, but it’s limited to targeting certain versions of Outlook, or everything except certain versions of Outlook.

If you are already familiar with web development, forget everything you know about it. The single biggest obstacle to you is expecting things to work like ‘normal’ web development. This will frustrate you and hold you back. The worst thing you can do is get angry that you can’t use DIVs or that margin isn’t fully supported. So forget everything you know about semantic HTML and the latest CSS spec. Trust me, it will help.

How to Approach Your Work

Let’s take a look at some email-building workflow suggestions.

Work Structurally First

Building the structure of your email first can help you avoid many bugs and issues later down the track. Never build the whole thing and then test — you can often end up with too many bugs to deal with, and they may all be influencing each other.

Test Often

Work until you reach a minor development milestone (for example, when you finish the basic structure) and then run a test. The best way to test is using Litmus or Email on Acid. I recommend taking out an unlimited plan with either of these companies because being able to test frequently is really important.

I also really like leaving in all my table borders so that I can see what I am creating, then I turn them all off at the end. You can also perhaps color the background of certain cells to help see which sections are where. My ideal workflow is to create a skeleton, test, then add my content, test, style the colors and fonts, test again and finally remove my borders and test again before sending.

Validate Often

Validate it using the W3C Validator as often as you possibly can. This will help you iron out small details and it will pick up on mistakes like missing or open tags.

Sending Your Email

There are a huge number of options when it comes to sending your email. The two services that I use the most are MailChimp and Campaign Monitor. They offer competitive pricing and they are very easy to use. There are loads of commercial platforms, too — it all depends on your needs. Sign up for a free account with either of these and have a tinker in their systems to see which one you like. Make sure you utilize the useful data that both services collect about your emails, such as open times and email client usage. This can really help you focus your efforts in the right area the next time you send.

Content, Development and SPAM Scores

When it comes to SPAM; content, design and development all go hand in hand. It’s important to avoid typical spammy tactics like using all-caps and lots of exclamation points in your subject line. There are certain words that are likely to trigger SPAM filters too (like ‘free’ and ‘invest’). The cleaner your code, the less likely your email is to be marked as SPAM, and the ratio of images to text also has an effect. Image-reliant emails with no text are more likely to be marked as SPAM and so are emails with really long image filenames.

The world of SPAM scores is a tricky one and it’s important to run a SPAM test through your testing account with Litmus or Email on Acid before you send your email, to make sure all your hard work isn’t headed straight for the Junk folder.

Diving into Development

Now, for the nitty-gritty of email development..

Tools of the Trade

You’ll need a text editor that you like (I use Sublime Text) and a test account with Litmus or Email on Acid. I highly recommend having an unlimited test account with either of these companies as it will make your life so much easier. If you don’t pay a monthly fee, you will end up paying between $3 and $5 per test which can add up pretty quickly.

Starting With a Good Base

I think that it’s good to start with a blank slate. Frameworks like the HTML Email Boilerplate are full of wonderful tricks and snippets that you can implement piece by piece. However, if you are just starting out I don’t recommend using it as a starting point as it contains a lot of elements that you won’t need. Boilerplates can often make it more difficult to troubleshoot any issues if there is a lot of unused code in your file.

Note: Because it can be very precarious to use any kind of editor (especially when it’s time to troubleshoot), you should never use a WYSIWYG editor, or any kind of editor that promises to take your formatted design and magically turn it into valid HTML for emailing. This stuff just never works.

!DOCTYPE

This might seem like a technical detail to start with, but you need a blank template to start working with, and that template needs a Doctype. A doctype is essentially a line of code which informs the program reading it which HTML tags to expect and which set of rules the HTML and CSS adhere to. Quite a few clients strip your Doctype out, and some even apply their own. Many clients do honor your doctype and it can make things much easier if you can validate constantly against a Doctype.

Using an XHTML doctype generally has the fewest quirks and inconsistencies between documents. I use XHTML 1.0 Transitional because it has proven itself to be the most reliable doctype in my experience. In the following tutorial, during which we’ll build a complete HTML email template, we’ll use the following code to start off our document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Demystifying Email Design</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
</head>

The Content-Type meta tag is for telling the destination rendering engine how to process text and special characters. In reality, you need to encode all of your special characters anyway (e.g., & becomes & for ampersand) to be safe, but it’s worth keeping this line in there anyway.

The viewport meta tag is telling the device to set the viewable area to the width of the device’s screen. It also sets the initial scale to ‘normal’ which is neither zoomed in nor out. If you don’t specify this, many smartphones may scale your content down so that the content fits within the viewable area, but not any of its padding or margins. This can result in text and images butting right up against the edge of the screen.

Finally, always enter a meaningful title because this is what people will see when they view the email in a browser, or share it with their friends.

Email is All About Nesting Tables

Due to the lack of standards support in email, it’s not possible to use divs, sections or articles — instead you have to use tables. Moreover, you need to use lots and lots of nested tables because neither the colspan nor rowspan attributes are properly supported.

Paragraphs or Cells?

Again, because of the lack of standards support, it’s not a great idea to use standard tags like h1, h2, h3 or p. I find that these can render really inconsistently across email clients and can create some pretty big headaches.

Your best bet is to place every block of text into its own cell and apply inline styling to that cell, for example:

<tr>
 <td style=“font-size: 12px; font-family: Arial, sans-serif; color: #666666;”>
   Text
 </td>
</tr>

Inline Styles or Stylesheets?

This one is more of a personal choice. I prefer to keep all my styles inline (ie: within the HTML tags themselves) because I like to know exactly where everything is and what is affecting what. You can code using styles and then pull them all inline at the end (Campaign Monitor and MailChimp can do this for you automatically, you can also use Premailer or something similar) but the reason I don’t like this is because you get to know your code, run it through an inliner, and then your code can become somewhat unrecognizable. I find that this makes it more difficult to troubleshoot. Saying that, if this is the way you want to work, that’s fine; there is no technical reason why you shouldn’t do it.

Don’t forget: You can’t apply multiple classes to things in HTML email because it is not supported. Every element can have a maximum of one class.

Also don’t forget: You can’t use shorthand for things like font size (i.e. style=”font: 8px/14px Arial, sans-serif;”) because it is not supported.

Image Names and SPAM Scores

When saving out images remember that it’s good to give your images names that are short and meaningful because it will improve your spam score. Names like “campaign_054_design_0x0_v6_email-link.gif” are likely to have a much higher SPAM score than “email.gif”.

Image Size

It’s also a really great idea to try to keep your entire email as small as humanly possible: under 100kb is ideal but not always possible, under 250kb is pretty standard. Use a compression app like JPEGmini or tinyPNG to cut all your images down to size as much as possible before you send. Slower load times, especially on mobile, can make or break your email if the overall file size is too large.

Other Gotchas

Don’t leave anything up to the email client. Specify all your widths, because otherwise you could end up with unexpected results. For your main container elements always set the size in pixels. You can then use percentages inside your containing element if you wish.

Conclusion

There’s a lot to take into account when designing and developing HTML email, most of which involves “un-learning” standards you’ve been encouraged to practice for web design over the years. However, this tutorial should have given you a solid base to work from, and you’re now ready to jump into the actual build process. Onwards!

Useful Links

I referenced a few things during this tutorial – so here they are again, all in one place.

Litmus testing tools
Email on Acid testing tools
The Outlook Team Blog
The Litmus Team Blog
The Email Standards Project
W3C Validator
MailChimp
Campaign Monitor
Premailer, preflight check for emails
JPEGmini image compression tool
tinyPNG image compression tool
Sublime Text, my preferred editor
Say Hello to the HTML Email Boilerplate
Don’t Forget the Viewport Meta Tag
Thumbnail icon by Pierre Borodin

Foundation for Beginners: Navigation

Matt Pilott — Fri, 07 Jun 2013 11:17:37 +0000

One of the most important aspects of a front-end framework is how it handles navigation. In this part of Foundation for Beginners, we’ll take a look at several forms of navigation, along with some JavaScript tools which add extra flourish. I’ll also introduce you to another helpful tool which will help you to become a better Foundation developer.

The Section Plugin

One of Foundation’s best JavaScript offerings comes in the form of Section; a plugin for building several forms of navigation, such as accordions, tabs, vertical and horizontal navigation.

Here’s some example markup:

<div class="section-container auto" data-section>
  <section>
    <p class="title" data-section-title><a href="#">Section 1</a></p>
    <div class="content" data-section-content>
      <p>Content of section 1.</p>
    </div>
  </section>
  <section>
    <p class="title" data-section-title><a href="#">Section 2</a></p>
    <div class="content" data-section-content>
      <p>Content of section 2.</p>
    </div>
  </section>
</div>

This may look a bit more complex than what we’ve previously covered, so let me break it down for you.

Any section you create, no matter whether it’s an accordion, or tabs, or even a nav bar, starts with a div using the section-container class followed by the auto class. On that same div add an empty data-section attribute. This attribute dictates what kind of section we’re dealing with, by default Foundation assumes we want an accordion. To use a particular type of section, simply change the auto class to tabs, accordion, vertical-nav or horizontal-nav. Finally, add that very same class as the data-section attribute’s value. This will ensure you are displaying the correct type of section for your needs.

Once the wrapper has been setup, we can add some content. For every section in your wrapper you will need a title and to link that title to the content:

<section>
    <p class="title" data-section-title><a href="#panel1">Section 1</a></p>
    <div class="content" data-section-content>
      <p>Content of section 1.</p>
    </div>
</section>

We can see here that each section is wrapped in a <section> tag (which makes things easy, although you could use a div). Inside each of these sections we have a <p> tag with a class of title which encloses the link to the corresponding section. Below the paragraph tag is the div which holds the content for the section; this has a class of content. Duplicating the code above will create each of your sections inside your section wrapper.

Note: Adding the vertical-nav class will display a vertical navigation on large screens, but will switch to an accordion when on small screens. Adding horizontal-nav will evoke the same behavior.

Deep Linking

Let’s say you want to link to the second section of your section wrapper, but when you open the page it shows the first section by default. Fear not! Foundation has a built in solution in the form of Deep Linking. To get this to work we need to add a new attribute to our wrapper: data-options=”deep_linking:true”. This tells Foundation that when a user visits a url with a fragment identifier such as this “http://www.website.com/#section3”, it should load the page with that section showing.

<div class="section-container auto" data-section data-options="deep_linking: true">
  <section>
    <p class="title" data-section-title><a href="#section1">Section 1</a></p>
    <div class="content" data-slug="section1" data-section-content>
      <p>Content of section 1.</p>
    </div>
  </section>
  <section>
    <p class="title" data-section-title><a href="#section2">Section 2</a></p>
    <div class="content" data-slug="section2" data-section-content>
      <p>Content of section 2.</p>
    </div>
  </section>
</div>

As you can see, we have added the deep linking data option and also added the data-slug attribute to the content div. This data slug instructs Foundation which section to display on page load.

Side Nav

Foundation’s Side Nav (a simple way to display vertical menus) goes hand in hand with sections. The HTML structure is very simple and allows for dividers where necessary. Let’s look at the markup.

<ul class="side-nav">
  <li class="active"><a href="#">Link 1</a></li>
  <li><a href="#">Link 2</a></li>
  <li class="divider"></li>
  <li><a href="#">Link 3</a></li>
  <li><a href="#">Link 4</a></li>
</ul>

This is a standard unordered list, comprising list items containing links to.. well whatever you want. Adding the side-nav class to the <ul> sets everything up, whilst the active class can be used to show which link is currently in use. If you need to divide up your list items, add an empty list item with a class of divider. Easy.

Sub Nav

Foundation’s Sub Nav tends to be used for things such as filtering content. The markup is as straight-forward as Side Nav, but differs in that it uses a description list instead of an unordered list. This gives you the option of using a term along with your description tags which hold your links. There are no dividers in the Sub Nav but you can still make use of the active class. Here’s the markup:

<dl class="sub-nav">
  <dt>Filter:</dt>
  <dd class="active"><a href="#">All</a></dd>
  <dd><a href="#">Photos</a></dd>
  <dd><a href="#">Videos</a></dd>
  <dd><a href="#">Music</a></dd>
</dl>

Pagination

Pagination is also a form of navigation; in fact, pagination should really be contained within a <nav> element. Let’s have a look at the markup of some pagination links in Foundation:

<ul class="pagination">
  <li class="arrow unavailable"><a href="">&laquo;</a></li>
  <li class="current"><a href="">1</a></li>
  <li><a href="">2</a></li>
  <li><a href="">3</a></li>
  <li><a href="">4</a></li>
  <li class="unavailable"><a href="">&hellip;</a></li>
  <li><a href="">12</a></li>
  <li><a href="">13</a></li>
  <li class="arrow"><a href="">&raquo;</a></li>
</ul>

Kicking your list items off should be an arrow, which requires the class arrow. You may want to use either « or &lsaquo; or maybe even ←. Take a look at unicode-table.com for more examples you could use.

The Pagination navigation type allows us to state classes unavailable and current, with the latter being very similar to the active class that we went over previously. You may also want to add an arrow to your last list item, this time using either » or &rsaquo;, or maybe even →.

As this is simple markup adding it to a content management system such as WordPress is fairly easy.

Bonus: You could center the Pagination by wrapping the ul tag in a nav with the pagination-centered class. As with all Foundation elements, pagination is responsive and easy to style.

Useful Tool

Using a responsive framework such as Foundation is a rapid way to get your project looking great on all devices, but testing is still a chore. To ease that pain I’ve create a tool called Respondr, allowing you to add a url to a smartphone, tablet and desktop giving you the chance to catch any issues quickly and easily.

Coming up Next

So far we’ve covered the grid system, block grids, the Orbit slider plugin, the section plugin and three types of navigation. Next time we’ll focus on the Top Bar plugin, breadcrumbs and yet another useful tool.

Foundation for Beginners: The Grid System

Matt Pilott — Wed, 05 Jun 2013 19:33:41 +0000

In the opening part of this session on the Foundation Framework, we took a look at how you could make use of this framework, what it can do and how you can fashion a custom build. In this part we’ll look in detail at the grid system, demonstrating some examples as we go. We’ll also shake things up a bit and take a look at the Orbit JavaScript Slider plugin; a great slider for displaying all sorts of content.

The Grid System

We only use one major breakpoint for the grid in Foundation to shift layouts for screens above 768px wide.

Foundation is a modern framework favoring the mobile first approach. This means that the bare minimum code and assets are loaded first to aid page render speed. As with most modern frameworks, Foundation is fully responsive. Unlike most, it makes use of just one break point for structural change. The break point defines the viewport width at which the large grid is put into action, this happens at 768px.

The grid system itself actually has three parts; the desktop grid, the mobile grid and the block grid. As foundation is mobile first, let’s begin with the mobile grid.

The Small Grid

<div class="row">
	<div class="small-12 columns">
		<h2>This is Foundation</h2>
	</div>
</div>

The code above is built up of three important classes; the first being the “row” class which holds our columns, much in the same way as a row in a spreadsheet holds columns of cells. In this demo we’re using a twelve column grid, so twelve is the maximum number of columns we can have within one row. Saying that, if you need more, Foundation supports up to sixteen columns which you can select in the custom build form.

The class that defines the columns here is small-12, changing the number in this class defines the width of said column. Using “small-12” on its own however only defines the width. In order to actually create a column, we need to pair it with the “columns” class. These three classes are the basis for the grid system.

Quite simply, the above markup dictates that there’s a row, with a div which is going to take up twelve columns worth of space (100% of the width). Inside the twelve columns is our content. Let’s take a look at a slightly more complex version.

<div class="row">
	<div class="small-4 columns">
		<h2>This is a sidebar</h2>
	</div>
	<div class="small-8 columns">
		<h2>This is the content area</h2>
	</div>
</div>

In this code we can see that there are two divs with the “columns” class. Each is coupled with a class (such as “small-4”) to dictate the specific size. Foundation then lines these columns up next to each other as opposed to on top of each other, as they would in normal HTML document flow. Our two columns occupy four columns’ width and eight columns respectively. The two total a full widht of twelve columns; “small-4” being around 33.3% and “small-8” being approximately 66.6% of the body width.

What’s important to realize here is that these divs are almost infinitely nestable. This offers great flexibility, for instance:

<div class="row">
	<div class="small-4 columns">
		<h2>This is a sidebar</h2>
		<div class="row">
			<div class="small-1 columns">
				<h6>#1</h6>
			</div>
			<div class="small-9 columns">
				<p>A post title</p>
			</div>
			<div class="small-2 columns">
				<button>Go</button>
			</div>
		</div>
	</div>
	<div class="small-8 columns">
		<h2>This is the content area</h2>
	</div>
</div>

You can see that we have added in some content to the sidebar using a row, in a column, in a row, this time making use of three columns of varying sizes. Great stuff eh? Well it’s probably time to throw in some big-screen code to take full advantage of the grid system.

The Large Grid

<div class="row">
	<div class="small-4 large-3 columns">
		<h2>This is a sidebar</h2>
	</div>
	<div class="small-8 large-9 columns">
		<h2>This is the content area</h2>
	</div>
</div>

Here we have added one extra class to each of our columns large-3 and large-9. This tells Foundation that when the site is viewed on a larger screen it should change the width of the sidebar from the small-4 with of 33.3% to large-3 which equates to around 25% of the body width. Our main area is thus able to grow, giving more room for content. This is a simplistic example but becomes very useful when it comes to re-arranging your layout for different screen sizes.

Whilst we are looking at the grid system it’s worth mentioning that by using large-centered and small-centered you can center a column quickly and easily, although you can only do this if there is one column in the row. You can also manipulate the order of elements using the push and pull classes.

<div class="row">
	<div class="small-3 push-9 columns">3</div>
	<div class="small-9 pull-3 columns">9, last</div>
</div>

This takes the second div, which would typically be displayed after the first, and pulls it to the front whilst pushing the first to show up afterwards. You can therefore have a list on the left and content on the right on large displays, but push it below on small displays.

The Block Grid

Having covered the ins and outs of the grid systems, we can look at the block grid which is used to keep list elements evenly spaced, no matter what the screen size. These are ideal for blocked-in content (such as that generated by an application) as they don’t require rows or even columns to display correctly. If your layout is intended to be the same on desktop as well as mobile then you only need use the small-block-grid-# classes.

This is also the case for the grids we previously spoke about. Instead of using small-12 and large-12 you would only need small-12. Easy.

<ul class="small-block-grid-2 large-block-grid-4">
	<li><img src="../img/photo1.png"></li>
	<li><img src="../img/photo2.png"></li>
	<li><img src="../img/photo3.png"></li>
	<li><img src="../img/photo4.png"></li>
</ul>

That concludes the grid systems that Foundation has to offer in their basic forms. Remember, the small grid will change to the large grid once the screen width hits the main break point. Use the small grid to target smaller devices and the large for what are typically desktops and larger screens.

The Orbit Plugin

We’re going to shake things up a little now, by introducing one of Foundation’s many useful plugins; Orbit.

This handy plugin can be used as a slider, allowing you to slide in images, video or regular HTML content. With simple markup it’s easy to get to grips with and is a real eye-pleaser when used properly.

<ul data-orbit>
	<li>
		<img src="../img/demos/demo1.jpg" />
		<div class="orbit-caption">...</div>
	</li>
	<li>
		<img src="../img/demos/demo2.jpg" />
		<div class="orbit-caption">...</div>
	</li>
	<li>
		<img src="../img/demos/demo3.jpg" />
		<div class="orbit-caption">...</div>
	</li>
</ul>

Orbit uses a list structure; each list item being displayed as a slide. Here, along with regular image tags, our list items contain a div with the class orbit-caption allowing us to place a caption on each image. Orbit takes this code and adds some more markup to get things working. It also includes a bunch of options for displaying pagination, controls and even a timer.

Take a look at some examples of parameters you can change in Orbit:

  timer_speed: 10000,
  animation_speed: 500,
  bullets: true,
  stack_on_small: true

These include speeds, bullet pagination and the option to stack on small screens. It’s important to note that these are passed on initialization, so you would need to take your standard $(document).foundation();, found at the bottom of the index.html included in the download:

  <script>
    $(document).foundation();
  </script>

then pass in the orbit options.

<script>
$(document).foundation('orbit', {
  timer_speed: 10000,
  animation_speed: 500,
  bullets: true,
  stack_on_small: true
});
</script>

As well as the options shown here you can add classes to all the elements produced by the plugin. These extra options (and more) can be found in the Foundation docs.

Note: Your Foundation download will include all the JavaScript bits and pieces you chose, compiled into one minified file. This is referenced at the bottom of the index.html, but you can also opt to uncomment individual JavaScript files if you prefer:

  <script src="js/foundation.min.js"></script>
  <!--
  <script src="js/foundation/foundation.js"></script>
  <script src="js/foundation/foundation.dropdown.js"></script>
  <script src="js/foundation/foundation.placeholder.js"></script>
  <script src="js/foundation/foundation.forms.js"></script>
  <script src="js/foundation/foundation.orbit.js"></script>
  -->

Useful Tool

Want to play around with Foundation right now without downloading it? Or perhaps you want a clean environment to test new ideas? Then check out this handy jsfiddle. It uses the latest build of Foundation and includes all of the components.

Coming Up Next

In this part of the Foundation guide we covered the grid systems and briefly spoke about the Orbit plugin. In the next installment we’ll look at navigation and the section plugin, along with another useful tool..

Foundation for Beginners: Getting Started

Matt Pilott — Wed, 05 Jun 2013 14:23:02 +0000

For many web folk, developing a project from scratch every time is part of the job; it’s often tricky to build up a reusable codebase when each project is different. More experienced developers may have taken the time to build up some form of front-end framework, but doing this properly can be a serious undertaking, not to mention the need to keep things up–to-date and inline with best practices.

Looking at the wants and needs of the every-coder it’s clear that developers want something that’s open source, stable, flexible and (most importantly) well documented. Depending on the size of the project a CSS grid system maybe enough, but wouldn’t it be great if you had the option to add and remove functionality as you saw fit? Well, in this session we’ll be looking at a customisable front-end framework called Foundation.

Covering a framework like Foundation needs to be done properly and in detail, so over the next few weeks I’ll be covering everything from getting started, custom builds, through to the ins-and-outs of the cogs which power this particular framework. Most importantly I’ll illustrate how it could benefit you in your future web endeavours.

What is Foundation?

Foundation is a front-end framework consisting of many tools useful for making responsive, mobile first websites. Primarily built with HTML, CSS and jQuery, Foundation uses modern technologies and practices, but gracefully degrades as far back as IE8. Although the framework is most commonly used by HTML and CSS developers, you have the option of taking things further using Foundation in conjunction with Sass and Rails.

The company behind Foundation, ZURB, have created a tightly regimented toolset for developers and designers. Every module has its part to play in the framework as a whole, but at the same time can work completely independently of central leadership. What this means then, is that you can mix and match features in your current project, or take a single feature and add it into an older project. You can even add it as a feature to a different framework.

So in summary, this is a modern framework which has been well built and which caters for a wide variety of users. It offers a good set of features, it’s free, and there is a growing community of people to help you out if you do get stuck.

Why Should You Use Foundation?

Nowadays it’s commonplace for developers to make use of frameworks (why reinvent the wheel?) Often though, many of these frameworks have become bloated from the creators trying to cover every eventuality on an adhoc basis. What once may have started life as a slick, lightweight tool, can grow into a hundred http requests and a choir to disassemble depending on your needs.

Foundation includes a range of functions and features. It’s built on a percentage-based fluid grid system, comes packaged with a jQuery slider, a lightbox plugin, has all imaginable HTML elements pleasantly styled and is built with mobile-first in mind. You can create custom forms which use jQuery to re-envision tricky input elements, dropdowns and checkboxes, meaning you can style these easily. The framework also has options for setting out custom mobile layouts by using the mobile grid, giving the flexibility to really personalize your project for mobile and desktop users.

Zurb have rebuilt a lot of core functionality in version 4 to cover fairly wide usage cases. The code appears to have been kept clean and commented where it needs to be. Adding and removing functions is straight-forward and allows tailoring of your build to match your requirements.

Users running version 3 are also able to follow a migration document to upgrade their existing installs, or, if they would like, can continue using version 3 as ZURB host the previous version for those that aren’t ready to make the jump to v4.

Downloading a Custom Build

Zurb have a download page which allows you to tweak a pre-filled form to generate a custom build perfect for your requirements. Let’s say you only want a CSS grid? Done. Just uncheck everything except “grid” and type in your project measurements. Perhaps you want basic UI elements? Done. Once again just check the UI elements you require, such as labels and buttons, and that’s exactly what you’ll get. You can even grab everything they offer (referred to as their kitchen sink) in just one click. It allows for custom default CSS colours and even key sizes such as max-width.

Although this is handy, it’s still just a form and I feel it could be improved upon. Ideally, I’d like to see a staged process with perhaps some visual representation of the HTML template. Also, as v4 uses em as its measurement unit and em is based on the main font-size it would seem intuitive to include a px-to-em calculator, just to make it that little bit easier.

Head on over to http://foundation.zurb.com and click the big download button. You’ll be presented with many options to customize your framework. Uncheck any features you don’t need, put in your primary, secondary, alert, success and font colors. Combine this with breakpoint widths, max widths, gutters and even a choice of how many columns you want.

After looking at the key benefits that Foundation offers and running through the custom build download, you should have a personalized build sitting in your downloads folder. Play around with it, try things out and if you get stuck take a look at the docs or throw your questions into the comment thread below.

Coming up Next

In the next part of this session we’ll be using the grid system, diving into the navigation, tabs, buttons and a few other key UI elements. We’ll also talk about some tools which can further aid your development when using Foundation as a basis for your projects.

Linkage..

Foundation 4
@foundationzurb on Twitter

Become a Better, Faster Front-End Developer

Jonathan Cutrell — Mon, 03 Jun 2013 16:15:11 +0000

So you're a pretty great web developer already.

You've got some killer CSS chops (cross browser even), perhaps you've been a Photoshop expert for years, and you've got enough jQuery knowledge to make almost any chained animation go smoothly.

But certainly you ask yourself, what's next?

In fact, one of the most asked questions about web development is, "how do I stay on the leading edge?" Chris Coyier recently presented a fantastic talk on the subject, and there are sites fully dedicated to staying up to date on the latest web design news. Addy Osmani's roundup on becoming a better front-end engineer sets some great content out on the board for you to consider on the subject; needless to say, a lot of smart people are thinking about this very subject, so you're headed in the right direction.

Space Ghost wallpaper, by Mads Frantzen

In this article, we will talk about a very important way to set yourself apart and become a better developer: becoming an effective rapid interaction developer.

What is "Rapid Interaction Development?"

Rapid interaction development is a term we're using today to describe the practice of rapidly creating something for the web that a user can interact with, specifically with an intention to quickly iterate and polish the interaction. This is not the same thing as designing flat documents; instead, this includes building something that has one or more storylines of interaction.

This may include, for instance, a widget that the user can type into and search, or a dropdown menu that allows a user to select a sub-menu item. These interactive pieces are the building blocks of a larger storyline of the user's full experience of using a website, and thus they are incredibly important to be able to iterate through and "feel". When designing a website, these interactions can make or break the user's experience, and thus could make or break the effectiveness of the site as a whole.

Interactions don't always have "moving" pieces; in fact, rapid interaction development often relies on content hierarchies and hyperlinks as much as anything else. Interaction development takes into account the full interaction of the human with the computer, incorporating intuitions about the userbase, basic understanding of human factors, and a knowledge of the message and image of the organization or individual represented by the interaction.

Understanding the Value of Rapid Interaction Development

If I am hiring a front-end web developer (or anyone for that matter), I will be thinking about five primary things.

Does their personality fit my team?
Are they talented?
Are they efficient?
Are they consistent?
Can I pay them properly?

These questions are extremely important to any part of the hiring process. The first question is usually decided based off of interaction chemistry – not something we are going to cover in this article. The fifth is usually decided on a case-by-case basis, and is also something that is outside the scope of this article. However, when answering the other three questions, two primary factors play into the judgement: speed and accuracy. In the case of the web developer, rapid interaction development is a way of proving that you have take the craft of interaction development very seriously.

Rapid interaction development isn't accidentally fallen upon when a muse strikes (as may be the case with a more art-driven degree). Instead, rapid interaction development is a skill that is honed by the developer. This skill proves efficiency and talent, and gives more confidence in the developers ability to achieve consistency. To be able to rapidly develop interactions, the developer must have the two magic ingredients: speed and accuracy.

A disclaimer: It may be that someone gets hired because, though they aren't as talented as another individual, they are extremely consistent and have a great personality. This by no means is a "how to get a job as a developer" guide.

Let's Get On With It, Shall We?

With the understanding of the importance of rapid interaction development, we now can understand how you can immediately begin to hone this skill. Some of these tips take a simple change in mindset, while others take an investment of learning or pattern change. All of these, however, can help you become a better, faster, more valuable web developer.

Optimize Your Patterns

Have you adopted a CSS framework? If so, then you understand the value of reusable code. You have most likely adopted patterns without realizing it. In order to prove this, ask yourself, "when I start to build a website, what is my first step?" If your answer is "I don't know", then it's time to figure it out. If your answer is "first I open my text editor", then you've adopted at least one step in a pattern.

So, how do you optimize a pattern? These are often called workflows, but that's not an adequate description, as workflow doesn't include everything we want to talk about here. Some common tools to help you structure your pattern are CSS and JS "frameworks" like Twitter Bootstrap, Foundation, or Topcoat..

..preprocessing tools like SASS or LESS..

..perhaps full optimization and processor tools like CodeKit..

..startup WordPress themes like Bones, and even the option of building customized scripts powered by a command line. If you're a more advanced JavaScript developer and are looking to move into a new space, you should consider looking at Backbone, Ember, and other (MVC-oriented JavaScript frameworks)[http://todomvc.com/]; it would also be advised to look into Node, which empowers server-side JavaScript. It may take you some time, but picking up and learning some of these tools certainly increases productivity in the long run.

Recommendation: decide on some kind of HTML boilerplate/reusable "index.html" document and associated file structure that follows commonly accepted conventions, is built with semantic markup, and gives a "blank slate" to work from (think: HTML5 Boilerplate). Perhaps if you work primarily with WordPress or another tool, you'd want to find a similar boilerplate with base-level functionality for that tool.

If you're a bit more advanced, pick up some Yeoman skills for fast project scaffolding and wizard-based boilerplate generation. Decide on a CSS and/or JS framework (Bootstrap, Foundation, Topcoat), and start using a preprocessor for CSS sooner rather than later. Learning a preprocessor is well worth the time investment, and won't reduce productivity as LESS and SASS can both handle vanilla CSS. Try building a full wireframe of a basic layout completely with a framework's built-in classes. You'll likely be surprised how little code you need to write to make a functional layout happen very quickly. This reduces the overhead of writing repetitive code and also has the added benefit of pulling from much more extensive testing and cross-browser considerations than one person can do on their own.

Work With What you Know; Intentionally Learn What you Don't.

It's absolutely important to adopt a lifestyle of learning as a developer. Adopting new tools and skills like those discussed above is a part of the lifeblood of any successful developer. The technology we are using every day is changing faster than anything else; in order to stay at or above our current place in the industry, it is imperative that we learn continuously.

But – it is also as important to understand that learning new technology will slow you down – at first. For this reason, when you are practicing rapid interaction iteration, you shouldn't also be learning a new framework. Instead, intentionally take some time out of your week and dedicate it to learning that framework through a pet project, weekend hack night, or by implementing pieces of the new tool in a project that absolutely needs the new functionalities provided by that solution. This will allow you to maintain your momentum, and solve problems fluently rather than in a stop-go Google and StackOverflow binge. Most importantly, this intentional segregation allows you to focus on what matters: solving design problems instead of code bugs.

As a secondary note, when you are intentionally learning, it also helps to solve problems that already have well-known and well-documented solutions; of course, the world doesn't need another simple to-do application. But creating a to-do application may help you understand JavaScript much more, and may help you in the future when you are synthesizing information in order to solve new problems. Building solutions for problems that already have well documented solutions helps you compare and contrast your solution, and makes it easier to search for help when you get stuck. If you are in uncharted territory and trying to learn at the same time, getting lost is much more likely, and will detract from the goal of the learning process.

Adopt Hyperfocused Mini-Sprints

If you've heard the term "agile", you might have some idea of what a sprint is. Sprints are short, pre-defined work periods where developers decide on a set of goals, and "sprint" to finish those goals within the alotted amount of time. Because we are talking about rapid interaction development, a sprint is well suited to this discussion. Here are the basics.

Define
Prioritize tasks/goals, define the length of the sprint, remove or add tasks until the estimated amount of time to complete the tasks matches the predefined length of the sprint
Sprint
This is time where you are "in the zone" – zero distractions, etc.
Reflect
Once the sprint is complete, check your progress. Did you meet or exceed your goals? What caused the most hangup?
Adapt
Learn from what you reflected on, and put systems into place to help avoid the hangups.

In the traditional agile approach, sprints are based on helping with team collaboration and generally last multiple days or even weeks. Here, we are talking about self-management and hyperfocused mini-sprints. These mini-sprints might even simply focus on a single task or interaction, and its associated goals. The process of defining and prioritizing the task or its subtasks before diving into the work, and subsequently taking time to reflect on the process and adapt your workflow or patterns (remember, it's important to optimize your patterns) will help you become more objectively aware of your speed and productivity, and will allow you to be more conscious of what could use improvement at a micro-level.

Recommendation: define two 3 hour sprints for one day, each with a primary task. The purpose of the sprint (as with a physical sprint) is to drive your brain as hard as you can for those 3 hours. After those 3 hours, you will need a brain break; perhaps this is your lunch break, or maybe you've chosen to adopt an alternative schedule to allow for an uninterrupted hyper-focused block of time (more on that later). Whatever the case, planning these sprints apart from each other will help you recharge your brain. It's worth trying completely opposite types of activity (like taking a walk or reading fiction) or even a nap – more on that here. If you work for an agency, perhaps the break in between is the time you set aside for meetings, administrative tasks, or less taxing development tasks. Some people consider this the best way to work every day, and some may choose to do this kind of "sprint interval training" sporadically; choose what ends up making you the most productive, and increases your interaction development speed.

Temporarily Block Go-To Websites

If you are like most people, your fingers have muscle memory; when you open a browser, is it instinct to immediately type in Hacker News, Tuts+, or Twitter? What are the sites that cause you to procrastinate?

Hacker News has attacked this problem in a specific way, offering signed-up users the ability to set up a "noprocrastinate" restriction. There are some interesting tools that also offer these kinds of restrictions, but why not do it yourself? On a Mac, run the following commands from terminal:

sudo nano /etc/hosts
# enter your password when it asks for it.
# This will open a file in a terminal-based code editor;
# Don't worry! You won't be doing much in here. Type the following lines.
0.0.0.0 twitter.com
0.0.0.0 facebook.com
# press Ctrl+C (exit), Y (yes I'd like to save), and enter (save as the existing filename)

You can edit the same file on Windows (see this explanation).

This will block you from using Twitter or Facebook, and will instead redirect you to your localhost (0.0.0.0 is a shortcut to your machine). To get back to social-network-land, just follow the same steps, but remove the lines you added.

Recommendation: Should you block Facebook and Twitter all the time while you are working? We say no. It makes sense to be able to take small breaks between tasks to keep from burning out. However, during a sprint, if these sites are seemingly causing you to waste time, it's important (at least until you break the muscle-memory driven habit) to put them on pause. The important note here is, control your procrastination, even if that means scheduling time to waste. Being aware of the time you are putting into a given activity will help you be more conscious of whether or not that time is slipping away from your control.

Minimize Interruption

Interruptions have long been known to decrease productivity of knowledge workers. (See here, here, here, here – and there is much more available through a quick Google search.) Programmers (and, therefore, web designers) are susceptible to potentially only getting one uninterrupted 2-hour session in a day. In agile methodology, there is the concept of core hours that holds that strong focus should be maintained for 5 total hours per day. This is a far jump from the two hours programmers can expect to achieve in a normal office.

The Anatomy of an Interruption

There are many kinds of interruptions, but we will look at two specific aspects of interruption today. The first are welcomed or "self-inflicted" interruptions, the second are external or "intrusive" interruptions. Both types are detrimental to productivity, and both types can be somewhat managed in different ways.

Self inflicted interruptions occur because you have in some way created space for them to occur. These usually come in the form of programmable notifications (phone, computer, etc).

Intrusive interruptions occur because other humans need you to pay attention to them. The disconnect is the timing and sense of urgency. You must manage your own time, and you must put into place ways of doing so that circumvent the negative effects of interruption as much as possible.

So what do you do to alleviate interruptions? How do you achieve Zen Zone Time? Here are a few of our recommendations.

Minimize or completely disable notifications
This includes phone notifications like texts, email, Twitter, and even "chat". Hide your chat windows, and attend to them as a part of your workflow, instead of on a response "demand" basis. This may seem like it will hurt your productivity at first, but you might be surprised how willing people are to wait if it is actually important, and how likely they are to problem solve for themselves if you are too busy to break from what you are doing.
Have your management read this: adopt an organizational respect for The Zone.
Create rules in the organization about "zone time" or "maker time". This means there are specific boundaries for when, where, and how you can interrupt someone when they are in the zone. Have specific ways of signifying you are "under", like putting your headphones in or working in a specific part of your office. This is the purpose of "away" messages on chat, as well. Management must set aside time for the cultivation of rapid interaction development!
Managers – this may seem like a potential threat to the office, but like anything, you can try this for a bit to see what pieces fail and what pieces succeed. You will likely see productivity increases immediately.
Isolate yourself
Perhaps the most effective solution, isolating yourself makes you the controller of your space. This can happen in many different formats; for instance, many web designers and developers work from coffee shops to dive into isolation. This will prevent interruptions that happen as a result of physical proximity. Isolation doesn't always mean location, however; if most of the office works from 9-5, perhaps you work from 6AM to 2PM or 12PM to 8PM. This will give you space and time to think and work without interruption. Perhaps you can work remotely one or two days per week? Maybe it's much simpler than that for you, particularly if you are a freelancer.
Be diligent with scheduled communication
If you are going to put barriers up around you, you must also be willing to stick to your word and respond to messages when you come out from under the Zone. Don't let this slip, or else the productive aspects of your Zone time will be reduced by the negative aspects of your communication habits. Oh, and don't forget to call your mother!

Game On: Competition and Reward

What makes "hackathon" events so productive? How do people turn out viable products in 48 hours? Perhaps it is a mixture of characteristics.
1. Anticipated, protected, planned time for focused rapid development
2. Competition with others
3. Cash rewards
Hackathons break from the "normal flow" of every day work. Certainly, we wouldn't want to work 48 hours in a row all the time. But the productivity mindsets that arise from this are extremely important. We've alluded already to how important focus and uninterrupted time is. However, it's a worthy effort to consider how creating some personal competition and reward systems may help increase your efficiency in development. This helps set benchmarks and naturally trains your brain to adapt to the behaviors that are rewarding.

Recommendation: if you work with another developer, decide on a competition with clear goals, and make it time oriented. Doesn't really matter what those goals are. Take some time to work through them. Perhaps you can compete against yourself; practice by using the sprints as your competition, and set your goals to increase your efficiency by some amount of time. Set rewards up both for when you are in a competitive mode, as well as for when you complete any focused sprint of work. This will help keep you focused during the sprint itself. A reward may be a physical thing (like a cup of coffee) or something less concrete (like a VIP parking spot for a week or "free time").

Dive into the Open Source Community

We will keep this tip short, because the benefits here will be obvious. The Open Source World is full of amazing and talented people building things that help others do their jobs better every day. Examples like the frameworks we mentioned above just barely scratch the surface. Here are some of the benefits to working and communicating with the open source community.

Exposure to new tools
Free solutions to common problems
New solutions to emergent problems
A better understanding of problems you may not know exist
Opportunity to contribute and become a part of the giving/receiving cycle
Thought Osmosis: learning by repetition and exposure

Diving into the open source community and learning to use tools that are offered can immediately increase productivity, but also makes it much more likely that another person could pick up your project and continue developing on that project. Open source allows for people to collaborate around a decided standard and pre-existing documentation. This reduces cognitive overhead for transfer of projects, and makes you a much more literate developer; this immediately translates into higher efficiency.

Recommendation: Get a GitHub account, and start building things with tools available on GitHub.

This is somewhat of a reiteration of what we said earlier – use open source frameworks to solve problems in predictable, patterned ways, and participate in the community of other people who are doing so. Collaboration and discussion are very important keys to learning.

Conclusion

This by no means is a complete list of things you can do to become a rapid interaction developer. Leave some notes in the comments of things you've tried that have worked, failed, or have had little to no effect!

Taking Ems Even Further

Ian Yates — Wed, 29 May 2013 15:40:13 +0000

I recently wrote about ems; what they are, how they’re used and some bits and pieces to bear in mind when you implement them yourself. I only scratched the surface though, and the comments thread threw up twice as many questions as the article answered! In this follow-up I’ll take things further, looking at ems in even more detail.

E on Dribbble

Note: The previous article covers all the basics. I recommend you read up on them before going any further.

Unitless Measurement Values

The subject of unitless measurements (ie: values without pixels, percentages, ems, yards, fathoms..) was offered up by a couple of people last time, especially as I’d encouraged the use of ems for specifying line-height.

Ems make perfect sense in this case as they’re relative to the font-size. If the text in question grows or shrinks, so too does the line-height if it’s set in ems. Absolute units, like pixels, would really mess things up. The same is true of letter-spacing, another example of a dimension which should always be relative to the font-size.

However, we can improve on this. Ems complicate things as their values cascade; elements inherit their parent’s em values. Take this arrangement for example: an article which contains a paragraph:

If we apply the line-height to the article, it will also be inherited by the paragraph, which is fine:

But what the paragraph is actually inheriting is the computed value (in this case effectively 24px), so its line-height is relative to the article’s font-size, not its own. If we increase the paragraph’s font-size to the equivalent of 20px:

then its line-height remains staunchly at 24px. Ideally, we’d like its line-height to appear 1.5 * 20 = 30px.

This is where unitless measurements come in. By removing the em unit from the article’s line-height:

the paragraph will inherit the unitless value instead, 1.5. The paragraph’s line-height is now relative to its own font-size, bingo!

This pen should help you out..

Interestingly though, this doesn’t apply to letter-spacing. And you can completely forget about margins, text-indent, that sort of thing.

If you’re interested in reading more on the topic Eric Meyer covered it solidly way back in 2006, plus Harry Roberts has a great overview of measurement units from a couple of years back.

Ems and Macrotypography

Whereas microtypography refers to the tiny details within a document (punctuation marks, ligatures, hyphenation, kerning and so on) macrotypography handles all the “big” stuff. Think about all the aspects of typography which make a body of text readable; whitespace, line length (measure), paragraph indentation etc.

Take a look at this fluid column setup:

A perfectly decent layout; two divs, each one precisely 50% wide, with some padding left and right to form the gutters (inside each div, assuming * { box-sizing: border-box } is being used). Typically, you’d be tempted to define the padding using pixels, or (even better) percentages, if you were feeling super flexible.

However, pixels and percentages will both have a detrimental effect on the readability of the content, if (when) the font-size is altered. Gutter width, as with whitespace in general, should really be sized relative to the text. In this example, we have two columns of text, with guttering applied as a percentage of the column width, just like we described above:

.column {
	width: 50%;
	float: left;
	padding: 0 3%;
}

This is a live demo, take a look and mess around with it yourself..

When you alter the font-size however, you’ll notice the gutter becomes relatively narrower, blurring the division between the columns of text and making it more difficult to read.

This is an extreme example, with absurdly large text for the column width, but it illustrates the point..

Far better would be to define the padding using ems:

.column {
	width: 50%;
	float: left;
	padding: 0 1.2em;
}

This way, the gutter grows and shrinks along with the text, maintaining the distance between columns and keeping things readable.

Try playing with this one..

The Ol’ 62.5% Setup

If you aren’t yet using ems, it’s probably down to one of two things which you don’t like about them; the fact that their values cascade, or having to calculate those values in the first place.

The 62.5% approach (first proposed by Richard Rutter way back in 2004) will help you out on the second one. Quite simply, instead of setting the base font–size to 100% (which we’ll assume is 16px) we set it to 62.5%, effectively 10px.

From that point, 1em = 10px. Therefore:

Ems	Equivalent pixels
0.5em	5px
…	…
1.1em	11px
1.2em	12px
1.3em	13px
1.4em	14px
…	…
47.3em	473px

and so on, which should remove some of the mental arithmetic. However, there is a small issue with this approach, and it all has to do with…

Em-based Media Queries

We’ll talk a bit about the 62.5% caveat in a moment, but first we need to lay down some foundations.

In their simplest form, media queries help us apply CSS rules under different circumstances, most commonly depending on screen size. Screen resolutions are measured in pixels, so it’s only logical we define media queries in the same way:

@media only screen and (min–width: 600px) {
/*some stuff*/
}

Let’s apply this to our previous demo, to split the columns up after a certain point.

In this mobile first approach, our columns are split once the viewport reaches 600px

The arbritrary figure of 600px just happens to be fine in this case; optimum line length (or measure) is a highly debated topic, but as Robert Brighurst states:

Anything from 45 to 75 characters is widely-regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal.

Robert Brighurst – The Elements of Typographic Style

In our demo, at font-size of 1em, the measure now hits around 70 characters before splitting into two columns.

Once we hit two columns, the measure is perhaps a little narrower than we’d ideally like, but these columns are perfectly okay for the purposes of this demo. However, problems arise when we alter our browser’s font-size (hit command +).

With font-size boosted to “Very Large” (I’m using Chrome) our column measures are way too narrow, making the content pretty unreadable. For this reason, we should consider making our media queries relative to font-size too.

Remember the formula from our previous article?

We’re aiming for 600px, from an inherited font-size of 16px. 600/16 = 37.5em, so let’s change our media query to reflect that:

Now, when our browser’s font size settings are altered, we see a difference in the way the media query behaves. With larger text, here’s the pixel-based media query, with the viewport set at around 630px wide:

Whereas, at that screen width, the em-based media query keeps things neatly in one column; nice and readable.

Zoom in/out and watch the media query take effect

Back to That 62.5% Thing

Here’s the crunch; em-based media queries are totally disinterested in any sizing on the html, body, or whatever; they’re relative to the browser’s font-size. This means that, by setting the base font-size to anything other than 100%, you’ll have to manage two scales of em values.

Work from a base of 100% and everything will begin from a level playing field. Besides, as Filament Group argue, working in this way moves you away from thinking in pixels, which is a good thing.

Ems, Rems, Functions and Mixins

One word came up more than any other in the comments thread of the previous article; mixin. If you’re struggling to get your head around the calculations, then why not let a CSS preprocessor do the heavy lifting for you?

With CSS preprocessors, such as Sass, LESS and Stylus, you can define mixins and functions. These accept parameters, then calculate and churn out CSS values for you.

Note: If you’re new to the concept, take a look at Mastering Sass: Lesson 2 in which Jeffrey introduces Sass mixins.

Mixins and functions can handle all kinds of things for you, including the troublesome mathmatics surrounding ems.

Take this simple example from Garrett Winder at Erskine. He starts out defining a function (called “em”) which accepts two values (just as our formula from earlier) though the context value has a default of 16, so it needn’t be specified again unless necessary.

We can then use that “em” function within CSS thereafter, asking it to calculate the equivalent of 30px:

Which, when compiled, outputs the CSS in its raw form:

And this isn’t the only example of its type either – thousands of front end developers have cut their preprocessing teeth by writing their own em mixins. Rems too; by inputting the desired pixel value in this mixin featured by Chris Coyier, you can just as easily have rems outputted, with fallback pixels.

Here’s the mixin.

Here’s the usage.

Here’s the result.

The list is almost endless, but if you have any mixins you like to use in your own work (for outputting ems and rems) let me know in the comments and I’ll add them here:

Conclusion

It’s a broad subject, there’s clearly loads to take in, but diving into the world of ems is one of the more satisfying challenges in front-end web development. Stop thinking pixels and start thinking relatively, today!

Making the Most of Your Student Years

Sven Lenaerts — Tue, 28 May 2013 18:00:41 +0000

For any aspiring designer or developer, your student years are a time full of opportunities to develop your professional life. Why should you wait until you have a degree to become more professional in what you do? In this article, we’ll explore how you can use your student time to give you a great start in a professional career. Even though this article is aimed at students specifically, any designer or developer could pick up a thing or two to improve their (budding) career.

Work Hard, Get Better

How’s that for beginning with a massive cliché?

Every budding designer is familiar with the following situation: you stumble across beautiful work by other designers and you feel disappointed or ashamed because you simply don’t reach that level. It’s a very natural thing to be disappointed by your skills in the very early stage of your career. This shouldn’t demotivate you or let you doubt your skills. Ira Glass has a wonderful quote on this topic:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. &hellp; It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.

Ira Glass

The motivation to become an amazing designer keeps you on track on improving your work. Glass mentions that by practicing, you become better. If you go about finishing your school assignments and sticking with that, you’ll be disappointed by your level of skill once you have your degree. Forcing yourself to improve your skills outside classes is the first step in making that leap to a professional career. Explore new techniques and try to experiment with what’s possible on the web. You’ll improve your capabilities as time passes.

Any experienced designer can relate to this. Whenever you look at old work such as your first website, it’s hideous. Looking at old work makes you realize that you’re making progress in what yo do. At first, it might be difficult to notice that you’re getting better. Don’t focus on progress, but focus on your passion, your ambition and motivation. Work hard, get better and become respected in what you do.

Don’t Let School Limit You

One of the problems I experience while following classes is that education is focused on studying in group. Which means that classes can end up being either too slow or too fast, too simple or too advanced. Besides that, schools often have issues with keeping up with the latest evolutions in the industry.

Classroom by Kyle Lambert on Dribbble

The best solution for this is that you spend your spare time on studying what you’d love to learn (such as the latest trends in web design, for example) at your own pace.

The fact you’re reading this article means that you’re doing a good job already. There’s so much amazing material to be found online to help you learn new skills or improve old ones. Be inspired, be informed.

Teachers can be great assets; ask them for feedback on work you’ve done outside school, for example.

The great thing about higher education though is that it collects people with the same interests, both students and teachers. Teachers can be great assets, especially those whose classes you really enjoy and those who just do an amazing job at educating people. Why don’t you ask them for feedback on work you’ve completed outside school? Or ask for some tips while trying something new?

Ideally, teachers will have experience from working in the industry themselves. Those who love their job know that it’s impossible to teach you everything in class, but they might have that extra knowledge you’re looking for, provide answers on questions, offer feedback or useful tips.

Contests, Awards and Opportunities

My personal game-changer was the participation in design contests. Even though chances might be small that you win (you’re a beginner after all), it still offers you the practice to translate a brief to a concrete product.

Achievement Badges by Steve Czech on Dribbble

Contests are a great way to start building up a professional network. Always go to the award ceremony (if there is one), even if you didn’t win. It sounds more scary than that it actually is. It’s an easy way to get in contact with other designers and people who are in need of designers. Talking with other, experienced designers is another great way to get to know people who can be useful assets during the development of your career. Showing your face and small-talk is fine. Get people to know and recognize you in your environment!

With dedication and luck you could even win a design contest. This doesn’t only result in the direct rewards and/or award of the contest itself, but also the opportunity to meet people and perhaps get other work. These are the opportunities you’re looking for.

Don’t just think as a designer, think as an entrepreneur!

You might not always have the fortune to win contests and that shouldn’t be your only way to build up a professional network and improve your skills. In your student environment, there are numerous ways to practice your craft. Student parties can have a hideous flyer or some student clubs have an ugly website (or no website at all?) Why not offer to rework it if you know those people? Naturally, this isn’t the most spectacular work you’ll do and you’ll likely end up doing it for free, but it’s a very good investment in the start of your career.

As time passes you might get known for your work and other people might ask you to help them. In this fashion, your first paid opportunities might come and you can slowly filter out the free work.

Besides thinking as a designer, you also need to start thinking as an entrepreneur. Dare to think in a more commercial fashion once you believe you have the skills and the opportunities in front of you.

People Buy People

Your network will be your main source of income.

“Networking” seems like a horrible term for a lot of designers, but it’s not as difficult as people believe. Besides, if you want to work as freelancer your network will become your main source of income. In marketing “people buy people” is a very familiar concept. It isn’t just about your skills, it’s also about who (or what) you’re buying something from. Your designs shouldn’t just be awesome, you as a person should be awesome. Stay friendly, stay humble, be yourself.

Networking can be simplified. Anyone you basically communicate with, in any form, can be a potential peer in your professional network. The chances are you don’t even realize you are networking.

Never quit meeting people.

The great thing about being a student is that you meet so many people on so many occasions. This results in many acquaintances who can prove useful at some point in your career. After all, some of them are the entrepreneurs of tomorrow and will start a company. They’ll also need a website at a certain point. Never quit meeting people. Continue to ask for feedback on your designs, even though the people you ask may not be familiar with our industry (this is were you receive the most interesting feedback!)

Finally, do you have a portfolio or a blog by now? Are you perhaps active on Dribbble or Behance? Show off your work online. Community design-related websites are a way to communicate with other designers but also potential clients. Besides, the community on these websites can offer you feedback from the best designers out there!

Your First Freelance Assignment

The most obvious step in launching your career is to work with real clients. We’ve discussed some possible routes to achieve this so far. Participating in design contests for example, networking, but also putting work online (letting people find you) are ways to get that first brief in your inbox.

A Tiny Voyage by Paddy Donnely – also used as the preview thumbnail for this article

Obtaining your first client is often the most difficult. Don’t expect large jobs initially, something small such as designing a logo or developing a newsletter are a great start. Nothing exciting yet, but good things come to those who deliver great work. Besides, receiving your first paycheck by doing what you love feels great!

Always respect the client and the job, no matter how small or large. If clients don’t appear, keep working on improving your skills and completing personal projects in your spare time. Update your online visibility and perhaps redesign a website you often visit as personal project for fun and experience. It’s work you can put in your portfolio and it gives clients a taster of what you’re capable of.

Take initiative as freelancing designer, it can be very rewarding.

Last, I’ve already mentioned thinking like an entrepreneur. Instead of waiting until you receive your first freelance assignment, you can also actively look for clients. Take initiative, especially if you see opportunities ahead of you. Out of personal experience, taking initiatives and making offers has gotten me much further.

Work and School: Finding a Workflow

There isn’t a perfect method to decide what’s more important.

As you become better and participate in more projects, there will be a moment that you find yourself stuck between work you need to finish for school and opportunities or work for clients. There isn’t a perfect method which decides on what you need to focus. I personally work with setting priorities on short-term and on long-term. Some people decide to quit with school if that’s a better choice. It’s arguable, but it can be a good choice if one reflects on its current situation and considers the risks.

Don’t say yes on every opportunity which comes your way.

Personally, I prefer to plan carefully and give enough room for error in my agenda. Am I faster than my schedule? Excellent. Am I slower? Not a big problem, I’ve got spare room to make mistakes or work longer on something than expected. Be realistic in your planning. Don’t say yes to every opportunity which comes in your way if you’re already busy (it’s a mistake beginners often make). Make sure you’re capable of dealing with your workload. Always consider that you might get extra work at school or the client you’re working with is a difficult person.

Finally, every day, take some time to relax. You can’t be productive every single hour you’re awake, that’s asking for a burnout.

Conclusion

I hope by now you’re inspired to get the most potential out of your time as a student. Work hard, get better at what you do. Get to know people, participate in opportunities and become an entrepreneur besides a designer. Work towards your first freelance assignment, your second, your third, etc. The final rule: design everything. Everything you say, do or share. By the time you finish your school, you’ll have an amazing starting point to start your career for real.

Connecting Creativity and Commerce

Sven Lenaerts — Tue, 28 May 2013 08:26:25 +0000

During previous articles, we’ve focused on being more creative, or overcoming obstacles which prevent you from being creative. Today, we’re making the sometimes difficult connection between creativity and business.

Gift by Roman Jusdado on Dribbble

Creativity is important from an economical point of view and it’s perfectly possible to monetize creativity. Even though during the session we’ve never really emphasized the power of creativity in a commercial way, by now you should understand to an extent how creativity can improve your business.

The great thing about really creative people is that they can come up with qualitative ideas in a short period of time. Besides this, they are able to beat creative block in a fairly efficient way by analyzing the cause and dealing with it. To put it simply, businesses should invest in creative people because they save time. Saving time means saving costs. Now, how can we make this happen?

Commercial Creativity Means Efficiency

As we discussed in the previous article where we polished up our creative process, there’s a split between either generating ideas and selecting ideas. In a commercial environment this means shortening the amount of time it takes to go through these two steps while still having valuable concepts.

First generate ideas (don’t judge!), then translate those ideas to a number of workable concepts.

Idea Generation

It’s important during the idea generation process that you work in an efficient fashion.

Making of Things

I personally prefer to go through this whole phase in a set amount of time with my preferred techniques to gain valuable concepts. There’s a difference between working in a team and working alone.

Even though our creative process can be a very chaotic one, in business it’s better to have it structured.

For teams it’s advisable to go through the whole process together; from brief to brainstorm. By having more people participate in your idea generation process in a limited amount of time, you’ll gain a lot of input within a short period. This is a great start for the idea selection, which can be done with fewer people, such as the art director and the lead developer.

The preferred techniques are a good old brainstorm, with rules explained in our previous article.

Creativity depends on the right conditions rather than time.

But what if you’re working alone? The problem with working alone is that you can be in a very creative mood and can come up with a lot of ideas quickly, or simply have no inspiration at all. This is why, unlike in team settings, it’s not really recommended to put a time limit on your creative process unless you feel experienced with time pressure and creativity.

Recognize when you’re creative and use that time for idea generation instead of developing, for example. Find your preferable methods which work out the best for you. The best tip is that whenever you lack creative ideas, step away from the problem (and your computer) for a while. Go grab a coffee or take a walk. A fresh mind does miracles. Creativity depends on the right conditions rather than time.

Even though our creative process can be a very chaotic one, in business it’s better to have it structured. Why? Simply, it generates results in a fashion you enjoy in a limited timespan. This is my preferred method, but you can play around with yours until you found the perfect approach for you or your company!

Start with a quick brief. Even if it’s just you. Define the problem. Understand the project and the expectations.
Spend about 15 minutes on the internet to figure what exists, what the best practices are and some general inspiration.
Shut down your computer, have a brainstorm with just you, a pencil and paper. Limit yourself in time. I prefer about 45 minutes. (In groups, have an old-fashioned brainstorm!)
Time’s up. Have a coffee together, have a conversation about what you ended up with. This first interaction is important. If you’re alone, try to call anyone who you believe can offer some feedback or insight. Always have a chat with somebody else before moving on.
Spend a half hour refining your ideas to a number of concrete concepts. (Still on paper!)
Time to move to the idea selection.

With an investment of about two hours, you should have a good start to the project. Keep things nicely open-ended. You might have a creative block during this process. No problem, remember the previous articles. Focus on finding the cause and beating it and you’ll be fine.

Idea Selection

Idea selection is usually a much smoother process. Again I prefer to work with a structure.

Scrap the obvious bad ideas after you’ve checked them if they can’t be combined with your other ideas.
Use any preferred technique to reduce your ideas to two/three concepts.
Take each concept to the next level. More than that you should.
Open your computer, start with intensive communication with your client.

When presenting ideas, don’t design pixel-perfectly. Rather, get your idea and the mood of your idea across. The power of moodboards are incredible. They are low-effort and give clients visuals. Clients love visuals. Always provide them together with your concepts.

Make sure that you like the concepts you are about to present.

On the topic of concepts, always read your brief again before presenting them to a client. Always make sure that you like the concepts you are about to present. You should be excited yourself. It’s far easier to sell something which you believe is really amazing and would be fun to work on. If it doesn’t make anyone excited, honestly, what’s the point then?

Three variations of one idea is still just one concept. Don’t offer clients variations, rather select which variation is best as a designer. Don’t provide one amazing concept and two bad ones in the hope that the client will select the amazing one. Even in this very early stage of your project, deliver gold. Have varied concepts, have a good discussion with clients how you came to these and how they can solve the clients problem. Choose a concept together and blow their mind.

Commercial Creativity Means Taking Decisions

Even when everyone has agreed on a concept, during the development process there will come a moment that you feel something is wrong. One of the guilty things we designers tend to do is move around elements, design variations or simply continue with the hope that it will get better, when it actually just becomes worse.

Switch by Delacro on Dribbble

Understand you’re doing something which is totally useless and stop it. There’s something wrong and you have to figure out what exactly is wrong. Ask other people what they think (they haven’t been staring so long on something as you have), what they believe the conflict is or start retracing your steps until you’ve figured what went wrong. This might look like a waste of time, but it’s smarter and quicker than making variations.

Risks, Innovation and Silliness

Silly projects relate to you as commercial designer, in that they make you a better one.

Creativity always has some magic tricks up its sleeve. Designers have crazy (and fun) ideas. Take this for example, or this, or even this. These silly projects might not have any commercial value, but they experiment with the possibilities on the internet. They might attempt new techniques. They might inspire you during the development process. They relate to commercial projects in a sense that make you a better designer.

Even when it comes to business models, creativity is an important asset. They can help you define new ways to earn revenue, reduce the risks or invent innovative ideas which can be a game-changer. Simply, it’s a skill you can use every day in any situation. To be truly creative, you will have to take risks and try to be innovative. Dare to beat the industry standards and blow everyone away.

Conclusion

Creativity has commercial value and it’s an important asset you’ll keep using day by day. Don’t be afraid to try something new to make your creativity more efficient. Question your way of working from time to time.

Take clients on a wonderful journey during the design process, communicate efficiently and deliver something better than you expected in the first place!

How They Did It: Flickr Redesign

Jonathan Cutrell — Mon, 27 May 2013 09:43:18 +0000

Fresh on the heels of Yahoo!'s acquisition of Tumblr, Yahoo! has implemented a complete redesign of Flickr.com. This was met with some strong criticism as well as strong praise, a lot of which has been attributed to Yahoo!'s new leader, Marissa Mayer. In this article, we will talk about the design decisions and some of the implementation details in the redesign, and we will open some conversation about Yahoo!'s acquisition of Tumblr.

Built for Photography Enthusiasts

The role of Flickr is often questioned by critics of Yahoo!, as Facebook surpassed it as the most popular online photo uploading service. In this redesign of Flickr, we see an interesting set of priorities reflected, which we will discuss in this section.

These priorities reflect that Flickr is targeting an audience of photography enthusiasts.

The Home Page Image Choices

By looking at a random selection of photos from Facebook, you will most likely see a collection of friends-at-the-beach or "selfie" photos. Even in Facebook's advertisements, we see images that are driven by one factor: capturing socially driven moments.

Writer Justin Rocket Silverman learns the art of the ‘selfie’

However, looking at the Flickr homepage, we don't see a single image that would be primarily considered "social". We instead see a selection of primarily nature or pet images, with a few other posed photos. These images are best understood as highly intentional, taken by photography enthusiasts.

The Home Page Information Choices

The home page of Flickr pushes a few messages and a single call to action. The primary message is Flickr's groundbreaking free terabyte of space for images and videos. They emphasize this in the primary landing message, "Smile. Everyone gets a free terabyte" and further in the second "Biggr" slide below the fold, which allows the user to see how many images of a given resolution they could upload to Flickr.

The megapixel slider goes from 0 to 16 Megapixels. The third slide explains that users can upload their images at their original resolution, and can expect no loss of quality.

These messages speak strongly to photography enthusiasts; having enough free space to upload high quality images is of importance to photographers. In contrast, Facebook does not communicate any quality or space implications to uploading images.

Photos are King: Content Citizenship

The new Flickr is hyper-focused on photo-centric experiences. This generally places user accounts as a secondary content element. For instance, when a user signs in, the "home" page shows a feed of images and their associated interactions from other users. The logged-in user's groups can be seen to the right. Clicking on a photo opens a navigable lightbox.

Flickr also has created a new slideshow experience. The search bar focuses on user uploads (rather than user "profiles") by default. The next two options are your personal photostream, then your "contacts' photos". Finally, the search type can be changed to groups, and lastly for members.

Flickr Isn't Confused

As a secondary effect of Flickr's hyper-focus on photography and the people who care about it, we can quickly see that Flickr's goal isn't to compete with Facebook. Instead, it is to become the photography cloud service for the average photography enthusiast and the professional career photographer to store and discuss photos.

This is not to diminish the interactions enabled by the new redesign. In fact, interaction and conversation is encouraged more than the previous Flickr, which was primarily focused on showing each individual user their most recently uploaded photos. But Flickr's social interactions revolve entirely around the photos; in fact, on a single user's profile page, there is no "wall". Instead, there is a stream of that user's uploaded photos, which can easily be launched into a slideshow. If you like a particular user, you can "Follow" them (Tumblr, anyone?), which will bring that user's photos and associated comments to your logged-in home feed.

Users can access FlickrMail, but only if they have people added to their Contacts; furthermore, access to FlickrMail is somewhat buried.

Groups can post very simple "discussions", which are like forum posts; however, further communication is relatively limited to comments on photos.

Flickr isn't confused or unfocused; instead, it is clearly focused on creating a place to talk about and store photographs.

Some Dirty Details

As is the custom with the "How they did it" series, we are going to spend some time talking about the technical aspects of the new implementation. This section isn't about the overall strategy or whether or not it's effective; instead, this section is packed with tips and tricks based on Flickr's implementation.

Welcome to the Future

Flickr's design hasn't seen a significant update for about seven years. In that time, there have been large advancements made in computing, including much more widespread access to broadband, a general increase in broadband speeds, and a massive shift to mobility and multi-device accessibility. For this reason, Flickr of 2012 looked quite dated, primarily based on a low-bandwidth thumbnail focus, generally displaying one higher resolution image at a time. Furthermore, the Flickr before the redesign did not take advantage of many of the affordances of newer browser technologies.

Flickr of yesteryear

Parallax – Flickr is Doing it Right

We've posted about parallax on Tuts+ plenty of times before. When opening a conversation about parallax techniques, one of the first issues addressed is performance. Too often, parallax is implemented in naive ways, like some variation of the following (or worse).

Note: this assumes the site is using jQuery..

$(window).on("scroll", function(){
  $(".parallax-item").each(function(){
    $(this).css({
      marginTop : $(window).scrollTop()*.5
    });
  });
});

For an example, check out this Pen!

What's wrong with this approach? First, every scroll event runs the function being called. There is no caching of JavaScript objects, no scroll throttling and as importantly, this doesn't take advantage of CSS3 transforms or hardware acceleration.

Making simple changes can help dramatically increase performance in scroll-event-powered interaction, and Flickr has done just that. Here are the primary JavaScript functions used in the parallax technique. (We've taken the liberty to add some comments for understanding's sake.)

(function () {
            // setting up variables to be used throughout
                var useTransform = true;
                var useParallax = true;
                var ua = navigator.userAgent;
                var winLoc = window.location.toString();
                // useragent matching for progressive enhancements
                var is_webkit = ua.match(/webkit/i);
                var is_firefox = ua.match(/gecko/i);
                var is\_newer\_ie = ua.match(/msie (9|([1-9][0-9]))/i);
                var is\_older\_ie = ua.match(/msie/i) && !is\_newer\_ie;
                var is\_ancient\_ie = ua.match(/msie 6/i);
                var is_mobile = ua.match(/mobile/i);
                // to see the page's performance with 2d transforms (instead of 3d), visit http://www.flickr.com/#transform=2d
                var use2DTransform = (ua.match(/msie 9/i) || winLoc.match(/transform\=2d/i));
                var requestAnimationFrame = null;
                var prefixes, transform;
                var parallaxItems = [];
                var scrollHandler = null;
                var nodes;
                var lastExec = new Date();
                // The next two checks potentially used for debugging, or for specific devices or links.
                // To see the page's performance without transforms (margin-top implementation), visit http://www.flickr.com/#notransform
                if (winLoc.match(/notransform/i)) {
                    useTransform = false;
                }
                // to see the page without parallax, visit http://www.flickr.com/#noparallax
                if (winLoc.match(/noparallax/i)) {
                    useParallax = false;
                }
                // Check user agent variables to decide whether or not to use parallax.
                if (is_mobile || is\_ancient\_ie) {
                    useParallax = false;
                }
                // If the url has "useraf" in it, use request animation frame
                if (winLoc.match(/useraf/i)) {
                    requestAnimationFrame = (window.requestAnimationFrame || window.webkitRequestAnimationFrame || window.mozRequestAnimationFrame);
                }
                // setting up transform prefixes
                prefixes = {
                    webkit: 'webkitTransform',
                    firefox: 'MozTransform',
                    ie: 'msTransform',
                    w3c: 'transform'
                };
                if (useTransform) {
                    if (is_webkit) {
                        transform = prefixes.webkit;
                    } else if (is_firefox) {
                        transform = prefixes.firefox;
                    } else if (is\_newer\_ie) {
                        transform = prefixes.ie;
                    }
                }
                // The main function for parallax items
                // takes a containerNode param, which is the relative-positioned
                // parent of the absolutely positioned parallax image.
                function ParallaxItem(containerNode) {
                    // set up some vars for caching values throughout
                    var container, bgElements, offset, bgHeight, containerHeight, maxScrolls, height;
                    // cache a YUI-wrapped instance of the container, similar to $(containerNode) in jQuery
                    container = Y.one(containerNode);
                    // get the elements with a class of "parallax-background" inside the container.
                    // the homepage only has one element per container, but this could scale to have multiple bg items
                    bgElements = container.all('.parallax-background');
                    // function to refresh variables for each parallax item
                    function refreshCoords() {
                        offset = container.getY();
                        containerHeight = container.get('offsetHeight');
                        bgHeights = [];
                        maxScrolls = [];
                        bgElements.each(function (item) {
                            height = item.get('offsetHeight');
                            bgHeights.push(height);
                            // max scroll of each container is the
                            // container's offsetHeight - parallax item's offset height + 2
                            maxScrolls.push(containerHeight - height + 2);
                        });
                    }
                    // the actual parallax moving function
                    function refresh(docScrollY) {
                        var i, j, scroll, transformParam;
                        i = 0;
                        bgElements.each(function (bgElement) {
                            // scroll is set to the max of the element's maxscroll and the
                            // document's scroll position minus the offset of the current container
                            // divided by the container's height multiplied by the max scroll.
                            scroll = -Math.round(((docScrollY - offset) / containerHeight) * maxScrolls[i]);
                            scroll = Math.max(scroll, maxScrolls[i]);
                            var transformParam;
                            if (!use2DTransform) {
                                transformParam = 'translate3d(0px,' + scroll + 'px, 0px)';
                            } else {
                                transformParam = 'translateY(' + scroll + 'px)';
                            } if (transform && transformParam) {
                                bgElement.setStyle(transform, transformParam);
                                bgElement.setStyle(prefixes.w3c, transformParam);
                            } else {
                                bgElement.setStyle('marginTop', scroll + 'px');
                            }
                            i++;
                        });
                    }
                    refreshCoords();
                    return {
                        'refresh': refresh,
                        'refreshCoords': refreshCoords
                    }
                }
                // this runs the parallax mover "refresh" function if there are parallax items,
                // passing in the current scroll position of the document
                function refreshParallaxItems() {
                    var docScrollY = Y.DOM.docScrollY();
                    if (!parallaxItems || !parallaxItems.length) {
                        return false;
                    }
                    for (var i = 0, j = parallaxItems.length; i < j; i++) {
                        parallaxItems[i].refresh(docScrollY);
                    }
                }
                function scrollWatcher() {
                    if (requestAnimationFrame) {
                        requestAnimationFrame(refreshParallaxItems);
                    } else {
                        refreshParallaxItems();
                    }
                }
                function addParallaxItem(containerNode) {
                    parallaxItems.push(new ParallaxItem(containerNode));
                    if (!scrollHandler) {
                        scrollHandler = Y.on('scroll', scrollWatcher);
                    }
                }
                // finally, this actually goes through the parallax items and adds them to memory,
                // which sets up all of the event watching, etc
                if (useParallax) {
                    nodes = Y.all('#flickr-frames .parallax-item');
                    nodes.each(function (item) {
                        addParallaxItem(item);
                    });
                    // Whenever a PhotoListView is rendered,
                    // refresh the coordinates of the parallax pieces
                    Y.on('PhotoListView:render', function () {
                        var now = new Date();
                        if (now - lastExec > 250) {
                            for (var i = 0, j = parallaxItems.length; i < j; i++) {
                                parallaxItems[i].refreshCoords();
                            }
                            lastExec = now;
                        }
                    });
                    // Load in the coordinates of the parallax pieces when the document loads
                    refreshParallaxItems();
                }
            }());

Check out the comments we've added to get a fuller understanding of what's happening here. This may seem a bit daunting, especially if you aren't familiar with Yahoo!'s YUI node JS utilities. Instead of getting caught up on all of the details of this code, let's look at a few specific important pieces that matter.

First we see the extensive use of variable caching. This includes setting up max heights, offsets, etc in a refresh. Next, we see use of progressive enhancement to define when to use 3D, 2D, or no transforms. This greatly improves performance for newer browsers. Furthermore, 3D transforms are supported in all current major browsers (except Opera and Opera Mini), which means a significant performance improvement by way of hardware acceleration, which kicks in when using 3D transforms on a given element. (Check out this article for more information). This helps the homepage realize much higher framerates – usually at or above 60fps.

It's interesting to note that the Flickr dev team left some seemingly unused pieces in the source code, like url-based functionality switches that enable or disable things like parallax and transforms. Perhaps this is used for certain device redirects; this may have been a debugging technique the dev team forgot to take out. It also could be a callout to devs to play around with the application and see the performance benefits of using these different techniques. Whatever it is, it's a blast to play around with once you find it, and has virtually no performance impact.

One more note about the parallax implementation: Flickr has completely avoided using background-size for the image containers, and has avoided "full-screen" sizing as well, opting instead for generally min-height parallax container elements. Why? Performance of background-size:cover is terrible, causing low framerates and generally a degraded user experience. Instead, Flickr has chosen to load larger background images; 2048×850, to be exact. This covers the width of almost any screen, and provides enough height to do an effective parallax implementation. Browser repaints are reduced significantly as well.

CSS3 Powered Call-to-action

In a throttled scroll-watching function, the final call-to-action at the bottom of the Flickr homepage transitions in as the user scrolls over a wall of horizontally justified photos from users. The animation is powered by CSS3 transitions, including a 12px webkit blur filter, opacity, and scaling. The call to action includes large typography (10em or 144px to be exact), and a fittingly large CSS3-styled button.

Here is the CSS for the button.

/* Webdesigntuts+ note: browser-specific prefixes removed */
display: inline-block;
padding: 0px 2em 5px 2em;
font-size: 2em;
line-height: 1.75em;
font-weight: 400;
text-decoration: none;
background: #ff0084;
color: #fff;
box-shadow: 0px 2px 8px rgba(0,0,0,0.5);
border-radius: 5px;
background-image: linear-gradient(bottom, rgb(215,0,104) 35%, rgb(243,0,111) 84%);
background-clip: padding-box;

Fairly straightforward, but effective. The internal site once a user has signed up has similarly large elements, like the upload form.

Other Polish and Best Practices

Small enhancements throughout the homepage also work to improve user experience. For instance, the megapixel slider utilizes an inline data uri for the handle, while the slider trough solely uses css gradients and other definitions. No http requests are required for any part of the slider, other than its associated JavaScript.

Very slight text shadows are used on the headers to lift them off of their associated background images a bit. Semi-transparent (RGBa) background colors are being used for the top navigation bar as well as the image wall titles. Flickr is also using Mustache templates for the image wall. All of these elements allude to the fact that Flickr is getting a push towards maintaining a much more leading-edge front-end design.

Criticism

Here are a few thoughts about things that could be better with the new Flickr, or that you may consider in your development practices.

Responsive Implementation

Right now, the mobile strategy adopted by Flickr relies on two main points: native applications and a mobile specific site. The mobile specific site is much less attractive than the desktop version. Considering the simple fact that mobile is growing faster than ever, this redesign could and should be reconsidered as an opportunity to adopt responsive strategies. The desktop version of the site is less than ideal at anything lower than 960px. This throws out many smaller tablets and almost any phone.

Minified, Less, More Specific JavaScript

Best practices tell us that marketing-driven, call-to-action homepages and splash pages are not the best place to load application content. However, Some of the scripts loaded on Flickr.com's new homepage are used throughout the rest of the application. It would be benefical to, instead, create a single, smaller JavaScript file that relies less on the YUI library, and more on simple event listeners, selectors, and AJAX functions.

That JavaScript file needs to be minified as well; however, it may be the case that it isn't minified for the sake of developers who want to peek at the source. (See the developer callout at the end of this article.)

UA Sniffing is Unreliable

User-agent sniffing is bad news unless you thoroughly check every string with every device (less practical than is useful). Unfortunately, using a simple string like "mobile" as Flickr is doing here isn't enough to definitively say whether or not we're on a mobile device. Sure, this may cover a significant percentage of devices, let's say even 99%, but when that's 99% of 200 million people, youre leaving 2,000,000 devices out.

It's also unlikely that using something that enhances performance drastically, like transforms, should be limited by simple UA sniffing. Instead, using a feature detection suite like Modernizr would be more beneficial and more definitive of the user's browser abilities. Seeing as Modernizr is backed by some of the folks at Google, it's not surprising we don't see it included on Flickr, but the underlying concept is simple, and the tests are easily replicable.

OpenGraph Tags

OpenGraph tags are essential to sharing a site on Facebook. Sharing a site on Facebook is a basic function of the web for many users. Unfortunately, if a site doesn't specifically implement OpenGraph meta tags, the shared link item looks fairly bare on a Facebook news feed.

If Flickr is indeed competing with Facebook, this may be a gamble that it will help them turn people against Facebook, or disassociate Flickr from Facebook entirely. Or, it could just be an oversight. Either way, it makes me (and likely some other users) avoid sharing Flickr.com with my Facebook friends.

Copywriting Considerations

Okay, we get that Flickr (and Tumblr) don't like er's. But, there comes a point where removing letters from words gets annoying and cheesy, and even difficult to read. Flickr is edging on that line. Using things like "Biggr", "Spectaculr", and "Wherevr" arguably don't improve the branding or user experience. Flickr is the name of the service; "bigger" describes a new feature of that service. Otherwise, why not also change "follower" to "followr", or "developer" to "developr"? Because it doesn't make sense and sounds alienatingly strange. Consider Apple's incredibly effective advertising copywriting; "iPad" does not translate into copy like "Take your iMac with you, iAnywhere".

Bonus: A Callout to Developers

An interesting piece Yahoo! included in the source for Flickr is a callout to front-end devs, with news that Flickr is hiring. This cool ascii logo can be found in the head tag.

<head>
   ad88 88 88            88
  d8"   88 ""            88
  88    88               88
d88888d 88 88  ,adPPYba, 88   ,d8  8b,dPPYba,
  88    88 88 a8"     "" 88 ,a8"   88P'   "Y8
  88    88 88 8b         8888[     88
  88    88 88 "8a,   ,aa 88`"Yba,  88
  88    88 88  `"Ybbd8"' 88   `Y8a 88
You're reading. We're hiring.
http://flickr.com/jobs/

What Will Happen to Tumblr?

Known for its younger audience with a propensity to be more brash than, say, Blogger users, but less brash than Redditors, Tumblr sits in a unique position having been acquired by a giant like Yahoo!.

Will Yahoo! kill the free-form nature of Tumblr's content creation? Will Flickr and Tumblr become integrated, so that users can publish Flickr photos automatically to Tumblr? Or will Tumblr transparently continue to exist, with simply a new terms of service that allows Yahoo! to collect and use data from Tumblr's 109 million blogs and 51.2 billion posts? It could be an incredible source of data to Yahoo!, who seem to be in acquisition mode, acquiring PlayerScale days after acquiring Tumblr.

What do You Think?

Let us know what you think of the new Flickr, and what you think about the future of Tumblr under Yahoo!'s direction, in the comments!

Win a Ticket to Our New Tuts+ Live Workshop

Joel Bankhead — Thu, 23 May 2013 13:38:36 +0000

This giveaway has now finished – but sign up to the newsletter to hear about every exciting new workshop before they’re announced!

We have 5 tickets to give away for our newest Tuts+ Live Workshop, all you have to do is subscribe to our newsletter. Be quick though, this giveaway ends on Monday!

We have a superb new Workshop, Introduction to WordPress Plugin Development, starting in a week. This is your chance to win a free ticket!

Simply subscribe to the Tuts+ Live Workshops newsletter and we’ll pick the winners on Monday 27th. Read on to find out more about the Workshop and for more details about the giveaway!

Introduction to WordPress Plugin Development

Our newest Tuts+ Live Workshop, Introduction to WordPress Plugin Development, teaches you everything that you need to know to start developing WordPress plugins; from setting up a local development environment, all the way through to building a WordPress plugin that’s ready for release into the WordPress Plugin Repository.

It’s led by Instructor Tom McFarlin, a self-employed WordPress developer who divides his time between running his own WordPress development shop, building plugins for WordPress, blogging every day about software development in the context of WordPress, and working for 8BIT (the team responsible for Standard Theme and WP Daily).

Each weekly workshop will last one hour, running over a five week period. You’ll have the opportunity to follow along with Tom, ask questions live during the workshop, and complete a weekly homework assignment. Not able to make it to the live recording? No problem! All of the workshop recordings will be made available online the day after the live workshop.

Learn more about Introduction to WordPress Plugin Development

Subscribe and Win a Ticket!

We have 5 tickets to give away and will be choosing the winners from everyone who has subscribed to the Tuts+ Live Workshops newsletter, so no worries if you’ve already signed up. We’ll also reimburse any winners who have already paid for their ticket.

To enter simply subscribe to the Tuts+ Live Workshops newsletter and stay informed on upcoming workshops!

Quick Tip: Switch Over to Photoshop Swatches

Adi Purdila — Thu, 23 May 2013 12:37:33 +0000

Let’s talk about Photoshop’s swatches panel. This is one of those tools which you may overlook or even intentionally ignore, which is a shame as it’s really powerful! Let me show you how it works compared to your usual color-picking workflow; hopefully I’ll convince you to make the switch..

(S)Watch Screencast

Alternatively, Download the video, or subscribe to Webdesigntuts+ screencasts via YouTube

Any Old Icon: All Wrapped up!

Ian Yates — Wed, 22 May 2013 15:59:51 +0000

Any Old Icon is complete, 70 icons in all! Thank you to everyone who contributed, you can be proud to have participated in the most random icon set on Earth! For the rest of you, here’s how to download and use the set..

Quick Hat-Tip to Icomoon

This really wouldn’t have been so easy to realise without the genius of @Keyamoon‘s Icomoon webfont app. Uploading a pile of SVGs and outputting as a neat, usable webfont package has never been easier! And I’m very happy to report that Any Old Icon is now featured within the Icomoon library for everyone to use.

Get it. Use it.

I bet you’re itching to use this icon set in your next project, well here’s how to do it..

Download

To begin with, head on over to the project page http://tutsplus.github.io/Any-Old-Icon/. Browse the icons if you wish (I’ll wait) then head back and hit the big download button.

Files

You’ll end up with a folder called “Any-Old-Icon-Master”, zipped up courtesy of GitHub, which looks a bit like this:

In it you’ll find the font files, an index.html demo web page, a style.css file, some other stuff and an “svg” folder which contains all the original vector artwork.

Installing the Fonts on Your System

If you’d like to be able to use the fonts in Photoshop, Illustrator and so on, double click the .ttf Truetype file and it will (should) automatically install to your system, whatever platform you’re using.

You’ll then be able to select the “any-old-icon” font from within your favorite design application. Go nuts.

The Web

The demo index.html file is what Icomoon automatically churns out and illustrates a couple of ways you can use webfont icons on the web. Take a look at style.css and you’ll see the necessary bits and bobs.

To begin with, the @font-face rules, which assign a font family name (any-old-icon) and point to all the font files which you’ll need to upload to a web server. Make sure all the paths are correct, relative to the css file.

@font-face {
	font-family: 'any-old-icon';
	src:url('fonts/any-old-icon.eot');
	src:url('fonts/any-old-icon.eot?#iefix') format('embedded-opentype'),
		url('fonts/any-old-icon.woff') format('woff'),
		url('fonts/any-old-icon.ttf') format('truetype'),
		url('fonts/any-old-icon.svg#any-old-icon') format('svg');
	font-weight: normal;
	font-style: normal;
}

With that set, you can now use the font files in a couple of ways. The next chunk of code in style.css looks like this:

/* Use the following CSS code if you want to use data attributes for inserting your icons */
[data-icon]:before {
	font-family: 'any-old-icon';
	content: attr(data-icon);
	speak: none;
	font-weight: normal;
	font-variant: normal;
	text-transform: none;
	line-height: 1;
	-webkit-font-smoothing: antialiased;
}

It sets up the styles to use data-attributes, applying a pseudo-element to any element on your page which has a data-attribute of data-icon. For example, you may have:

<span data-icon="&#xe039;">This span will have a :before element applied!</span>

In which case, the value within the data-icon, an HTML entity () will be injected into the :before pseudo element. The any-old-icon font family is applied to this :before element, so the correct icon is displayed.

This is just how Icomoon styles things, you can handle it however you want of course..

Or..

The next chunk of CSS applies indvidual classes for each icon (pretty big chunk of code). Then each class has further styling, applying the pseudo element in a similar way to before, but representing the icons using escaped unicode entities, which is necessary in CSS.

.juan-ortiz-zaforas-plug-c-female:before {
	content: "\e01a";
}

Lastly..

What you may prefer to do, though which arguably incurs a small performance hit, is to apply the font-family to a global selector like this:

.icon {
	font-family: 'any-old-icon';
}

Which then points to the following:

<span aria-hidden="true" class="icon">&#xe039;</span>

Slightly muddying up the markup, but hey.

Note: that aria-hidden="true" is useful for hiding the markup from screenreaders and other assistive technologies. The character has little meaning without the icon, so could cause confusion.

Changing the Character Mapping

If you prefer to use different characters with these icons, head on over to Icomoon, use Any Old Icon from the library there (or upload the font files provided with our own source), then assign whichever characters you wish before downloading the package.

One Last Time

Thanks again to everyone who took part! If your icon didn’t make it into the final cut, I’m sorry, but I have a feeling we’ll be running more of these in the future. Enjoy the icon set!

Learning from Historic Web Archives

Warren Day — Tue, 21 May 2013 15:19:59 +0000

There are a plethora of resources available to aid in your success on the web. From countless analytics and SEO applications, to thousands of articles and reports from our peers. For anyone who runs their own website we can use these resources to improve and fine tune the online experience we give our visitors. One oft-overlooked resource is the Internet Archive, which contains years of fine-tuned updates and improvements from the world’s biggest and most successful websites – and we can learn from them.

How can we have critical thinking without being able to quote and being able to compare what happened in the past?

Brewster Kahle, the founder of Internet Archive

What are the Internet Archives?

As you would expect from any kind of historial record, the Internet Archive houses information dating back years. But there’s a twist; these records are cached snapshots of websites, so you can actually visit webpages such as Google from as far back as 1998. This information is priceless (not to mention quite humorous) and it’s astonishing to see how design has changed over the years.

Check out this example from 1998 when Google was still in Beta!

All these amazing resources can be found on the waybackmachine over at archive.org. Simply type in a URL and start exploring. You can have a lot of fun seeing how some of your favorite sites have developed over the years (or am I just a huge nerd?) Regardless, a lot of time, research and money had gone into improving and tweaking these websites and we can observe this information for our own benefit.

How can we Learn From These Records?

A people without the knowledge of their past history, origin and culture is like a tree without roots.

Marcus Garvey

We are always building on the knowledge of others, and I can’t think of a better place to apply this ideal than in the field of web design. By analysing the archives available to us we can see (through a certain amount of assumption) why certain decisions and changes have been made. This can help to not only see the natural progression of a website, but better understand the development process involved in bringing something like Google to what it is today.

By comparing the progression of many websites we can also see how design trends have changed over the years. Currently flat design is “in” and you can see how Webdesigntuts+ itself has changed to embrace this style.

Leveraging archives is essential in learning from past developments and mistakes, so let’s take a look at a process I often use.

Step 1: Choose a Website

It’s important to choose a subject to begin your research, preferably within the same field you wish to improve on. If you run a blog then choose a successful blog in a similar niche, if you have an online store then learn from the eCommerce masters. Of course, these are just examples.

When you encounter these sites as they are today it’s easy to think that they popped up from nowhere with overnight success, but the Waybackmachine will tell a different story. With archives we can begin to see the years of hard work put in to achieve their current position and their design progression along the way. So just how did they do it?

Step 2: Follow From the Very Beginning

I will use play.com as an example here. Being the desirable URL that it is, there is data running back until 1996. However, I came across its first instance as the eCommerce store it is today on 7th August 2003. The first thing I noticed is the iconic look and feel Play have maintained for years until being acquired by Rakuten back in 2011, at which point it underwent a much larger update and style change.

As we look at each incarnation of the site we must also remember that there are always the technological limits of the time at work, such as cross-browser support and reduced speeds.

Step 3: Analyse the Progression

By comparing how Play started to what it is today, you will find that the changes have been drastic. Let’s drill down and examine areas such as user-experience, functionality and aesthetics. I have found four snapshots for the large updates made between 2003 and 2013. So let’s take a look and begin to understand how each change has contributed towards the next.

2003

This is the very first version launched in 2003. Built with tabular markup, which at the time was common, and has a simplistic layout. A unique style has been developed to give strong brand identity. The large area in the center has clearly been chosen as the prime spot for internal advertising whilst the search bar is given little weight on the page.

2007

Four years later you can see from the number of categories that the product range has grown substantially. The main navigation has managed, however, to maintain the same format with a much needed design upgrade. You wouldn’t think it today, but heavy bevels were actually pretty trendy at one point..

The old center piece has been moved down to make way for a more prominent advertising section. Not having removing it completely indicates that it was actually doing well, but it was felt the area could be put to better use.

2010

Again the catalogue of products has expanded. The menu has grown substantially, becoming left justified to better fit all content. The original center piece (after losing its prime spot) has fallen from grace, becoming second best to the more prominent feature, ultimately being removed completely.

The search bar has finally been given more weight on the page, most likely due to analysis, perhaps heat maps and user feedback highlighting its importance. You can also see how the way people interact with a website has changed as on site search became more popular.

2013

Finally we have play.com today; this is by far the biggest update of all. The side bar has been removed completely and there is much more whitespace. The center piece has now stretched to the full width of the page after proving for years that it held an important role on the page.

The style of the site has changed completely and it has almost been totally rebranded. Some familiar colors remain, however, and it is easy to see that we are still on the same website. The search bar is now much bigger than before and a user trend has clearly been noted for this to happen.

Step 4: Gather Your Results

By looking at each step towards the final and definitive website we can take a lot away to learn from. We can see that search has become a crucial part of eCommerce, user interaction has changed and from this I can begin to make accurate assumptions. I believe that a user will already have in mind what they are looking for before they even get to the site, heading straight for the search bar. For this reason they will become relatively blind to most elements on the page. By making the main advertising section massively more prominent it can better catch a visitor’s eye, even subconsciously.

Bringing it all Together

Now that we understand the benefits of learning from archives we can add it to our arsenal of tools and resources available to us. By using archives alongside other tools we can uncover even more information.

With Alexa.com we are able to track the traffic of a site over the course of the last two years. By comparing this to archives we can often observe correlation. Often this can be a way to confirm our analysis of a page, be it good or bad. Sometimes a change could have had negative effects on traffic and we can learn from this not to make the same mistakes.

Don’t Jump to Conclusions

When seeing correlations between Alexa and Internet Archives you must be sure not to jump to conclusions. The demise of MySpace was not due to a design change, but the rise of stronger opposition.

Do your research in order to make sure your results are accurate.

Case Study: Disqus

Disqus is an awesome commenting system used across millions of websites (includiung Tuts+). Over the last year its popularity has seen huge gains. This would have been for a number of reasons, but at the time of its rise in traffic it just so happens that a large design update was made. This has surely contributed to the rise and we can begin to question why.

The Old Design

Here is the landing page of the site back in 2011.

You have just 10 seconds to engage users and convince them to take a closer look.

Jakob Nielsen

The overall design is solid, but the actual product is not well displayed. Without reading into it you would not have a clue what Disqus is or does. Dr Jakob Nielsen, a renowned usability expert noted that you have just 10 seconds to engage users and convince them to take a closer look. This means you need to get your initial message across as quickly as possible in order to convert visitors, here I am not convinced. Bring in the new design.

The New Design

Instantly you can see a huge improvement in aesthetics, the design is clean and simple.

The product itself is now clearly understandable and has been given a prime spot on the page. From this, users with no clue about Disqus can better see that it is an onsite commenting system. Although the previous graphic looked nice, it held little meaning and was rather distracting from the purpose. The call to action “Get this on your site” is also much more prominent now and better guides the eye towards it.

I believe that from this there is clear evidence that a design change has contributed towards the increase in traffic and a decrease in drop rate. We can take this information and use it as a guide towards our own decisions when designing a splash page or advertising a product online.

Conclusion

From these examples we can clearly see the benefit of learning from historic archives. They can form a crucial part of the research process in order to gain inside knowledge of the most successful websites around today.

It is important to do your research and use Archives as a tool alongside all other resources available. Remember that you can only make assumptions here and nothing will be hard fact. Archives can compliment your arsenal and improve the quality of your research.

I hope you enjoyed this article and thanks for reading!

Dunked: Launched, but Hardly Finished

Mark Southard — Tue, 21 May 2013 08:22:59 +0000

I'm part of the team that has recently launched a web app called Dunked. Dunked is a free simple-to-use online portfolio for creative types. As of May 2013, we are in public beta; continuing to build out features as well as making incremental improvements based on user feedback.

In this article, I am going to discuss some of the reasons I believe that a beta launch is important to the development of your product. I will also discuss how we, at Dunked, are going about the process of monitoring and gathering user feedback. Finally, I will discuss how were are going about implementing changes based on user feedback as we continue to build the product out.

Why I Like Beta Launch

I personally believe that having a beta launch is a really great idea. Of course, it’s inadvisable to release something which is riddled with bugs. It’s also a bad idea to release a product that isn’t ready for public consumption. It’s far better to release the product once it has the necessary core features and is free of bugs.

Google is probably one of the more well known companies that initially offers products as a beta release. Gmail is a great example. Gmail was in private beta from April 2004 to February 2007, when it was made available to the general public. Even then, it still had the "beta" label. Gmail wasn't officially taken out of beta for another two years. Having it as a beta product enabled Google engineers to continue enhancing Gmail based on user data as well as to test various additions.

Perfect just doesn't exist within software development

I recognize that it can be tough letting users see a product before you believe it to be perfect. But perfect just doesn't exist within software development. You will always need to iterate over a product in a constant effort to make improvements. I believe that by releasing a beta version of a product, you put yourself in a position to best offer users what they want. You may have assumptions that are just flat out wrong. By operating in beta, you can quickly pivot to improve your product to your users' needs.

In taking Dunked to launch, we felt that it was crucially important to identify and establish the differences between must-have features and nice-to-have features. Must-have features are the features which shape, and essentially, make your product. Must-haves are the features on which you should focus your time pre-launch. Once you've completed your list of must-haves, launch. After launch, you can tackle the nice-to-haves, fix any bugs that arise, and make adjustments based upon user feedback.

Monitoring and Gathering User Feedback

As we continue to build, user feedback is like gold. Users tell us when we're doing things great; when we're doing things wrong; and when we're being just plain stupid. Because user feedback is so valuable, it is important that you have a system in place prior to launch so that you can monitor and gather feedback. You must also establish a system to act upon the feedback that you receive.

Monitoring and gathering feedback is no easy task. Users are all different, with varying preferences in how they go about expressing their opinions. Therefore, you need to have a system in place to actively monitor a variety of channels of feedback. We've opted to use Desk. It serves as our central hub collecting all tweets directed at our @DunkedHQ Twitter handle, comments on our Facebook page and emails sent via our support contact form (this form is linked to from within the app itself). It enables me to log into a single location, where I can review and respond to feedback in the order it was submitted. This is a win-win for us and for users. Users can express their opinions however they feel most comfortable, and we can very easily access all feedback in a single location.

That handles current users, but what about the people that just delete their accounts without offering any feedback. Know that accounts will be closed, and do your best to collect information from users closing their accounts. At Dunked, we direct the user to a quick "exit" survey once they have completed the account deletion process. The survey is completely optional and can be completed in under five minutes. Most folks have been willing to fill it out, providing us with additional feedback on why they deleted their account. We've used Wufoo to handle our survey needs because they make it really dang easy.

Using User Feedback

Now that we have a method of monitoring and gathering feedback, what should we do with it? For Dunked, we have a pretty simple approach. We use a to-do list within Basecamp to house the feedback we collect. Whenever a user writes in with a suggested improvement or requests a missing feature, we add it to our Wishlist/Suggestions to-do list. This list also contains our previously mentioned nice-to-have features. Not all the items that get added to the list will be added to Dunked, but it helps us to monitor the suggestions. Common feature requests are noted, moved to the top of the list, and are often included in our code sprints, which I will discuss later.

Unfortunately, the Dunked platform hasn't been perfect, so we do occasionally get bug reports. We maintain a separate bug list also within Basecamp. Any item added to the bug list is considered a top priority and is fixed as quickly as possible.

As I previously mentioned, we are continuing to build out core features for Dunked, but we feel it is important to act upon the feedback provided by early users. Because users have been so great in providing us with feedback, we want to implement their suggestions as time permits. We do this through daily code sprints. Once or twice a week, we will go through our Suggestions/Feedback list, and pick a few items that can be completed in a single day of coding. We complete those items, test on our development server, and then push to the production server once we are happy with the code.

To illustrate how user feedback has improved Dunked, consider the following example. For image uploads, we created a simple, click-to-upload button. Clicking the button launched the file browser on the user's computer enabling them to browse to and upload images for their projects. It worked perfectly for us. Users, however, had some issues.

There are two basic options on how to handle image uploads: click-to-upload or drag-and-drop to upload. As it turns out, we (Team Dunked) each prefer click-to-upload. We didn't envision that users would want drag-and-drop uploads. In gathering feedback, it became evident that we had room for improvement in image uploads. We added "Drag-and-drop uploads" to our Wishlist/Suggestions list. After multiple requests, drag-and-drop uploads was added to one of our early code sprints. Now when you want to upload images to a project, you can click-to-upload or drag-and-drop.

This is a rather simple example of how users used Dunked differently than we envisioned. We never considered that users would be put off by our traditional method of image uploads. In monitoring, gathering, and acting upon user feedback, however, we were able to improve the Dunked for our users.

The Limitations of a Beta Release

Now that I've explained a bit about our approach to a beta release and why I think beta releases are great, I must discuss some of the mistakes and limitations that could plague a beta release. The biggest mistake that one could make in a beta release is to release a beta before it is ready. If you encounter bugs in your own testing or if you haven't run a thorough set of tests on your application, you have no business releasing into beta. When you release software that you know isn't ready for release, you are risking the trust of your users and the life of your product. While most beta users are willing to forgive minor bugs that pop up in beta, releasing a product that you know to be buggy is irresponsible.

When you release software that you know isn't ready for release, you are risking the trust of your users and the life of your product.

The second biggest mistake you could make in a beta release is to let in users too fast. While you can run stress tests, you won't 100% know what your server can handle until it's been put under a real test. If the server is going to crash, you want it to crash with 1,000 beta invites out and not 10,000 or 100,000 beta invites outstanding. Additionally, you are in beta, so it is possible that you will come across a bug or two. With Dunked, for example, we had an odd bug related to certain project slugs. Everything worked fine with the admin, but the live page resulted in a 403 error. It turned out to be a very simple fix. But because the issue was related the URLs, we had to correct existing URL slugs. It was certainly easier to search and remedy hundreds of project and page slugs than it would have been for hundreds of thousands.

One of the biggest limitations of a beta release is related to feedback. Granting users beta access, does not mean that they will provide you with feedback. Users may fully intend in provide feedback, but simply don't have the time put their feedback into words. They may also feel that they are doing something wrong, when the application doesn't work as they expect, and thus don't write you with feedback. Additionally, if you have to iterate over a certain component within your application, odds are that the quality and quantity of the feedback is going to wane.

Summary

I do not believe that it is not wise to try and include every single wanted feature when launching a product. I think you are better off launching a "completed" beta version, and then continuing to iterate over the product, adding additional features. In doing so, you'll be able to gather and use user feedback to improve your product.

Saying that, you must have a plan in place as to how you are going to monitor, gather, and act upon the feedback you collect. Thus, you'll be in a position to add features that create real value for the user, improving your chances of success.