futuraprime

On Design Trends: Footers

2009-11-04T04:39:29+00:00

Well, all right: lots of people are still going to put up meaningless lists of trends for 2010 or 2020 or whatever it is they're doing. And Jason Santa Maria's criticism is (of course) spot on.

The tendency towards meaningless lists is probably as much lamented as it is irreversible, but I'd like to counter it at least a bit. So, as a public service because I have nothing better to do since it's a fun way to procrastinate, here's my stab at addressing the situation: I'll take a look at a couple design trends that are coming on the web now and try to parse out a bit why they're effective (or not effective) and what sorts of sites might want to use them. Today...

The Footer

A number of sites (including this one) have been reinventing the footer. Footers have often been afterthoughts in web design, a place for some fine print, utility links, or a basic sitemap. CNN's recent redesign uses something like this.

But there's been a big change in the way people interact with content on the web. In the early days of web design, people were obsessed with “the fold”—that area of the page that appeared on the screen when people first load the page, before they had to scroll down. These days, “the fold is dead.” We need no longer obsess about fitting stuff into the top of our sites.

The fold is dead?

Well, all right: the fold isn't really dead. There's a number of reasons why people say that, most of which are explained in the links above, but the part that's important for this discussion is that, contrary to the belief (and perhaps the reality) of the early web, visitors will scroll down the page. Indeed, people scroll all the way to the bottom. (I attribute this to two things, by the way. First, scroll wheels have become ubiquitous on mice in the last decade; second, the rise of blogs and the run-on designs that software like Blogger and WordPress have made commonplace means the web is teeming with very, very long pages.)

If people will scroll, it means the bottom of your website is not a tomb. Visitors will read what goes down there.

Moreover, visitors that do get there are probably people who're interested in what you have to say. They read your page.

Enter the massive footer.

Behold the Mammoth

So now we've learned that visitors to our sites will actually look at stuff at the bottom of the page—putting things in the footer isn't a waste.

Still the most common use for a footer seems to be site-mapping, but instead of the giant jumble of links many pages use, it can be done elegantly, taking a little more vertical space to let readers make sense of the list. The Los Angeles Times takes this approach, setting out a basic directory of the site at the bottom of every page.

The wonderful FortySeven Media take this a step further, diving into their sites content structure and providing individual bits of content.

Alternatively, CSS Tricks puts a list of site feeds and Chris Coyier's related other sites in his footer.

Jason Santa Maria's blog uses its footer as a digest of many different kinds of content he features on his site: portfolio, photos, book reviews, assorted links—and, of course, a search bar.

There's a central theme in these approaches, and it's a good one. The visitor who makes it down to the footer read your page—or, at least, was interested enough by what you put above to want to keep going.

More importantly, they're done with what you've just served up to them. They're looking for where to go next. These footers are in the business of giving them ideas. Sticking RSS feeds or links around your site in the footer is inviting the reader in. They're saying, "Oh, you liked what you saw? Well, here's where you can get more."

An ideal footer might even tailor links in the footer to content on the page (instead of putting it in the sidebar, where people have to scroll back up once they've done reading)—though standard blogging software isn't generally set up for this, preferring to have uniform headers and footers and put post-dependent content in between.

Making Contact

The other common use for a footer is for contact information. Arrival Design puts their address, phone number, email, and a helpful map in their footer, so that anyone can get in touch.

Some sites, like the Greg Brady Project, put their whole contact form into the footer, to make it easy to get in touch.

Alternatively, Edgepoint Church features their social media outlets—Facebook, MySpace, Flickr, and YouTube—prominently in their footer.

These sites are out to make contact with the reader, whether it's in a business transaction, fan feedback, or to establish a connection, rather than just directing them to other parts of the site. By putting this in the footer, they're inviting feedback, giving their readers a gentle nudge in the direction of getting in touch, taking the next step—ultimately, making a conversion.

Do I Want One?

Start by thinking how your users are going to interact with your page. Footers work best with linear content, like blogs or articles, where readers will scan from top to bottom and the footer is the natural endpoint for their progression through your content. If you're designing something that's more application-like than page-like, a large footer is probably not for you.

Similarly, if your page isn't organized in a linear fashion, a big footer isn't going to be as effective. On a site like Typeneu, a large footer wouldn't make sense (even if the page didn't scroll endlessly), because the eye isn't drawn down the page, it's pulled across and up and every which way. The footer is most effective when the content is driving your reader towards it.

