« June 2008 Entries »

Design Notes

Time to dive back in to the Bright Creative redesign I wrote about last week, and focus on some of the good stuff that came out of it.

Most people got it; but for anyone who misinterpreted my laundry list of rants from last time, that was just some healthy critiquing of my own work. It’s a good idea to step back every now and then and judge what you do with a critical eye. The truth is I’m very pleased with the way this redesign came off. Here’s why.

jQuery

I’d like to thank the star of our show, John Resig’s fabulous jQuery library. No doubt you noticed the portfolio page effects, with sliding and zooming and fading and the like. Yep, that’s Javascript. No Flash here. I’ve only been playing with jQuery for a few months now, but it’s already one of those “how did I live without it?” tools.

To me it’s the difference between avoiding Javascript as much as possible, and embracing it whole-heartedly. jQuery abstracts away the hard stuff like DOM incompatibilities, leaving me free to write fairly basic script to accomplish what I need. And the CSS-like selector syntax is absolutely wonderful. I’ve already learned that so it’s building on what I know. I’m still not convinced I’m much of a scripter, but writing with jQuery makes me feel like I’m actually somewhat in control when it comes to Javascript. And the joy of seeing my script work as expected first time ‘round across the board when testing in various browsers? Undefinable.

With this design I wanted to see what kind of useful user interaction effects I could pull off with some jQuery magic. I had a vague idea in mind to use sliding portfolio pages, echoing something I did with the previous design’s thumbnails. But I also wanted to treat the slideable area as real content with enlarged previews and live text. I looked at a few canned scripts that seemed to do what I wanted, including some jQuery plugins like Coda Slider and various lightboxes, but ended up needing a bit more flexibility. So I rolled my own.

There’s nothing particularly new or clever about my implementation, but it came together nicely. I have a bunch of divs in the page source that are assigned the class item, and in my CSS file that class is treated as a non-scripted element by default. I’d hoped for graceful degradation when Javascript is disabled, and the default rendering without script is actually somewhat usable. It’s not great, but it works.

Then on page load, the script does a bit of work to change that default and get the page ready for interaction, things like adding new classes and then re-positioning the divs based on those classes. The resulting style of the elements updated by the script is still handled in the CSS file as a new set of classes, triggered by that scripted changing of the class. That’s the ideal, but I did need to script some of the positions, so there are a few spots where hard-coded pixel values ended up in Javascript. I’m sure there’s a way to make it more elegant, but that’s as far as I got.

The actual slide effect happens by giving each individual item in the portfolio a sequential position within a horizontal series of items, and then updating the left value of each based on which item the user is currently viewing. The current frame has a left value of 0, the next is 750, the one after that is 1500, and so on. Frames prior to current are negative values, ie. -750, -1500 and so on. And then by declaring overflow: hidden on the parent frame I’m hiding the inactive items and only showing the active item so you never see more than one at a time. This allow lets me slide things in and out of the frame without more tedious clipping calculations, something I’d far rather let the browser handle.

That was the quick easy way to do it, but it also led to the expandability problem I wrote about in the previous post; I can’t use overflow: auto in the portfolio area to allow for a scrollbar when the user resizes the text, because the divs intended to be hidden by the overflow end up forcing scrollbars and making a mess of the page. The unscripted version allows this, but the scripted version doesn’t. Oh, sweet irony.

The larger previews triggered on click are also added with script; in an unscripted state these are simple links to images that open in the same window, a fairly clumsy way of doing it, but at least the unscripted state is functional. Again by manipulating the classes in script, I change those links into positioned target areas that have an onclick event which pulls in the target image of the link as the contents of the pop-up area. There’s a nice jQuery fade effect too, though the first image load usually takes longer than the fade so the effect looks more like a vertical slide-down than a fade. But once that baby is cached after that first click, watch out. Fades for everyone.

Something a little more subtle than the portfolio effects is the logo and primary nav hover glowing animation. This is a trick I demoed at An Event Apart last month, and I’m about 2/3rds of the way through formally writing it up. I’m using jQuery to take your basic CSS Sprites setup and add animation effects to produce a smoother transition between off and on states. It’s a tiny bit more involved than that, as you’ll see if you dig into the source. But keep your eyes peeled for the article, there will likely be a pre-built function that abstracts anything remotely difficult about it. Oh, and yes, it gracefully degrades to plain old CSS Sprites.

Copywriting

Updating the copy was a big reason for redesigning the site. The previous version was built at a time when I didn’t have a clear idea of what the business would be in one, two, or five years. Since that time I’ve figured out what it is I want to do and how I do it, but the site didn’t reflect that. I’d been handing out an intro PDF to new clients for a while to fill that gap, but it’s the sort of information that really needed to be directly on the site.

I ended up scrapping almost everything that existed before, and changing the voice from an impersonal royal “we” to a much more direct “I”. This didn’t come easily; it was hard to adjust to talking about myself in the informal first person on an ostensibly professional site. But I often get email starting out with “I’m looking to contact Dave Shea”, or “do you guys offer such and such a service?”, so I realized it was time to kill the ambiguity.

