I’ve been known to enjoy a little chess now and then (not to say that I’m particularly good at it). It’s the hallmark of strategy games, and often very complicated events or situations are compared to it metaphorically. I have gone one step further in thinking of website production as the classic strategy game chess and have associated the pieces with the various people that bring a website together.

The Players

Pawns

The pawns are the people dealing with the website content directly. Content is the most important thing on a website, so naturally there should be more pawns than anything. Pawns quickly setup the basis of the game, and the direction it will go in. They represent writers, editors, content entry people, photographers, bloggers etc. In chess when a player thinks of Pawns as disposable the game doesn’t go well—in reality the way these are played will make or break the game.

On the other side of the board are enemy pawns, this natural nemesis is lousy content; ad heavy, endlessly scrolling pages, rehashed top-ten lists, pages harvesting content from other websites, etcetera. The dark side can be so compelling.

Rooks

These pillars represent the Quality Assurance, Analytics, and Testing of a site. A straight forward approach is always the best way—provided that content people are out of the way! Rooks have a unique rapport with kings (the site’s greatest stakeholder) as demonstrated in the move of castling (which we’ll talk about later).

Conversely, ignorance stands tall in the opposite corner, casting tall shadows across the equally ignorant content team – this can take shape as an untested product, ignored user data and poor quality of content. When this player doesn’t do its job, a site can break quickly.

Bishops

Developers are the forward thinking and often hard to follow characters that often strike from out of nowhere at problems that are in the peripheral. They often work in terms of black and white, so naturally this is how they travel.

No surprise that a developer’s biggest enemy is themselves: His own lousy code, scope creep, lack of attention to detail and failure to plan ahead will create their own undoing.

Knights

Working in an often incomprehensible and unpredictable fashion, designers are best represented as the knights. They are often seen as the heroes who will make a name for the site (author bias admitted). Their job description involves breaking rules, which can allow them to get around steps and obstacles with ease.

Their equally wily opponent: Failure to plan ahead and battling deadlines. Knowing four moves ahead is crucial in this game, a misstep can be a long painful road to recovery. Misunderstanding the goal of the design, not knowing the requirements or painting ones self into a corner with an inflexible library might be some of the designers greatest weaknesses.

The Queen

The most powerful player on the board is naturally the top ranking person on the production team; be it the boss, the stake holder, president or any other figurehead. This position can make powerful, fast movements and radically change the direction a site or project is going. This piece often sits back and observes. Even if they’re not an active part of the action, their mere presence inspires confidence in the other pieces. The best leaders began as Pawns and have been through these battles before. Their experience is always a complete asset.

The most powerful deadly crushing weapon the enemy has in its arsenal is the dreaded middle-management trying to climb a ladder; or worse – the diabolical committee. Either force trying to constantly adapt a project to keep up with trends, add features and change requirements.

The King

Who do all of these players play to protect? The client of course! Steady and methodical, the client needs to be surrounded by a group of experts who are highly skilled at their art. When they are felled, the game is over. One of their most incredible moves is interacting with Rooks with castling – based on the analytics and test results the site may need to reevaluate objectives to better serve the client; a decision only the king can make.

The arch-enemy is the very same client! Making moves against themselves; co-ordinating the worst kinds of opposition and unwittingly commanding a hoard of obstacles against their own final goals.

Check. Mate.

Sometimes making a website is an incredible battle filled with gut wrenching strategy and action. If we all do what is right the good guys win.

In reality, website production is a lot more complicated than even the iconic strategy game; but it’s fun to think about. Naturally you’re probably noticing that Account and Project Management is missing from my list of pieces, but the reason is obvious: they’re the ones playing the game.

Rematch?

Since writing this post I did a Google searcheroo to see how original this line of thinking it was. I was initially disappointed, then thrilled to discover a similarly themed post on Smashing Magazine. The difference is that this post talks about how you as a web professional can adopt the personalities of the various pieces for the purposes of making great websites for your client. If you have room for two nerdy chess illustrations about making websites I highly recommend it!

I told you chess makes a great metaphor.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

So a couple weeks back I was doing some work on a client website. I had just recently signed up for TypeKit and was using that to serve up the custom fonts for the site. It was working splendidly. The only exception in my early round of testing was on my iPhone 3G. In technology terms, my phone is definitely getting old now, but I am still using it and am running iOS 4.1, which is incompatible with TypeKit. So, instead of getting Adelle served up, I was just getting a standard sans-serif default from my font stack.

Was this acceptable? Probably. Everything degraded gracefully enough, but I really liked that slab-serif appearance and wanted to bring it to the website on my iPhone too. So, without getting into all the gritty details, I downloaded Arvo from FontSquirrel and coded the site so the font would be accessed by the iPhone as required. Everything seemed to be set up properly.

Except that the font was not being rendered.

I spent several hours tearing my hair out trying to figure this one out. I had successfully used @font-face with files from FontSquirrel before, and seen them rendered on my iPhone, so I knew it could be done. I just couldn’t figure out why it wasn’t rendering in this instance.

Solving the Problem

After testing to make sure that my stylesheets were being loaded, and turning off TypeKit to confirm that Arvo was being loaded in other browsers (which it was), I slowly determined that the problem had something to do with the SVG files that I was using. I am by no means an expert in SVG and only understand into conceptual terms. But, as I did some digging through the code of sites I knew were working and the code of the site that I was actually working on, I discovered a strange irregularity.

There is a tag within the XML of the SVG file which looked something like this:

<font id="webfontOTINA1xY" horiz-adv-x="335">

What was interesting about this tag was the id attribute. In the stylesheet supplied in the @font-face kit downloaded from FontSquirrel, the font declarations look like this:

@font-face {font-family: 'ArvoRegular'; src: url('Arvo-Regular-webfont.eot'); src: url('Arvo-Regular-webfont.eot?#iefix') format('embedded-opentype'), url('Arvo-Regular-webfont.woff') format('woff'), url('Arvo-Regular-webfont.ttf') format('truetype'),url('Arvo-Regular-webfont.svg#ArvoRegular') format('svg');font-weight: normal; font-style: normal; }

I have bolded the line specifically relating to the SVG version of the font. Notice the fragment identifier after the file name. When I went back and looked at the site that was working, this value was identical to the id attribute of the font tag in the SVG’s XML. This got me thinking, and I actually went in and changed this id attribute to be the same as the fragment identifier of the @font-face code that was calling it.

As soon as I did that, Arvo was rendering perfectly on my iPhone. It was a ridiculously easy fix that only served to irritate me more, since I had spent several hours working on the issue.

Again, I am not an expert in SVG, but here’s what I think is going on. The <font> tag within the XML seems to contain the entire character set, while the id attribute provides the unique identifier for that particular font. When the SVG file is called within the @font-face declaration, the fragment identifier seems to be required to tell the CSS rendering engine what block of code to use, even though there is only one font declared in the file.

This seems to suggest that you might be able to combine all of your SVG fonts into a single file and then access them through the appropriate fragment identifiers. I have not tested this, though, so if any SVG experts would like to chime in on this one, that would be awesome.

A FontSquirrel Bug?

Don’t get me wrong: I love FontSquirrel. I even listed them in a post about 10 of my favourite online tools for design and development. There does, however, seem to be a slight bug in their kit generation. From what I understand, they build their own SVG files, based on the existing font files for most of their typefaces. So far, they seem to do a pretty good job too—when they work, the type looks great on my iPhone.

For some reason, however, there seems to be this occasional breakdown where the id attribute in the XML will contain some coded identifier and the supplied CSS will use a camel case version of the font name (such as ArvoRegular). It doesn’t happen in all instances, though. It doesn’t even seem to happen consistently with the same fonts. I downloaded Arvo again as a test, and it was fine. Then I downloaded League Gothic, which has always been fine, and I found the discrepancy.

Fortunately, if you are aware of the issue, it only takes a moment to open up the files and do a quick cross reference to make sure everything is working properly. Unfortunately for me, I didn’t know about this and had to figure it out the hard way. After reading this post, hopefully you won’t have that same problem.

Webfonts Moving Forward

Is this SVG thing really a big deal? Maybe not. If you check out the information provided at webfonts.ingo, every major browser now supports @font-face rendering with either TrueType, OpenType or WOFF format fonts (or even all of them). This includes SafariMobile as of iOS 4.2. If this is the case, then do we even need to worry about SVG fonts?

Maybe not in a few years. Right now, though, there are still people running older versions of iOS. I know. I’m one of them, and I don’t want to upgrade because my iPhone is already running slow enough.

That’s enough of a motivation for me to take the time to ensure that any @font-face declarations that I make are working across the board, especially since it’s just a matter of making sure a couple of values line up.

I hope you find this quick tip useful. As already noted, I’m not an expert in this area, so if you have any comments or insights on @font-face or SVG fonts, feel free to share in the comments below.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

So here we are, well into the second half of 2011. Some might even say we are in the home stretch, already looking toward what 2012 will have to offer. In this moment, it seems that everywhere you turn somebody is writing about responsive web design. Several days ago, Andy Clarke even went so far as to tweet

From now on, if it’s not responsive, it’s not web design.

