When you think about it, the phrase ‘modern front-end development’ is a relatively new thing! When compared to competing platforms and industries, the web is still in its infancy stage. That being said, one only needs to read a development-specific Twitter feed, or say hello on a few applicable IRC channels to realise just how quickly our techniques and processes are advancing into a modern age of front-end development.

It’s fun to reminisce back to the days, not too long ago, when the process of building a simple website involved little more than a text editor and a bit of HTML and CSS understanding. Not a fan of Internet Explorer 7? Well back then, in the late Nineties, we were wrangling Internet Explorer 3 into shape! Though the ecosystem wasn’t nearly as mature as it is today, the process was simpler. Hand-code some HTML (in all caps, of course), add a touch of inline CSS, insert your favourite animated GIF and you’re done! Upload that bad-boy to Geocities and wait for the traffic to come rolling in!

Ah, those were the days. Thankfully, though, the web has matured immensely since then. In fact, as a community, we’ve agreed upon a plethora of best practices and tooling. We use version control to collaborate on open source projects. We embrace test-driven development for JavaScript (using tools like Mocha and Jasmine). We prevent ‘reinvent the wheel’-itus, by instead harnessing our efforts into contributing to highly tested libraries, such as jQuery. We’ve broken free from untestable spaghetti code by evangelising the necessity for dedicated frameworks, such as Backbone and Ember. We’ve even applied the principles of object-oriented programming to our CSS (OOCSS)! Yes, ladies and gentlemen, it’s a very good time to be a front-end developer!

While all of this may seem overwhelming at first (don’t worry, it should; we’ve all felt that way at one point or another), all of the items listed above are prerequisites for building modern, cross-browser web applications. The only question is: in an ocean of tools, libraries, and frameworks, which ones should you use? Or, put more directly, how do you separate the abandonware from the cream of the crop? This article will provide a somewhat opinionated stance on what tools you should be using, along with a few alternatives for each category. So let’s get started with those essential tools…

EDITORS

Sublime Text 3
www.sublimetext.com/3
Even a few years ago, you’d struggle to find a developer who knew what Sublime Text was. Fast-forward to today and it’s easily the most evangelised code editor in our industry. The reason why is obvious; while competing editors, such as TextMate and Coda, have either fallen by the wayside or disappointed their user base with underwhelming updates, the Sublime Text team (consisting of one person, believe it or not) focuses the bulk of its efforts on the most important aspect of your development workflow: speed. And, boy oh boy is Sublime fast. With a simple keystroke, you’ll find yourself switching from file to file with such ease and finesse, to the point that you’ll cringe at the thought of manually browsing through a file tree, like your former self once did. As with most things in life, there’s a reason for Sublime’s popularity. Though not free, it’s the best code editor available today. Period.

LightTable
www.lighttable.com
If Sublime Text offers the pinnacle traditional code editor, then LightTable hopes to completely revolutionise the coding experience. While it’s still very much in an alpha state, the progress so far has been incredibly promising. Imagine having the ability to evaluate your JavaScript in real time, without ever leaving the editor. This level of real-time feedback is unprecedented. Combine the speed and configurability of Vim with the elegance that we’ve come to expect from modern apps; LightTable offers this and more. Could it surpass Sublime Text in 2013? We’ll have to wait and see! Until then, keep a close eye on this one!

WebStorm
www.jetbrains.com/webstorm
While there’s certainly been a movement away from full IDEs in recent years, nonetheless many continue to champion their benefits. Luckily, there’s a variety of options to choose from! Most notably, the JetBrains team has been doing a wonderful job in recent years of maintaining a variety of platform-specific IDEs, including WebStorm, PHPStorm, and RubyMine.
If you’re one who prefers such an IDE, place JetBrains’ offering at the top of your ‘to review’ list. You won’t be disappointed.

Vim
www.vim.org
You might be thinking to yourself, “Why would Vim be included in a list of modern tools?” While Vim, or originally Vi, has, indeed, been around for decades, the truth is that it’s very much a modern editor that remains in active development. In terms of sheer extendability and speed, it’s difficult to top Vim. Keep in mind, though, that if you do give it a chance, you should plan on months of training. It’s a notoriously difficult editor to use. However, once you do commit those keybindings to memory, you’ll be unstoppable!

Brackets
brackets.io
Brackets is unique in that it’s an open source code editor developed by Adobe that takes HTML, CSS and JavaScript to the extreme: it’s built with those very technologies! As a result, as long as you have a relatively basic understanding of JavaScript, you already have the necessary tools to extend the editor as you see fit. Front-end developers are doing this very thing every day, in fact.
Though it’s still in need of some polish, Brackets is very much in active development. Expect to see this one give Sublime Text a run for its money this year!

JAVASCRIPT FRAMEWORKS

Backbone
backbonejs.org
Currently the reigning champ of JavaScript frameworks (at least, in terms of popularity), Backbone provides structure for your sloppy spaghetti jQuery code!
Though it may require a bit of rethinking, when it comes to your understanding of a client-side MVC (or MV*) framework (especially, if you’re coming from a server-side framework, such as Rails or Laravel), once you fully grasp the essentials you’ll find yourself writing clean, modular, downright elegant code.
Hoping for a crash-course in Backbone? Check out Tuts+ Premium and CodeSchool; they’ll have you prepped in record time.

Ember.js
emberjs.com
Ember is the spiritual successor to SproutCore, a powerful open source JavaScript framework that attempted to port Apple’s Cocoa user interface to the web. The reason for the name change stems from
the fact that the code base was completely rewritten from scratch, in an attempt to break away from a considerable amount of legacy code and some ‘faulty’ ways of thinking.
As the Ember team puts it, the success of Backbone proved to them that the development community indeed wanted the ability to build responsive, client-side apps. However, they also had years of experience crafting custom UIs with HTML and CSS. SproutCore’s attempt to replace this, in favour of its Cocoa-like UI, wasn’t the correct path.
From this failure came Ember, a new framework that’s sparking its way through the development community at record speeds. If Backbone doesn’t quite fit the bill, move up to Ember.

AngularJS
angularjs.org
Angular, developed and backed by Google, takes a different path, by providing the necessary tools you to extend HTML’s vocabulary for your applications, as needed. While some feel that this sort of data binding makes for messy, non-separated code, others champion its flexibility and ease of development.
As the Angular team puts it, HTML was not designed to manage dynamic views. Angular fills in this glaring gap. What’s your opinion?

Knockout.js
knockoutjs.com
One of the original modern JavaScript frameworks, Knockout – which preceded Angular, too – advocates a data-binding approach for building responsive applications with a minimal amount of code.
While, again, countless developers have argued against this approach, there’s no denying that it has its merits. What may require hundreds of lines of code in Backbone can be accomplished with but a few dozen in Knockout. The only question is: can you sleep at night, with all of that data binding in your HTML? There’s no correct answer to this question. Only preference.

Meteor
meteor.com
Meteor is a new full-stack JavaScript, powered by Node.js. It will revolutionise the way that you approach writing highly responsive and dynamic web applications.
Imagine writing your entire application in nothing but JavaScript; not just the client-side, but the persistence layer as well! With every single API offered in one language, imagine the convenience and flexibility that this could provide!
While the framework has not yet reached version 1.0, as long as development remains active you should absolutely investigate this new approach to writing applications.

CREATE A 3D EARTH SCENE

While WebGL itself is pretty inaccessible for novice users, by using a specialist library that abstracts a lot of the complexity it’s possible to very quickly generate a 3D scene that’s rendered by WebGL!

In this tutorial we’re going to create a pseudo space scene. We’ll use a bit of smoke and mirrors to generate the final piece, but the final result will be an impressive animation that features the earth rotating about its axis and a randomly generated star field. Once you’ve completed working through the steps below, you’ll have a good sense of how to create your own 3D scene and populate it with objects, apply textures, and create simple animations.

Download three.js

To make it much easier to get started with WebGL, we’re going to use the excellent three.js library. This abstracts a lot of the complexity associated with the WebGL API, and makes a light and simple task out of assigning renderers, shaders, cameras and objects to our 3D world. Download the library from github.com/mrdoob/three.js

Create a simple page

We only need the most basic of HTML pages to test our effect, so create that now. You’ll want to include the three.js library you downloaded in step one, and a smattering of CSS to define the size of your canvas element.

001 < !DOCTYPE html>
002 < html lang=”en”>
003 < head>
004 < meta charset=”UTF-8” />
005 < title>Create a 3D scene with WebGL and Three.js
006 < script type=”text/javascript” src=”scripts/jquery.js”>
007 < script type=”text/javascript” src=”scripts/three.min.js”> 
008 < style type=”text/css”>
009 body {
010 background-color: #000000;
011 margin: 0px;
012 overflow: hidden;
013 }
014
015 #scene {
016 width: 100%;
017 height: 100%;
018 position: relative;
019 margin: auto;
020 }
021 < /style>
022 < script>
023
024< /script>
025
026 < body>
027 < div id=”scene”>
028
029 < /div>
030
031< /html>

The basics

To create a 3D scene using WebGL you need at minimum a scene, a camera and something to put in the scene – an item of some sort. We’ll start by defining our basic properties and objects to be used in our scene. Add the code shown below to generate the basic scene dimensions variables.

001 // set the scene size
002 var sWIDTH = 800,
003   sHEIGHT = 600;

Camera properties

As well as a scene, we’re going to need a camera through which we can view the scene. A camera has a number of properties that we need to set – including a field of view (how much of a scene the camera can see), the focal distance, and the aspect ratio (such as 16:9, 4:3 etc). Add the code below to set variables up for these properties:

001 var cVIEW_ANGLE = 45,
002  cASPECT = sWIDTH / sHEIGHT,
003  cNEAR = 0.1,
004  cFAR = 10000;

Create the renderer

As we’ve already discussed, to create a 3D scene we need a renderer to draw the scene onto the screen. Let’s set that up now. Three.js supports multiple different renderers including the standard Canvas API, but we’re going to use WebGL to draw our scene. Add the code below to create the renderer:

001var renderer = new THREE.WebGLRenderer();

Create the camera

Now we’ve got our renderer set up using the three.js library, let’s set up the camera ready to view our scene! We’ve already set up all the properties earlier on, so all we need to do is add in a call to the perspectiveCamera method to generate our camera:

001 var camera =
002  new THREE.PerspectiveCamera(
003    cVIEW_ANGLE,
004    cASPECT,
005    cNEAR,
006    cFAR);

Make a scene!

Now we’ve got both a renderer and a camera, we’re ready to generate a scene that will hold our elements and appear on our page! In vanilla WebGL this is a bit of an undertaking, but with three.js it’s as simple as writing a single line of code:

001 var scene = new THREE.Scene();

Set it running!

We’re now ready to set our scene rendering out to screen. We start by setting the camera position, then the width and height of the renderer, and finally appending the resulting element to our page DOM using jQuery, before using the renderer to draw the scene. Make sure you’ve grabbed the jQuery library from jquery.com before testing the following code in your browser!

001 // set the default position for the camera
002 camera.position.z = 300;
003
004 // start the renderer
005 renderer.setSize(sWIDTH, sHEIGHT);
006
007 // attach the render-supplied DOM element to the page
008 $(“#scene”).append(renderer.domElement);
009 renderer.render(scene, camera);

Test nothing

If you test your page at this stage, you’ll see that although there aren’t any errors thrown up, there’s also nothing displayed. This is because while we’ve successfully created a scene and camera, we haven’t actually placed anything inside our scene yet – so there’s nothing to draw! We’ll fix that next…

Add a primitive

In three.js there are a series of primitive shapes you can add to your scene as basic building blocks for your items. We’re going to use the sphere primitive to create the earth, but we need to start off by defining how big we’d like the sphere to be. As everything in 3D is split into flat segments, we’ll also define how many segments to break our sphere into.

001 var earthRadius = 50,
002    earthSegments = 16,
003    earthRings = 16;

Generate the mesh

Now we’ve got our variables defined we can create the shape using the Mesh() method within three.js. A Mesh is a way of describing simple geometry. Add the code below to generate your mesh sphere, passing in the variables we just defined as arguments to define the properties of the sphere.

001 var earth = new THREE.Mesh(
002
003  new THREE.SphereGeometry(
004    earthRadius,
005    earthSegments,
006    earthRings),
007
008 earthMaterial);

Add a material

You’ll have noticed we added a final argument to the Mesh object call that referenced a variable we haven’t set up yet – earthMaterial. This will define the texture that we wrap around our sphere to make it look like the planet earth rather than a ball. We’ll define the material now by applying an image we downloaded from the web as a texture:

001 var texture = THREE.ImageUtils.loadTexture( “images/earth_clouds.jpg” );
002 var earthMaterial =
003  new THREE. MeshBasicMaterial( { 004map:texture } ));
005
006 scene.add(earth);