There were two items I felt a bit conflicted about putting out there. In my previously private PDF I had included details about pricing and process that would be helpful for prospective clients, but it’s the kind of information that people in our industry don’t generally publish on public-facing sites. I have some theories why this is, and they’re not all to do with competition, but the result is the same in any case. I decided to go ahead anyway, a decision which I don’t know will prove to be a good or bad idea long term; we’ll know for sure if it ends up going away one day.

Design

The visual design was actually one of the least important things I needed to accomplish this time around. When I began planning this redesign, I tackled the scripting and copywriting first, and only opened Photoshop after I had a pretty clear idea of what the content was going to be. You know, the same sort of expectations you’d have of a client; I believe the phrase we’re looking for here is “eating your own dog food”.

Somehow I ended up building a colour scheme derived from primaries, though the red, yellow and blue are not exactly full saturation, and the brown of the content area serves as more of a neutral in this case. Previously I’d been using brighter shades of red and yellow, so there’s some consistency with the past, but the blue was a new addition this time for the sake of more interesting colour contrast. The overall tone is a lot darker than last time, but that feels like a good change.

This visual design isn’t a huge departure either; the previous one had a bit of a gritty, non-pristine feel to it that I wanted to continue using. I went for broke on the texture and detail work, but that ended up causing some fun layering challenges. After the Photoshop work was done, I spent some time looking at the design wondering how in the world I’d build it out into something that would work in a browser. In the last post I mentioned that transparent PNGs would have spared me some headaches, but I don’t feel like I can yet thanks to IE6. So I went with GIF images instead, which caused a lot of tedious matching of foreground and background images. Saving a transparent GIF to sit on top of a solid colour is easy; saving one with texture that must precisely align with a second background texture while fading out into transparent areas is… not so much.

For example, the portfolio’s white stage area sits on top of the page’s background texture. Its drop shadow and frilly decorative bits have varying levels of opacity, something GIF obviously can’t do. To simulate this I had to save the background texture into the image itself, which forced precise alignment of the foreground and background images. I could have gotten away with simply flattening my Photoshop file and saving out the background with the image as a big non-transparent rectangle, but that would have made the site’s already-large image profile even larger. So I dropped what background I could by first hiding the background in Photoshop and saving a preliminary transparent 1-bit GIF to basically create an outline of the foreground area, then loading that GIF back into Photoshop and using it to create a mask for the background, then saving the combined foreground + background combo out together into the final GIF. It looks like this.

There are also some extra little details I added to try and elevate the HTML-based text to something a bit more interesting. I applied text-shadow to the various headers and links for Safari’s benefit. Primary h2s on the site have a very faint PNG absolutely positioned over top that fades in the background texture a little, resulting in a semi-transparent almost gradient-like look. Getting the PNG gamma to display consistently was a challenge; my first attempt worked well in Safari, while the overlay was too obvious in other browsers. So I had to tinker with various colour output settings and finally got something that seems like a good enough compromise. The PNG is still somewhat visible in all browsers, but faint enough that I can live with it. (and I did a lot of Googling for workarounds; what you’re thinking of suggesting? I tried it.)

Contact Form

Finally, one of my favourite bits from the site, the contact form’s Stress-o-meter. This was a fun little idea I had in mind from the beginning, but it was the last thing I built because I wasn’t quite sure how to make it go. Design-wise, there are three levels: Low, Medium, and High. The higher it gets, the more distressed the meter looks.

Luckily it ended up being easier to build than I expected. There’s a simple text file sitting on the server with a date in it. Every time the contact form is viewed, I have a PHP script that opens that file and reads the date. If today’s date is within a certain number of days from the previous date it will display Low, and if it’s above that range it shows Medium. There’s a second range it checks that will show High. I’m still working on precise values, right now Medium is 5 days and High is 10.

That’s it for the viewing part, the updating part was pretty basic too. I’ve created a cron job on the server to run a second script every couple of days. That script sends me an email asking me whether I want to update the meter, which is just a link to a third script that replaces the contents of the text file with today’s date. If I don’t hit the link, nothing changes, and the previous range checking script will compensate. That’s it. Simple. I’m still wondering if various spiders are going to find the update script or not, but a permanent Low status on the meter would be the only real side effect so I’m not terribly worried.

Comments (33) | posted to

Design Rants

Last night I launched a long-needed redesign of my business site, Bright Creative. The site had been languishing for years, but fact is, it is a business and I do keep my contract work at arm’s length from what goes on over on this here site, so I decided to keep it rolling along instead of folding it all into one.

Of course then I got ambitious, so it’s been in the works for months while I’ve tweaked. Designing for yourself is never easy, is it? I feel like I could spend the better part of a month continually tweaking and making improvements, but I finally hit the point where it was “done enough” to launch.

While this is design work I’m quite pleased with, I still see things I think could have been done better. It might be more interesting to write up my notes on those first, so I’m going to do this in two parts: first the rants below, then I’ll follow up with another post on the parts I’m happy with.

Typography

