Web Design for Developers

There’s an excellent article over at the Van SEO Design blog that talks about what you, as a designer, need to know aobut perception and memory. It does an excellent job of explaining how we find things, how we search, and more importantly how we sometimes ignore things that are right in front of us.

• What Designers Should Know About Visual Perception and Memory

My second book, HTML5 and CSS3, is now available in print and is a good solid guide to all of the cool features you can start using in your sites and applications. It’s not a beginner book by any means, but if you’ve gone through Web Design For Developers, you’ll be just fine.

HTML5 and CSS3 takes a different approach, this time leading you through over twenty small tasks which introduce you to the various new features.

Best of all, it shows you how you can use various libraries to implement these future features in your current sites so you can keep your existing users happy.

If you’re developing web sites, you can really add value by incorporating many of HTML5’s features.

Favicons (those icons for web sites that show up in the browser bar) can be a little tough to make sometimes, but Favigen make is pretty simple thanks to its easy web-based interface. Simply upload a square version of your logo or icon, select the output icon size, and download your newly created file. While there are ways to do this with Illustrator and Photoshop, this tool makes it very easy for people who haven’t shelled out the money for those tools.

Here’s a nice series of presentations and example code from Google that show you how to build user interfaces using HTML, CSS, and JavaScript.

HTML, CSS, and JavaScript From The Ground Up

My article “Better CSS with Sass” was published in the February issue of PragPub Magazine. It is now available in HTML format. You can read the article here.

Sass is a great alternative to working with regular stylesheets. You get all the benefits of working with a dynamic programming language, and you still get usable stylesheets when you’re done. I don’t use CSS anymore without using SASS to build the files.

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