Conversely, a big footer is great for text-heavy sites that draw have blocks of text that direct the reader down, down, down. Blogs and newspapers/magazines are the obvious examples.

Before we move on, though, a special consideration for blogs: comment threads get in the way of the footer. If your blog accepts and displays comments by default, your comment thread and comment form at the bottom will separate your content from your footer. Many visitors who are interested in your content, won't read through your readers' content—and won't see the footer on post pages. Plan accordingly.

Amazon addresses this problem by putting a "footer" in the middle of the page, rather than at the end. There's a short block of vital information about the book: title, author, price, if it's in stock, add to cart, etc.— and then: a footer!

Below this is minutiae about the book and then user reviews (e.g. the comment thread). But Amazon wants to be sure people see their footer (links to other stuff you might buy) before you get bored by content they don't control, and wander off to some other website.

Setting Out on the Right Foot(er)

The first rule is contrast. If you're going to have a footer, make sure it's obvious where your content ends and your footer begins.

There's plenty of ways of achieving that, but by far the most common (and most effective) is with color contrast (e.g. as Jason Santa Maria does). Others use lines (like the LA Times) or large white space (the Greg Brady Project). Whatever you do, it should be clear to your users that they're looking at a separate piece of the page.

The same things that make for good web design in general, make a good footer. It's an opportunity to draw your reader in, and suggest to him or her what a likely next course of action might be. Do you want customer contact? Give them a way to reach you. Want them to read your article? Link it in the footer. Do you want people to buy your book? Point them at its Amazon page. Are you soliciting money? Drop in a donate button.

The footer should be part of your overall content strategy—think of it as a generic conclusion to every page of your site. Its job is to tie things up neatly and restate your point (so to speak).

Don't try to cram the footer with too much content. Keep it straightforward and directed. Your footer can give the reader an idea of where you think they might want to go next. Lay out some alternatives, in a clear fashion. Think about which “next actions” you want to include are more or less important, and use contrast, size, and placement to prioritize them to the reader.

Well, that's all for me for now. I'll do another of these... probably next time I've something to put off. I hope you found this useful. And by all means, let me know what you thought or what I've got wrong in the comments.

A Corollary to Merlin

2009-10-22T23:57:45+00:00

Merlin Mann posted a long (long, long) video rant today, following up on a much shorter and funnier one he posted yesterday (note: neither video is safe for work, but the second one is much more egregiously so).

One of the things he talks about (the main point, I think, of his rant) is that there are tons of advice blogs that threaten purport to help you with lots of little bits of information, and that these can be really dangerous because they won't tell you to stop when you've had enough—indeed, it's in their best interest that you go on benders as often as possible.

This mirrors a change in writing that's taken place with the internet. 20 years ago, you'd get your advice from a book, a piece of a defined length which has a beginning, a middle, and an end. The author, in the course of writing a book (if they did it well), starts at one point, walks you through all the things they want you to get through, and ends. By its very nature, the book tells you to, forces you to put it down.

Websites don't do that. They're not like books: they go on and on serving up bite-sized pieces of content for as long as whoever maintains them can keep up the pace, hour on hour, day on day, week on week. It is, in some sense, the nature of the internet to cater to that frenetic "advanced beginner" stage of understanding.

Obviously, the solution (to the extent that this problem needs a solution) isn't to go back to books. But I'd be thrilled to see a format for publishing on the web that abandons the hyper-current pace of the blogosphere for a more careful, deliberate, considered approach, with a beginning, a middle, and an end. The model for the internet thus far has been newspapers, magazines, and periodicals. Maybe we should think about making it like books?

Be Wrong As Often As Possible

2009-10-08T04:13:13+00:00

It's an entertaining rant, but it's the bit at the end—“Programming is an exercise in overcoming how wrong you’ve been in the past”—that's particularly noteworthy.

Insincerity

2009-09-30T03:11:34+00:00

I've been thinking a lot lately about the ways people relate to one another. (I'm perhaps not the best person to be doing such thinking, but, never mind for now.)

