I’ve been building web sites for more than a decade now, and one of the best resources is the web itself. There’s all kinds of help for aspiring Web Designers/Web Developers/Web Whatever-We’re-Calling-Ourselves-These-Days. Online coding dictionaries, tutorial sites and inspiration sites abound.
What I’m considering doing here is a bit different, perhaps a combination of some of the above. I recently built a few pages of an upcoming website, designed by my friend and frequent collaborator Dave. I thought it might be interesting to write about the process that fell between receiving the Photoshop file from Dave and the pages as they now stand.
I’m hesitant to call it a “tutorial,” because that seems to presume that what I’m showing is the only way, or even the best way, to do this. But my hope is that by demonstrating some of the steps I followed, I can shed some light on possible approaches to common web design tasks and problems. Also, the reverse might be true — commenters may provide me with insight on how I might do a better job of approaching these issues. So don’t hesitate to post comments, questions, or suggestions.
The Photoshop (PSD) file
Okay. Dave wants to send me the Photoshop file. He can email it to me, which is nice because a copy will always be there in my email. If I need to go back to the original, I can just download it again. But it occurs to me that I may need other files from Dave, and he may want to revise some things. So instead, I use my Dropbox account. I create a folder that Dave and I can share and he puts a zip file of the PSD in it. Now whichever machine I use has access to the latest file, and I’ll see if Dave modifies or adds anything.
I never, ever modify the original PSD file a designer provides for me. Ideally, I’ll keep the initial zip file plus the PSD that comes out when I first unzip it. Then I’ll make a copy of the PSD, and work on that. From then on, if I need to, I’ll either make another copy of the original, or a copy of one of my copies. Sometimes by site launch I’ll have half a dozen copies of the PSD, depending on how many modifications I have to make to get the slices I need.
The first thing I do is take a look through the layers, to get an idea of what each page will look like. Ideally, you’ll be presented with a nice, neat set of concisely-labeled layers and folders, which you can easily turn on and off to view pages, popups, etc. Noupe.com has a great article about how designers should prepare PSD files for web developers. Often, though, it’s not a bad idea to follow these steps yourself if the designer hasn’t. Dave’s done a pretty good job of setting up the PSD for me — thought not a perfect one, as we’ll see later.
So let’s start by looking at the home page. Ordinarily it’s better to start with a sub-page, because the home page is almost always different from the rest of the site in many respects, and it’s better to start by creating styling that will affect the most pages, then create the styles which will occur less often. But in this case, I’m only making three pages — the home page, the Gear page, and the Fighters page — and they all share enough elements that I’m comfortable starting here.
One of the first questions I usually have to ask about most designs is, “What happens when the user resizes the window?” It’s easy to overlook, even for experienced designers like Dave. But Dave has it covered this time: the right, left and bottom of the design fade to black. So I can just give a black background to my page and place the background image at top center.
Which brings me to my first issue: the background. It’s red. It’s very, very red. And it’s quite detailed. check out the diagonal stripes at the bottom, before the fade to black:
So this means I’m going to have to make a really big JPEG for the background image. One with a lot of red in it. Why is red a problem? It simply doesn’t compress well.
Sound crazy? It’s true though. The human eye is more sensitive to variations in shades of red than it is to variations of other colors. So JPEG compression artifacts (the kind of crinkly weirdness you see in some web graphics) are far more noticeable in images with lots of red.
So what to do? Well, if it were feasible, I’d try to make the background color a solid red and lay the other parts of the background image on top. But I can’t really do that here. Another option would be to put a black box in the middle of the background image, where it’s covered by the boxer photo. But this background is used on other pages where the middle is seen, so that won’t work.
So there’s really nothing for it but to play with the settings to try to get the best-looking image I can in the smallest file size I can. Which is going to be a fairly big file. But at least once it’s downloaded it will be cached. And it will load in over a black background, which will allow the other elements to be perfectly visible while the background loads.
The Header and Navigation
After I really started getting into CSS-based design, I kind of went on an anti-image vendetta. I wanted the page to have no images except what CSS brought in. Everything needed to be text. Including the logo at the top or top-left of most sites which links you back to the homepage. It would be the company name in an H1, then CSS would hide the text and add the logo as a background image (a common form of CSS image replacement).
My position on that has changed. While I still think that you should carefully consider which images are truly page content and which are decoration, I like to have the logo appear at the top of the page. Why? Well, there are a few reasons. For one thing, if the logo is on the page, search engines can grab it, which is good. Second, if a user shares a link on Facebook, usually the first large image is chosen to be part of the Facebook post. Also, if your user is viewing the page with an older smartphone browser and seeing most of the page content as unstyled text, one image you would like them to see is the company logo. (Most of these browsers will shrink the image to fit.)
When I first looked at the design, I seriously considered making the logo part of the background image. It’s in the same place on every page, and it would save a server call and the download of a somewhat large PNG. But because of the arguments listed above, I decided to have it sit on top.
Now the navigation. I’ve become a big fan of the CSS @font-face tag lately, and I’ve had good results with it. So it’s tempting to render the navigation links as text and use CSS to add the red bars and drop shadows.
However…There’s a gradient fill on the text to make it look shiny and metallic. Hm. There are methods to create gradient text in CSS. But it’s kind of a hack. The drop shadows are doable, even in IE. But the red bars will need to be borders, and how will the drop shadow affect them? And if the red bars are background images…
After some internal debate I decide to go with the sprite method for the navigation text. If you’re not familiar, here it is quickly. I create one image that contains the normal and rollover states for all navigation items:
(If the above paragraph didn’t make much sense, do a search for “CSS sprites.” It’s a technique well worth learning.)
So far, I’m still in the realm of thinking about how to create this. I’ve written no code. Next time I’ll talk about handling the big main image and the links below.