Last time, I talked about the design theories that went into my new site: Metro, minimalism, reductionism, galleries, etc. This time, then, I want to talk about the tech it took to make those design sketches a reality.
First and foremost, before I was finished even drafting the design layouts, I had been convinced to move the site off of a static grid and onto a responsive grid. Why? Traditionally, websites have been designed for a known horizontal width. Usually the smallest one commonly used on the market (ever seen a size designed for “1024 or greater”? yeah, that.) But with a responsive grid, everything is based on percentages, not pixels. So, instead of a column being 62px wide, it might be 7.82% of the screen width instead. The advantages are obvious: content always fills the view while maintaining the same proportions. Those annoying “sidebars” of space blocking out most websites? Gone. The visual fills your entire view.
Knowing I wanted a responsive grid, I did some poking around. And I very quickly settled on one by Tyler Tate / TwigK (@tylertate) called “Semantic.gs.” Why? Because all of the grid work is done behind the scenes in the CSS, not by adding fake grid alignment classes to elements, which remove the flexibility of the grid and interrupt the dream of a semantic web (you know the one, where HTML markup is actually just markup and not styling.)
Letting Go Of The Pixel
The first thing I had to learn was that the pixel was dead to me. In a fluid world, there’s no place for calculating size by pixels. Block level elements were set to percents (and every image is set to 100% width within a containing block-level element). Type is set by em. Everything is relative and in an ideal world that’d be great.
In a fluid world, you can always know the width of an element. You live and die by the width. When aligning things in a grid, however, you sometimes need to know the height of things. Like my logo (to set the menu height). Or the height of a single square element so that input heights can be made to match. This is where things get… messier.
My first idea was, in all regards, a reasonable one: images have implied dimensions. Once the DOM calculates the width for one, it’ll also know the height, and with some assistance from jQuery I can just use that.
var rssHeight = $("img#rss").height();
Those of you smarter than me probably already see the problem here: you have to wait for (often large) images to finish loading. The end result? The website kinda loads then “snaps” to the right aspects. Not exactly elegant.
My second idea was a better one. Pick an element with a ratio I could know (like my logo, or the RSS icon or anything really because I made the bloody graphics), then, calculate its height based off that ratio and something the browser was going to know right away anyway: the browser width. This way, we don’t wait for the image to load to grab it’s height. As soon as the DOM is ready we tell it in advance what height it’s going to figure out it’ll be eventually anyway. Way, way faster.
var body = $("body");
var bodWidth = body.width();
// the content is only 78% of the page width to keep it from raping eyeballs
var adjustedWidth = bodWidth*.78;
var squareHeight = adjustedWidth*0.0491;
Thinking Big. And Bigger
I’m pretty young, really. When I started designing for the web. 800×600 was already the dominant web resolution, with 640×480 the trailing legacy support size. But even so, if I were to go back in time and tell that me that someday in the not-so-distant future he’d find out that the largest standard resolution he’d need to support one day would be 2560 pixels wide (the approximate width of a 4 megapixel image), he’d laugh me out of his web dev class. 2560? Shit, the bandwidth alone would be impractical, and even then, what would you show it on?
Yet, here we are, and supporting 2560px is a real limitation to making a genuinely responsive site (you know, because downsizing looks OK to great, but upsizing never ever ever looks good ever). Yowzer.
In design, “web-size” refers to a low-resolution image that’s no good for printing, but thanks to the web’s approximate 72ppi resolution (actually varies a lot these days by display), and low total resolution, these images look just fine on the screen.
Yeah. That’s not the case when you’re looking at monitors that have more pixels than the average digital camera of 2004. “Web-size” doesn’t cut it anymore. I had to think it out. Every header image must be at least 2560 pixels wide. The homepage uses a 1:2.45 size ratio. The other pages all use a 1:4.6 ratio. But the width is always the same. 2560. No more casually scraping images off the web for blog posts, that’s for sure. Every image I upload needs to be planned, and it needs to be high-quality. And, because bandwidth is still an issue, I always have to worry much more about optimization than I did when graphics could be 500px or less. I promise you, your average mobile connection will throw an absolute hissy over a 2.1mb png file. As will your average user. Among other things, it means that highly compressed JPGs are currently the only way to go. Don’t believe me? Here’re some export weights from Illustrator’s save for web for a 4112x1429px image (the one used earlier in this blog, before I resized it):
- PNG-24: 3.26mb
- PNG-8 (256 perceptual): 1.33mb
- PNG-8 (64 perceptual): 1.07mb
- JPG (80, Optimized): 1.52mb
- JPG (40, Optimized): 696.5kb
See? Compressed JPG, clearly the winner. The gallery images suffer the compression hammer a bit less, because, well, it’s a portfolio site after all. But the point stands: a true fluid responsive site really makes you think about your images. A lot.
Whew. That’s a lot, and we’re just scratching the surface. Next time we’ll take a look at waypoints, sticky elements, and what’s in a gallery. After that, WordPress hacking for fun and flexibility. See ya then.
Well, now that I’ve got the new version of my site up, I thought I’d take a moment for anyone interested to talk about the design decisions, theories, and methods that went into making this a reality. This new version is, I feel, a massive success in what it seeks to do, and it pushes my own online presence far beyond what I had been doing before. And while maybe all that just comes across to the viewer, it does so because of a lot of decisions I’ve fussed with over the past few weeks, the past few months, and some going back the past few years.
First up, the design was a pretty large undertaking. I’ve found out over the past five years that an artist portfolio is actually a very difficult thing to do right. Artists tend to be non-linear. Websites (and how we as people actually use them), are linear. This causes a lot of tension between artists and their websites, and how the conflict between non-linear thinking and linear display gets resolved varies a lot. I’ve seen quite a few approaches, a lot of solutions, and a lot of things that I didn’t like. I’ve seen artists try and reconcile the need for a creative, interactive space by using very free-form, experimental sites. As a designer, though, I’ve felt these have always failed the end user, serving only to satisfy the wants of the artist, and not the actual needs of the website or its users. Among other things, these creative sites tended to have one or many (if not all) of the following design shortcomings:
- A heavy reliance on Flash. While I was never of the hardline “Flash is the devil” camp, Flash was always an unwieldy solution. It was very, very programmatic to create. Very difficult to make flexible. It didn’t scale well or easily to various page heights, leading to fixed viewport style sites. It kept the data locked inside. It didn’t index into Google. It didn’t work on mobile. The list goes on…
- No permalinks. Usually because of Flash. When you went to a gallery, the address of the site didn’t change. You couldn’t bookmark or share individual pages, galleries, or images. For a portfolio page, this was absurd. It was counter-intuitive and harmful. Users are coming to look at art, and the site shouldn’t hinder them on sharing it once they have.
- Mystery-meat navigation. ”Creative” sites really worked on eschewing things like labels. Unfortunately, the web lives on labels, and discarding them often meant I was clicking on anonymous images or icons, hunting around trying to guess what I’d just asked to see, and how the hell I was supposed to find what I really was trying to find. Sure, it meant the artist didn’t have to ask themselves the hard questions, like how to edit and show their work in coherent bodies, so, they felt more freed. But as an end-user, it sucked. A lot.
The sites that shy away from Flash aren’t without their own faults, though. Usually, they take the idea of “simple” to a point that’s closer to “crude.” These sites, though much preferable to the Flash ones, have a few different concerns:
- The content loads a whole page for each piece, increasing load time, interrupting the flow, and slowing down the ability to scan a body of work. Plus, it just doesn’t convey the level of polish and gloss a modern web user expects, leaving things feeling chintzy.
- The home page is often just an image, lacking any information to help orient a user. Or for Google to index.
- The layout is formulaic and static, leaving the image left to look like it’s “floating” among some scattered menu links.
So, having seen a lot of what I didn’t like, I keep a shortlist of things I demand out of a “good” portfolio site, and design the way mine works around those limitations:
- No Flash. Period.
- Permalinks are a must. Users need to be able to bookmark and share individual pieces.
- The home page needs a large key photo (since I am a visual artist, not a blogger), but also search engine-friendly text content that updates regularly.
- All sections need to be clearly labeled. All collections need to have a coherent theme, motif, or topic. Users shouldn’t have to guess any more than they have to where to find what they want.
- The images need to be as large as they can be, without requiring scrolling on smaller screens to see the entire image.
Metro UI and Gallery Aesthetics
From Microsoft's "Codename Metro" Documentation
With those goals in mind, I turned to the design mantras most concisely laid out by a rather unlikely source: Microsoft. In the original concept docs for their Metro UI used on Windows Phones, they talked about a new, modern approach to UI design that takes its cues from older, more tried design movements like Constructivism, Brutalism, and other such theories. Of particular resonance from the whitepaper on the aesthetic was the following line:
We think content should be elevated, and everything else should be minimized.
This is really the core of their philosophy, which has been fleshed out with statements like “LET’S BE HONEST. IT IS WHAT IT IS,” “TYPOGRAPHY IS BEAUTIFUL. PERIOD,” and “WHEN ALL IS SAID AND DONE, CONSUMERS WANT CONTENT.” But it keeps coming back to the simple idea of reducing and fiercely eliminating all unnecessary UI, and reducing the visual architecture (or “chrome”) that computers and the modern web have often used to deliver that content.
As a design philosophy, it’s one I’ve been working towards for a long time, and the external inspiration of the whole system has helped me define and refine that sentiment. And, it also reminds me of something else I’ve always loved: the gallery aesthetic.
Galleries tend to have a uniform look: empty walls, sparsely hung art, lots of white, very little clutter. They emphasize something that’s very important–white space. They let the art be the focus, and stay out of the way as much as they can. They strive to reduce visual distraction and cross-chatter. And they’re elegant as hell for it.
ZmZ V5 Uses Only 12 Graphics and Icons Total
With those ideas and aesthetics in mind, I set about to looking at the last version of my site. I had to decide which elements were going to stay, and which weren’t. Then I removed everything unnecessary. The implied-page drop shadows are gone, releasing the content into more white space. Horizontal rules went too, and instead I just use comfortable, generous margins on content to provide necessary visual breaks. At the suggestion of my girlfriend, I also used an increasingly-popular web design idea known as “responsive” or “fluid” adaptive design, that lets the site fill the entire browser window. The design ration stays the same, and the experience is enarly identical for desktop resolutions from 500 to 2560 pixels wide. I moved the menu below the header images and galleries, letting the visual be the dominant cue. When text is used, it has wide margins, and large type. Only the things needed are shown at any time. The menu is sticky and joins and exits the flow as it needs to. Return to top buttons are hidden on short pages and quietly enter the picture on longer posts and pages as you scroll.
Images are given priority, and are allowed to be as large as they can be. Text takes the next visual priority, and as much as possible is done with type alone. Icons and graphics are kept to a bare minimum, with only 12 icons and graphics used across the site, and only an additional couple chrome elements (such as the shadow behind the menu and over the header) to help establish a clear visual hierarchy. All said, only 22 image files are used to make the entire site. Everything else is pure content.
The result, I feel, is gorgeous. Images are huge, and take up most of the prime visual space. The text is relevant and dynamic. Controls are pared down to just what you need, and they’re right where you expect them to be as soon as you want them. It fills the browser. It changes size as you resize your window in all browsers that properly support it.
But, it took a bit of work to make all that happen. So, for the designers among you, press on and we’ll look at some of the technical difficulties that had to be overcome and the compromises made in part 2.
Not a whole lot to say here that can’t be experienced better by just browsing around, but after a few bug patches today, I can proudly say that my fifth revision of zedmartinez.com is now live and rockin’. So, hop on over. Experience the 17 large, crisp header images for the homepage. Check out the new and larger galleries. And so on. And so forth.
I’ll follow up next week with some posts about the buttloads of design research and theory and technobabble that went into making this sucker, but for now, whew, I’m taking a break, and it can speak for its own darn self.