How much of our relationships are built upon insincerity—or, rather, the appearance of sincerity? Upon not letting the other person know what we really think? Could we still function without that?

Ricky Gervais has a movie coming out soon called The Invention of Lying, premised on the idea that he's the first guy to figure out you can tell untruths. People spend the whole movie tearing into him, blurting out thoughts about how unsuitable he is as a person. Would anyone stand for that?

Everyone has something to say about everyone else, behind their back. It's a shameful way of being: but I guess that's just life. There's always that moment, though, when all that insincerity snaps. When you find out how someone really feels, really thinks. Usually a fleeting glimpse.

I suppose it's inevitable it usually turns out badly. It's not the nice things that we refrain from saying.

The Man Inside the Window

2009-08-10T15:59:10+00:00

If a man's home is his castle, mine is not a very good one.

Last Thursday, while I was at work, someone scaled the wall behind my apartment building and got in an open window, making off with a number of items. They took a random assortment of objects, from the large (my desktop computer) to the small (a box of cuff links), and many things in between.

It's a disorienting feeling, knowing that your little corner of the world isn't as private as it once was. I've found myself wondering a lot of things the past few days. Some of them are mundane (how am I going to clean all the fingerprinting powder off?) and some of them are practical (what passwords do I have to change for security?).

The biggest thing that nags at me, though, is the question of who this uninvited guest into my apartment was. Was it a he? (Probably.) Was it one person or more? What's he look like? What does he think of me?

It's an imbalance. These are questions he has the means of answering about me. He has all my files, years' worth of photographs, writing, bookmarks, and so on. I often wonder what he thinks of me. I don't know if he's even bothered to switch my computer on. He spent some time rifling through my things. Did he puzzle over a broken pocketwatch? Was he disapproving of my wardrobe? Did he like my taste in art? (Evidently not enough to take it with him.)

I've now got this mystery presence in my life, this person whose life is now connected to mine, who I know nothing about. Oddly, all in all, that's what I find the most interesting, the most disturbing. Whose life have I thus intersected?

Does Gotham Bark?

2009-07-23T18:02:47+00:00

I often protest the ubiquity of Gotham, the beautiful typeface from the foundry Hoefler & Frere-Jones. Gotham's attained tremendous success--and rightly so. Since it became the principle typeface of Barack Obama's presidential campaign, however, it's use has really exploded, from Media Matters to the National Rifle Association, in the ads of Pepsi and the packaging of Coke. Starbucks even picked it up.

I think this is a terrible development.

I was discussing this with a friend the other day, and she didn't quite see what I was complaining about:

—"I object to the overuse of particular fonts," I said, "mostly because I think fonts carry real meaning, and if you start just using one for everything then I'm not sure it means much of anything anymore."

—"What you're saying," she countered, "is that, if something says 'dog,' the font has bark. The typeface has to conform to the mood. I don't think that's necessary."

—"No, I'd say it's more I think the font should be capable of barking (or not barking) at all."

—"I can make Gotham bark for you."

And she submitted this snarling example of Gotham's barkability:

Much gnashing of teeth there.

But what's going on here? Is Gotham really barking? Or is it just the dog?

I think it's a great deal trickier. Gotham is a refined, clean, stripped down font; a warmer geometric with subtle concessions to humanist forms, along the lines of Avenir. It's orderly, restrained, not quite corporate but never unruly. It's just not the barking sort. The dog here, straining its lead and snapping, is barking through Gotham. It's caged by the restraint of the letterforms. That the font does not bark itself makes a statement. It changes the photograph completely.

This is what I mean about wanting typefaces to be capable of barking. A font has to have its own identity for its use to have any effect--as it undoubtedly does in her example. And, indeed, this is obvious. If we could mold every face to any purpose, make it say anything we wanted, then there would be little purpose in choosing one over another. A designer might as well choose at random and then mold the font to their needs. But that's not what we do--and with good reason.

I mentioned, a bit later in our conversation, Times New Roman, a font which through years of abuse has come to symbolize one thing above all else: Microsoft Word. Since it became the default text face in Windows, its statement about the typographer (or, rather, lack thereof) has come virtually to drown out any voice it might have of its own.