Now, I don’t particularly agree with this all-encompassing statement, and in a previous article I discussed some of the potential caveats and pitfalls of responsive design. That being said, however, this responsive movement strikes me as being more than just another tool in the toolbox. Statements like Andy’s plainly suggest an entire paradigm shift within the community (or at least part of the community).

For those who adopt it, responsive design doesn’t just change the way we create websites, it changes the way with think about creating websites. That’s pretty revolutionary.

Instead of creating a “normal” site and a “mobile” site, we are now looking at the possibility of creating a single site that “responds” to its context and offers up different layouts, based on the amount of pixel space that is available. Exactly how we do this is still up for debate in some areas. Yes, media queries are going to be part of the solution, but there are still all kinds of questions surrounding other elements, such as images and advertising.

Still, by all indications, the responsive movement is here to stay, and I cannot help but wonder if its arrival means that we can finally start moving beyond the concept of the mobile web.

It’s A Flawed Term Anyhow

I’ll confess: I’ve never really liked the term “mobile” anyhow. It just seems semantically wrong to me. In my somewhat literal mind, my iPhone is not mobile at all. If I put it down on the desk in front of me, it just sits there, as inanimate as a book or a rock. If it was actually mobile, would it not be able to propel itself into motion, or at least be made to move on its own, without me having to pick it up and carry it with me? I would certainly think so.

And so, by this definition, my iPhone is not a mobile phone at all. It’s a cellular phone, which connects to other devices through a wireless network. The only thing mobile about the entire situation is me and my ability to carry the phone from location to location.

Of course, I recognize that I am arguing—probably very much in vain—in the face of the established vernacular. People have been calling their cell phones “mobile” for years now and I have no expectations that my little rant here will do anything to change that. In fact, one of the largest providers of cellular telephone services in Canada is actually called Bell Mobility.

So, when it comes to how we talk about our phones, there is little chance that we will actually get away from the term itself.

But that doesn’t mean we still need to maintain this fragmented sense that somehow the “mobile” web is a disconnected or separate entity from the “normal” or “desktop” web (which is just as problematic of a term).

Looking at Behaviours

At first glance, there seems to be an initial assumption that, if people are using their handheld devices to access the web, they must be doing so “on the go”. Maybe this means riding the city bus, or taking a cab ride through downtown New York (I hear that’s an adventure). From a certain perspective it does make sense; these devices allow us to bring the web to places it could never have gone before. If we accept this assumption as truth, it is easy to infer that people who are accessing our sites via these devices will be in a rush, simply because of where they are (or where they are passing through). This, in turn, can lead to assumptions about how content should be designed.

Yet, more and more, I am reading about research indicating that a large percentage of “mobile” internet usage is actually happening in the home, rather than out there in the oh-so-busy world. One article states that the percentage may be as high as 43%. This amounts to almost half of the total usage and, based on my own behaviors, makes total sense to me.

I use my iPhone at home all the time. I might be downstairs in our basement watching TV, and come across something that I want to look up. Or, I might suddenly remember I need to send and email or check the some stats of some sort (traffic or MLB standings, for instance). If my Mac is up on my desk and my iPad upon my nightstand (or, more likely, in the hands of my daughter), I’ll just whip out the iPhone and search for the desired information that way.

The interesting thing to note is that these actions are based on exactly the same motives that might have driven me to my laptop or desktop a few years ago. Today, I simply have to convenience of being able to carry the internet with me wherever I go (or at least wherever my 3G network will allow me to connect). Is there a difference in context? Absolutely. But, it’s more about the device than it is about my intentions, and any assumption that I am in a hurry when I am lounging on my couch is likely to be fundamentally inaccurate.

I just want to get the information I’m looking for.

Mobile First?

Of course, the logical extension of designing as though users are in a hurry is not necessarily a bad thing, and has been one of the fundamental principles of good usability for years. Even before the explosion of web-ready cellular devices, I seem to remember most UX pundits preaching that the fewer obstacles you put between your user and the content they are looking for, the more usable your site will be and, by extension, the more enjoyable the experience will be for the user.

As far as i can tell, that hasn’t changed.

It just seems that a number of factors have brought it to (back) to prevalence. The first is this assumption that users surfing on a handheld device are in much more of a hurry than users surfing on a desktop or laptop; we assume that they need information faster. In response, we start to cut out all the fluff (widgets) that have filled our sites for so many years, leaving us with optimized “mobile” sites that are leaner and more efficient than their desktop counterparts.

Of course, we’re thinking of the user first here. Right? It has nothing to do with that other factor called screen space. Because, as Luke Wroblewski has rightly pointed out:

There simply isn’t room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.

Suddenly, we don’t have room for all that extra content. We can’t cram an entire brochure’s worth of material (which probably too much even for a brochure) above the “fold”. Advertising banners or Google Adwords just take up too much valuable visual real-estate and either need to be relegated further down the page or removed entirely. As Luke points out, we suddenly need to prioritize, and if we have any common sense at all, that priority needs to be the content.

In ruthless, butcher-shop fashion, we cut away all the extra fat and produce simple sites where content is allowed to shine. In fact, we produce the type of sites that we should have been creating all along, regardless of the device they are being viewed on.

And, at least as I understand it, that is the reason (or at least one of the reasons) that Luke Wroblewski preaches his concept of mobile first with such fervor. It takes us back to the basics and helps eliminate much of what the calls the ”interface debris that litter today’s desktop accessed Web sites.”

Interestingly, however, if we dig to the core of this argument, we find that its not about division, but cohesion. The beauty of the so-called “mobile” design is that its fundamental constraints naturally lead to a better user experience on handheld devices (or at least handheld devices that offer a modern browsing experience). But the idea shouldn’t stop there. Instead, it should flow over into the entire site, placing the focus on content and usability in all contexts, not just for the smaller screens of our handheld devices.

The New Boston Globe

As a case in point, let’s look at the Boston Globe as an example. If you haven’t heard about its recent redesign, you clearly don’t spend much time on Twitter. Regardless, since it’s launch, news of this redesign has been plastered all over the design circles, mostly with a reasonably positive reception.

Setting the subscription-for-content model aside, the site overcomes a number of the issues that face many news-based sites these days (see this installment of The Brads for plentiful examples). It has a clean, elegant design that places the emphasis directly on the content. Lovely typography makes reading a real joy.

The new Boston Globe at a wide resolution

The exact same site with a narrower window

And finally, the same site in a very narrow window

More significantly for our purposes, however, is the fact that these statements remain true on my iPhone, my iPad, my MacBook, and even on IE8 on my Vista-powered home PC. The site doesn’t try to distinguish between “mobile” and “desktop” users. Nor does it appear to make any glaring assumptions about behaviour in these areas. It is simply designed to respond to the space allocated for display, and to do so in such a way as to provide optimum readability and usability.

In my mind, this is the way of the future. It’s not about a “mobile“ web that stands in direct contrast to a “desktop“ web. Instead, its about a single, flexible and meticulously crafted web that provides rich user experiences across a wide range of different devices.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Over the past few months, it seems that pretty much every site I’ve been working on has required functionality that allows users to register and then log in, either to access certain content or to interact with the site in some way. As such, I’ve been working to determine the most usable solution to provide a seamless user experience.

In this article, I would like to look at one popular technique that I tend to favour for a number of different reasons. First, we’ll look at how to achieve it using a bit of jQuery. More importantly, however, we’ll also be considering how to develop the entire thing so that it degrades gracefully for users who may have JavaScript turned off, maintaining usability and preventing a poor experience for these users.

The Concept

The basic concept is to have a single login button in the top right hand corner of the page. It could be a single button that stands on its own, as we see on something like Twitter’s post log out page (shown below). Or, it could be part of a larger menu, as we see on a site like MediaLoot.

We van see the drop down menu on Twitter after we've logged out

Either way, when the user clicks on the button a small but simple form appears directly below, allowing the user to log in.

What I like about this technique is its immediacy. The user indicates their desire to log in and is immediately presented with the interface to perform that action. There is no need to wait for another page to load. Also, with the Twitter page, focus is automatically given to the username field, meaning that the user can start typing without any additional clicks.

It’s little details like this—which work to reduce the amount of time it takes to perform a particular action—that really enrich the user experience. So, let’s look at how to do it.

The Markup

The first thing we’re going to need to make this work is a bit of HTML. Here’s what we’ll be starting with:

<ul> <li><a href="#" id="loginButton">login</a></li> </ul>

Since we’re only using a single button in this example, it would be possible to use just a single link, but I generally tend to have the login button as part of a larger menu—perhaps featuring home, register, contact or other buttons. So, I am working from a simple unordered list. This will also provide some structural hooks that will come in handy later.

Obviously, this list will also be surrounded by the additional markup which forms the rest of the document. There’s no real reason to reproduce that here though.

The CSS

Next, we need to style it up with some CSS. Again, I’m not going to reproduce all the rules that are used to style the complete list, the button and the form inputs, since those are choices that are going to be made based on the specific design of a given site. What I do want to focus on are some of the more functional styles that we’ll need for the form element itself:

ul li{ position: relative }ul li form{ position: absolute; top: 33px; right: 0px; display: none; }

