The idea is fairly straightforward: With all the new internet devices coming out, people are accessing websites in many different ways and viewing them on many different screen sizes. Monitors are getting bigger, smartphones are (mostly) getting smaller, and tablets are, well, somewhere in the middle. So why develop sites at just one size? If people are viewing sites at different times in different ways, shouldn’t the design—and in some cases the content—change as well?

The idea is a great one. The executions, however, are easy to screw up. Yesterday on Twitter I briefly discussed the blog post More Responsive Design, Please and some of the problems I see with many mobile sites. With Responsive Web Design starting to gain momentum, I fear we will start to see many designers getting caught up in the idea and trying to implement responsive designs just for the sake of it, throwing away many principles that still hold true.

This post is not an attack on Responsive Web Design. I think the idea is great. This post, rather, is to make sure designers are thinking things through before acting. A word of caution, and a reminder of some of the design and development principles that should still hold true regardless of how “responsive” a site is.

Grids are good

While technology and devices will always change, good design principles will not. Proper grid alignment will always be key, and the Golden Ratio will always be golden. Similarly, the ideal number of characters-per-line of text is still 66.

For these reasons, fluid layouts, while they can be great, can also be very dangerous. Extra attention needs to be placed on these kinds of details for such layouts, otherwise good design is simply being sacrificed in the name of a web design movement. Adapt.js looks to be another interesting idea for using multiple grid layouts.

Mobile users don’t always want to be mobile users

This was the main subject of my tweet yesterday. A growing trend is to create mobile versions of websites, often at 320 pixels. Back before smartphones ran complete browsers, mobile versions were actually necessary. Today, however, they’re generally not. They can still be a great idea, but if designers aren’t careful, they can often just make the situation worse.

To create a solid mobile site, a designer needs to nail exactly why users are accessing the site on a mobile device. And assumptions on this issue are not always correct. For me personally, when I access a site, generally the first thing I do is search for the “full site” link. This is especially true for Facebook’s mobile site. Why? Because I already have their iPhone app that essentially has the same features as the mobile site. If I’m accessing Facebook via Mobile Safari, it’s because I’m looking for something only accessible via the full site.

If I’m accessing a site via my iPhone that I also regularly visit in a full browser, chances are I know what I want and where it is. Changing anything, regardless of intent, does not help. I already know where everything is—don’t make me find it again.

Jason Rhodes puts it best:

We can’t reliably determine a user’s intention based on the capability information we collect from her device or internet connection.

Unless you are sure beyond a reasonable doubt that you know exactly what your mobile users want, there needs to be a better way of determining which content to show than simply checking for the type of device.

Things change

Remember back when people used to do this awful thing called browser detection? It sounded like a good idea at the time, then we realized it only complicates things.

Developing sites based on set resolutions may work for the time being, but it is important to remember that screens and resolutions, even on mobile devices, will change.

Analytics are your friend

There are a lot of great analytics options out there, and they’re not only useful for determining ROI.

Want to know for sure exactly what mobile users do on your site? You can find out. If more designers looked at actual data before making design decisions, we’d have a lot more excellent mobile sites out there (and a few less bad ones).

Use your brain

In summary, we just need to remember to use our brains. It’s the best design tool we have.

And yes, I am still alive. I realize this is the first time I’ve posted here in almost 2 years, but things have been a little busy. I hope to get back into the habit of posting more regularly, and I can always be caught over on Twitter.

Where have I been?

Since quitting my job back in May, I’ve been working alongside Bryce Clemmer and Matt Polzin to bring DuroCast to the web.

I have been working with this team as Co-founder and Creative Director, and it’s been a blast. This is definitely one of the most involved interfaces I have worked on, and it’s been an interesting experience getting a startup company up and running.

What now?

Six months later, we’ve sent out the first round of beta invites and couldn’t be more excited.

It’s come a long way and has an even longer way to go. And because I couldn’t help myself, here’s a little sneak-peak of the homepage (just don’t tell on me ):

Expect to hear a lot more from us as we reshape radio on the web. It’s going to be a fun ride, and if you haven’t yet, definitely sign up for the beta.

It’s fairly easy to figure out. Can it be turned into definitive list of something? Could it be a quick how-to, or make people feel more efficient? Could it be easily scanned, something that would be bookmarked?

If it can fit into one of these, chances are the article has a good chance of making the social media rounds. But should an article’s viral potential have anything to do whether its worth writing (or reading)? Has good writing gone missing due to online magazines in need of social media traffic and ad revenue?

I think Smashing Magazine plays the social media game best — 30 Ways to Do X, What You Need to Know About Y, etc. Net tuts is another popular one that comes to mind, and there’s many more out there. Don’t believe me? Just take a look at the Delicious popular list. Enough said.

Now, don’t get me wrong: These are great publications, and they know how to write for the web. But when some of the most powerful publications all rely on the same proven formula that’s almost guarantied to land articles on Digg, Delicious, and get retweeted several hundred times, are we missing out on what could possibly be some truly great content?

I’ll confess that I used the same formula with my Howto: 3 Easy Ways To Speed Up CSS Development While Staying Organized article, and it definitely made its way around the social media sphere (simultaneously landing on the Digg homepage and the Delicious popular page). It was fun to write (and I’m not going to pretend the traffic wasn’t nice as well), but as soon as we have a proven formula for viral content, doesn’t that defeat the whole point of social media itself?

Perhaps I’m naive, but wasn’t the point of social media to share and reward good content, not to encourage top 10 lists?

But some good news: Quite a bit of this CSS3 awesomeness can be used right now to spice up your designs. Some (most) of it will not render in all browsers equally (generally those of the IE variety), but websites don’t need to look the same in every browser–nor should they. Just because IE6 users can’t see some fancy effect doesn’t mean everybody shouldn’t. Similar to how those watching TV on a standard television will not be able to see HD, users on older browsers need not get the same experience as those on newer browsers as long as they see nothing wrong with the site.

But enough ranting and onto the good part. CSS3 properties you can use now and how to use them:

1. Text-shadow

The text-shadow property is probably one of the most commonly used aspects of CSS3, likely because of it’s extremely easy setup (it’s almost too easy…).

For a text-shadow, the property is used as follows:

text-shadow: 2px 2px 5px #000;

The first and second values represent the shadow offset, the third the blur radius, and the last value the color of the shadow.

For tips on effectively using shadows in your designs, check out one of my previous articles, The Shadow World: CSS3 Text-Shadow and Reality.

Browser support for text-shadow: Safari 3.1+, FireFox 3.5, Chrome 2.0+, Opera 9.6+

2. Box-shadow

The box-shadow property is used in a way very similar to text-shadow, but it adds shadows to the elements as a whole rather than to the text inside them:

box-shadow: 5px 5px 10px 10px #000;

The first two values are the offset of the shadow, the third the blur radius, and the fourth value the spread radius. The last value is, of course, the shadow color.

Browser support for box-shadow: Safari 3.1+, FireFox 3.5, Chrome 1.0+

3. Box-sizing

The box-sizing property is one of the most under-appreciated yet widely-supported properties in the CSS3 spec.

The box-sizing property is quite simple, and it accepts three possible values: content-box, border-box, or inherit. This declares how an element’s size is to be rendered:

box-sizing: content-box | border-box | inherit;

In properly-behaving browsers, all elements are displayed as content-box by default — padding and borders are rendered outside the specified width and height, so an element with a width of 20px with a 1px border and 5px of padding will actually be rendered as 32px wide (20 + 1 + 1 + 5 + 5).

However, by declaring the box-sizing property to border-box, the padding and borders are rendered inside the element. So, our example from earlier would be 20px wide total, with 10px of that element taken up by borders and another 2px taken by padding. This can be extremely useful when using percentage-based widths in your layouts.

Browser support for box-sizing: IE8+, Safari 3.1+, FireFox 2.0+, Chrome 1.0+, Opera 9.6+

4. Columns

The columns property is also fairly easy to setup and makes for great magazine-style layouts. Both Mozilla and Webkit browsers require prefixes before the property, so setting an element to render its content in multiple columns works as follows:

-moz-column-count: 2; /* For FireFox */
-webkit-column-count: 2; /* For Safari/Chrome */
column-count: 2; /* For when the standard gets fully supported */

-moz-column-width: 250px; /* For FireFox */
-webkit-column-width: 250px; /* For Safari/Chrome */
column-width: 250px; /* For when the standard gets fully supported */

This tells the element that you want the content displayed in 2 columns, each 250px wide. Either of these values can also be set to auto, which allows it to be determined based on what best fits with the other value.

But what if you want custom gutter sizes and dividers? No problem, as we have column-gap and column-rule coming to the rescue:

column-gap: 25px;
column-rule: 1px solid #000;

-moz-column-gap: 25px;
-moz-column-rule: 1px solid #000;

-webkit-column-gap: 25px;
-webkit-column-rule: 1px solid #000;

This will place a 25px gap between our columns with a 1px solid black line running down the middle of the gap. There’s even more you can do with CSS3 columns, and I’d recommend that those interested checking out this article for more goodness.

Browser support for columns: Safari 3.1+, FireFox 3.5, Chrome 1.0+

5. Border-radius (rounded corners)

Because everybody likes rounded corners, the CSS3 spec contains the popular border-radius. Mozilla and Webkit browsers require their standard prefixes, so to add rounded corners with a 10px radius to an element, use the following:

-moz-border-radius: 10px; /* For FireFox */
-webkit-border-radius: 10px; /* For Safari/Chrome */
border-radius: 10px; /* For when the standard gets fully supported */

For slightly more advanced usage (using on only select corners), check out this excellent article.

Browser support for border-radius: Safari 3.1+, FireFox 2.0 (non-antialiased), FireFox 3.0+, Chrome 1.0+ (non-antialiased)

6. Border-image

The border-image property is not used nearly as much as border-radius (probably because the syntax is somewhat hard to understand). However, it can be used for some awesome effects and John Resig provides a fairly good explanation of how it can be used through the following example:

-webkit-border-image: url(whiteButton.png) 0 12 0 12 stretch stretch;
-moz-border-image: url(whiteButton.png) 0 12 0 12 stretch stretch;

Basically, the property declares an image to be used before telling the browser how to clip and stretch different sections of it. Check out his full article for more examples and details.

Browser support for border-image: Safari 3.1+, FireFox 3.5, Chrome 1.0+

7. @font-face (web font embedding)

While not technically a property, the CSS3 @font-face declaration has been receiving quite the attention as of late. Håkon Wium Lie, the original proposer of CSS, wrote a must-read article for A List Apart all about @font-face. Essentially, this allows developers to embed fonts in their pages that can be called by the simple font-family property.

To embed a font, simply add an @font-face declaration as follows:

@font-face {
      font-family: "My Awesome Font";
      src: url(MyAwesomeFont.otf) format("opentype");
}

This tells the browser that whenever the font “My Awesome Font” is used, pull it from “MyAwesomeFont.otf.” Simple and brilliant, really. So then to use our font, we just declare like we would any other font:

h1 { font-family: "My Awesome Font", sans-serif; }

There are a couple things to note, however. Firstly, and most importantly, make sure the font you are using has a license that allows font embedding. There’s a fairly decent list of legal fonts over here, and Typekit will be another solution that looks promising.

The other thing to note: Fallbacks. Cufón and typeface.js are both good options for when @font-face isn’t supported. Kilian Valkhof has a great article on combining Cufón and @font-face.

Browser support for @font-face: Safari 3.2+, FireFox 3.5, Chrome 2.0+, IE4+ (sort of)

8. RGBA color

While actually a value and not a property, rgba() is also worth mentioning (and using!). While generally colors have been declared using hex values (e.g., #000000 for black) or RGB values (rgb(0,0,0) for black), CSS3 has now added a new option: RGBA.

This works identically to RGB color with the addition of a fourth parameter declaring opacity. So, if you want to create a black background with 50% opacity, simply do the following:

background: rgba(0, 0, 0, 0.5)

While this (of course) will not work in IE, there’s a great (though slightly complicated) article on creating bulletproof, cross-browser RGBA backgrounds using some filters and PNGs.

Browser support for rgba() (without filters): Safari 3.1+, FireFox 2.0+, Chrome 1.0+

9. Transitions

Ever wished you could do transition effects with CSS? Well, now you can using the CSS3 transition property. Webkit browsers (mainly Safari and Chrome) currently support it and do so with the -webkit- prefix:

#element {
      opacity: .7;
      -webkit-transition: opacity 1s linear;
}
#element:hover {
      opacity: 1;
}

The transition property is actually shorthand for transition-property, transition-duration, and transition-timing-function. Our example code above thus tells the browser that when #element’s opacity changes, do a 1-second linear transition.

These transitions can be applied to any property (and even multiple ones at the same time!), such as padding and background, for instance:

#element {
      background: #000;
      padding: 5px;
      -webkit-transition: background 1s linear;
      -webkit-transition: padding 1s linear;
}
#element:hover {
      background: #FFF;
      padding: 20px;
}

For more advanced usage, check out the Webkit blog.

Go forth and use the future!

CSS3 brings some awesome stuff to the table, and now is the time to start using it. As the web development community gets more and more excited about CSS3, Mozilla and Webkit browsers are quickly adding more and more support for new properties, declarations, and selectors. So take advantage of it!

I would also like to give a special thanks to Alexis Deveria’s awesome When Can I use… table for providing browser compatibly information.

Thanks to clients who delay coming up with content and that wonderful Latin we all know so well, design and content is often separated. But this is a major disadvantage.

Graphic designers don’t design a product ad without good copyrighting, so why do web designers think they can design websites without good copywriting? While there may be some instances where writing the content and designing the interface cannot occur simultaneously, just as much emphasis should still be placed on making content accessible to an online audience.

So how do you do this?

Rule #1: Assume I’m in a hurry.

Always. Because as your visitor, whether or not I should be in a hurry, I am. If your site isn’t going to help me, then there’s approximately 1,458,987 more sites out there that might. So why would I spend more time on yours if it might not help?

This means:

Use headings. Lots of them, and make them good. I might not read your paragraphs, but I will probably at least glance at a heading or two to see what’s up. If your heading’s are good enough, I might even read your first sentence.

Write interesting topic sentences. Congratulations, your heading passed the test. The next thing I will likely check out is your topic sentences. So these sentences must be clear, interesting, and give a good idea of what’s in those paragraphs if you want me to read them.

Keep paragraphs short. While you might be able to get away with a page-long paragraph if you’re Tolkien, that doesn’t work on the internet. Us web-surfers have super short attention spans due to the massive amount of options out there, so don’t waste our time. Keep paragraphs to one solid idea and no longer than a few sentences.

Pick a tone, and stick with it. Because not only does your content need to be easily consumed, it must also be interesting. The photo-sharing site Flickr does an excellent job at this with their welcome messages which cycle through at each refresh:

Rule #2: Assume I’m selfish.

I’m spending my time looking at your site, so make it worthwhile. I want to know what’s in it for me, so take every opportunity to let me know. I don’t want to hear how great your product is, I want to know what I can get out of it. I don’t want to hear how cool you are, I want to hear about me.

This means:

Talk about me. Not “We provide the best pogo sticks in the country,” but, “Experience the best pogo sticks in the country.” I don’t care about what you provide, I just care about what I can get. 

Be personal. If you know my name (which you should if I signed up for something), use it. Emotion is often lost during online communication, so add it back in with expressive language. Don’t preach at me, communicate with me.

Basically: Pretend you’re me.

In short, don’t believe that I’m going to think like you–you already think your product is awesome, but you’re going to have to convince me. Pretend you know nothing about yourself. Pretend you don’t care. Pretend you’re just a visitor.

That is who you’re trying to reach, isn’t it?

MMS? Awesome. Oh, wait. No AT&T yet.

Tethering? Awesome. Oh, wait. Never mind.

$199? Oh, wait:

Requires new two-year AT&T wireless service contract, sold separately to qualified customers; credit check required; must be 18 or older. For non-qualified customers, including existing AT&T customers who want to upgrade from another phone or replace an iPhone 3G, the price with a new two-year agreement is $499 (8GB), $599 (16GB), or $699 (32GB).

- via first footnote at Compare iPhones.

Then I kept scrolling, and it occurred to me. That’s a lot of legal copy:

I decided now is the time to find out. At the end of last month I clocked out of the day job for the last time, and while it won’t be completely freelance (more on that later), it should be a ton of fun.

Freelance

I plan on doing a lot more freelance work, and next month I’ll be putting a lot of focus on WordPress theming. I may release a few themes and will definitely be available custom theme work (so if you have a project in mind, by all means, drop me a line).

This blog and WorthWorkingFor should also be getting a lot more attention, and perhaps I’ll release one or two of the side projects I’ve had sitting around for a while.

DuroCast

As excited as I am to get more into the freelance game, what really made me take the jump is DuroCast. Bryce Clemmer and Matt Polzin have taken me on-board as a fellow co-founder for an awesome new startup that promises to bring some innovative stuff to online radio.

As we’re still in the product development stage I can’t say too much, but you can follow @DuroCast on Twitter if you want to keep up-to-date with what we’ve got going. Should be a fun ride.

Now.

Certainly not everybody will see it, but better to have some people experience it than nobody at all. That is, if you think before you type and don’t abuse it. When used correctly, text-shadows can be a great addition to a design. If you aren’t careful, though, it’s quite possible for them to end up as bad as the next blink tag.

Shadows on the web should imitate shadows in real life: They shouldn’t be everywhere, and they should make sense. Take a look at a photograph off the Flickr Explore page of something in real life (in case it’s been a while):

Now compare that to some of the shadows on this tutorial. Notice a difference? Both use shadows, but one uses them naturally while the other uses them extravagantly. Shadows are not special effects, they are natural effects that bring out the details of a design. The point of a text-shadow is not to show off the shadow, but to show off the text.

Good design disappears. Generally speaking, visitors should not be physically aware of the text-shadows, they should simply feel them. You don’t always notice shadows in the real world because they just become a part of the experience. They make things stand out, the create depth and perspective, and make things seem real–all without you even noticing.

So the next time you’re about to whip out your text-shadow, don’t look to Photoshop for inspiration. Look out your window.

I’m a big fan of brainstorming, so naturally I got to thinking. I wrote down what I wanted to communicate, what elements and pages I needed to have, etc.

Next came the grid. I decided to give 960.gs a try, first starting off with the 12-column grid. After a couple hours of playing around, I ended up switching over to the 16-column and came up with this first design:

After showing it to a few people and taking it all in, the generally consensus I heard from people was that they all hated the red. Eventually, I decided that I hated it as well. Enter design #2:

I liked the darker color in the header, but it just didn’t seem to fit with the rest of the design. So, I changed the rest of the design:

I had gotten rid of all the serif fonts and dulled out the top of the header. Everything flowed much more smoothly, and it was at this point that I started coding it out.

While hacking out the code, I ended up making quite a few changes to the design. I realized it was still just way too busy. So, I cleaned up the header, moved the search bar, and changed up a few of the colors and padding.

Eventually, it came to what I’ve got here now.

I’ll be providing many more posts in the near future with all sorts of things learned from this redesign (subscribe to the feed if you haven’t already to keep up with those), but I just wanted to do a quick overview post to quickly point out a few things.

The design

This is a fairly big difference from the past couple of designs I’ve had on here, but I think it’s a good change. I wanted to draw more attention to what I do (i.e., I would like to get hired more), and I also wanted to add some more interactivity (more on that later).

The design process for this design was quite a long one and involved several renditions, so I’ll definitely be posting more on that soon.

The code

This is what most of you will probably be interested in. As I’ll be going more in-depth in future posts, I just want to do a quick snapshot of some of the new stuff:

• I’ve used Nathan Smith’s excellent 960.gs framework. I’ll definitely be using this in my future projects as well.
• I’ve switched to jQuery as a JavaScript framework, and I love it. Check out the Explore tab up top, the AJAX lifestream in the sidebar, and my contact form for a few examples of some of the JavaScript work I’ve done on here.
• In a similar note, I’ve re-built Better-Than-Live AJAX Search as a jQuery plugin. To test it out, open up the Explore tab and do a search (and yes, this will be released in the near future).

There’s still a few kinks to be worked out, but overall it should be all up-and-running. And as always, I’d love to hear everybody’s thoughts, opinions, critiques, comments or whatever else you’d like to call them.