Much the same fate has befallen Trajan, which has found use in such a mind-bogglingly wide variety of movie posters and book covers that it now recalls those more than it does the Roman inscriptions from which it is derived, and in movie posters signifies nothing beyond another bland, establishment-endorsed film.

So I'd say Gotham is a font to avoid--not only to help rescue it from such a fate, but you risk having your own message suppressed as the font descends into incoherence. At this moment, the font is in such heavy use as to be a default for any brand wanting a refresh, without regard to the subject at hand. It risks looking more careless than elegant--unless it's used with extraordinary care. And for heaven's sakes, don't bother with it in branding or advertising. Even when it's done very well, it still looks a bit generic.

Above all, I hope Gotham can go on not barking.

Browser Incompatibility 5

2009-07-13T09:45:16+00:00

There's been some contentious debate about the advent of HTML 5, and we're now (with Safari 4 and Firefox 3.5) getting our first go at actually working with it.

I'm sorry to say it's not going well.

Others have covered some of the ridiculous issues the new "standard" has brought, like the video standard-that-isn't and the mess of unnecessary, non-backwards-compatible, semantic tags. I'm going to get into Javascript, here.

One of the key purposes of HTML 5 is to move the browser towards creating richer interfaces. A number of features have been added to the standard. Two I've been working with recently are the drag-and-drop functionality and the contentEditable property. Drag and drop is new; contentEditable is much older (it's a Microsoft invention in IE 5.5 that's slowly spread to the other browsers).

contentEditable

contentEditable turns an element into a rich-text editable element, but the spec on this offers no particular guidance on how to implement the things it's supposed to do. execCommand is inconsistent among browsers, and so is the styling: Safari, for example, tosses in <b> and <i> tags where Firefox dumps in <span style="font-weight: bold;"> and <span style="font-style: italic;">.

Drag and Drop

Drag and Drop is even more bizarre. The spec here is much more prescriptive about how the Javascript behind it should work, but there's still plenty of room for silliness. Ideally, you're meant to just stick draggable="true" ondragstart="/* drag function here */" on a element and it becomes draggable. It works in Firefox, but not in Safari, which requires an extra CSS element(!?) be applied to the draggable items. Moreover, in Firefox, text is draggable, but in Safari, it's not. For example:

This is draggable!

You'll notice in Firefox 3.5, the above rounded box is completely draggable (though you can't drop it anywhere). In Safari 4, however, it's only draggable if you click on the healthy padding—click on the text itself and you're just selecting text instead.

Drag and drop also leaves a lot of mess on the HTML itself: there are a lot of events firing. Shapeshed has a great little overview here.

You'll notice to create a drop zone requires this lovely markup:

<div id="trash" ondrop="drop(this, event)" ondragenter="return false" ondragover="return false></div>

Cancelling ondragenter and ondragover are currently required. That's a bit of a mess. (And all the event attributes! Ugh.)

Firefox 3.5's drag events also bubble in the wrong order: events fire on the lowest elements first, and only then up to the elements they contain. If you stick a dropzone on the <body>, it's the only dropzone on the page that will fire. Ever.

Worse Together

There's a note at the beginning of the "User Interfaces" section of the HTML 5 spec (here):

"Would be nice to explain how these features work together."

Alas, in the case of contentEditable and drag and drop, fact is they don't, at all. I've spent some time hacking the two of them together, and I've come up with something that's almost workable in Firefox 3.5, though not in Safari 4, which (of course) has different behaviors. I worry it'd take me another week at least to figure out the further idiosyncrasies of Safari 4's implementation; frankly it's not worth it as I sincerely hope both implementations will be replaced with something better in a future version--which will render my version broken and useless.

Right now, to drop an element into a contentEditable region in Firefox, you have to parse it to HTML (not actually a trivial task). contentEditable has its own idea of what dragging and dropping is and does and it's got no awareness of HTML 5's new thoughts on the matter, so it doesn't interact in any especially controllable (or sensible) way with the dataTransfer features of HTML 5's drag and drop. In a number of ways, it seems the whole implementation is set to just do what it decides it wants to do and that's that.

In Firefox 3.5, dropping an element on an editable area dumps text/html or text/plain out of the dataTransfer, which is immutable. (It prefers text/html.) You can drop an HTML element this way by rendering it into HTML, and at least this allows you to drop it at the cursor.

Safari 4, by default, does nothing at all when you drop an element into an editable area, which makes it very hard to select a spot in the text for insertion based on the cursor location.

In neither implementations does there appear to be a model for figuring out where in the contentEditable text you might be dragging something in to; Firefox just happens to handle this by default so long as you're doing something reasonably compatible with its basic functionality.

In all, it's a frustrating experience. These new features have a lot of bugs to iron out, and it doesn't help that browser manufactures are happily pushing out products based on unfinished specs that will leave behind inconsistencies web designers will have to plan around for years to come.

Ira Glass On Good Taste

2009-06-27T09:31:56+00:00

This is a great little piece from Ira Glass on taste and creative work. (HT to Dustin Curtis). He's talking about video, but it's just as important for design. It takes a long time to live up to your ambition.

When Not To Roll Your Own

2009-06-25T20:43:56+00:00

One of the questions I face a lot when presented with a problem in web design is this: should I build it myself? Or should I take something off the shelf?

The Web today is full of "time-saving" alternatives to us coding things ourselves. These sorts of tools range in complexity from really simple things, like a little piece of Javascript to make .png files appear properly transparent in IE6, to extremely powerful tools that perform a huge host of functions, like content management systems. Some of them are more popular than others.

What can go wrong?

Well, a number of things. The biggest is that you're taking a risk by using someone else's code. You don't know how it works. You won't be able to modify it without breaching what may prove a steep learning curve. Such things often break in unpredictable ways. People don't set things up the way you expect. You can cause bugs in places you never expected them.

There's a risk associated with using these shortcuts, which you're balancing against the risk that you might not finish the project in time without them.

So how do I choose?

There are a few questions I usually ask myself before I choose solutions like these:

Does it work?

This ought to be a no-brainer, but it's often skipped: before you commit to using something, make sure it does what it's supposed to. (If it's not easy to test yourself, wide adoption is often—but not always—a good indicator of this.)

How long would it take me?

If you're going to use a shortcut, it should at least be saving you time. This is why I don't use CSS frameworks (like the increasingly ubiquitous 960.gs). Sure, it's nice. But I can throw together a custom CSS layout for a site that works as well or better in about the same time it'd take me to put the framework in place and tweak it the way I like it. I'm picky, and it's just not that complicated.

What does it prevent you from doing?

Shortcuts are often limiting. For example, there's a really elegant script called s3 slider, built in jQuery, to make a rotating image/link gallery. It's gorgeous—one of the most elegant examples of its kind, honestly. But it's restrictive. To set up buttons to skip to particular items in the s3 slider, say, you'd have to alter its core functions (which means first going through someone else's code to figure out how that might work).

By contrast, jCarousel Lite isn't as pretty out of the box, but it's massively configurable. It doesn't limit you. It's not that s3 slider is bad: if s3 slider fits your needs exactly, by all means you should use it—but if it doesn't, or if you think your needs might grow in future, you're better off using jCarousel Lite.

Is it extensible?

This isn't always important. In the case of a small element, like the slider managers I discussed above, it'd probably take you longer to learn a plugin architecture for them than it would to just reprogram them from scratch. But when you hit the really big projects, extensibility is key.

Realistically, you'll never hit a content management system or a JavaScript framework (or anything of comparable complexity) that does everything you want it to, out of the box. But it's easy to build a plugin for jQuery or WordPress or ExpressionEngine—and there are tons of plugins already built for them. If you've picked a good system, it'll be saving you so much time that learning the plugin system will still be worth the effort.

In summary...

There are some really great systems out there that have saved me huge amounts of time, like jQuery, jQuery UI, and ExpressionEngine; there are plenty of others, like Google Maps, Google Checkout, or sIFR, which let me do things completely beyond my abilities and/or resources. Plenty of others have proved exercises in frustration.

In general, I'm skeptical of timesavers and tend to want to build my own solutions where and when I can. But carefully selecting smart pre-built solutions can save a whole lot of time.

There's no point reinventing the wheel. Just mind the square ones.

We Love Typography

2009-06-03T05:23:12+00:00

Somehow I've omitted linking this before. From the wonderful I Love Typography comes its communal counterpart, a collection of delightful typography that brightens my day.