First, we want to set the position of the list element to be relative. Why? Because we will actually be appending the login form into that element, right after the link itself. By setting the individual list element (the parent) to position:relative, we can then set the form element (the child) to position:absolute, allowing us to place the form relative to the button.

We can then set the top property to whatever value is required to ensure that the login form appears directly beneath the button (this is usually equal to the height of the button itself, including padding).

Lastly, we simply set the display property to none, as we only want the form to be revealed when the button his clicked.

Again, the properties I’ve listed here are only those necessary to control the behavior of our form. You will also likely want to style things like the background and text colours, or possibly even use some CSS3 properties like border-radius, box-shadow or text-shadow to really enhance the visual experience of the form (see the form button in the demo).

The jQuery

You may be wondering about this form I keep referencing. With the HTML and CSS we have thus far, there is no form. That’s also exactly what we want. We’re now going to create the form dynamically, using a bit of jQuery. Here is the code:

jQuery(document).ready(function(){ var formHTML = '<form id="loginform" method="post">'; formHTML += '<input type="text" name="username" id="username" value="username" />'; formHTML += '<input type="password" name="userpass" id="userpass" value="password" /> '; formHTML += '<button type="submit">Login</button>'; formHTML += '</form>'; jQuery("#loginButton").append(formHTML); }

This code assumes that you already have jQuery linked into your document. Once the document has been loaded, we declare a variable named formHTML and fill it with the simple HTML that will make up our form. Then, we use the jQuery append() method to add the form into the list element, which now looks more or less like this:

<ul> <li><a href="login.html" id="loginButton">login</a> <form id="loginform" method="post">'; <input type="text" name="username" id="username" value="username" /> <input type="password" name="userpass" id="userpass" value="password" /> <button type="submit">Login</button> </form> </li> </ul>

Of course, because of the CSS we added, you won’t actually see this form being dynamically added to the DOM, which is exactly the type of invisible behavior that we want. For the user, it will be as though the form was always there, just waiting to be revealed. Unfortunately, if you were to click the button at this point, nothing would happen. So we need to add the following code to our jQuery listener:

jQuery("#loginButton").click(function(){ jQuery("#loginform").slideDown(250,function(){ jQuery("#username").focus(); jQuery('html').click(function() {jQuery("#loginform").slideUp(500,function(){ jQuery('html').unbind('click'); jQuery("#loginform").unbind('click'); jQuery("#loginButton").toggleClass('clicked'); }); }); jQuery('#loginform').click(function(event){ event.stopPropagation(); }); }); jQuery(this).toggleClass('clicked'); });

There are a lot of nested functions in this, but what’s going on here is really simple. We’re telling jQuery that when the login button is clicked we want the login form (targeted by its ID) to slide down and become visible—with the animation taking 250 milliseconds. Once the animation is complete, we immediately add focus to the username field.

It is very common for elements like our form (or like modal or lightboxes) to close automatically whenever the user clicks anywhere else on the screen. The Twitter login form I mentioned above does this, and we’ll be emulating this behavior with the next few lines. Once the form has been revealed, we will apply another listener, which is triggered any time the document (html element) is clicked. The associated function will then slide the form back up to its hidden state, unbind the active listeners and toggle the clicked class (which we’ll get to).

There is, however, one problem with this: because the form itself is part of the DOM (obviously), if we click it for any reason, the form will close. Yes, that is bad for the user experience.

Fortunately, we can fix this using the stopPropagation() method. Basically, this stops the click listener we set for the html element from being applied to our form element, thus allowing us to click on it without also closing it. Beyond that, I’m not sure exactly how the method works. I’m just glad that it does.

Lastly, when the login button his clicked I also use the toggleClass() method to add the class of “clicked” . This allows us to apply different styles to the button when the form is open or active. This class is also toggled off when the form is closed.

The Fall Back

By this point, we should have a nice, functional drop down form that makes logging into the site a simple and easy process.

Unless, of course, the user has JavaScript disabled.

In that case, it’s not usable at all because the login form simply will not appear. In fact, it won’t even exist, because the script that we used to create it will not be executed. If we stopped here, it would be a definite UX fail.

We could use the noscript tag to inform users that JavaScript is required in order to use the site, but that doesn’t make for the best experience either. Instead, we can make a couple simple changes to our code to create a simple, usable fallback position that does not rely on JavaScript at all.

First, we’ll add an actual value to the href property in our button. This should link to a separate login page, which you will need to create (or use one that already exists). Our HTML will now look like this:

<ul> <li><a href="index.html" id="loginButton">login</a></li> </ul>

When the user clicks on the login button, they will now be taken directly to the separate login page. It’s not as elegant as having the login form drop down on the same page, but it is still a perfectly usable alternative for users who don’t have JavaScript enabled.

The only hiccup here is that this link triggers for all users, meaning that even users who do have JavaScript enabled will be forwarded to the separate page, thus rendering all our hard work on the drop down useless. Fortunately, this is easy to fix too. Just insert the following line of code directly before the block that automatically generates the form.

jQuery("#loginButton").removeAttr("href");

The logic here is simple. If JavaScript is enabled, it will execute and remove the href attribute from the login button, thereby breaking the link and preventing it from sending the user to another page. The script can then continue as intended and generate the login form, revealing it whenever the button his clicked. If JavaScript disabled, the href (and our fallback) remains completely intact.

Using this technique, we have enhanced the login experience using jQuery, while still maintaining usability in situations where the our scripts cannot be executed.

Here's a simple screenshot of what the drop down will look like (with a few more styles)

Check out the demo

(Also, don’t forget to try turning of your JavaScript)

A Pure CSS Solution

For you purists out there, it would likely be possible to create a similar effect using pure CSS. I’ve played around with this, and while it is certainly possible to make the form appear on a hover, I have not found a way to make it appear on a click. A hover-based CSS solution also has the distinct drawback of requiring the persistence of the hover state; if the user moves the mouse away, the form disappears.

In my opinion, this hurts overall usability.

There are also touch-based devices to consider, which do not support hover functionality. Without this support, using hover to reveal the login form would also seriously effect usability on these devices.

For these reasons, I feel that using a JavaScript technique—with an appropriate fallback—provides the most usable experience. If anyone knows of a pure CSS, however, I’d love to hear about it!

Also, feel free to use any of the code that was discussed in this article or that appears in the demo for your own purposes.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

As designers and developers, most of us are working on projects for clients on a regular basis. For most readers here, it will probably be the design and development of websites, or possibly even web or mobile applications. For others, it could be different forms of design, such as identity work or packaging. In any case, we invest hours and hours into the planning, execution and even revision of these projects.

Client work is certainly important, since it is often a large part of what helps pay the bills and bring home the proverbial bacon. Unfortunately, when working for someone else, we generally don’t have complete and total control over what we are doing. Yes, we have been hired to do the job, and yes that should mean that we—not the client—are making the design decisions. Still, a big part of the web designer’s job is to deploy his or her skills not only to create a totally awesome website, but also to help realize the client’s vision and develop solutions to their unique problems. This naturally places some constraints on the process.

In some cases, these constraints may involve working within standardized corporate guidelines for branding and identity. In other cases, it can be a matter of consulting on what kinds of layouts and interactions might make for the most effective and usable e-commerce solution.

Yes, occasionally, that odd project will come along where we are given the extensive creative freedom to take the project and/or design in pretty much any direction that we see fit (cherish and enjoy these projects whenever they come along). Even in these situations, though, all the creativity, energy and experience you pour into the work is still all for the primary benefit of the client.

That’s why I think that every single designer and/or developer needs at least one side project—something that is all their own, and which is entirely free of any kind of client direction or expectation. There are a number of great benefits to be derived from these kinds of projects. Let’s look at a few of them.

Passion

As much as you may have a passion for all things related to design and web development, that does not always mean that you will be working on projects that your are also passionate about. In fact, quite often you may find yourself working on designs and sites that are somewhat dull or commonplace. Unless you are in a situation that allows to turn down work that doesn’t interest you, this is likely something that you will find quite common in the world of client services.

A good side project can provide you with an outlet through which to truly channel otherwise frustrated passions. It can be something to embrace with enthusiasm, energy and vigour, and to throw your entire self into. It can also be extremely surprising how energizing a project like this can be.

If it’s something you are truly passionate about, you may find yourself putting long hours into the project, but coming away excited and full of energy because of it. Ideally, you would then be able to channel this back into the work you are doing for your clients.

It’s almost like a mini-design holiday to recharge your batteries!

Experimentation

A side project can also be a great area for experimentation and trying out new techniques, especially in the world of web design, where new technologies seem to be released on an almost monthly basis. Though there are always different perspectives on when these technologies may be ready for implementation on client projects, more often than not we will find designers and developers deploying them in some way on their personal sites.

CSS3 is probably the best example of this. While it is certainly not fully supported (though we are getting closer all the time), a wide range of designers are still using CSS3-based techniques on their own sites. In some cases, it’s used as just a bit of progressive enhancement. In other cases, it manifests itself in much more expressive ways, with all kinds of innovative and sometimes just plain whacky concepts (see this article for some examples).

Sometimes these experiments may not be the most practical or approriate uses of the technology, but they do tend to help keep our web-geek minds entertained.

Experimenting on a side project can also just help you further develop and hone your skills. You can attempt a number of different possible solutions to a particluar problem without having to worry about billing clients for that experimentation. Then, when the need for such a solution comes up in a project, you can impress the client with your skill, efficiency and knowledge in that area.

Remember, we always need to be learning and growing, and using a side project as a playground for various types of experimentation is great way to stimulate this growth.

Recognition

It’s a common enough desire to be recognized (usually in a positive way) by our peers, and side projects can help in this regard too, especially if they are of benefit to the community. There are all kinds of tools out there that people have developed and made available, and which have helped to establish their reputations within the community.

Take Tyler Tate for example. If you haven’t heard of Tyler himself, chances are you have heard of his 1KB CSS Grid, which is one of the more well known of the grid frameworks that have been commonly used over the past several years. More recently, Tyler has created another framework called the Semantic Grid System, which addresses the issue or semantics (or lack thereof) with class-based grids like the 1KB system.

1KB Grid System is the type little side project that can increase recognition for its creator

Seemingly as a direct result of this new system, he also authored a recent article on Smashing Magazine, in which he discusses the concepts behind the new system (which runs of of LESS).

It’s a simple example, and one that was at the forefront of my mind, having recently read Tyler’s article, but it is a clear demonstration of how a meaningful side project can actually help establish yourself in the community. Without his experience creating the CSS grids, maybe Tyler doesn’t get the chance to write for Smashing Magazine (though he probably would—he has also recently written for A List Apart), potentially losing out on an excellent example for exposure.

A Little Extra Coin

Let’s be honest—it never hurts to make a little extra money, especially when dealing with the unpredictable ups and downs of the freelance life. Side projects can sometimes help in this area too. You may create an awesome web service, and sell some advertising space. Or maybe you just sit down and create something which ends up growing far beyond what you expected it to, to the point where you either sell it off or it becomes a viable business onto itself.

One great example is the site DesignNewz. Originally crafted by my good friend Jon Phillips (formerly also of SpyreStudios), this popular design news site was conceived, crafted on WordPress and then launched all in a matter of hours. Over a period of time, Jon watched the site grow and flourish, to the point where he didn’t have the resources to manage it. So, he put it up for sale and made a bit of extra cash off the project.

DesignNewz was originally a side project that has grown into something much larger

Today, DesignNewz continues to deliver content and has even seen a network of related, sites that sprung up around it.

On a larger scale, we can look at something like Dribbble. I am not as familiar with the specifics behind its founding, but from what I’ve read and heard about the site, it certainly seems as though the site was originally launched as a collaborative side project of Dan Cedarholm and Rich Thordnett. Having now processed nearly twenty billion image pixels, it has grown considerably, featuring thousands of members, paid (pro) accounts and income from advertising.

Of course, not all side projects are going to become the next Dribbble, but that doesn’t mean that you can’t make a little extra cash with your project too!

What Should You Do?

By this point, I hope that you can see that there is true value in having and developing some kind of side project. The question that remains, however, is: what kind of side project should you have? Well, that depends most strongly on a single variable; and that variable is you.

What do you want to do?

There is no right or wrong answer here, and it manifests itself differently for everyone. One common choice is the design and development of a personal blog. It could be a design blog, but it doesn’t have to be. Well known design author Andy Rutledge has his Design View blog, where he writes about design-related topics, but he also has blogs about bonsai and cycling, two of the other things that he loves.

You don’t need to create a blog though. You could create a new framework, theme, application, typeface or even a book or printed magazine (Elliott Jay Stock’s lovely 8 Faces comes to mind). Moreover, a side project doesn’t even necessarily be design-related at all. Personally, the project that I am tackling at the moment is a fantasy-based novella, which I hope will be the first in an ongoing series. There are some design related elements (a website, book covers), but they are more or less peripheral. The real focus is creative writing.

I hope to have some preview material available my mid-september so stay tuned!

So, I hope you can see the real benefits of a side project, and in In closing, I will simply ask: what’s your side project?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

By now, I think it’s safe to say that most designers on the web are using CSS in some capacity. Even those (misguided) individuals who are still using table-based layouts have a tendency to use CSS for some basic styling, such as establishing fonts and link colours. With that in mind, I thought it might be worthwhile cover some of what I have found to be best practices.

Before getting started, it’s important to note that these are practices and habits that I have developed based on my own experience, which includes developing different sites, my own experiments and reading from a variety of sources. While I have my own reasons for the way I do things, I am in no way presenting the following as CSS gospel that absolutely needs to be followed.

As with anything, take what you read, weigh it against your own knowledge, values and experience in order to formulate your own methodology.

Start With A Reset

When starting the CSS development of any new site, I always recommend using some type of reset. In spite of how things may appear, I find it helpful to assume that an “unstyled” page is not actually unstyled when viewing it in a browser. Instead, it is simply rendered with the browser’s default styles. Some of these will be based on the CSS and HTML specifications—such as whether an element is rendered as an inline, block or other type of element. Others are based on some common conventions that have emerged, such as the blue default link colour.

However, default styles are not identical between all browsers, and using a good CSS reset helps bring everything back to a common starting point. From there, you can begin adding the various rules that you need for your specific site, without having to worry as much about minor variations.

Of course, there are some excellent designers and developers who have expressed that they don’t like using hard resets, for a variety of reasons. Even if you chose not to use a full reset, there are benefits to using some sort similar technique, even if it’s just a matter of declaring global properties like typographical styles, document padding or default colours for text and links. Instead of having to declare these properties over and over again, simply set them at the highest possible level—often the body tag—and let it filter down through the rest of the document.

Use Inheritance and the Cascade

Which brings use to the next topic—inheritance and the dreaded cascade. These are powerful tools for writing lean, effective CSS, and I highly recommend adding them to your repertoire, and using them wherever possible.

First, inheritance is exactly what it sounds like. Elements inherit certain properties from their parent elements. For instance, suppose I write a very simple rule like this:

div p{ color: #0000FF; }

This would style any HTML paragraph element that was the descendent of a div element as blue. It doesn’t matter if that element is a first-generation child of the div. So long as it is wrapped in a div at some level, the rule will apply through inheritance. So, suppose we had something like this in our HTML:

<div> <p>First level paragraph text</p> <ul> <li> <p>List level paragraph text</p> </li> </ul> </div>

Both paragraphs would be styled the same colour. The element within the list would simply inherit that colour based on the single rule that we wrote.

Obviously, this is a simplistic approach, but it’s powerful in that it allows properties to be declared at a broad level and then filter all the way down through the document, without having to redeclare them multiple times.

Of course, we don’t always want to have every element in a document styled exactly the same way, and this is where the cascade comes into play. Explaining the entire concept of the cascade and CSS specificity is beyond the scope of this article (check out the W3C on this topic), but if you understand how it works, you can harness the many advantages it offers, and learn to write elegant rules for anything from the very broad to the highly specific.

The key, however, is to not get unnecessarily specific. Writing something like

html body header nav ul#mainNav li a{  color: #FF0000; }

is probably taking things a little far. If all you want to do is change the colour of the links in your primary navigation to red, then something as simple as

#mainNav a{ color: #FF0000; }

will likely have all the specificity that you need. Everything else is (in the vast majority of cases) simply unnecessary. Obviously, there can be situations where you do need to get more specific for one reason or another, but generally speaking, it’s simpler and more efficient to tap into your understanding of the cascade and use the fewest possible elements in your selectors.

More On Typography

CSS is, hands down, the absolute best way to deal with typography on your website. Yes, there are some JavaScript solutions like Lettering.js that allow you to do some pretty awesome stuff, but stylesheets still remain the typographical backbone of any CSS-based site. As such, I have developed a few practices that I find to be very helpful when managing the typography on my sites.

First, I always like to set some basic rules for visual hierarchy on a page. As I’ve written before, I do like using CSS frameworks, and I’m quite fond of the way the Less Framework approaches document hierarchy. Here is a segment of the framework’s default CSS:

/* Typography presets ------------------ */ .gigantic {font-size: 110px; line-height: 120px; letter-spacing: -2px; }.huge, h1 {font-size: 68px; line-height: 72px; letter-spacing: -1px; }.large, h2 {font-size: 42px; line-height: 48px; }.bigger, h3 {font-size: 26px; line-height: 36px; }.big, h4 {font-size: 22px; line-height: 30px; }body {font: 16px/24px Georgia, serif; }.small, small {font-size: 13px; line-height: 18px; }

Granted, this is a really simple set of rules, but it’s amazing how effective a collection like this can be for establishing the typographical hierarchy of a site. Of course, I generally tweak and add to these rules, often changing the typefaces that are used, setting colours or tweaking font sizes.

Also, I want to stress that I am not suggesting that you need to use this exact method of defining your typography. I am merely citing it as an excellent example (that I happen to be partial to) of how this useful practice can be executed. You may also want to check out the article “More Meaningful Typography,” which offers additional perspective on the issue of typographical hierarchy.

The other typography-specific practice that I like to use is to include all my @font-face declarations right at the top of my stylesheet, before any of my other typographical presets. Not only does this force a logical progression (I am not calling a typeface by name before it has been declared), it also helps with organization. Because I always know exactly where all my @font-face code is, it’s easy to make changes, such as swapping one typeface out for another—something that I do quite frequently in the early stages of a new design.

Comments & Logical Sections

With stylesheets of any significant size, it’s always a good idea to be organized. Well-commented code that is broken into logical, semantic sections is, in my opinion, the best way to accomplish this.

Any well-coded HTML document will have a clear, semantic structure. Even if you have different layouts for different pages, chances are they will at least share some key semantics and common structural elements, such as headers, navigation and/or footers.

This provides a perfect blueprint for organizing your stylesheet. Look at each of the large areas within your HTML structure and use comments (demarked in CSS with the syntax /* comment */) to break your CSS down accordingly. If you have thousands of lines of code, you may also want break these main sections down into smaller, sub-sections for increased organization.

The better organized and commented your code is, the easier it will be for you (or someone else) to read and maintain it.

A Declaration Per Line

This may be the most personal (and perhaps argued) of the practices that I will be covering in this article, but when I write my CSS I almost excusively work on a one-declaration-per-line basis. So, if I was to define a number of properties for my paragraphs, I might write something like this:

p{ font-family: Georgia, serif; font-size: 16px; line-spacing: 22px; color: #444; margin: 1em 0; }

For me, this is really the only way to do it. I know some people who prefer to write all their declarations on the same line. Reading their code drives me nuts. I find it much easier to isolate a particular declaration when they are all on their own lines. I don’t know about you, but I don’t always get all of my CSS declarations right the first time, and may need to change something. Even if I’m happy with the way things are displaying, something I do later on may effect inheritance or the cascade, forcing me to tweak rules I have already written. Placing each declaration on its own line makes subsequent changes much, much easier for me.

There are, however, a few exceptions to this habit of mine. If I am only including a single declaration in a rule, I will sometimes write the entire rule on a single line. This is especially true when I am working with image sprites, and require a block rules that change the background position for a number of different elements (usually icons or buttons). So I may do something like this:

div.icon{ background-image: url(icons.png); background-repeat: none; width: 20px; height: 20px; }div.contactIcon{background-position: 0px 0px} div.aboutIcon{background-position: -20px 0px} div.servicesIcon{background-position: 0px -20px} div.homeIcon{background-position: -20px -20px}

Because I am only using a single declaration for each of the icon classes, I can save a bit of visual space by just using a single line, without sacraficing readability. In fact, this helps to bring all the position information into closer proximity and can make the code even more readable.

There are a few other special cases like this, but for the most part, I really do perfer to keep each declaration on its own line. As already mentioned though, this is just a personal preference that I feel improves my code.

Multiple Selectors, One Rule

Efficiency of code is always something worth striving for. This can help simplify maintenance and reduce overall file size. One way of doing this with your CSS is by using multiple selectors with the same rule.

For instance, I frequently want to set all my document headings in a typeface other than the one that I am using for my body copy. For the sake of example, let’s suppose that I decided to use Georgia. I could do this by writing a separate rule for each heading level:

h1{ font-family: Georgia, serif; }h2{ font-family: Georgia, serif; }h3{ font-family: Georgia, serif; }h4{ font-family: Georgia, serif; }h5{ font-family: Georgia, serif; }h6{ font-family: Georgia, serif; }

This is entirely valid and would accomplish the desired goal. It’s also somewhat redundant. A more efficient solution would be to use multiple selectors on the same rule:

h1,h2,h3,h4,h5,h6{ font-family: Georgia, serif; }

This accomplishes exactly the same thing as using six separate rules, but in a much more efficient manner.

If I find myself writing the same property/value pairs over and over again, I always try to ask myself if there is any way to combine them all into a single rule. It’s not always possible (or even desirable), but I do frequently find logical ways of using multiple selectors to combine identical declarations.

The key here is logic. I value organization over saving a few property declarations, and if I have to sacrifice some significant level of organization (such as combining two selectors from different semantic areas), I prefer to maintain that organization and keep them separate.

When to Use Shorthand

CSS has a number of properties for which you can use a shorthand notation, allowing you to set multiple style properties with a single declaration, rather than having to declare them all individually. As you can well imagine, it’s an incredibly useful technique that can save a ton of time, but sometimes it’s not always the appropriate solution.

First, let’s start by looking at an example of one of the more common shorthand notations. Instead of writing this:

p{ margin-top: 5px; margin-right: 10px; margin-bottom: 15px; margin-left: 20px; }

We can simply write:

p{ margin: 5px 10px 15px 20px; }

The choice of margin sizes here is mostly to illustrate the shorthand pattern, relative to the individual declarations, but you can see how using a single shorthand format is much more efficient. A similar shorthand exists for padding and there are also shorthands for backgrounds, borders, fonts and a number of other properties.

So when do we use them? I generally rely on common sense. If I only need to declare one or two margins in a specific rule, than I will declare each property separately. The non-declared margins will simply inherit their values according to the rules of the Cascade. On the other hand, if I need to declare all, or even three of the margins, I will generally go with the shorthand.

Pretty straight forward.

Again, there are some key exceptions to this practice. If we look back to the example I gave regarding icon sprites, I defined each property individually, instead of using the shorthand method. I did this because I would subsequently be re-defining the background position for each class. I have typically found that when I need to do this kind of thing, it’s a better practice to define each property on its own rather than using the shorthand.

Single vs. Multiple Files

There is some debate about whether or not we should be using single or multiple files with our CSS. I don’t necessarily think that there is any clear cut answer to this question, but personally prefer to minimize the number of files that need to be downloaded for any given page. Given this, I tend lean to towards putting most (if not all) of my CSS into a single file.

There are, however, some notable exceptions. For instance, when I first set up my site, I elected to establish this blog as a subdomain, leaving the main Echo Enduring domain as my personal portfolio. When I came around to undertaking my first redesign, I wanted to streamline the process a bit, and developed a single stylesheet that set some of the key styles that would be shared between both sites. I then used secondary styles for rules that were unique to either the portfolio or the blog.

Similarly, if you are working on a large network of sites, like the Tuts+ network or the Fuel Brand sites, it can be helpful to have a single stylesheet that helps establish the universal rules that are shared among all the network’s sites. You can then use secondary stylesheets for things like colours, logos and other site-specific declarations. This can help simplify maintenance across all sites. It can also simplify the process of deploying a new network site at a later date.

The other main reason that I would use multiple stylesheets would be when adding support for various versions of Internet Explorer to a site’s design. Using conditional comments to link to separate IE-specific stylesheets allows us to write rules that will override those declared in the main stylesheet. Obviously, this is far from ideal, but it has proved to be one of the most effective and widely used solutions for dealing with the idiosyncratic (hair-pulling) tendencies of IE.

These certainly aren’t the only reasons for using multiple files; they are simply illustrative of the most common scenarios in which I find myself doing so. There are certainly other appropriate circumstances.

The one thing that I advise against, however, is using multiple files simply as a means of organizing your CSS. This simply adds extra requests to accomplish something that can just as easily be done with a good commenting system in a single stylesheet (as discussed above).

Conclusion

Well, there you have it. That actually ended up being a lot more than I thought it would when I set out to write this post. Hopefully, you either found some new and useful ideas, or you were reminded of practices that you believe in, but may not have fully following or implementing in your own work. Even in just writing out my thoughts in these areas, I’ve found that I can certainly improve my code in a number of these areas!

Lastly, I want to stress that I don’t use any sort of CSS processing tools, such as SASS or Compass. As such, I’ve approached all of these practices from the perspective of writing flat stylesheets. I can, however, see how some of the organizational techniques may not fully relevant when using some of these other tools.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Let me start by saying that, as a concept, I am a big fan of what people are calling responsive design. The ability to build a site with multiple layouts that are displayed based on the size of the browser window (and, by extension, the device) is really attractive and has a great deal of practical use in the everyday world of web design. Over the past few months, I’ve even been implementing it in a number of the projects I’ve been working on.

I’ll be the first to admit that I do still get a kick out of being able to resize my browser and watch the design shift as I cross certain thresholds. I also love being able to access the site on my iPhone and have it render simply and elegantly, without having to pinch-zoom to actually be able to read anything.

That being said, however, there does seem to be a current, prevailing sentiment that responsive design is somehow going to be the ultimate solution for design on the increasingly mobile web. Just this week, I read a tweet in passing, which basically stated that there is no “excuse” for not using responsive design on websites today. It struck me as an overly broad, and perhaps even somewhat naïve statemnent.

Yes, responsive design is a wonderful, useful tool, but it is not a all-encompassing panacea. Amidst all of the hype and excitement that surrounds responsive design in the community right now, there are a number of issues that we need to be considereing and discussing.

Longer Development Times (and Greater Costs)

Any experienced web designer would probably agree that creating an excellent, well-designed, cross-browser compliant (which is not to say identical) site involves a great deal of work, part of which is generally the creation of CSS. Even if you’re using tools like SaSS or Compass, which are designed to make CSS authoring quicker and easier, there’s still a lot of time involved.

Now, imagine doubling or even tripling that work.

The beauty of using media queries is that it allows you to set a global rule, and then create subsequent rules within your queries, which override the global rule if the specific media conditions are met. This is an incredibly powerful technique, to be sure, but it’s not something that just magically happens. Although you may actually author rules for different resolutions in tandem, from the perspective of the final product, you need to create both a complete “default” stylesheet, and then additional sets of styles to account for different screen sizes.

It’s a lot of extra work, both in terms of writing the CSS and testing at the different resolutions. Depending on the size of a project, it could potentially end up taking on a lot of extra development time. And, of course, with extra time also comes extra costs, which a client may not necessarily want to incur.

This is equally true of the Photoshop mockup phase (assuming that you work that way). If you generally create a series of mockups in order to build the visual “skin” of your site, what are you going to do if you’re undertaking responsive design? Produce a different mockup for each key width? Let’s assume that you have four different types of pages that you need to design, and that you’re accounting for four different types of browser widths (as recommended by a responsive framework like the Less Framework). That’s four pages at four different sizes each, brining the grand total to a whopping 16 mockups.

Of course, I do recognize that there will be some reusable elements. Headers, footers and other key visual items will likely be the same, so it’s not like you will be creating each mockup from scratch. Rather, you will likely create an initial design and then use that as a baseline for all subsequent variations. That being said, however, each page will likely have its own unique features that will require your attention to some degree.

So, instead of simply assuming that all your future projects will automatically require media query-based responsive design, be sure to weigh both the cost and the value of building a responsive layout. Will the value it brings to the site balance the cost of implementation, relative to the project’s budget? If not, then maybe a fully responsive layout is not appropriate, at least in the short term. Of course, if you design the static, non-responsive layout properly, it should be relatively simple to come back and make it more responsive in the future.

Advertising Considerations

One of the other things that I’ve given a great deal of thought to in terms of responsive design is the question of advertising. Selling ad space is a huge cog in the money making machine of many websites. There are a great number of different ways of handling advertising. One popular choice is the use of Google Adwords, or a similar, text-based link advertising. This is probably the easiest way to deal with ads in a responsive layout.

But what about the type of advertising that is based more around banners? In my experience, these types of ads are generally sold based on their position on the page, with prominent spaces near the top of a page selling for more than spaces further down or in the site’s footer. What happens when we try to introduce a responsive layout to a site like this?

If we create a layout that renders differently in varying window sizes, and if part of that response involves shifting the way elements are arranged, then the question of advertising suddenly becomes a whole lot more complicated. That stack of six 125 by 125 banners that displays so prominently on a desktop or laptop may not be nearly so prominent on an iPhone, or even on an iPad, depending on how you layout the page and/or how you establish its responsiveness.

The current Spyre Studios design is not responsive, but if it was, how would they accommodate all those ads?

How does this effect ad sales? Do you (or your client) sell based simply on the number of non-mobile visitors and write off mobile visits as a bonus for your advertisers? What happens when your desktop or laptop visits start to diminish and mobile visits start to increase? If we maintain that model, it’s entirely probable that ad revenue could begin to decline, even if site’s traffic continues to rise. And, from a business perspective, that’s never a good thing.

Another potential solution might be to sell different ad spaces for mobile and non-mobile devices. Setting aside the challenges associated with making this distinction in the first place, we then have to start questioning the place of responsive layouts as we have been considering them. The beautifully simple idea behind this type of responsiveness is to not require both a regular site and a separate mobile site. Instead, we are able to present the same HTML document, allowing the CSS to optimize the layout based on the available real estate within the browser window. The moment you start to introduce conditional content, however, you are are no longer serving up the same HTML, and as such are moving away from the beautiful simplicity of CSS-based responsive design.

It’s more akin to having a regular site and a mobile site, rather than just a single site that simply adapts to its context.

Of course, this is not to say that this is a bad or faulty technique. In fact, if you are using a reasonably reliable technique for detecting mobile devices, this may be the most viable and practical solution for your advertising-driven site (see WebDesigner Depot for a good example of this). It also doesn’t mean that the CSS techniques that are at the core of responsive design cannot be used. It’s just not purely responsive, which suggests that there may be contexts in which responsive design is only part of the solution for making the site accessible across multiple devices and platforms.

Regardless, the point is that the presence of advertising on a site raises some important questions that need to be thoroughly considered before diving head-first into building a fully responsive layout.

User Experience(s)

The last point that I want to touch on is the issue of user experience. A great deal had been said and written on this broad, broad topic. One of the conceptual cornerstones of much of this discussion is the importance of consistency. In an article titled “Consistency: Key to a Better User Experience” (published over at UX Booth), the author writes:

[Users] shouldn’t have to spend a long time finding what they’re looking for. A consistent website is predictable and therefore learnable. After a while, users will find the information that they’re searching for effortlessly.

There is definite truth to this statement, which begs the question: how does responsive design effect the consistency of a site? When a user who has historically browsed your site on their home computer visits it for the first time on their brand-spanking-new smart phone, how comfortable will they be with the layout? How much of it is familiar and predictable for them? How much of it will require re-learning the interface?

As a basic example, consider the following site. Here it is at full resolution on my MacBook:

Here we have a very attractive site with lots of lovely white space and a cool vertical navigation bar

It has a lovely design, with the logo and menu appearing in a simple, vertical black box. Now, here is a screen shot of the exact same site, at the exact same URL, but visited from my iPhone:

The logo and navigation on the iPhone are very different from the full width version

Now, I don’t read Swedish (which the language Chrom wanted to translate this page from), so I have no idea what this is actually saying, but there is a somewhat stark contrast between the design of the menus in the two screenshots. And, it doesn’t seem to be a matter of spacial limitations. For some reason the white on black theme for the logo and menu is suddenly inverted at a smaller resolution. The designer may have a reason for doing this, but it still strikes me as inconsistent.

Is this really a big deal? On its own, probably not. I’m sure that visitors will be able to figure out the navigation. But what would happen if this was just one of many instances of responsive inconsistencies? How would that effect user experience? Probably in a somewhat negative fashion.

Responsive design can be great, but it’s important to keep the user experience in mind and design the layout so that it responds in ways which, while different, are still consistent and predictable to users. The site Mediaqueri.es is a spectacular resource for inspiration in this area. Examine some of the sites posted there to see how other designers have solved (or not perhaps not solved) this dilemma. There are all kinds of creative approaches.

Conclusion

Obviously, there is a lot that can be said about responsive design and I do plan on continuing to write on the topic as my own experience continues to grow. For the purposes of this article, the important thing to understand is that responsive design, like any other tool, has both benefits and potential shortcomings. As designers, it’s our job to weigh both sides of that proverbial coin in order to make appropriate decisions, based on the unique needs and context of the project.

It’s also worth noting that not everyone on the web is in love with responsive design. Recently, Luke Jones authored a short post about why he is looking for the “trend” of responsive design to eventually die out. His article, and the discussion in the comments, raises some very interesting points, and clearly demonstrates that not everyone has eagerly jumped on the responsive design bandwagon.

Food for thought.

photo by Jason Weaver

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

As designers and developers working on either traditional websites, web apps or mobile apps, we can have a tendency to become too narrowly focused on features. We create lists of functionality (either on our own or together with our clients), and determine that our product needs to be able to do this thing or perform that action. As an example, over the course of the past few days, I’ve been neck deep in concepts of functionality, as I’ve been working on a number of flow charts that map out the proposed functionality for a new site that I am working on.

From such a perspective, it’s all too easy to set about implementing the listed functionality and, once it’s all in place, believing that we have created a feature-rich and usable product.

However, the presence of all the desired functionality doesn’t mean that the product is necessarily usable in and of itself. Being able to do something is not always synonymous with being able to do it easily. Often, the opposite is true. Key or advanced features can be buried so far down in a chain of menus and navigation, options and preferences, that it becomes all but impossible to perform a simple, desired action without the assistance of an instruction booklet or extensive road map.

To put it in simple, though somewhat mathematical terms: ability does not equal usability.

Can You Change the Ringtone?

As a perfect example of this issue, I recently had a conversation with a colleague that happened turn to the topic of mobile phones. With more than a hint of frustration in her voice, she told me about the difficulties she was having with her phone when it came to changing her ringtone.

Yes, the ringtone.

It may seem like a relatively mundane and commonplace sort of functionality, but my colleague had no end of difficulty in figuring out to make the change. I even grabbed her phone and worked on it for a few minutes myself and simply couldn’t any logical (or even illogical) way of performing the desired action.

With a bit more time and experimentation, we did, eventually, manage to figure it out. However, we had go through a number of different menus that involved the device’s somewhat obscure profiling system. To be honest, it would probably still take me at least another five minutes to figure it out if I had to do it again.

Fortunately for me, I use an smart phone which, when compared against my colleague’s phone, has a much higher level of usability. I can just open up my settings, chose sounds and then change my ringtone. It’s quick, easy and highly intuitive.

In both cases, the phone in question has the ability to change ringtones, but with my colleague’s phone the feature is all but unusable because it is so difficult to find.

Potential Keys to Usability

With this discrepancy between ability and usability, then, how do we take a product or interface from a state of merely being able to do something to the point where it can be done in a usable and intuitive way. Well, there are probably dozens (if not hundreds) of different things that we could talk about, but since our phone example was primarily a menu issue, here are just a few navigation-based ideas.

Expectation-Based Paths

The biggest hurdle that both my colleague and I encountered in the mobile phone example was that we simply could not find our way down through the phone’s menu system to the required feature. We both tried all kinds of different paths. I know that I even tried the same ones several times.

Part of that repetition was clearly the result of thinking that I may have missed what I was looking for the first, second or even third time I looked. More than that, however, it was also bred from a natural human behaviour known as expectancy.

This wasn’t the first time that I’d changed (or, rather, tried to change) the ringtone on a mobile device. As such, I came to the task with a certain set of expectations as to how I would need to go about completing the task. Those expectations, however, were not only proven wrong, they were also frustrated by my inability to determine an alternate solution.

One common example that I like to use when talking about this kind of expectation (or, to put it another way, these kinds of design conventions) is the power button. Based on the near-universal symbol that has been adopted across a wide range of appliances and devices, I have developed an expectation through which the symbol should lead powering a device on or off. To a lesser, extent, I also expect that power buttons and/or switches would be marked with this symbol.

The near-universal symbol for power brings with it certain expectations when used on devices and machines

If either of these expectations were subverted in some way—perhaps by using a different symbol or using the symbol in another context—my expectations would be frustrated, and as a result I could be confused, irritated or even angered.

When designing a new system, always keep expectation in mind. If you’re at all familiar with your platform (web, mobile, desktop etc), you should have a basic set of expectations yourself, which can form the foundation. Beyond that, though, do your research. Examine how others have solved a given problem and take note of trends and patterns that you see.

It’s not about stealing or ripping off, though. The chances are good that these patterns have either emerged in direct response to existing sets of expectations, or that their frequent repetition is ultimately setting the groundwork for a new set of expectations.

There’s nothing wrong with a little bit of innovation in terms of functionality and navigation, but there does come a certain point when a user will want to rely on their own experience and expectations to guide them.

Multiple Paths

Traditional menu architecture tends to be very singular and hierarchical. Just think about a common drop down menu, either in a website or an application. Generally speaking, you will have your main menu items, beneath which there will be a number of sub menu items, many of which will trigger different actions or options. Some of these items may even have sub menus of their own, allowing for extensive multi-dimensional navigations.

This works well (up to a point—dozens of nested sub menus can become burdensome), but there is really nothing out there to state that the hierarchical pattern is the alpha and omega of navigation. This is especially true on the web. Based on the very nature of the hypertext, internal links provide users with the ability to move from one page to another, based on how they are responding to content, rather than how that content is arranged.

Wikipedia is great example of a site that uses the power of internal links as part of its core navigation technique

Remember, that they key to any information-based site (or application) is to get users to what they are looking for as quickly and painlessly as possible. From a usability standpoint, multiple, well-considered and well-managed access paths provide users with a variety of different ways to arrive at the same point, thereby increasing the probability that they will, in fact, get there. Wikipedia (and other wikis) are a great example of this. In fact, with the possible exception of search, the interlinking of articles is likely the most important form of navigation on their site.

Of course, as with nearly anything, we still need to work within reason. Having too many paths can be paralyzing, confusing or dizzying—possibly even all of the above—and lead users along a continuous cycle of link-clicking. Focus on logical navigation paths that will make sense to different types of users, not just on creating as many different paths as possible.

After all, it’s called the web, not the maze.

Contextual Help

Another technique that can be very helpful, especially in large and more complex sites or applications, is the use of contextual help—that is to say helpful cues, hints or suggestions that are actually provided based on a user’s actions or their current context.

For instance, when I was developing Survd, I knew that there would be some elements of the interface that new users might not grasp immediately. With this mind, I elected to add simple, contextual help icons (rendered as a familiar question mark) beside some of these items. When the user hovers over these icons, a simple tooltip appears explaining what the interface item is and why it’s important.

A simple little help icon provides contextual help in the Survd interface

I’ve found that it’s a simple, noninvasive way to increase overall usability (I’ve even released a super simple little jQuery script that can allow you to do the same thing in your site or web app). Plus, for more advanced users, I also added in an option to turn the contextual help off. This way, users who are more familiar with the interface and don’t need the help can actually remove the icons entirely.

Another form of contextual help might involve tracking the user’s behaviours, either within a single session or across multiple sessions. Then, based on those behaviours, you can provide additional cues or shortcuts that will allow them to accomplish what they’re trying to do more quickly and efficiently.

Google’s Chrome browser does this really nicely by providing a default homepage that lists the eight sites that you have visited the most recently. It’s a nifty little feature that actually adapts to your browsing habits, and which could be migrated to a number of different types of applications.

Conclusion

There are, of course, many other things that we could talk about when it comes to how to improve usability. To come back to the point at hand, however, the important thing to remember is that just because you can do something doesn’t mean that a product has good usability. Instead, usability is measured (at least from my perspective) by the relative ease with which the feature is accessed or the function is executed.

As designers, I believe that a key component of our job should be facilitate that ease as much as possible.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Over the past couple of days, I have been working on an initial concept/prototype for a new, interesting website. As I normally like to do whenever I am tackling a new project, I started by opening up a notebook and making a few really simple layout sketches for how I initially thought the page should be laid out (at this stage, I am just working the layout for a single type of page, with others following later). After discussing these initial concepts with members of the team I am working with, I very logically moved on to the creating more fully realized wireframes. For me, this meant printing of some grids and using a pen to draw and label content boxes.

The process, however, started me thinking about wireframes, their importance and the role(s) that they play in the design and development process. More specifically, it got me thinking about how wireframing— even in the rudimentary pencil on a paper grid method that I use—may be even more important and useful than it may initially appear, or than we like to give it credit for.

Any form of design—but especially web design (or anything else that actually requires a tangible user interface)—is about more than just what the product looks like. It also needs to consider its audience, its purpose and its media. On the web and in application development, this means questions of usability and user experience, interaction and information architecture, all of which are at least as important—and likely more so—than the what something looks like.

Yet, in the same way that “design” has a tendency to be understood merely as the creation of a unique (and often disconnected) visual aesthetic, so to can wireframing have a tendency to be relegated solely to the realm of layout, when it is, in fact a tool with a much broader scope.

It’s All About Structure

Often, many good designers will approach the question of layout from the perspective of arranging the elements on a page in such a way as to create something that is aesthetically pleasing to look at. Conversely, others will approach the layout as a matter of arranging elements in a logical, predictable and consistent fashion, which leads to improved usability and a better user experience.

Great designers do both, and I wouldn’t be at all surprise to learn that 9 times out of 10, this is generally reflected in their wireframing.

Earlier this year Nick Haas authored an excellent post on why wireframing is important and should not be glossed over in an effort to jump straight into the “real” design (and I use that term somewhat ironically) that determines a site’s appearance. In this article, Haas rightly points out that wireframing:

forces everyone to look objectively at a web site’s ease of use, conversion paths, naming of links, navigation placement and feature placement. Wireframes can point out flaws in your site architecture or how a specific feature may work.

From this perspective, wireframing is as much about the underlying structure of a site as it is about the visual dressing that we drape over that structure. It’s about planning the skeleton or framework on which the site will ultimately be built. And, while this skeleton will be reflected in a visual manner, with a number of sketched or grey boxes arranged in a particular fashion, that does not mean that the wireframes themselves are at all limited to the visual aspect of the site.

When done properly, those boxes tell us more than what kind of grid to use or how many CSS floats will be required. Through their positioning and interaction (and, ideally, accompanying notes), they bring a site’s underlying structure to the forefront. If that structure is solid and logical, then it will be easily be able to accept the aesthetic trappings that will eventually formulate its final apperance.

On the other side of the coin, if there are issues or flaws in that structure, those problems can be readily addressed (and hopefully fixed) at this early stage of the process. This certainly beats having nearly completed the entire design only to discover some fundamental structural flaw that forces you to tear everything apart, fix the problem and then try to put it all back together again.

Wireframing can help you catch these issues early, saving time and precious budget dollars.

Wireframing With HTML

There has been a lot of discussion at different points about the merits of designing in the browser, as opposed to creating flat mockups in an application like Photoshop. There are strong opinions on both sides of the fence. My own view is somewhat less concrete, in that I feel that approaching any new web design project is really a matter of context, and the tools and techniques that I chose to employ will depend on what I am looking to accomplish.

That being said, however, while I may not always start in the browser (or even get to it early), I do feel that it is vitaly important to always be designing with the browser in mind. In other words, to consciously design within the constraints and limitations of HTML and CSS. With new and emerging technologies, these constraints are certainly shrinking, but there remain certain things that we still can’t do (or things that we shouldn’t do).

Moreover, it is important to always keep in mind that when we are designing for the web in the traditional sense (apps, I believe, may be somewhat different in this regard), what we are actually doing is creating the visual skin that will be placed over our standard HTML.

We’ve already touched on how wireframing is very much a matter of creating the initial skeleton or structure for a site. In practice, the HTML that we craft becomes the tangible result of that structure. It the context of the document, it brings semantics and meaning to the content, while simultaneously providing the key hooks that will be required to wrap that same content in the visual layout that we have created.

For this reason, I believe that wireframing and HTML are (or at least should be) fundamentally connected, to the point where I am increasingly finding myself actually writing out simple HTML structures at the same time that I am creating my wireframes. In my experience this has a number of key benefits:

1. It helps remind me that wireframing is about more than just the visual aesthetic of the site.
2. It helps keep my mind “in the browser” so to speak.
3. It helps me think of structure in a broader context. By constantly working out how the layout would need to be represented in HTML, I am better able to consider the placement of my wireframed boxes and make important decisions about the relationships between those boxes, both visually and structurally.

For me, these are all key components to my design and development process—components which help strengthen the quality of my work and ensure that the structure and layout are more than just a cool visual treatment. As such, I plan to continue to pair my traditional, rough pencil and paper wireframing with equally rough HTML structures, especially as I dive deeper and deeper into world of responsive design.

Of course, while the concept of wireframing generally serves the same basic purpose from designer to designer (or team to team), the techniques that are used in the process can be very different. As already noted, I like to work more traditionally with pencil and paper. Some designs will use simple grey boxes in Photoshop or Fireworks, while others will actually use applications and other tools that are specifically geared towards wireframing. Regardless of the technique that is used, I believe that the important relationship between these wireframes and HTML still exists and needs to be considered.

The only “exception” would be for those designers who wireframe by creating basic, lightly styled HTML documents right out of the gate. Of course, in these cases the exception is not that HTML should not be considered, but rather that it is no longer a matter of considering the relationship between two seemingly autonomous elements. Instead, the HTML is the wireframe, which only serves to further underscore the point that I’ve been driving at through the entire article: that a thorough consideration of HTML should be an integral part of any wireframing process.

How that manifests itself is up to you.

For those readers who may not be all that familiar with wireframing, feel free to check out Grace Smith’s “Get Wireframing: The All-In-One Guide” for a full complement of resource materials. There are all kinds of wicked resources to help get you started, or to help you dig deeper into the concept.

article photo my sonali sridhar

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

One of the cool new properties that CSS3 brings to typography on websites is the ability to quickly and easily create columns with the column-count property. For browsers that support this property, and the related column-gap, the columns will be generated automatically, without having to split the content and create columns with extra markup.

It’s an incredibly useful property, and I used and talked about it my “Create Beautiful CSS3 Typography” post from last May. Check out that post to see it in action.

As useful as it is, however, there are definitely some usability and user experience considerations that need to be taken into account when using this property. More specifically, we need to remember the medium that we are working with and continually remind ourselves that this is the web, not a piece of printed matter.

The Influence of Print

That being said, let’s start with question of print itself. When we were first introduced to the web back in the early to mid 90′s, I think that, for the most part, it was fairly clearly understood that the web and print were two distinct entities that were not at all analogous. Print was this wonderfully free medium where designers could run wild and do all sorts of interesting things with type, colour, alignment, rotation ans so forth (which is not to say that all printed pieces should do all of these things).

The infant web, on the other hand, was this network of publicly accessible, digital repositories of information. Sure, we called it the “information superhighway” because it was great for being able to share and find information on different subjects, but let’s be honest, compared to the world of print, the stuff we were seeing on the web really wasn’t all that pretty.

But then something started to change. I’ll admit that I don’t have any official documentation or source material to point to, but from my own observations and experience, this is what I generally believe was happening: businesses, big and small started jumping onto the web bandwagon—to the point where it pretty much became a necessity for almost all businesses to have their own online presence. As corporate websites were being deployed with more and more frequency, an increasing amount of attention was paid to these sites. Questions of identity and branding started to become important, and more and more designers started to become involved.

Many of these designers would have been traditional graphic designers—people who had previously developed their skills and earned their experience in the world of print. As such, many of them would have come to the web with a number of expectations and misconceptions, many of which were likely dashed like waves against sharp, pointy rocks.

Beautifully designed and carefully crafted, a site like Alexander Charchar's Reinart suggests a strong print influence

Over time, though, we have seen more and more advancements in terms of technology that actually brings a wider range of options and possibilities for design on the web. We spend a lot more time talking about grids, typography and other elements that have their roots in the world of print design.

This is good thing, but it can also be a dangerous trend if it starts to blur the boundaries between a website and a printed page.

Columns on the Printed Page

Over the course of my design career, I have had occasion to work in both the web and in print. Some of the print projects that I have been given were magazine-type booklets, and I’ve found that there a number of benefits offered by working with columns. One of them is that they just look nice on the page. Just looking good not a great reason to use something, but it always helps. In some cases, depending on the text I was working with, I’ve also found that using two columns can actually fit a bit more content onto a page.

But, by far the biggest advantage of using columns is the benefits they bring to readability. The measure (or length) of a line of text has a direct impact on readability. Beyond a certain point, the longer the line, the more difficult it becomes to read with a high level of retention and comprehension. In a typical sized book, this is not generally an issue, but when you start to get into larger format publications like magazines, the measure of a single column will generally be undesirably high.

This is where the use of columns can be hugely beneficial. By using two, three and sometimes even four columns (in newspapers, for instance), designers can limit the measure of their text, helping to improve the overall readability of their designs and layouts.

Columns have been around for a long time. Here's an old german leaflet as an example. Photo by kladcat on Flickr

The Usability Issue

Armed with both this knowledge and the continuing influence of print on web design, the introduction of CSS columns may seem like a great tool for us to use as a means of improving readability on our sites. And it certainly is.

It just needs to be used thoughtfully, and with the full spectrum of usability and the user experience in mind. Using CSS columns to improve readability is not necessarily a good thing if it comes at the expense of some other aspect of usability.

And there is certainly potential for this to happen.

The accustomed behaviour for reading longer editorial like articles, stories and blog posts online is to start at the top and then scroll down as far as it takes to reach the bottom of the page. This works because it is a logical, gradual process that the user can work through at their own pace. But what happens if we start introducing columns into the equation without careful consideration?

The reading pattern is broken.

If the content spills beyond the immediate viewport, it means that I need to scroll down the first column, then scroll back up to the beginning of the next column, only to resume the downward movement again. I don’t know about you, but on a long, in-depth article, I would find this kind of thing incredibly frustrating, which is certainly one of the hallmarks of a poor user experience.

This contrasts against the use of columns on a printed page, where the entire page is visible at any given time. We simply move our eyes across the page, again in a predetermined and accepted reading pattern. It’s intuitive because it matches how we have been taught to read.

So Where Do We Use CSS Columns?

Now, I am by no means suggesting that column-count is not a useful property, because it is. As I’ve already mentioned, it just needs to be used thoughtfully and with careful consideration. Setting two columns on a long article doesn’t work because it disrupts an accepted reading pattern that users are used to.

One place that I love the idea of columns, however is with lists. Let’s suppose I wanted to present a list of characters from the X-Men universe.

• Cyclops
• Jean Grey
• Beast
• Iceman
• Angel
• Professor X
• Magneto
• Wolverine
• Rogue
• Gambit
• Sabertooth
• Mystique
• Cable
• Nightcrawler
• Shadowcat
• Banshee
• Colossus

I could go on and on, but you get the idea. Now this list works well enough, but there’s a lot of dead space to the right of it, especially since the list items are relatively short. I’m all for the use of white space, but in this particular case, it might be useful to be able to have this list broken across three columns.

Traditionally, to do this I would have to manually select where I wanted each column to end and then intervene by adding in specific markup, such as a <div> or <span>. It would likely also be possible to use JavaScript to compute this dynamically, but it would still require extra HTML to be added.

With CSS columns though, I can do it quickly and easily. In this case, I’ve created a simple class called threeCol, which basically sets the value of the column-count (and its related, browser-prefixed cousins) to 3, and the column-gap to 20px. Suddenly (if you have a supporting browser) we have a list that looks like this:

• Cyclops
• Jean Grey
• Beast
• Iceman
• Angel
• Professor X
• Magneto
• Wolverine
• Rogue
• Gambit
• Sabertooth
• Mystique
• Cable
• Nightcrawler
• Shadowcat
• Banshee
• Colossus

This works nicely because it brings all of the list items into closer proximity to each other, without affecting usability by disrupting any reading patterns. It’s also just one example of how this new property can be effectively leveraged! There are many others, but the thing to keep in mind with all of them is that most of its effective uses will be in small, snippets of content rather than longer sections.

Conclusion

CSS3 is a big deal, and there are dozens of new articles and tutorials being written on the subject, seemingly on a daily basis. Some of it is still experimental and some of it can be used for some pretty awesome progressive enhancement. Like any new technology or technique that gets introduced into the web design mix however, it needs to be carefully considered and weighed.

I hope this article has not only illustrated some of the issues specific to CSS columns, but that it has also demonstrated the importance of critical thinking when it comes to usability and the user experience!

What do you think? Are you using CSS columns in your designs today? How do you implement them and what kind of restrictions to place on their use?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd