This is not breaking news, but I’m still surprised that so many web designers don’t know it: Fireworks’ 8-bit PNGs support alpha transparency.
If you’re like me, your install of Fireworks from the CS Suite doesn’t do much more than sit around in your Applications folder hogging memory. Once a year, I hear on a podcast or blog that a designer I admire swears by Fireworks versus Photoshop; so I fire it up and give it the old college try, but it never takes. Maybe I’ve been using Photoshop too long, but to me, Fireworks is the blaster to Photoshop’s lightsaber: Fireworks’ layer styles don’t look as refined to me as Photoshop’s, the type tools are really weak (not that Photoshop’s are a whole lot better) and the multiple “glossy button” presets give off kind of a cheesy vibe from the get go. Not to mention the fact that everything is in the wrong place. So I tend to try using it for an hour or two, get frustrated, and give up. Definitely more my fault than Fireworks’, but there ya go.
However, Fireworks now more than justifies its place on my hard drive because of its wonderful, efficient alpha-transparent 8-bit PNGs. In fact, it made this site’s design possible from a performance standpoint. Ever since alpha transparent PNGs went mainstream with IE7, arriving at a site, starting to read the content, then being shocked when a massive background PNG suddenly finishes loading has become a daily annoyance. I have no doubt that many of these images were sliced up in Photoshop and Saved for Web using its PNG-24 preset. This creates beautiful, fully alpha transparent, but unfortunately huge transparent PNGs. What Fireworks offers with its 8-bit alpha transparent PNGs is slightly lower quality, but at file size savings of (in my experience) around 75% compared with Photoshop.
See for yourself
Here’s the same lily pad PSD from this site design, exported with Photoshop’s PNG-24 preset and Fireworks’ PNG 8. The Photoshop PNG weighs in at 230KB, while the Fireworks export is only 50KB.
Photoshop PNG-24 (left, 230KB) and Fireworks PNG 8 (right, 50KB)
As you can see, there is a degradation in quality. The Fireworks PNG 8 weighs so much less because, like a GIF, PNG 8 works from an indexed color palette: You get an index of X colors (commonly 32, 64, 128, and so on), and that’s it. The alpha transparent PNG-24 from Photoshop (which is the same as a Fireworks PNG 32.. don’t get me started), on the other hand, supports full-on alpha transparency. In almost every case, however, I’ve found that the slightly more jagged edges and lower fine detail of PNG 8 are more than compensated for by the increase in load time from a much lighter image. If the image is being placed over a light background especially, the difference in quality is really negligible.
Don’t settle for the preset
To make Fireworks cough up an alpha transparent PNG 8, simply select “Alpha Transparency” from the transparency dropdown in the Export menu in the PNG 8 preset. But don’t stop there: Fireworks gives you options for color palettes and dithering. You’ll have best luck with the Adaptive and Web Adaptive palettes; although if your image can stand it quality wise, you can shave a few precious KB off by slumming it in Web 216. Dithering will smooth the appearance of more complex graphics, but at the same time it increases file size. It’s possible I need more hobbies, but since discovering PNG 8 in Fireworks, playing the whole quality vs. file size tradeoff game when exporting an image has become something I kinda enjoy.
So if this is news to you — as it was to me only a few months ago — uh, fire up Fireworks and give PNG 8 a whirl. You don’t have to be a used car dealer to get excited about savings like these.
Why? Because it’s a pain in the butt but ultimately well worth it. And it’s a real pain if you go about it like I did.
Requisite showoff-y composite of this site on three different Apple devices
I started out very inspired by the approach Andy Clarke took with his well known 320 and up framework: Design primarily for mobile and add CSS via media queries as you need it for larger screen sizes. Brilliant. Makes so much sense. Unfortunately, I found designing only for mobile takes a lot of discipline: I found myself constantly widening the browser window “just to see” what the design was looking like beyond mobile. Next thing I knew I was having flashes of debatable layout inspiration and quickly adding styles to the main “mobile only” section of my style sheet because I couldn’t be bothered to scroll down to the appropriate media query.
Long story short, I gave up and designed the site for the desktop. Then when I was done, I had to go back through each selector and figure out what declarations were needed for each screen size. This editing took at least a couple of evenings of my life I will never get back — and by flitting around between screen sizes while designing in the browser (constantly second guessing myself as I flitted), I’m pretty sure I added a substantial amount of development time to the project. Fortunately, I was the only client, and next time I’m going to exercise a lot more self control when I’m designing in the browser.
Fitter, happier, more responsive
The site has three layout states: Under 555px, it’s a single column. At 555px, it expands to a flexible multi-column grid, until the screen size reaches 992px, at which point it snaps to a fixed-width grid with a maximum width of 960px. Why the specific widths? The single column layout is obviously for smartphones, while the flexible grid between 556px and 992px was my attempt to accommodate various tablet sizes in both horizontal and vertical states. Despite the fact it’s been a standard of sorts a while now, I feel like 960px is still my happy place for desktop site width. Super-wide sites are fun to look at, but I find them a bit overwhelming and not super usable.
Or maybe I’m the toddler
So I ended up with a 320 and up-inspired site, but I got there the hard way. And maybe if I hadn’t gone about the CSS like a 2 year-old with the attention span of a gnat, it wouldn’t have been such a pain. That responsive design is worth the extra effort isn’t even a question for me anymore. I was sold the second I pulled up this site’s homepage on a germ-infested iPad at the Maine Mall Apple Store. It’s up to me to adapt the way I work to make it happen efficiently — just like I did when I weaned myself off table-based layouts five or so years ago.
Happy browser window resizing!
Unless you’re using IE8 or below or you’re on a smartphone, you’re probably looking at 2-4 bright lily pads right now. Why? It’s really a lesson in self-editing.
Drunk on the heady possibilities of CSS3 and jQuery, my original vision for this site was to have no main navigation. It sounds great already, right? And it gets even better: Each corner of the screen was going to feature a lily pad that was going to serve as a link to a main content section (Blog, Work, etc.). If the user were to click on a lily pad, the requested content would appear to rise up from the depths of the pond (through animating the box-shadow property via a sketchy plugin I found), after which — wait for it — a jQuery-powered carp would appear from beneath said lily pad, elegantly fading out as it reached the middle of the screen.
As you will read in my About section, I pride myself on keeping content top of mind when I’m working on a design. It’s not rocket science, but I’m of the opinion that design template of any kind — print, web, whatever — should never, within reason, dictate the content. It should always be the other way around. You know what I’m talking about — those websites you have to work on early in your career where “you can only add five lines of copy to the I Love My Cat section, otherwise the layout will break”. This I believe, so realizing that I’d got so carried away with some minor design garnish that I hadn’t given much thought to the greater goals of the site was a hard pill to swallow.
Anyway, this is a very long-winded way of saying that I had to suck it up and go back to square 1. Or actually, square 2, because I found myself with a bunch of very nice lily pads and other pond-themed PSDs I’d spent hours creating for the non-starter version. And so this site design was born – I kept the lily pads, but went with a more conventional, scalable navigation. I scrapped stupid gratuitous stuff like content sections rising from the watery depths. The carp is no longer jQuery-powered, but if you’re reading this at over 768px, you might see him make an appearance. What can I say? I like carp. No, really, I do.
So I guess this is my “Hello World” moment. After putting my site redesign down about a million times over the past year to do other side projects or simply get a good night’s sleep, it’s finally done.
I have a newborn blog! And in much the same manner that it hit me when my daughter arrived, it dawns on me that now I have a blog, I have a responsibility to keep it fed, watered and happy. And I’m determined to be good about that because there are few things on the Internet sadder than an abandoned blog. I can tell you one thing right off the bat, though: my content will be on the nerdy side, so unless you’re interested in web design and development, I would hold off on adding me to your reader.
So bear with me while I find my blogging voice. I think to start, I’m just going to write a few posts about redesigning this site …