Web Design for Developers

One of the first things I assert in the book is that design is so much more than how your site looks. If you’ve been doing programming for even a few months, you’ll understand that design is about both form and function. You design things to solve problems. If a site looks good but has weak content or broken functionality, it’s a failed design.

Unfortunately, many technical people tend to completely miss the point. A pretty face is important, but I have seen applications with serious usability flaws praised for their excellent designs. I have seen applications win awards when the actual promised functionality doesn’t even work.

Beauty is in the eye of the beholder, which is why saying something looks pretty doesn’t have much meaning. I personally don’t enjoy the way the 37Signals applications like Basecamp and Backpack look, but I recognize that they are extremely well-designed applications. And when I am actually using Highrise to get things done, I don’t notice the colors, fonts, or design elements because the interface and application work really well. It’s really important to remember that design is about the look and function.

Check out Myth #4: Design is about making a website look good (via UXMyths) for some interesting quotes about this issue.

Developers who don’t understand web development often tend to use way more markup than they need. Take a look at this article, which dissects an SMS message displayed within Google Voice. A single message uses the following:

• 369 lines
• 46 divs
• 7 tables
• 8 spans

In the book, I point out that more characters in your markup can cost you money, because your servers have to serve that data over your data lines and most ISPs (for web hosting) charge by the data you transfer. Even those “unlimited” hosting plans have a limit, if you read the fine print. Extra markup can be a problem for you, but now it could be affecting some of your users.

Mobile devices are kind of a big deal these days. iPads and Android phones are browsing web pages more and more, and each character you make a user download is more data they have to pay for. AT&T no longer offers an “unlimited” plan. In addition to the bandwidth, more tags and more rendering means more CPU crunching. That can mean decreased battery life over the course of a day.

The sad thing is that most of the markup in the SMS is unnecessary. Properly coded HTML5 semantic markup can eliminate the need for most of the extra elements there. Developers just need to learn it and understand how to style it with CSS.

Let’s just take one small part of the SMS message:

<tr>
<td class=”gc-message-bg-f”></td>
<td class=”gc-message-bg-tl”></td>
<td class=”gc-message-bg-t”></td>
<td class=”gc-message-bg-tr”></td>
</tr>

That’s a single table row, and the columns are empty! I don’t know what the reasoning for this is, but it’s a good example of bloat Let’s shorten this a little.

<tr class="gc-message-bg">
<td class=”f”></td>
<td class=”tl”></td>
<td class=”t”></td>
<td class=”tr”></td>
</tr>

You would then just use CSS child selectors to style things.

.gc-message-bg f{color: #f00;}
.gc-message-bg tr{color: #fff;}

If you had CSS3 support, you could just remove the classes from the table cells and use nth-child instead.

But beyond that, this is part of a bigger structure. You could decide that you simply have a container called “sms” and use the HTML hierarchy to style elements, eliminating the need for lots of classes. You can use the same selectors in Javascript too, so you don’t need tons of hooks like this.

As developers of web applications, it’s important to keep our users in mind, and even more important to understand the tools we’re using. Keep your markup as small as possible. Say less with more. Be stingy with your markup.

Usability pundits often talk about “graceful degradation” and “progressive enhancement” as if they are opposites. They argue that graceful degradation implies you’re leaving it until later. If there’s time, you’ll get around to providing an alternative method. They argue for “progressive enhancement” instead because this implies you’re building in accessibility from the beginning. While they’re correct that you should use the progressive enhancement approach, graceful degradation is a very important part of the user experience.

Progressive enhancement is professional. It’s what separates experienced, professional web developers from less experienced ones. A college student may build you a cheap web site, but many of them have no idea what a screen reader is or what it means to be colorblind.

Progressive enhancement is all about choosing the right colors from the start and being aware of how they will work in different contexts. It’s all about actually planning a screencast with a script so that you can easily provide a transcript to your deaf users. It’s about planning your writing so that you remove extra unnecessary words so that more people can comprehend and connect with your message, and it’s about designing systems that work without Javascript so they can be used more easily with screen readers and mobile devices without Javascript support. All of these are examples of graceful degradation brought about by progressive enhancement.

You should progressively enhance. Your applications should degrade gracefully.

A Way Back just posted a really great article on font stacks this morning and it’s worth your time to read. I talk about font stacks a bit in the book, and this article gives some good advice on some new combinations of fonts.

As you know from the book, constructing a good font stack lets you get around the limited number of “web-safe” fonts by providing sensible, similar fallbacks for your fonts.

I’ve selected 10 popular typefaces, serif and sans-serif, each from the survey. By considering the font-share % statistics in the following table, we can try some other typefaces, but with care.

I particularly enjoyed the “Facebook” font stack.

"Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Verdana, Tahoma, sans-serif;

The article is well-written and points out some interesting small details, including some statistics on the availability of fonts on various operating systems, which you can use to your advantage when creating your own stacks.

• Revised Font Stacks – A Way Back

Mike Riley reviewed the book over at Dr. Dobbs Code Talk. He had some very nice things to say, too.

I am unabashedly more comfortable with grokking loop, iterator and ORM than I am with terms like color fluting, page folds and RYB. However, it was with these and many other graphic arts terms that author Brian Hogan coaxed me to become more comfortable with effective use of color, image weight and content balance when constructing web pages. He also taught me some helpful designer tricks like the use of grids for graphic element (titles, descriptions, buttons, etc.) placement, anti-aliasing icons the right way, using the right measurements and font weights for the page presentation and the subtle use of photos to enhance the page’s intended message.

Of course he does take issue with the fact that I went with Adobe products in this book, which is something I plan to address in an upcoming post. The short answer is that while on you can do all of the things in this book with Inkscape and GIMP, the workflow is not nearly as smooth, especially if you’ve never done this stuff before, which is what I am assuming with this book.

It’s a good review, and I feel that Mr. Riley learned something from my book, and I’m very proud of that.

• Read the review

One thing that may surprise readers of the book is my choice to use HTML4 Strict for the markup in the book. That may seem strange given that the last decade has been devoted towards pushing “web standards with XHTML.” After all, experts like Jeffrey Zeldman can’t be wrong, can they?

Of course not. At least not then. Zeldman and others took a gamble on XHTML, picked it up and ran with it. Zeldman taught many of us through his articles and books that semantic well-formed markup is right and good. Unfortunately, some technical problems came up in the last few years that most web developers who took Zeldman’s advice haven’t really paid attention to until recently.

XHTML is fundamentally broken thanks in large part to Microsoft Internet Explorer. Allow me to explain.

XHTML documents, in order to be read by Internet Explorer, have to be served as text/html> which causes browsers to treat the page as HTML anyway. All those closing tags you added that you didn’t need to add get stripped out, and worse, self clsoing tags get removed.
The article “Beware of XHTML” shows some great examples of what can happen when you serve completely valid XHTML with the wrong content type. Here’s my favorite one:

Self-closing tags

You can visit the same page served with the correct content type of application/xml+html, unless you’re on Internet Explorer, which will try to download the file instead of displaying it!

Self-closing tags (served properly)

I’ve made the switch away from XHTML, and I urge you to do so as well. But don’t blindly follow anyone’s advice, experiment for yourself. One of the reasons XHTML has stuck around for so long is that developers, including myself, cargo-culted the advice and techniques of others without doing their own research. Stop that right now!

Besides, XHTML isn’t the future – HTML 5 is, and HTML 4.01 Strict documents have a better shot of forward compatibility. That sets you and me up quite nicely to embrace HTML 5 when it’s ready.

• Beware of XHTML

Typography is so important when it comes to communicating written work. Choosing the wrong typeface or not paying attention to column width or line spacing can really put a strain on your readers’ eyes, and they won’t stick around too long to find out what you have to say. In the book, I spend a chapter talking about how to make your text readable, and as a follow-up, I want to share an article I found today that offers some additional advice.

Specifically, I love this idea:

The fibonnaci sequence

the first two Fibonacci numbers are 0 and 1 and each other number is a combination of the previous 2. These numbers are meant to have a natural visual elegance to each other. Since the Renaissance, many artists and architects have proportioned their works to approximate the ‘golden ratio’. Therefore in typography it is a good suggestion to consider using only these numbers to structure your chosen point sizes to. It will give your whole document a natural elegance.

• Simple rules for good typography via Fred Design

Web Design For Developers is now available in print and the Pragmatic Bookshelf is shipping out all of the preorders.

This book aims to teach you the basics of web design and guides you through picking colors, choosing fonts, setting up a grid, and then walks you through planning and implementing a site redesign. It’s aimed at developers who have little to no front-end or graphic design background. By the end of the book, the reader should have a good foundation on which to continue exploring web design.

I hope you enjoy it.

Favicons, or “Favorite icons” are icons associated with your site. The icon appears next to the address bar on most browsers, and is often used as the icn for the bookmark or tab associated with the site.

There are many different ways to create favicons. In the book, you saw how you can use Illustrator to resize your company’s logo. You could also use different tools like ImageMagick to create scaled-down versions of existing images. Sometimes, though, it’s nice to draw an icon by hand.

http://www.favicon.cc/ has a free online icon utility. Simply draw your icon in their grid and click to download. It supports transparency and works extremely well.

More and more browsers are able to handle embedded fonts, but getting the right formats for each browser can be tricky. For example, Internet Explorer requires a proprietary format called EOT, or “Embedded OpenType”, but getting fonts in that format isn’t easy and Microsoft’s tools don’t seem to work all that well for some people.

Thankfully, FontSquirrel has a @font-face generator that gets you exactly what you need. Upload a TrueType or OpenType font and it gives you the CSS files and the EOT file you need for Internet Explorer.

Of course, you must have the right to use and redistribute the font in order to include it on your web site.

• @font-face Generator