Add light to your scene

To help our scene render we need to illuminate it with a light – otherwise we’ll be looking in the dark! Lights work much like cameras in that they take a set of co-ordinates, but they also have a colour setting. We’re going to set ours to give off white light:

001 // add lighting
002 var light = new THREE.DirectionalLight(0xFFFFFF);
003 light.position.x = 150;
004 light.position.y = 250;
005 light.position.z = 150;
006 scene.add(light);

Create an animation

So far our earth is looking pretty good but it’s sitting in our scene without any movement. To get the earth moving, we need to set it up to rotate about the Y axis. We’ll create a simple animation function that rotates the earth a small amount each time the function is called:

001function animate() {
002earth.rotation.y += -0.0025;
003 renderer.render(scene, camera);
004 }

Call the animation

We could use the time-honoured setInterval method to call our animation function every X milliseconds, but that continues to use computer resources even when the tab isn’t active in the browser, leading to uneccessary processor and battery use. Instead we’ll use the requestAnimationFrame method which doesn’t suffer the same issues. Add the code below inside the animate() function:

001requestAnimationFrame(animate);

Start it off

The final missing piece is to kick-start our animation by calling the animate() function from the main scene setup code. Once it’s been called once, the animate function will continue to be called as a result of the code we added in the previous step. Add a simple call to the function beneath all the existing code:

001 animate();

Reach for the stars!

Our earth is now rotating beautifully about its axis, but we can do more to make our scene look like space – let’s add some stars! We’ll start off by creating a simple particle system that will contain all of our stars’ co-ordinates. Add the code below to generate a random set of co-ordinates for 500 stars:

001 for (var i=0;i<500;i++){
002 var star = new…; // Create mesh object
003 star.position.x = (Math.random()*sWIDTH-(sWIDTH/2));
004 star.position.y = (Math.random()*sHEIGHT-(sHEIGHT/2));
005 }

Add the stars

Now we’ve got our co-ordinates, we need to create them and add each to the scene. This is simply a case of copying our earlier code, and making sure we call the appropriate three.js object in each case to generate the star for each instance. We’re also positioning each in Z space so that it sits behind the earth:

001 for (var i=0;i<500;i++){
002 var star = new THREE.Mesh(new THREE.SphereGeometry(1,1,1),new THREE. MeshLambertMaterial({color: 0xFFFFFF}));
003 star.position.x = (Math.random()*sWIDTH-(sWIDTH/2));
004 star.position.y = (Math.random()*sHEIGHT-(sHEIGHT/2));
005 star.position.z = 0;
006 scene.add( star );
007}

Test and review

Our code is now complete, so fire up your browser for one final test and make sure everything is working as it should. You should see a random pattern of stars spread over the canvas, and these will change each time you refresh the page!

3D graphics and animation has long been possible on the web with the likes of Shockwave or Flash – there’s always been the opportunity to deliver high-quality 3D renders within the browser. But until recently, creating a compelling 3D experience took expensive authoring tools, as well as obtrusive browser plug-ins for rendering. But why? It’s partly because of the bandwidth demands associated with the amount of data required to render high-quality textures, intricate models and shapes, but also the need for powerful graphics, hardware and fast processors. Until now, these requirements were confined to a small percentage of desktop machines, but in the past couple of years that’s all changed: browser-based native 3D has officially arrived!

There are actually several different complementary technologies that can be used to create 3D objects and scenes within your webpages – some you’ll already be familiar with, while others are a little more like dabbling with the dark arts if you haven’t encountered them before. The principle options are Canvas and WebGL, with the option to use CSS3 to create 3D effects.

WebGL itself isn’t actually a 3D system, rather it provides a method to talk to the graphics card of the host computer directly. This means that graphics produced and rendered using WebGL can be enormously impressive, but at the same time the raw code (normally using JavaScript) can be very challenging to pick up. In this feature we’re taking a look at the different options for getting started with 3D in your webpages, and to simplify the development process we’ll use one of the most popular libraries available to abstract WebGL and make it user-friendly to generate simple scenes without having to understand every aspect of the underlying WebGL code.

The primary driver behind the new 3D capabilities of your web browser is the adoption of the WebGL API by browser vendors. WebGL (Web Graphics Library) is an interface that allows JavaScript to talk directly to the GPU (Graphic Processing Unit) of the device running the web browser, and this allows both 2D and 3D graphics to be rendered inside a canvas element on the page, utilising physics models and image processing effects. WebGL is based on the OpenGL ES 2.0 standard maintained by the Khronos Group, and is now supported by all bar one of the main browser vendors.

WebGL content can be created entirely without the need for programming using 3D modelling software such as Autodesk’s Maya, or the free-to-download Blender application. Scenes are exported to WebGL either natively, or using a plug-in in the case of some commercial 3D suites.

Using 3D in the browser requires several things to be provided either using code or the output from a 3D application. At its simplest, each 3D world requires at minimum a scene to place objects within, a renderer to draw the objects, a camera to act as the viewer, and one or more objects (each with one or more materials). For developers already familiar with 3D modelling, this will all come as second nature, but if you’re new to 3D you may find it a bit overwhelming at first.

Thankfully there are a number of different JavaScript libraries that abstract some of the more complicated aspects of procedurally generating graphics and models in WebGL, so you don’t need to understand all these elements to get started. Most of these libraries default to using WebGL as the renderer for 3D scenes, but some also allow you to use the standard canvas drawing API instead. Canvas is more widely integrated and adopted by browser vendors, but it doesn’t benefit from hardware-accelerated graphics.

A word of warning: the standard WebGL API isn’t friendly in the way that, say, jQuery is. It’s more akin to a C programming library than most modern web-focussed systems, making it feel inaccessible when you start out. It’s also quite a common mistake to think of WebGL as being a 3D engine in itself – it’s not actually 3D at all. What WebGL does is make it possible for you to develop 3D applications within the browser, acting more like a drawing API that gives you direct access to hardware-accelerated graphics rendering.

WebGL uses something called a shader to determine how things are drawn on screen. A shader comprises two different elements: the fragment shader, and the vertices. A vertex helps define the shapes of the items drawn, while the fragment shader deals with filling in the pixels that make up the face of these shapes. The manner in which these shapes are rendered is determined by the camera position, which determines how the shapes appear in space, the material, which assigns different colours and textures to the surface of each shape, and the lighting within the scene. Lights are optional with WebGL in that without them, the entire scene will be rendered flat – without any shading at all. This is perfect for a cartoon-like look, but does nothing to help describe the 3D nature of your scene.

WEBGL TOOLS

There are a number of tools you can use to help you generate and render 3D scenes using WebGL. At its most basic, all you need is a browser capable of rendering WebGL and a text editor, but with these tools it’s a little easier to get started

Blender

www.blender.org
Blender is a 3D modelling tool that’s free to download and use. It works across Windows, Mac OS X and Linux, and has a wide range of books and online resources available to help you get started. There’s also an extremely active community offering plug-ins and support, making Blender an excellent way to get started with 3D in general, and WebGL specifically.

Maya 2013

usa.autodesk.com/maya
Maya is a commercial animation and 3D modelling tool that’s widely used in the game and film business to create high-quality 3D scenes and assets. It supports WebGL through a plug-in, which offers native output to WebGL-compatible code, making it simple to set up your scene and render it using the API. Users can download a free trial of the latest version to try out the software.

Sketchfab

sketchfab.com
Sketchfab is a web service that uses WebGL to render and publish 3D interactive content in the browser. It acts as a free repository for 3D models, which can be authored in most of the popular formats including Blender, 3DS and KMZ. The output can be embedded on your site using a YouTube-style player, making it a great way to get started with using WebGL on your website.

USING CSS3 FOR 3D EFFECTS

If you don’t need fancy lighting and textures, CSS is also becoming capable of rendering content in 3D space and can offer an easier solution to generating simple 3D effects in the browser

For simple 3D effects rendered as part of your website user interface, there’s no need to go to the trouble to use WebGL to render your content. Instead, you can take advantage of one of the newer CSS specifications and use 3D transformations and transitions to pull or push your content around in 3D space. The premise is simple: a series of properties are defined for an element defining it’s translation in 3D space using the transform property to affect the item. When combined with the transition property, elements can be animated in response to user interaction, resulting in index cards that flip over in 3D space to reveal additional information behind, or simple spinning 3D cubes.
The 3D transformation module of CSS3 is already well supported by the most common browsers including (amazingly) Internet Explorer 10, Firefox 10+, Chrome 12+ and Safari 4+. Crucially, it’s also supported by many mobile handsets including iOS devices running Safari, Blackberry browser, Android, and Firefox for Android, but not Chrome.

BROWSER SUPPORT FOR WEBGL

Browser support is growing for WebGL, but there are a few restrictions to be aware of when deciding to deploy your content using WebGL as the renderer. Check out our round-up below.

Chrome

Google Chrome has good support for WebGL and is the best browser for high-performance rendering of content, although mobile versions do not yet support WebGL due to graphics limitations.

Firefox

Older versions of Firefox need a slightly different syntax to work, using gl rather than mgl prefixes. Access and force-enable WebGL using the address about:config in the address bar.

Internet Explorer

Microsoft haven’t yet announced any support for WebGL yet, so those users of Internet Explorer will not be able to view WebGL-rendered content natively.

Safari

WebGL is supported on Mac OS X 10.6 and above, but is disabled by default. Enable it by choosing Safari>
Preferences and checking Show develop menu in menu bar, then choose the Enable WebGL option from the Develop menu.

DON’T MISS – A beginners guide to Git for Designers pt1

Tracking Files

To track files, we must first add them to the staging area – or, put them on the truck.

001 git add index.html

Now, if we check the status again, we’ll see:

001 On branch master
002 #
003 # Initial commit
004 #
005 # Changes to be committed:
006 # (use “git rm –cached …” to unstage)
007 #
008 # new file: index.html

Excellent; Git is watching this file for changes. In this case, we’ve only added a single file. If, instead, we’d prefer to add all files to the staging area, we can use the period/full-stop symbol.

001 git add

Keep in mind that the truck hasn’t yet left; we’ve merely loaded a couple of boxes (or files) into the back. To perform the snapshot, and save a copy of the project in its currently tracked state, a commit must be performed, which will be.

001 git commit -m ‘First commit’

Above, we’ve created a new commit, and provided a message of ‘First commit’. With that, our first commit has completed, and the truck has left for the factory, with a copy of the project in the back.

In order to verify your work, you must use a new command: ‘log’.

001 git log
002 commit 02c934fcaf3de7677273b74d8ad3 ed5041066986
003 Author: Jeffrey Way
004 Date: Wed Dec 19 15:07:23 2012 -0500
005 First commit
Perfect. A new commit has, in fact, been created, and it also seems that the commit has a unique reference ID. File that away for now. You can check the status if you would like to.

001 git status

Because no changes have been made since the last commit, Git tells us as much:

001 # On branch master
002 nothing to commit (working directory clean)
90 per cent of your Git usage will follow this cycle.
- Make changes
- Add files to the staging area
- Perform a commit with a message describing the action that took place

Rinse and repeat! Now let’s move on to the next step. As an easy example, perhaps we would like to include a simple reset stylesheet in our project. We will write the most basic (perhaps ill-advised) of resets, as you can see here:
001/* css/reset.css */
002 * {
003 margin: 0;
004 padding: 0;
005 }
Now, return to index.html, and include a reference, such as the below:

001 < !doctype html>
002 < html>
003 < head>
004 
005 
006 < /link>
007 < body>
008 < /body>
009 < /html>

As a basic rule of thumb, just remember that if you are able to describe to the person sitting next to you what change you just made to a project, then it more than likely deserves a commit. This should help you make a decision on whether to commit. Just make sure you do it often. Let’s do it now, in fact; back to the Terminal!

001 git add .
002 git commit -m ‘Add and include reset stylesheet.’

When writing commit messages, it’s generally considered to be best practice to use present tense. So, ‘add file’, not ‘added file’
Fast-forward to tomorrow, and now your boss tells you that they don’t want to use your simple reset file. Instead, they’d prefer to use Normalize stylesheet – necolas.github.com/normalize.css – by Nicolas Gallagher. This is no problem; with Git, this is an easy fix. Let’s revert the previous commit, and then make the necessary modifications.

001 git revert HEAD

This command will reverse all of the changes that you made in the most recent commit. Essentially, it’s a commit that does the exact opposite of what the previous one did. Why revert instead of undoing the commit entirely? Again, because we’re following best practices. With Git, the rule is: ‘never rewrite history’. Revert the changes, but never erase and undo them.
Upon hitting enter, you’ll be brought to a new screen with the text *”Revert “Add and include reset stylesheet.”* At this point, you’re in Vi mode (though you’re free to configure Git to use any code editor that you wish). For now, go with the defaults, save, and exit. Accomplish this by typing :wq (Write and Quit).
And with that single command, the changes have been reverted. Go ahead and check to make sure. The Tracking Files
To track files, we must first add them to the staging area – or, put them on the truck.

001 git add index.html

Now, if we check the status again, we’ll see:

001 On branch master
002 #
003 # Initial commit
004 #
005 # Changes to be committed:
006 # (use “git rm –cached …” to unstage)
007 #
008 # new file: index.html

Excellent; Git is watching this file for changes. In this case, we’ve only added a single file. If, instead, we’d prefer to add all files to the staging area, we can use the period/full-stop symbol.

001 git add .

Keep in mind that the truck hasn’t yet left; we’ve merely loaded a couple of boxes (or files) into the back. To perform the snapshot, and save a copy of the project in its currently tracked state, a commit must be performed, which will be.

001 git commit -m ‘First commit’

Above, we’ve created a new commit, and provided a message of ‘First commit’. With that, our first commit has completed, and the truck has left for the factory, with a copy of the project in the back.

In order to verify your work, you must use a new command: ‘log’.

001 git log
002 commit 02c934fcaf3de7677273b74d8ad3 ed5041066986
003 Author: Jeffrey Way
004 Date: Wed Dec 19 15:07:23 2012 -0500
005 First commit
Perfect. A new commit has, in fact, been created, and it also seems that the commit has a unique reference ID. File that away for now. You can check the status if you would like to.

001 git status

Because no changes have been made since the last commit, Git tells us as much:

001 # On branch master
002 nothing to commit (working directory clean)
90 per cent of your Git usage will follow this cycle.
- Make changes
- Add files to the staging area
- Perform a commit with a message describing the action that took place
Rinse and repeat! Now let’s move on to the next step. As an easy example, perhaps we would like to include a simple reset stylesheet in our project. We will write the most basic (perhaps ill-advised) of resets, as you can see here:
001/* css/reset.css */
002 * {
003 margin: 0;
004 padding: 0;
005 }
Now, return to index.html, and include a reference, such as the below:

001 < !doctype html>
002 < html>
003 < head>
004 < title>
005 < link rel=”stylesheet” href=”css/reset. css”>
006 < /link>< /head>
007 < body>
008 < /body>
009 < /html>

As a basic rule of thumb, just remember that if you are able to describe to the person sitting next to you what change you just made to a project, then it more than likely deserves a commit. This should help you make a decision on whether to commit. Just make sure you do it often. Let’s do it now, in fact; back to the Terminal!

001 git add .
002 git commit -m ‘Add and include reset stylesheet.’

When writing commit messages, it’s generally considered to be best practice to use present tense. So, ‘add file’, not ‘added file’
Fast-forward to tomorrow, and now your boss tells you that they don’t want to use your simple reset file. Instead, they’d prefer to use Normalize stylesheet – necolas.github.com/normalize.css – by Nicolas Gallagher. This is no problem; with Git, this is an easy fix. Let’s revert the previous commit, and then make the necessary modifications.

001 git revert HEAD

This command will reverse all of the changes that you made in the most recent commit. Essentially, it’s a commit that does the exact opposite of what the previous one did. Why revert instead of undoing the commit entirely? Again, because we’re following best practices. With Git, the rule is: ‘never rewrite history’. Revert the changes, but never erase and undo them.
Upon hitting enter, you’ll be brought to a new screen with the text *”Revert “Add and include reset stylesheet.”* At this point, you’re in Vi mode (though you’re free to configure Git to use any code editor that you wish). For now, go with the defaults, save, and exit. Accomplish this by typing :wq (Write and Quit).
And with that single command, the changes have been reverted. Go ahead and check to make sure. The style.css file has been removed, and there is no longer a reference to the stylesheet within index.html. This is the power of Git! Because we adopted a development style of committing often, when placed in situations where edits need to be reversed, it only takes a single command. No more pressing Cmd+Z for eternity, making life much simpler.
Following the boss’s earlier request, now let’s make sure we update the project to use Normalize.css, which we have already downloaded and placed within css/normalize.css. Within index.html, reference it:

001 

And, finally, we commit the changes:

001 git add .
002 git commit -m “Include Normalize in project”
Though this was certainly a simple example, imagine how useful this technique can be for larger changes, which span multiple files within your application. By grouping all related changes into a single commit, we achieve maximum flexibility and security.

Room to Experiment

Ever been at a point in a project, when you want to experiment with an idea that may or may not make it into the finished application? You can always revert the commit if things don’t go according to plan, but it’s a smarter idea to instead leverage branching.
The best way to illustrate the concept of Git branches is to reference Back to the Future 2. (On that note, if you’re a nerdy developer and haven’t watched the Back to the Future trilogy, stop what you’re doing right now and watch them!)
Remember the part in Back to the Future 2, after Marty and Doc return to 1985 from the future to find everything is different? Upon meeting at Doc’s now-destroyed lab, Doc draws a diagram, describing how “the timeline skewed into this tangent, creating an alternate 1985.” This is just like branching.
Consider our current demo project; right now, there’s one timeline: a straight line. As soon as we create a branch to work on our idea, we break away from this timeline, and create another one. At this point, both timelines exist, and can contain their own respective commits, without interfering with one another.
How is this useful? Consider an agile development cycle – one where you or your team deploy updates multiple times each week. If you stick with the ‘single timeline’ approach, deploying a simple typo fix, for example, it would not be possible until you finished working on your idea as well. With branching, however, we have the flexibility to take as long as we need on our idea, while still freeing the master branch (the default and primary one) for deploying the typo fix.

To create a new branch, run:

001 $ git branch idea 002 $ git checkout idea

Alternatively, combine these two commands into one:

001 git checkout -b idea

This translates to: create a new branch called ‘idea’ (replace this to be more descriptive of what you are working on, of course), and then switch over to it.
From this point on, any modifications and commits that you make will not be referenced within the master branch. Go ahead and try it out for yourself. Simply edit index.html and make a small change:

001 < body>
002 < h2>My Idea
003 < /body>

Then, commit your work:

001 git add index.html
002 git commit -m ‘First draft of my idea’

We’ve now made our first commit in this new timeline. Our fictional idea still needs work, but we’re on our way! But now a customer just reported a typo that we need to fix as soon as possible. Because we’re correctly using branches, we can return to the master branch, fix the typo, and deploy it.

001 git checkout master
002 # fix typo
003 git add index.html
004 git commit -m ‘Fix small typo’
005 git push

Once our idea feature is finished, it’s time to merge it back into the master branch.

001 git checkout master
002 git merge idea

If all goes according to plan, your feature branch will successfully be merged back into the master branch, resolving the alternate second 1985 timeline!
That said, you’ll undoubtedly come across situations when Git seemingly plants its feet into the ground, and refuses to continue as asked. In these cases, Git isn’t being awkward for no reason! Most likely, the problem relates to some conflict that first needs to be resolved before Git can proceed. Imagine attempting to merge a file back into the master branch; the only problem is that, since the branch was created, the file has been edited in both the feature branch, as well as the master. In situations such as this, how could Git possibly know which version of the file should take precedence when merging the two? It doesn’t in fact know, and this is what we call a conflict.

001 Auto-merging index.html 
002 CONFLICT (content): Merge conflict in index.html
003 Automatic merge failed; fix conflicts and then commit the result.
Before Git can proceed, you must resolve the conflict, by editing index.html.

Ignoring Files

There will likely come a point when you determine that it’s best to not track certain file types with Git. Examples might include the common .DS_STORE (with which Mac users will be familiar), build directories, and temporary compiled assets.
Easily enough, Git allows us to ignore certain file types via a .gitignore file. To make use of this, create a new .gitignore file in the root (but not limited to) of your project. Within it, provide a list of files or file types to ignore. Here’s a basic example:

001 .DS_STORE
002 build/
003 *.log
004 *.sql
005 *.exe

Social Coding

So far, you’ve learned how to commit your code locally. But, how can these modifications be shared with either your team or the rest of the world? Enter GitHub.
GitHub will allow you to share your code with the entire world, and it is the largest open source community in existence.
Once you sign up for a new account at github.com, you’ll need to follow a few steps to generate a special key, in order to associate your computer with your GitHub account. Don’t worry; if you follow the steps, you shouldn’t have any problems.

At this point, we can create a new repository, and push our little project to share it with the world. Once logged in, click the ‘New Repository’ button, give your repo a name, and click ‘Create Repository’. Next, you’ll be presented with a few commands that can be pasted into the Terminal. As we already have an existing repo, we need the second option:

001 git remote add origin https://github.com/ USERNAME/project.git 
002 git push -u origin master
This instructs Git to add our new remote repository, and alias it as ‘origin’. Next, we will push the master branch (not the idea one, remember!) to the remote with the alias of ‘origin’.
That’s it! Return to the browser, refresh the page, and you’ll find your fresh new repository, waiting to be shared with the rest of the world.
When other members of your team would like to pull in the changes that you have made, they only need to run the following:

001 git pull

This command will pull in the latest updates that have been pushed to GitHub! In addition to sharing code, GitHub also offers the ability to track and contribute to popular open source projects, as well as an issue tracker for bugs and feature requests. It’s social coding at its best!

Closing Thoughts

Though we’ve only scratched the surface of what Git is capable of, the truth is that, again, for 80 per cent of your Git usage, the techniques referenced in this article will suffice. Create a feature branch, write some code, add it to the staging area, and commit it with a message. When ready, merge it back into the master branch, and deploy. Next, rinse and repeat!
Don’t forget: when stumped, StackOverflow is your best friend. Whatever the problem may be, others have been in the exact same situation. Search there first.

Back in the Seventies, cognitive psychologists started to realise that all humans tend to make the same categories of mistakes, which they named cognitive biases. They had effectively found a set of mental Achilles heals that we’re all prone to.

It became obvious that this discovery could be applied in different ways. We could use this knowledge for the benefit of mankind, to help avoid things like industrial accidents and catastrophic errors in judgement – or we could use it as a weapon of deception, to get one-up on our fellow humans.

In about 2005, cognitive biases became a hot topic in web design. What’s interesting is the way we as an industry reacted to this knowledge. Sadly, we didn’t turn the lens of analysis on ourselves – we didn’t say ‘hey, what does this mean about the way we make design decisions?’ or ‘How can we prevent these biases from tripping up our users?’. A lot of web designers decided to go for the dark side and asked ‘how can we exploit these biases? How can we use them to really push our conversion rates up?’

Like casino architects who install bright lighting and hide clocks, or advertising executives who sell products on half-truths, a number of us have decided to apply our new-found understanding of psychology to create subtly deceptive user interfaces that nudge or trick users into doing things – using techniques now known as dark patterns. Whether it’s low cost airlines that sneak travel insurance into your basket, or eCommerce sites that signs you up for a monthly membership through hidden small-print, these tricks have started to become increasingly common. As an industry, we desperately need to take a stance – which of these patterns are acceptable, which are borderline and which should be outright banned?

How Do Dark Patterns Work?

The interesting thing about dark patterns is that they are designed from the exact same corpus of knowledge that we use to enhance usability. This means that if you’re a good web designer capable of creating great user experiences, you probably already have the know-how to create some very sinister dark patterns. All you need to do is take the usability principles you know and then invert them, as shown in the table below.

Why do businesses use Dark Patterns?

Dark patterns typically boil down to a judgement about ethics. There is always going to be a tension between what customers want – low prices and outstanding service – and what businesses want – namely maximizing profit. It’s no surprise that businesses want to experiment with what’s possible. After all, they often find combinations that customers find acceptable. For example, it’s slightly manipulative that supermarkets put bread and milk at the back of the store to tempt people to walk past the rest of their stock but people don’t tend to mind. IKEA takes this principle even further, and turns the entire store into a maze – customers might moan a little, but they keep flocking back. Similarly, nightclubs often allow the queues outside to run around the block even when they’re not yet busy inside, just to attract more passers-by. People seem to accept that it is something they need to do to stay in business, and it’s just the cost of being a customer with them.

The real allure to online businesses is that dark patterns push conversion rates up. They tend to win in A/B tests and, as far as the analytics data goes, they appear to be a good thing. In reality though, there are many things that analytics data doesn’t capture. Whenever a customer notices that they’ve been caught out by a dark pattern, they’ll develop a negative opinion about the personality of the brand. If that brand continues to try to take advantage of the customer, they’ll begin to hate them and they’ll spread that opinion among their friends. Even if the company has no ethical qualms and doesn’t mind being perceived as a bit low end, there’s still a very real risk that customers will migrate to a less frustrating competitor. After all, this is the web – competitors are only one click away.

Trick Questions

Trick questions are one of the most common types of dark pattern, often seen in the marketing communication options of registration forms. Trick questions rely on the fact that people usually scan web pages rather than reading them word-for-word like a novel. For example, since checkboxes are usually taken to have a positive sentiment, some sites use double negatives to flummox users and make them believe they are opting out when they are actually opting in to.

A tick usually means yes – except when combined with a negative statement, tripping up many users.
Another similar deceptive trick is to show a series of marketing options but to alternate the sentiment, so that ticking the checkbox causes an opt-in on one line, and causes an opt-out on another. Users have to really keep on their toes to avoid being duped. Here users are likely to be confused by the way the sentiment is switched on different lines.

Trick questions are known to boost conversions, so they look impressive on your analytics dashboard, but they lower the quality of the lists generated. What’s more, they can end up really irritating users, defining the personality of your brand in their minds as one that’s quite annoying. Arguably, if you don’t mind being perceived as a seedy ‘price-‘em cheap, stack-‘em high’ type of business then this is just about okay, but on the other hand, users only have a limited amount of patience and your competitor isn’t far away.

Forced Continuity

This is a particularly devious trick that involves getting users to sign up to a paid monthly membership when they think they are only buying a one-off product.
One large fashion retailer in the USA has recently had a class action lawsuit raised against them for using this pattern. Their implementation of the trick involved sticking a clause in their terms and conditions which stated that buying a single item would automatically enrol customers into their VIP membership program.
On its own that sounds benign enough, until the customer checks their credit card to find a repeating monthly charge of a certain amount – a sum small enough to go unnoticed for quite some time. Very cheeky indeed, and most likely illegal in the UK. Small print can be used to hide all sorts of tricky clauses, but surely this is going too far?

Bait and Switch

This involves enticing users in with an attractive sales pitch, only to reveal a far less desirable outcome. Bait and switch is one of the oldest tricks in the book, and it even features in fairy tales like Rumpelstiltskin. In spite of this familiarity, it’s still an effective trick on the web. One popular implementation used on travel sites is to hook the user in on a low price, cleverly labelled with the prefix ‘From…’ then showing a high price when they select their specific dates and configuration at a later stage. An even more worrying variant of this is allegedly being tested by some unscrupulous online retailers (a type of ‘dynamic pricing’) whereby the cost of tickets or other time-sensitive items are automatically increased if a user returns to a product detail page after viewing it a few days previously – not because of increased scarcity, but simply because of the user’s behaviour pattern.

Sneak into basket

This pattern was popularised by low-cost airlines who have a habit of sneaking insurance into users’ baskets when they’re trying to buy flights online.

Most eCommerce websites show an upsell page prior in their checkout flow, serving the purpose of enticing you into buying extras and add-ons. For airlines, travel insurance has one of the best profit margins among the upsells, so some sites subtly preselect this option, requiring the user to take action to opt out, rather than to opt in. This additional ‘cognitive friction’ is enough to push sales, and many users don’t even realise they’ve bought insurance until it’s too late. Often when they do realise, the price point is so low (usually around £10) that they feel it’s barely worth the effort to call up and jump through a load of hoops to cancel it. If a user doesn’t stop to read the details here, they’ll end up buying the insurance upsell without even realising.

Faraway Bill

If an organisation hides a user’s bills, then it’s easy for them to overspend. This is a grey area, and it’s not clear if it is a dark pattern in all cases. Under the premise of green initiatives, many organisations have switched to eBilling, where they need to log in, navigate to the appropriate area, and click through a number of menu items. This is unlike the days of paper bills where all you had to do was open an envelope. Since many billing systems run on legacy software that is hard to update, some might argue that this is just bad design rather than actively nefarious. Either way, more effort needs to be made to communicate with end users.

Friend Spam

Apps and games ask for permission to access to your account. Some exploit this and secretly publish content as if it is was written by you. One person gives an app access to their account, it then publishes an endorsement that appears to be written by the user. Following this, a few of their friends see the post, trust it as a reliable source, they all register, and the app publishes more endorsements. This permissions dialogue is asking a user to allow a game to post endorsements. But how can a user endorse something they’ve yet to see?

Privacy Zuckering

When social networks first appeared, many consumers didn’t realise that ‘if you’re not paying for the product, you are the product’. It’s in a social network’s commercial interests to collect your personal information and expose it in ways that are commercially beneficial, such as behavioural ad targeting, using your face to endorse products, or encouraging you to post about brands. However, they need your legal permission to do this, so how do they get around it? Funnily enough, they don’t have a large button that says ‘sell my personal details to advertisers’ – they’d go out of business. Instead they obfuscate their user interface in such a way that hides your settings and makes it hard work for you to get the exact level of privacy that you want. Of course there’s nothing wrong with a business model that relies on targeted advertising, but it needs to be to be transparent and honest if it’s going to earn the trust and respect of their user-base.

Roach Motel

This is when a site has fantastic usability in registration, but is difficult to leave. Most websites have a lot of attention focused on perfecting their sign-up process, because this is where membership revenue comes from. However, churn is always a problem: a business needs to keep the inflow higher than the outflow or it will die. The best solution is to provide a good service, tempting users to stay of their own accord. However, the dark pattern approach is to try to trap them, to generate more revenue from recurring membership fees. For example, instead of having a Cancel Account button, the business could require the user to ring a call centre. This is more effort, so the user might delay, generating more revenue. When they do finally call, the call centre operative can try to convince them to stay, offering a last-ditch discount or freebie.

User Profile Price Discrimination

It’s easy for a server to find a user’s location and platform, but is it ethical for an eCommerce site to alter prices if they think you’re rich? A recent Wall Street Journal article (on.wsj.com/Tj1W2V) found that a number of different US eCommerce companies were detecting users’ locations and serving up higher prices to people in richer areas. The companies argued that this was done simply to match the prices in their local bricks-and-mortar stores. Users were understandably upset when they found out, because the price changes seemed arbitrary and punitive – it’s not as if it was costing the company any more to serve each different location. It’s interesting to consider that price discrimination is a very grey area. For example, people don’t mind the fact that tickets go up in price nearer the date. In the UK we’re used to paying more for electronic goods than the USA. But it seems that profiling users without their knowledge is an act that mixes privacy concerns with unfair discrimination, and many people find this too bitter a pill to swallow.

Conclusion

Back in the fifth century, Greek physicians realised the power that came with their newfound knowledge, so they wrote the Hippocratic oath. Should we do the same in web design? It’s clear that the combination of applied psychology and user interface design can be very powerful. Heavy-handed regulation rarely ends well – we all know how the cookie law panned out – so isn’t it time we take matters into our own hands and agree upon a set of rules to work by? One thing’s for sure: if we continue to ignore it, this problem is only going to
get worse.

You’re likely to be familiar with tools such as Git and Subversion. However, although you might claim that you leverage version control in your web-design projects, more often than not, you probably don’t.

If you think you’re guilty of not doing this, you’re certainly not alone. In fact, it’s more than likely that the majority of web designers don’t use version control properly in their projects, if at all. The dilemma stems from the common belief that version control is strictly for hardcore coders; those who spend most days in total darkness, and who rarely come up for air. This isn’t and shouldn’t be the case.
In reality, if you code for the web, whether on the front-end or back-end, it’s your duty to code responsibly, so make sure you use version control.

Five Signs That You’re Overdue for Version Control

1. You have no concept of what version control is, or why it might be useful.
2. You code locally, and have no backup system.
3. You back up your projects by sporadically duplicating the root directory.
4. You accidentally deleted a file permanently, and had to recode from scratch.
5. Upon making a number of edits, your application breaks, at which point you have to hold down Command+Z for a painful number of seconds, as you watch the editor reverse your changes.

It’s likely that every developer has identified with one of the above signs at one point or another in his or her career. But remember the first step to recovery is to admit that you have a problem!

Five Immediate Benefits to Version Control

1. Accidentally deleted that class or PSD? Run a single command in the Terminal to revert to a previous state in the project. Disaster avoided!
2. Ever gasped in horror, as your website somehow vanished from your desktop? It was there yesterday, but today it’s gone! A free service, called GitHub, makes this a non-issue.
3. Who the heck would write this bit of code that I now have to spend hours re-writing? No need to wonder who’s to blame; Git will tell you.
4. Code with abandon, while knowing that, with each commit, ‘snapshots’ of your application are being saved, just in case you need to roll back to this state at some point in the future.
5. Accept that developers, who are likely to be far more seasoned than you, have deemed it a best practice. It’s helpful to mimic those we admire, and this situation is no exception.

How git works

So how does Git actually factor into this whole version control thing? Well, the super nerdy definition is that Git is a distributed version control system, developed by Linus Torvalds, where each working directory is its own repository with the full history available at any point. In addition to this, Git also offers the ability to share code, and create multiple branches (or timelines) for your projects, making it particularly suitable for agile development teams.
A more understandable definition might be: Git is a command-line tool that you – and any other developers on your team – can use to save frequent snapshots of your projects. At any given point, it offers the flexibility to roll back changes to previous states, with only a single command.

Installing Git

Certainly, the first step to wreckless ‘cowboy coding’ recovery is to download Git from git-scm.com. Use either of the following URLs, depending upon your operating system.
- Mac git-scm.com/download/mac
- Windows git-scm.com/download/win
Next, we need to configure the installation just a touch, by associating a username and email address. Open your nearest console (Terminal on the Mac), and run:

001$ git config –global user.name “Your Name”
002$ git config –global user.email email@ example.com

This only needs to be typed once, right after you first install Git. Now, for every action that you take, Git will use these settings.
There are further configuration options, such as specifying which code editor should be used when Git requires you to type in a commit message, but ignore that at the moment. Now Git is successfully installed!

The Basic Cycle

One of the most difficult aspects of learning Git is deciphering what the various jargon refers to. Commits; staging; branches; logs – it can be confusing.
As with any new technology, there’s a small bit of learning required. Luckily, as complex as Git can be, particularly as a web designer, you’ll find that a handful of commands will go a long way. For comparison, consider the English dictionary, and then the number of words that we realistically use in everyday conversations. The same is true for Git – at a much lower level. So don’t feel overwhelmed. Take it one command at a time.
To knock out this confusing terminology, it might help to think of something tangible in the real world, such as a delivery truck. We’ll refer to this analogy later.
First, imagine that you’ve begun a new static website. You’ve created folders for JavaScript and CSS files, as well as an index.html file with a bit of boilerplate HTML. In fact, do that very thing right now! When finished, it’s time to create the first commit.
Return to the Terminal, and type:

001git init

This command, ‘initialise Git’, informs Git that we desire version control for this project. It ‘starts the ignition’ of our delivery truck. It only needs to be executed once, at the start of a new project’s life cycle.
Next, let’s determine what the ‘status’ is.

001git status

If working along, you’ll likely see something along the lines of:
001# On branch master
002# Initial commit
003# Untracked files:
004# (use “git add …” to include in 
what will be committed)
005# index.html
nothing added to commit but untracked files present (use “git add” to track)

Though somewhat confusing, if we take a moment, we’ll see that, by default, we’re working on a ‘branch’ called ‘master’. Next, we have one untracked file: index.html. From this, we’re able to decipher that Git isn’t magic; it must be told which files to monitor.
Curious why the JavaScript and CSS directories aren’t included in the list of untracked files? Git tracks files, not folders. A common technique, though, to include empty directories in a commit is to add a .gitignore file to each subdirectory. More on that later.

DONT FORGET TO COME BACK FOR PART TWO. THIS WILL INCLUDE TRACKING FILES, EXPERIMENTING, IGNORING FILES AND SOCIAL CODING

01. FANCY SKEWED HEADER TEXT

Once again, with CSS3, we can avoid relying on our graphic editor and create easy to maintain typography effects. This effect will use a number of different features to produce a 3D, skewed header. First, our HTML:

001< h1 data-text=”CSS3 Type”>CSS3 Type< /h1> 

A simple < h1> tag with our header text, but notice the unique custom data attribute that duplicates the header’s text – this will come into play in a moment. Now our CSS:

001 h1 {
002 display: inline-block; 
003 font-family: “Archivo Black”, sans-serif;
004 text-align: center;
005 colour: #ff5500;
006 text-transform: uppercase;
007 font-size: 90px;
008 transform: skew(-14deg) rotate(-6deg) translateZ(0);
009 position: relative;
010 z-index: 5;
011 white-space: nowrap;
012 border-top: solid 6px #ff5500;
013 border-bottom: solid 6px #ff5500;
014 line-height: 100px;
015 padding: 0 0 7px 0;
016 margin: 0;
017 }
018
019 h1:after {
020 content: attr(data-text);
021 display: inline-block;
022 position: absolute;
023 colour: white;
024 top: 5px;
025 left: 5px;
026 z-index: -1;
027 text-align: center;
028 white-space: nowrap;
029 }

A few things can be discussed here. First, we’re combining three different transform functions. The -6 degree rotation rotates the text, but rotation alone looks sloppy. If we combine the rotation with a slight skew, however, we give the rotated text a sleeker look.
But that’s not all. To add depth to the text, we duplicate it with a pseudo-
element. That’s where our custom data attribute comes in. We can grab the content of that attribute using the attr() function as the value for the content property. Then we just have to style the text to match the header.
First we position the pseudo-element absolutely. We make it white, and we put it below the other text by giving it a z-index value of -1. We also position it 5px offset from the original text, so it is visible. The rest of the styles are inherited from the main element, giving the duplicate text look.
There are other styles shown in the code that are not discussed here, and we’ve also used a custom font from Google Web Fonts. All of this is really incidental: the main parts to focus on are how we used transforms to alter the look of the text, and then duplicate it using a pseudo-element and a custom data attribute.

02. PRINT STYLE MULTI-COLUMN LAYOUTS

With the advent of responsive design, many websites now appear at large widths on larger screens and then respond accordingly. On a site with such a wide layout, long strings of text can become difficult to read.
As an option, you may consider using CSS3’s multiple columns feature. Let’s see how this would work on a simple page that has multiple paragraph elements on a wide display. Here’s the CSS:

001.wrap {
002 padding: 20px;
003 margin: 0 auto;
004 max-width: 1400px;
005 column-count: 2;
006 column-width: 50%;
007 column-gap: 3em;
008}

Here we’re using the column-count property to define how many columns to divide our text into, and we’re setting each column’s width at 50%, which makes this section of our page responsive.
The column-gap property defines the space we want between columns. We’ve left out the column-rule property, which allows us to define a vertical rule between the columns.
As an option, we could change the number of columns we want to define (and subsequently the size of each column) depending on the size of the screen using media queries. For example, on the smallest devices we could revert to a single column and on very wide screens the columns could be divided into three.
The CSS3 spec has additional related properties that help get better control over the look of the columns, related to column breaks, spanning columns, and filling columns. Not all these properties have full browser support, however.
Finally, remember to test how the columns degrade in non-supporting browsers. For example, a single column may not be readable on IE8 at 1,400px wide. Due to the performance hit, polyfilling is not recommended for this type of feature. You’re much better off degrading gracefully to a single column at a reasonable width, rather than slowing down the page considerably on what is already a much slower browser.

03. PATTERNED BACKGROUNDS

This has gained notoriety in large part thanks to Lea Verou’s CSS3 Patterns Gallery.
The basic concept is based on the use of CSS3 gradients to create repeating background patterns without images, thus reducing HTTP requests. Of course, if the gradient code is too large or convoluted, then the benefits may end up outweighing the drawbacks,
so you’ll have to consider that if you use this technique.
In almost all cases, this technique requires layering multiple gradients (thus taking advantage of multiples backgrounds in CSS3) along with the use of background-size and background-position. The example shown here creates a brick background.

04. PAGE CORNER ADS

Most developers have seen code libraries and scripts hosted on GitHub. The websites for these projects often have a ‘fork me on GitHub’ promo in the top-right corner of the page. Normally, this is a triangular image, with an annoyingly square clickable area.
Other page corner promos are similar. We’re going to create one that’s more intuitive and only the triangular shape will be clickable. Here’s the code:

001.page-wrap {
002 position: relative;
003 overflow: hidden;
004}
005.corner-ad {
006 display: block;
007 width: 210px;
008 height: 190px;
009 background: 010linear- gradient(#ffaa00, #ffbb33);
011 transform: rotate(45deg) translateZ(0);
012 position: absolute;
013 right: -100px;
014 top: -90px;
015 text-align: center;
016 line-height: 330px;
017}

Besides some common styles removed for brevity, we have a regular box-shaped element. But to make it look triangular, we hide the top by rotating it with CSS transforms and positioning it into the corner of the page with absolute positioning.

05. HIGHLIGHT PAGE SECTIONS

The :target pseudo-class lets you style a part of the page that matches a fragment identifier, defined as part of the URL of the current page. This is the kind of thing often referred to as ‘in-page links’. The href values of such links begin with a hash symbol (#).
In our HTML, we might have sections that look like this:

< section id=”one”>< p>Content for one< /p>< /section>
< section id=”two”>< p>Content for two< /p>< /section>
< section id=”three”>< p>Content for three< /p>< /section>
004 //code ends//

If a link points to #one, we can style that section differently when it’s visited. Here’s the CSS:

001 :target {
002 background: #ccc;
003 }

It’s as simple as that. With this in our CSS, every ID in our HTML that matches a hash in the URL will cause those styles to be applied to that element. This technique is used on Wikipedia to help the user see which footnoted reference has been selected.

06. ANIMATE FORM FIELDS ON FOCUS

In most cases, when CSS transitions are added to a page, they’re associated with hovering over elements. But transitions can occur as a result of any event on the page that causes changes to the CSS. One of these events is giving an element focus with the cursor.
CSS has a pseudo-class called :focus that lets us select the focused state of an element. When we combine this with CSS3 transitions, we can create a highly intuitive experience when a user is interacting with form fields.
Here’s how the code will look:

001 input {
002 width: 280px;
003 transition: width 1s 004ease;
005 }
006
007 input:focus {
008 width: 340px;
009}

It’s that simple. An effect that in the past required JavaScript, is now just a few lines in CSS

07. MULTIPLE BORDERS

There are a few different ways to put multiple borders on a single element. You can use a pseudo-element, a combination of border and outline, or even an extra nested element in your HTML.
One of the simplest ways to do this is using the box-shadow property. Here’s the code:

001 .example {
002 width: 400px;
003 height: 400px;
004 box-shadow: 0 0 0 6px #1ac4e6, 0 0 0 12px #3355ff; 
005 }

The key to this effect is how we define the box shadow. First, we ensure there’s no blur (the third value in each shadow value set). This keeps the shadow sharp, so it’s straight, like a border would be. Next, we use the spread value (the fourth value) to size our borders.
We could alternatively utilise the offsets (the first two values), but the spread alone is enough to give us the effect we want.

08. MAKE AN ELEMENT RESIZABLE

In many browsers, a textarea form element by default has a handle in its bottom right corner that allows the user to resize it. This is great for usability.
But these aren’t the only UI elements that could benefit from being resized by the user. Let’s make a simple div element resizable:

001 .resize-this {
002 width: 300px;
003 height: 300px;
004 border: solid 2px #aaa;
005 background: #ddd;
006 overflow: auto;
007 resize: both;
008 }

Two things are needed here. The resize property needs to be set, which can be a value of both (meaning the element can be resized vertically and horizontally) or one of either. The second thing needed is an overflow value of something other than visible. This makes the resizing handle appear on the element.

09. FORCE HARDWARE ACCELERATION

Usually only in WebKit browsers, you may notice certain bugs occurring when using transforms, transitions, or animations with CSS3. By default, browsers do not invoke hardware acceleration for these features, but you can tell the browser to do so with a single line of code:

001 .example {
002 -webkit-transform: translateZ(0);
003 }
004

This line will trigger hardware acceleration and can fix a number of issues that occur in WebKit-based pages. Streaks that occur behind animated elements will disappear; jagged edges on transforms will appear straight; rough looking text will look smooth; pages will not blink during animations or transitions. So if you notice any of these problems, add this property to the problematic element and it should improve things greatly.

10. MEDIA QUERIES FOR IPAD

With responsive design being one of the most prolific trends in web design, it’s useful to consider what styles can be used to target a specific device size and orientation. Media queries are declared using the @media directive in conjunction with conditional media features. The following syntax targets the iPad in both landscape and portrait mode:

001 @media only screen 
002 and (min-device-width: 768px)
003 and (max-device-width: 1024px) {
004 /* selectors and styles go here
005 */
006 }

If you want to target iPad in landscape mode alone, you would do this:

001 @media only screen 
002 and (min-device-width: 768px) 
003 and (max-device-width: 1024px) 
004 and (orientation: landscape) {
/* selectors and styles go 
here */
005 }
006

And to target the iPad in portrait mode:

001 @media only screen 
002 and (min-device-width: 768px) 
003 and (max-device-width: 1024px) 
004 and (orientation : portrait) {
005 /* selectors and styles go
006 here */
007 }

This is just a small sample of the flexibility of media queries. As a supplement, you can visit ipadpeek.com for a quick look at how your website looks on an iPad.

HTML and CSS are the building blocks of webpages. The CSS3 specification modules have added a great number of new features to the CSS specs that allow us to spice up our pages and avoid extra markup, overuse of decorative images, and other coding annoyances. Here we will utilise shadows, transitions, new selectors, pseudo-elements, and much more. This is really just the beginning, and should give you a good overall view of what is possible with pure CSS without relying too much on images or bloated scripts and libraries.

Of course, in most large projects, you’ll still rely on utility libraries like jQuery and Modernizr; images will always be a part of your content. But with CSS3 your dependence on scripts and images will fall dramatically, and you’ll find yourself designing right in the browser much more often. CSS3 makes so much possible, and often with very little code in comparison to what we used to do with extra markup and cut-and-paste scripts.The techniques and tips chosen in this feature are practical for solving real-world problems and adding flair and creativity to your pages and interfaces. But, keep in mind the principles and concepts that can be gleaned from all these techniques. Understanding the concepts behind these tips can help you come up with newer and better ideas in your future projects.

01. Scaled animated background images

Using transitions along with the background-size property, we can add a neat rollover effect to a promo box. Here’s the pertinent code for you to try:

001.bg {
002 background: url(example. png);
003 width: 400px;
004 height: 260px;
005 transition: background- size .5s ease-out;
006 background-size: 100% 100%; overflow: hidden;
007 cursor: pointer;
008}
009
010 .bg:hover {
011 background-size: 110% 
110 %; background-origin: 
012 border-box;
013}

The background image should be purely decorative, not essential to the content – otherwise an inline image is more appropriate. When the user hovers over the element, the background-size property is transitioned to a larger size. For this to work, we need to set the initial background-size on the element, and hide the overflow. Changing the background-origin on hover adds more. A similar technique is used on the Webdesigner Depot photos (www.webdesignerdepot.com).

02. Tucked corners

The Gravatar.com homepage displays a promo box with a tucked corners effect. This type of thing makes an appearance in print design, and no doubt developers have used images and extra markup to achieve something similar on the web.
The beauty of this technique, as with many CSS3 techniques, is that you don’t require images and the code is quite easy to understand and maintain. Let’s take a look at the code:

001. tucked-corners { 
002 background: #fbfbfb;
003 position: relative;
004 box-shadow: 0 1px 25px hsla(0,0%,0%,.2);
005}
006
007. tucked-corners:before,
008. tucked-corners:after {
009 background: #d2d2d2;
010 content: ‘’;
011 width: 100px;
012 height: 50px;
013 position: absolute;
014 top: -25px;
015 box-shadow: 0 5px 10px -7px hsla(0,0%,0%,.5);
016}
017. tucked-corners:before {
018 left: -50px;
019 transform: rotate(- 02045deg);
021}
022. tucked-corners:after {
023 right: -50px;
024 transform: 025rotate(45deg);
026}

What we’ve done here is use :before and :after pseudo-elements to add to new elements as children of the . tucked-corners element. Each of these pseudo-elements is given the same background colour as the page, which allows the pseudo-elements to blend in seamlessly with the background of the page. Each pseudo-element is styled with multiple CSS features to produce this effect. First, a box-shadow helps the pocket-like look that overlaps each corner of the main element.
Of course, in order to position the pseudo-elements, we’ve employed absolute positioning, along with a specific height and width for each corner pocket element.
Finally, the part of the code that really brings this effect to fruition is the CSS3 rotation transform, which turns each corner 45 degrees and -45 degrees respectively, to ensure the bottom-side box shadow takes its position correctly.

03. Drop cap

In print terms, the drop cap is customarily referred to as an initial, and often didn’t just drop but would sometimes appear outside on the left margin, or with the bulk of the letter above the first line. Using CSS3, we can incorporate the drop cap by combining two CSS3 selectors: first-child and first-letter. Our code might look like this:

001p:first-child:first-letter {
002 float: left;
003 colour: DarkGoldenRod;
004 font-size: 100px;
005 line-height: 80px;
006 margin-right: 10px;
007}

Floating the first letter causes all inline elements (in this case, any subsequent text) to wrap around it nicely, so when we apply the sizing and colour, the first letter will drop beside the other lines, giving us the visual effect we desire.

04. Animated button rollovers

CSS gradients cannot be animated directly, because they don’t fall under the category of animatable properties (www.w3.org/TR/css3-transitions/#animatable-properties). But we can get around this by using the background-size and background-position properties, which are animatable. Here’s an example:

001.button {
002 background: linear-gradient(#2876b2, #549ad0); background-size: 100% 200%;
003 transition: background-position .5s linear;
004}
005
006.button:hover, .button:focus {
007 background-position: 0 -102%;
008}

Trivial styles have been removed purely for brevity, but the relevant parts of the CSS are shown here. These include the linear gradient, the background-size property, and the transition settings. When the user hovers over the button, the background position changes. Because of the transition, the change is not instantaneous, but takes place over the specified duration (0.5s).

05. Custom radio buttons and checkboxes

All browsers and operating systems have their own way of displaying form elements. For usability purposes, you don’t want to mess too much with the look of these. But, should you want to give them a bit of a custom look that matches your site’s theme or your product’s branding, there are options available that don’t involve you doing any complex scripting or similarly unmaintainable hacks.
This technique uses a background image in combination with the general sibling selector (the tilde character, ~) and the :checked pseudo-class. Here’s how our CSS might look if we applied this technique to a set of radio buttons and checkboxes:

001input[type=radio], 
002input[type=checkbox] {
003 position: absolute;
004 top: 0;
005 left: 0;
006 opacity: 0; 
007}
008
009.radio-buttons label {
010 display: block;
011 padding-left: 45px;
012 height: 35px;
013 background: url(radio- sprite png) no-repeat 0 0;
014}
015
016.checkboxes label {
017 background: url(checkbox- sprite.png) no-repeat 0 0;
018}
019
020input:checked ~ label {
021 background-position: 0 -35px; 
022}

Some common unrelated styles have been omitted for brevity. The first thing we do is remove the actual radio buttons and checkboxes from the page using display: none. Next, we add a background image sprite to all the label elements. You’re probably wondering: ‘how will the user select any of the elements, to toggle them?’
To accomplish this, we ensure that in our HTML each label element is associated with a radio button using the for attribute on the labels and a matching id element on each input. With this in place, any input element whose associated label is clicked will become checked, or selected, even though it’s not actually on the page.
This allows us to use the general sibling selector and the :checked pseudo-class to target the checked input. The checked state moves the background sprite image to show the checked, or ‘selected’ part.

06. Extruded Text

This technique can be applied to any piece of text, and the text content can be changed without editing the effect itself. The basic idea here is that we utilise layered text shadows to give the appearance of an extruded letters effect.
Depending on how you want the extruded part of the text to look, you can alter the colour of the shadows, the opacity using RGBA colours, and the general shape by altering the vertical and horizontal position of each shadow.
With slightly incrementing position values, the layered text shadows appear to be a single text artefact extruding from the real text, without changing the position or flow of surrounding elements.

07. Design in-browser with HSL

Most of us are probably pretty set in our ways when it comes to our design workflow. We do most of our design work in Photoshop then we convert our design to HTML and CSS. Some designs require at least some work in Photoshop, but how can we move some or all of our design work to directly inside the browser?
Enter HSL and HSLA colour values. Here’s how a colour value looks when declared using HSL:

001.example {
002 background-colour: hsl(50, 100%, 50%);
003}

The values inside the hsl() function represent hue, saturation, and lightness respectively. So if you want to experiment with different colours on different elements on your page, just increment or decrement the hue value until you get a colour you want (choosing between 0 and 359).
If the colour is not quite right, you can adjust either the saturation or lightness to get various alternatives based on the chosen hue. The hue values are based on the colour wheel, so it’s a super-simple task to adjust colours.
Even if, due to the need to support older browsers, you don’t plan on using HSL values in your final stylesheet, you can use them only during the design phase, and then convert everything to hex or RGB values later.
So just as you would do in Photoshop – adjusting text colour, border colours, background colours, and more – you can fiddle with values right in the browser, skipping a lot of potentially wasted time with Photoshop’s rather
clunky interface.
As a bonus, HSL values also allow for an alpha channel (declared as a fourth value in the same way as the opacity property), giving you even greater control over your colour choices.

08. Fancy centered heading

In many cases fancy headings require use of a background image or an image inserted via a pseudo-element. This technique will look somewhat graphic-like, but will not use images. Instead, we’re going to utilise the flexibility of CSS3 gradients to create a horizontal line behind our heading. In the HTML, we nest a element inside of our heading element, around the text (this is necessary) and then the CSS is as follows:

001h1 {
002 background: linear- gradient(#ae4e1e 0%, #ae4e1e 45%, #fff 46%, #fff 54%, #ae4e1e 54%, #ae4e1e 100%);
003}
004
005h1 span {
006 background: #ae4e1e;
007 padding: 0 20px;
008}

To achieve this effect, the span element is given the same background colour as the parent element holding the content. The gradient uses multiple colour stops, positioned at intervals that avoid any kind of gradual transition. For example, notice the 45% colour stop, followed by a 46% colour stop. With this sudden change in colour from one pixel to the next, the colour stops have no gradual change, thus keeping the gradient edges straight, rather than, well, gradient-like.

09. Stacked Pages Effect

Decorative elements can be added to pages easily by taking advantage of features inherent in certain CSS3 properties. For example, CSS3’s box-shadow property allows multiple shadows to be added to a single element, giving the appearance of extra elements. These are declared by comma-separating shadow value sets.
In addition to multiple shadows, each shadow can be customised to no longer look like a shadow. Here’s how our code might look:

001 body {
002 background: #666;
003}
004
005.papers {
006 border: #ccc solid 1px;
007 background-colour: #fff;
008 box-shadow: 
009 4px 4px 0 #fff,
010 5px 5px 0 #ccc,
011 9px 9px 0 #fff,
012 10px 10px 0 #ccc,
013 14px 14px 0 #fff;
014}
015

This example uses five stacked shadows. Each shadow allows vertical and horizontal offsets, so with some fine tuning we can create the 3D-like stacked effect by slightly incrementing those values for each shadow. Also, every other shadow element has a smaller distance increment in addition to a different colour.

10. Animated glow boxes

This technique will use both transitions and box shadows to create a growing glow effect on the box when the user hovers their mouse over it. Here’s the relevant code:

001body {
002 background: #c4c4c4;
003}
004
005.glow-box {
006 background: #ffaa00;
007 colour: #333;
008 box-shadow: 0 0 0 0 001001#ffff99;
transition: box-shadow .3s ease-in, colour .3s ease-
in; 
009}
010
011.glow-box:hover {
012 box-shadow: 0 0 80px 
01310px #ffff99;
014 colour: #ffff99;
015}

The transition affects both the text colour and the shadow, giving the appearance that the glow appears through the text and around the box, effectively lighting up the background. The box shadow’s colour is a yellowish shade, giving it a glow-like look, rather than a customary dark shadow look. The transition is given a short duration of under 0.5s, and we’re using ease-in timing to make it appear more realistic.

Starter themes are themes that are great to begin a project with – as the name ever so subtly implies. It really doesn’t matter if you intend to fork the theme and use it as a foundation for your project, and what’s more, it doesn’t even matter if you choose to use the starter theme as a parent theme and build a child theme on top of it. What all starter themes have in common is that they are great starting points, no matter what.

There are obviously things to consider when choosing a starter theme. First of all, you shouldn’t just go with any starter theme for your project. Pick one that has as much in common with your planned end result as possible. Second, make sure you actually have an end result, all too often projects are started without a clear goal in mind. Third, you need to decide wether to fork the starter theme into your own creation, or build upon it with a child theme of your own. The latter is obviously handy since it means that all updates to the parent theme, which is your starter theme, can be applied with minimal risk of issues on your site. It all depends on your goal, and how close the starter theme of your choice is to it to begin with.
Finally, there’s one more thing to remember: anything can be a starter theme. As long as the theme is free for the taking, you could use it as a basis for your project. Don’t get too hung up on how the themes are branded, as starter themes, frameworks, or whatever. Instead, look to the possibilities and how you can save time and effort by taking the head start that is the starter theme of your choice.

_s

underscores.me
_s, or Underscores, is a great starting point for your theme projects. Underscores (which is a lot easier on the eyes than _s in text so we’ll stick with that) is an interesting project. This starter theme is not even meant to be used as a parent theme for your child themes. Instead, you’re supposed to take the code and build something completely different from it. Does that mean that Underscores is a more complicated starting point that the other starter themes in this article? No, not at all. In fact, it is quite the opposite, because while a lot of the other options have a tonne of bells and whistles with their own templating systems and theme options, Underscores keep things simple fairly simple. In fact, it only has one widget area, or sidebar if you will, defined to start with – and just the one menu as well. This means you have less to alter and/or remove when you get started on your project, but it also means that you have more to add should you need more than this.
As Underscores isn’t meant to be used in its original form – you are expected to alter it, including its name – the feature to build your own fork of the theme on the website is welcomed. Sure, you could do a search and replace for all the references to Underscores functions and textdomains, but why bother when the site will do that for you? It’s a nice feature that adds to the general feeling that Underscores is a project worth supporting. Speaking of which, Automattic is the official publisher, which means you can support it in the future as well.
Code-wise, Underscores is pretty straight forward. It puts HTML5 to good use, with nice semantics and proper CSS markup. As the theme is bare as it is, you’ll have to supply your own CSS, but if you need help getting started, there are some simple stylesheets available in the /layouts folder.
The template files are easy enough to understand, with layout separated from output code in a logical manner. Underscores puts the get_template_part() function to good use here, making sure that you can reuse as much of your output as possible. When you’ve acquainted yourself with the code, you’ll see that it is properly commented, making it easy to understand what does what. If anything, there’s too much commenting here, but you can easily clean that out when you’re working, or leave it in if you want to be nice to, say, your successor at work where you’re building the company website, or something like that.
Underscores is the natural starting point for anyone on the lookout for a starter theme to fork to their own projects. It is well made, well documented, and a solid base. The only downside is that it is less prepared for you to use it to build child themes upon, but that can easily be changed by forking it and taking the necessary steps yourself, with your own version. Give it a whirl, it might suit your needs.

BONES

themble.com/bones
Sometimes you want to start with something that’s a little more designed. If so, Bones might be for you. Sometimes it can help to have a little more style when starting a new project. Not everyone enjoys looking at a CSS naked site and then start defining everything from scratch. Bones is visually simple out of the box – not overly designed in any way, but at least it does not look like the stylesheet failed to load. If this helps, then Bones is a nice starting point.
Bones uses LESS or Sass, your choice. You could obviously use traditional CSS as well, but you’d have to fork it should that be the case. It makes little sense to pick Bones if you intend to use traditional CSS, this is a choice for the LESS/Sass lovers out there. You’ve got all the files you need to get started, as well as some tips on helpful reading if you want to get started with LESS or Sass. That’s always nice.
The Bones markup is good and appears well thought through – there’s not much to complain about there. The theme comes with one default widget area, and supports both menus and custom backgrounds, but not a custom header. When you want to add something that usually goes in functions.php you’ll notice that the file requires functions from additional files. And yes, there are quite a few additional files in Bones, which you will either like or dislike. It sure makes the theme a bit harder to understand to those of us who are less-experienced theme developers.
On the other hand, Bones helps you as well. You’ll find placeholder template files for Custom Post Types, a nice touch. There are also placeholders for adding Custom Post Types to your theme, by enabling a function in functions.php and then defining the Custom Post Types you need. This is a less than stellar idea I’m afraid, because Custom Post Types is definitely something that does not belong in a theme, but in a plug-in (a compatibility plug-in, ideally).
The reason for this is that your Custom Post Type content will most likely be something you want to stick around when you switch themes, and if the code for it resides in the theme, that means you’ll have to remember to copy-paste this to your new theme. The same goes with any added taxonomies you might have. You want that to traverse across themes, not suddenly be disabled. The Custom Post Type thing notwithstanding, Bones is a nice alternative that you should consider for your projects.

TOOLBOX

wordpress.org/extend/themes/toolbox
The Toolbox theme might indeed be the perfect tool for child theming, if you’ll pardon the pun.Toolbox is a classic bare bones theme, if you’d believe there was such a thing. There are, in fact, a lot of these themes, consisting almost solely of HTML markup, with just about no CSS at all. The idea with this sort of theme is to make it easy to style it to your liking, which fits the whole starter theme concept perfectly well – customisation is key.
Toolbox can be both forked into a completely new theme, or used as a parent theme for a child theme. While both make perfect sense, the latter use is where the theme stands out from the other alternatives presented in this feature.
The thing with Toolbox is that it doesn’t try to reinvent the wheel in any way – it is just a basic WordPress theme without a ton of CSS for you to overwrite. Just about everything it does is straight up regular WordPress – something a lot of developers will appreciate, since it means they won’t have to spend any of their time learning a new template file structure.
The HTML5 markup is simple and straightforward, in a good way. The only question mark you might find is in the side column, which is a widget area. In Toolbox every widget is an aside tag, not a list item within an unordered list. This is a step away from the traditional setup for WordPress themes, as some of you will no doubt have noticed, and it could be hassle for amateurs. That said, it is not a bad idea semantically, so it might not be so bad after all. It is worth noting though.
Other than Toolbox features two widget areas and support for a menu out of the box. It also has support for some Post Formats, which you may or may not want to use in your projects. There are also some nice functions in functions.php that you could put to good use. The template file structure is reasonable as well, with all the template files you’re likely to need, all split up using get_template_part(), but without going nuts with template inclusions all over the place.
Toolbox is a great starting point if you’re going to build something blog-like, that’s for sure. The theme is also easy to style, which makes an ideal candidate to use as a parent theme.

ROOTS

www.rootstheme.com
A different starting point – Roots might just be what you were looking for. The first thing that will strike you when you’re installing and activating the Roots theme is that you’ll get a few theme options directly after activation. Here you’ll get alternatives for creating a static front page, changing the uploads folder, permalinks, creating a navigational menu, and adding your pages to said menu. Pretty handy if you want to follow the basic setup, and nicely done. The Uploads folder change is a nice trick by the way; rewriting permalinks to files so your image and asset URLs won’t have wp-content/themes/roots/, and substituting this for ‘assets’ to make prettier links. It’s the little things. Other than this, you’ll also get two widget areas, but no custom background nor custom header for that matter.
Roots features decent markup, but while it is indeed HTML5, the lack of the article tag, for example, is a bit of a mystery. Some developers will disagree on the semantics in Roots, so make up your own mind.
The Roots file structure is a story of its own. Templates are broken out and stored in a /templates folder, and you’ll find that functions.php is only used to include a number of files from the /lib folder. The stylesheets are in their own folder within the /assets folder, much like images and JavaScript files. Roots uses LESS, which given the organisation of the theme, should come as no surprise to developers. Everything has its place in Roots, which can be both a good and a bad thing, since it does indeed make it a bit harder to get started. Luckily there’s a lot of documentation to ease the transition to this theme structure.
Another nice thing about Roots is that it is localised to quite a few languages, and they ship with the theme as well. This is always appreciated when working with international clients and/or sites.
Roots is not for everyone. It demands that you learn how it works if you want to do something slightly more advanced than a minor tweak or build a child theme. That is not necessarily a bad thing, so if you like your themes structured then take a look at this one.

STARKERS

viewportindustries.com/products/starkers
Starkers is something of a blank slate or tabula rasa – a naked (see what they did there?) WordPress theme with semantic HTML5 markup. If there’s a definition of a bare bones WordPress theme, it is Starkers. Even the theme’s background story is about bare bones. You see, the theme used to be a stripped down version of the current default theme, with all the bells and whistles, all the styles, everything not completely necessary, stripped away. As of version 4.0, this is not the case – the theme is rewritten with its own structure, making it even more lightweight and stripped of what might be perceived as nonsense for a developer when starting a new project. This means no widget areas, no menus, no custom backgrounds – you will not find anything that is not totally essential when starting a new project.
Starkers features a nice semantic HTML5 markup, but it might not be for everyone. Some might have a hard time swallowing the use of ordered lists when listing posts in an archive, for example, not quite what we’re used to in WordPress themes (but fairly common in Tumblr themes, incidentally) – although it does makes sense from a semantic point of view. Not everyone will approve of the markup for article headers either, where the h2 tag is used rather than h1 – even on single posts – but that’s a matter of taste and your SEO philosophy. All in all, the markup is really clean and really simple. You should have no trouble styling Starkers.
Where you might run into trouble is the way in which the theme is built. As with so many other themes in this article, Starkers has its own templating structure, with the template files including various parts of the code from the /parts folder. This, just like with other themes that stray from the WordPress standard, might take some time getting used to, but it does offer a better overview of the template files within the theme. Since Starkers is aiming to be lightweight, some functions and features that the theme ships with aren’t even used per default, but you can easily add them by reading the code.
The lack of documentation, other than notes within the files, is a pretty big barrier when it comes to getting started with Starkers – but it really is a good starting point, and easy enough to learn. Do take a closer look if you’re after a bare bones theme. It might be right up your alley.

Pros And Cons Of Theme Options

Dedicated theme option pages might sound like a good idea, but its not always the case
n Theme options are fairly common today. Sometimes it is something as simple as adding a bit of additional text that the theme wants to show some place, and other times you can control the layout, fonts, colours, and whatnot. This might sound like a good idea, but most of the time it is not, and when it comes to starter themes you should definitely be wary of theme options as they might mean that the end user will ruin the look and feel, or even the functionality, of your theme.
It is often a good idea to stick with the WordPress default features, as they will rarely lead you astray. A custom header, custom background, and some clever use of widget areas and menus, and you’re probably where you want and need to be.
If you do intend to use theme options, keep in mind that they should only be for things that are theme specific. Adding a box for storing the Google Analytics ID number in the theme is a bad idea for example, since chances are the site statistics should work even when switching themes. Keep the theme options as simple as possible, and use with caution.

You can’t force anyone to click, or do anything they don’t want to do on the internet. So how do you encourage visitors to your website to do what you want them to?

The answer is to use websites to engage in conversations with their users, just as a business would with a potential customer face-to-face. In person, they’d be polite, trustworthy, expert, answer questions (perhaps even before they’d been asked) and show off the business’s benefits over its competitors. In short: make the customer feel relaxed and in good hands.

You can anticipate the conversations a business would like to have with its customers and design the website to reflect that. Whether the business wants to make an online sale, provide information online before an offline sale takes place, or simply provide information – a website that answers its users’ questions will stand any business in good stead.

The practice of UCD (user-centred design) means considering a website’s end-users at every stage of the design process. As a designer, it is your job to balance the needs of clients with those of their users. The user-centred design techniques help you and clients understand what their customers want and need.

UNDERSTAND WHAT YOU WANT USERS TO DO

It sounds obvious, but if you don’t know what you want your users to do, how can you possibly design an online experience that encourages that behaviour? The business goals for the website and any given webpage are key. Goals provide a clear understanding of what the page is for and what the desired user actions are.
If a business or organisation wants a new or improved website, there will always be a reason behind it. Some businesses will have a list of goals or KPIs (key performance indicators) for its new website. Others will be less explicit. If you understand its reasons, you can design to meet its goals.
Eliciting business goals is often a case of simply asking. It’s something that’s easy to forget, especially when you’re caught up in the thrill of a new design project. For that reason, it can help to have a more formal approach to drawing out the information and documenting it. When starting a new project, the first step is to conduct stakeholder interviews, asking people in the business with an interest in the website a series of questions. Typically one of the most useful ones is ‘what will make this redesign successful for you?’ Answers can range from ‘a 5 per cent uplift in conversion rates’ to ‘a website that isn’t embarrassing’, but they are always helpful in shaping the design work ahead.
At the level of individual pages, it’s hugely useful to discuss business goals. It gives focus to the design work and provides a framework for critique of proposed designs. Does the design meet the business goals set for the page?
Consider documenting the page goals as part of the design process, perhaps as annotations to wireframes or alongside early sketches or content lists.
Understanding the goals of a webpage has the added benefit of allowing you to set up analytics to measure the outcome of your design choices.

UNDERSTAND WHAT USERS WANT TO DO

Considering likely user goals for any given webpage before you start design work is hugely important. It is always interesting to compare user goals with business goals. Are there any tensions there, and how can they be addressed? It is very difficult to encourage users to click in an environment that makes them feel uncomfortable or over-sold-to. Later on in this article, we’ll discuss specific ways of understanding what your users need and want. The point here is to list out user goals alongside business goals, and discuss any conflicts before you start on design work.
An extremely common example of business needs conflicting with user needs is within transactional forms. Businesses typically want to gather as much customer information as possible, alongside eliciting permission to use that information for marketing purposes. Customers, on the other hand, want to complete their task as quickly as possible, give away as little information as possible, and sign up for no spam at all.

PRIORITISE, PRIORITISE, PRIORITISE

A prioritised list of page content is the first thing to start with when designing a new webpage. If you don’t know what the most important item on the page is, how can the page be laid out to convey that?
Discussing the conflict between business and user goals is an invaluable tool for prioritising page content and calls-to-action. If you want users to click, you need them to clearly understand what and where to click. If there are too many options, choice paralysis will set in.
There are often lots of things that the business would like the user to do (buy now, add to shortlist, share on Facebook, Twitter, Google+ or Pinterest, read reviews, add a review, understand the returns policy, look at more products, read another article – the list goes on and on). Clearly, the most important item on that list is to actually buy the item. In order to design a coherent experience, we need to know which of those options the business most wants users to go for. If we know that, we can design a page that supports the business goals. If we don’t know the answer, we’ll have to design a page that equally supports all those options, which is likely to provide a bewildering array of choices. A prioritised list of desired page content and outcomes is every UX designer’s friend.

REFLECT USERS’ LANGUAGE

Remember that conversation the website is having with its customers? Here’s where the analogy comes into its own. If the website speaks the same language as its users, they are far more likely to click where the website’s owner would like them to. If site content is organised in a manner that is logical to its users, they are far more likely to find what they are looking for. A sales person wouldn’t use complicated jargon when speaking to a new customer face-to-face, so don’t do it on the website.
Common mistakes here include using business- or system-centric language. For example, my current pet hate is a link on the Virgin Tivo UI. It says, ‘express series link’. I know from experience that this means ‘record series’, but I’m always reluctant to click it as the wording introduces doubt in my mind. What on earth does ‘express’ mean, and why do I want a ‘series link’? Another easy mistake to make is to organise a website’s navigation and information architecture around the business’s internal structure. Where I work, we call this “’showing your organisational underpants’ (www.cxpartners.co.uk/cxblog/showing_your_organisational_underpants). An example might be having main navigation options based on revenue streams, when these names mean very little to new users arriving from a Google search. Is my virtual course listed under Training or Online shop? Who knows, but a joined-up experience would be much more useful.
UX practitioners have a number of tools and techniques to help them understand their users’ worlds. Chief among them is user research in the form of user testing. Interview existing or potential website users about their needs and concerns. Watch them use the website or those of competitors. This is the single most valuable activity you can do to improve a site’s UX. I’m lucky enough to work somewhere with a dedicated user research lab. It contains a computer and cameras, with audio and video links to a viewing room elsewhere in the building. We use a market research company to recruit existing customers, or people matching the customer profile, as test participants. We typically devise hour-long user tests and invite our clients to come and view them so they can learn along with us.
However, you don’t need all this fancy kit to conduct invaluable user research. You just need a computer and some test participants. The key with test participants is to get people who have experience of the content you’re designing around. For a camera website, your dad may not be suitable, but your mate the photography enthusiast could be. Your client may be able to help you out here – can they point you at any existing customers? Talk to your interviewee about
their experiences in your area of interest. Try to ask them about past experiences rather than asking them to speculate about what they would do – you’ll get much more accurate information. Note the words they use to describe the things they are looking for. Watch them using relevant websites. What works, what doesn’t, and why?
There is a veritable wealth of information to be found on how to conduct user research, it’s all over the internet and in plenty of books (sorry for the shameless plug, but that includes my own book). There is also a number of online tools that allow you to conduct user testing remotely.
Website analytics are another useful tool for informing user-centric navigation and other naming structures. What search terms are users typing into Google before arriving at the site? What about the search terms users type into any existing site search? Can you adapt the terms the website uses to better match the terms real people use?

SUPPORT USERS’ TASKS

The key here is to understand what the website’s users are looking for and to tell them that the website has it (or to not waste their time if it doesn’t!). Answer their questions at the appropriate time and don’t bombard them with too much information up front.
It is useful to capture the gems we learn in user research in diagrams. These diagrams are then used to support our decisions throughout the design process. For example, a task model is a diagram that describes the activities users perform in order to reach their goals. They help us to create websites that fit seamlessly into users’ lives.
To generate a task model after conducting user research, look for patterns. One way to do this is to write each task or activity you heard from your test participants on a Post-it note. If you were looking at a website selling shoes, you might have heard someone say ‘I need to know if this is heel is low enough to walk in’, so you could write ‘Heel height’ on your Post-it. Keep going with all the needs you heard in user research. Get your client involved – are there any other questions they get asked? Once you’ve got a wall full of Post-its, you can start to organise them. Take away duplicates, and then try to put them in chronological order, perhaps grouping them into phases in the process. This is your task model. You might want to document it in a drawing program so you can share it and easily refer back to it, but you have all the information right there in your wall of Post-its.
The illustration shows a possible shoe buying task model (don’t rely on it, it’s made up!). There’s a free task model template available to download from www.cxpartners.co.uk/ux-resources.
Task models come into their own when designing the user journey through a website. This is often a balancing act between too much information and a clean design. For example, a page with a list of many products on it needs to provide summary information to allow users to decide which product to click to find out more. If you know that the main things that your shoe buyers care about are price and appearance, design a product-listing page that allows users to easily see what the shoes look like, as well as refining by price.
Use a task model to help you decide which features are important enough to users that you need to filter out unsuitable options early on. Provide richer details later in their journey, for example on an individual product page where the information may be more relevant. Returning to the shoe example, your task model might show that most users need to understand material and heel height, in addition to the overall appearance. Some users care about wide fittings and others about returns information. When you design the page, prioritise the information most users need, then provide the information that others want, but give it a reduced visual priority so the page remains clear.

ANTICIPATE USERS’ PROBLEMS AND CONCERNS

This is goes hand-in-hand with supporting users’ tasks, and is again about having a conversation with a website’s users that they find helpful. What are your customers worried about, and what can you do to address their concerns? Again, creating a task model helps here. Also, customer-facing staff are great people to ask for this information: shop assistants or anyone who speaks to customers on the phone. Ask them about common customer questions or problems. Ask them what they do or say to resolve them.
Recent research has revealed that some users wanted to search for a particular product by name, while others wanted to use its code. The website only used codes to refer to the product, so users who wanted to search by name ended up leaving in frustration. We redesigned the website to use both name and code every time the product was referred to, including in main navigation and in search results, and this has tested well. If you fail to solve your users’ problems on the website, they will have to go elsewhere to solve them, and they may never come back.

BE TRUSTWORTHY

Again, this is about the conversation the website is having with its users. Does the business want to come across as a trustworthy one? There are many, many things that contribute to users’ perceptions
of trustworthiness. User research will identify the important factors for the website’s specific situation.
As food-for-thought, here are some examples I’ve come across:
Users don’t like surprises, particularly when their hard-earned cash is involved. Be really clear about stock levels, pricing, and the implications of options and extras.
Be consistent. Always refer to the same product or concept using the same words, whether that’s in site navigation, content or in the shopping basket. Make sure sums always add up and
show what’s included.
Users prefer ‘real’ content. Showing your expertise with blogs or news can be compelling, but don’t resort to filler as it will erode trust. Think twice before using obvious stock photography.
Be careful with advertising. A poorly located or ill-chosen advert can really undermine trust. Conversely, unintrusive ads from companies that your users feel complement your offering can be seen as helpful.
Use clear, well-written, proofread copy. Even a small thing like a spelling mistake will make some users doubt your veracity.
If you have a customer services phone number, show it in the header area of every page. I have often seen user test participants looking for the phone number of a company they are unfamiliar with. They generally don’t want to actually call the company, but a concrete number is reassurance that the business exists in the real world, and they are not about to get shafted.
Use clear design. Make clickable things look clickable. Provide clear calls-to-action: make it obvious what your users should do next.

USE SOCIAL PROOF

Social proof is one of psychologist Robert Cialdini’s six principles of persuasion, which have really worked their way into the world of UX over the last few years. One persuasion principle is that of reciprocity, whereby if someone gives you something, you are more likely to give them something in return. Another principle is scarcity, in that we feel compelled to act faster if we feel that we will otherwise miss out.
Psychological persuasion techniques can be extremely powerful, but be careful not to go too far and undermine trust. For example, using the scarcity principle to show that there is only one item left in stock may well cause users to act, but it will seriously erode trust if they think it’s made up (‘are there really 20 other people looking at this hotel room right now?’)
The social proof persuasion principle states that people are more likely to do something if they see that others are doing it too. There are clearly many applications of this to web design projects:
Customer ratings and reviews. Make sure you stay trustworthy, though. Don’t remove negative reviews. I’ve often seen user test participants deliberately seek out negative comments in order to reassure themselves the content is genuine.
“People who looked at this eventually bought…” and other recommendations. The key here is to be genuinely useful. Irrelevant recommendations really undermine trust.
‘Zeitgeist’ links (which reflect what’s popular at this moment in time) such as top tens, most reads, bestsellers or most shared.

TEST, ITERATE, AND TEST AGAIN

If you have examined the business and user goals for the website, then they are the first things you should test your designs against. Does your design support the business goals for the site as a whole or for any given page? Does your design answer users’ needs and concerns, as documented in the task model?
If you really want to make users click, you need to watch them using your product. Look at when they click what you want them to, and crucially, when they don’t. Why didn’t they do what you wanted them to? Is there anything you can do about it?
You don’t have to wait until you’ve finished building a new website before you test it with users. In fact, it’s best to test as early as possible. That way, if you need to make a change, it should be quick and easy to make. Where I work, we typically design wireframes to convey the initial UX of a website. Wherever possible, we conduct user tests on these wireframes.
Of course, different practitioners will produce different deliverables, ranging from sketches to PSDs to fully-functional HTML. But the principle of testing with real users remains the same. It is surprising how quickly test participants happily interact with even the most low-fidelity sketch. We generally test on wireframes because we find they provide the best balance between understanding if the design meets user needs, and making cost-effective changes. They provide enough information for users, before requiring the visual designers and developers to make changes.
User testing your designs, whatever fidelity they may be, will always show you ways in which you can improve them. This time, you’re trying to understand if users can find everything they need. Do the words you have used for the navigation system make sense to them? Can they predict what will happen when they click on a link? Are they able to complete any forms there may be? Even if there is any information missing, or your users cannot find it, or your forms are tricky, you’ll come away from the testing sessions knowing what needs changing, and buzzing with ideas on how to improve your design.

DON’T ASSUME CONTEXT OF USE

Don’t assume you know where users are or what device they are using. They may be at home, at work, on public transport, or out shopping. They may be on a desktop, a laptop, a tablet, a smartphone, an internet TV or next year’s new gadget. They may be using more than one of these items at once and they will likely be using more than one of these devices over the course of several interactions with the website.
Yes, it’s unlikely that someone’s going to buy a £2,000 holiday on their iPhone on the bus on the way home, but it’s not impossible. Do you really want to miss that sale? Admittedly, a more likely scenario is that someone who’s considering buying a holiday is using that spare half an hour on their commute home to browse for holiday ideas.
There is plenty of debate about approaches to this question. First, it was all about iPhone apps, then mobile-specific websites. Now the focus is on responsive design, with techniques and best practice shifting over time as lessons are learned.
Technology issues aside, I would argue that consistency is the most important factor here. What if your commuter on the bus wants to take another look at the holiday they saw in your print brochure or on their laptop computer at home? They might be very frustrated if their iPhone redirected them to a mobile-only website that did not provide as much detail as the brochure or the desktop website. How many times have you found yourself madly scrolling to the bottom of a mobile website in the hope of finding a link to the desktop version?
Of course, you don’t want to force mobile users on patchy connections to download loads of superfluous images, but if the images are truly redundant, why subject your desktop users to all that clutter?
Prioritising your page content and having a thorough understanding of the website’s users and their tasks really helps with decision-making when it comes to considering context of use. My advice would be to never give your users a reason to go to another website to complete their task, even if they are on the bus.