I had this grand goal of keeping all my text in HTML and avoiding image-bound text or sIFR entirely, while avoiding looking like HTML text if I could help it. I looked for effects and typefaces that might accomplish that, and landed on Microsoft’s ClearType set. The headers were going to all be Candara, and the body text all Calibri, and that looked pretty nice in Photoshop.

But oh, the pain when trying to get a browser to duplicate it. Firefox OS X does not render Calibri well at all. Seriously, what is this? The kerning is all over the place, and look at that crazy overlapping of the link on the right; there’s no fancy letter-spacing happening in my CSS that could explain that, it’s just what 13px Calibri does in Firefox.

So I found a CSS hack that would allow me to keep the Calibri in Safari, and step down to Lucida in Firefox… except that the x-height of Lucida is quite a bit larger, so the type size contrast in the two versions was not equal. Since those without the most recent versions of Office or Windows don’t have Candara/Calibri anyway, my fallbacks weren’t going to work well either.

I ended up scrapping Calibri and running with Lucida for the body text. The headers are still Candara, or Georgia if it’s not installed; I did save some Candara into an image for the top navigation despite it all, but the headers throughout are styled HTML text (more on that in the follow-up).

And after all this ordeal it felt like the finely-grained type control I had carefully planned got away from me; I have three different type sizes for body copy in various spots, when I only intended to have one or two at most. It’s all still functional, and looks okay at a glance, but I still see areas where it should be a lot tighter.

Readability

I put up a link on Twitter last night, and one of the most frequent pieces of feedback I’ve had since was that text contrast was too low, the brown-on-brown is hard to read. Yep, guilty.

Embarrassingly enough, I spent most of my design time on the portfolio and home pages, neither of which have excessive text on the brown textured background. And then when I started working on content pages like Services, I realized there was a problem.

Since then I’ve gone back in and smoothed out the background behind the main text area on content pages, so there’s less distracting texture. It still suffers from a text contrast issue, but short of brightening up the entire background texture, that’s probably as far as I’ll go.

One thing further compounding the matter is the anti-aliasing method used to render the text. With sub-pixel rendering everything appeared a bit darker and thicker, and that really helped the contrast. However, the fades and animation effects I’ve used in parts of the site caused flickering between sub-pixel and regular anti-aliasing, a known issue where the best fix is to manually force regular non sub-pixel anti-aliasing by setting the opacity of the parent element to 0.9999. As soon as I kicked this in, the readability took a big hit.

I’m not sure if/when I’ll come back to this issue; it’s not something I’m totally happy with, but it’s also something I may end up just having to live with. (Automated contrast checkers tell me the brightness contrast is okay, though I think you and I both know just by looking at it that it could be better.)

Expandability

You’ll notice in some parts of the site, resizing text in your browser causes it to expand gracefully, but it falls down on the home page and the portfolio pages. I always try to design for text expandability, but those two pages had to be the exception this time.

There were a few factors at play here. For one, my image sizes are already large (see below), and creating even more for expanding text areas was starting to feel a little silly. And absolute positioning on the home page in order to overlap textures seamlessly caused me to force hard pixel values for text area heights. I did think of trying an overflow: auto kludge to force a scrollbar in the portfolio, but the script for the sliding pages just doesn’t allow that. Interestingly, turning off script allows overflow: auto just fine, so the expandability issue goes away when Javascript is disabled. That’s a lovely bit of irony.

I don’t really have a good fix for this one. I ran out of ideas, so no text expandability. But I feel really bad about that, so the guilt makes up for it, right? Right?

Markup

Yeah, so, viewing source is going to get you a whole mess of extra wrapper divs and such. I had a lot of images to layer, it had to happen. Did you know that you can nest your divs so deep that Firebug stops working properly? I do now.

The real shame of it is how unnecessary most of them are. With multiple background images ala CSS3, I could get away with far, far fewer. But alas, I live in a world where supporting IE6 is still necessary, so I’ll just keep my dreaming to myself while I propagate the useless divs throughout my markup.

Also, you may notice a bunch of empty <i></i> pairs here and there. These are as semantically neutral as reusable empty divs or spans, only with less characters. That’s a trick I picked up from Eric Meyer along the way, I think in conjunction with the A List Apart redesign, though I’ll be damned if I can find the post in question now.

Images

I still have this philosophy about using the PNG format — it’s great for throw-away images that I can effectively hide from IE6, but for core site UI elements, it’s still GIF all the way. The alpha hacks and colour profile issues just aren’t worth it. So I had to find fun and creative ways of overlapping compex faded imagery with 1-bit transparency. The amazing thing about doing it this way? IE6 testing was actually fairly painless this time around. I did not expect that.

The upshot, however, is that I’ve got 556k in images for the primary UI elements alone, not to mention the 6MB of project-related images. I’m not saying all that would go away with PNG transparency, but I bet I could shave off a few bytes. This is the sort of site where heavy imagery isn’t a huge ordeal, but still. A half meg of images rubs over a decade of image optimization practice the wrong way.

I think that about covers the ranting. Next up: the fun scripted bits, the design notes, the copywriting, and more.

Comments (46) | posted to