futuraprime:blog

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?

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.

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.

Happy Towel Day

2009-05-25T16:24:13+00:00

the full quote →

In the event you've never heard the original radio show, or read the books, you should do that. Now.

Happy Towel Day, everyone.

Twitter Explained

2009-05-10T15:56:34+00:00

I have often been told, usually with a certain air of self-satisfaction, that Twitter will not replace the newspaper. (Well, okay, maybe The Guardian.)

This is sort of like saying that rollerblades won't replace the family car. It totally misses the point. Twitter is not destined to be the next iteration of reporting. Or blogging. Or searching the web. Or Facebook. That's a complete misunderstanding of what it does.

Join the chat room!

Twitter's most reasonable analogue, if you must have one, is something like IRC. It's a place where people can come and have a chat in short bursts. The other similar invention of the early web is Usenet. (Of course, both these things still exist; on the web, nothing ever quite dies.)

There are, however, a couple key differences that separate Twitter from its antecedents. First: Twitter is fundamentally open. There aren't rooms or groups on Twitter. The only closed parts of the system are users who make their posts private (in which case, only people they allow can see their feed), and direct messages, which are fairly incidental. If someone tweets about, say, Expression Engine, someone else can search for that and find it. (Even better if they use the hashtag #expressionengine or #ee, which people use to unify all the tweets on a given topic.) Many twitter clients let you run and observe searches like this in near-real time.

The second big difference is that you only see what you want to. Twitter can't be derailed the way IRC or Usenet could. There's no need for moderators. Your main feed is pulled from the people you choose to listen to. If you don't like someone's tweets, you can always unfollow them. People needn't "play nice," because there's complete separation.

So what?

That makes Twitter exceptionally useful -- if you're in one of those groups (like web technology or politics) that's adopted it broadly. You end up very quickly coming into contact with people who have the same interests as you, because they're searching for the same things on Twitter, or monitoring particular topics on Twitter that are important to them. It's all a very cool way of making conversation across great distances, and it accomplishes it in a way that its closest relations don't, because of its open, casual nature. All in all, a brilliant invention.

Know What You’re Saying

2009-05-06T12:56:36+00:00

I like graphs — they're a wonderful way of conveying information. I love to make elegant, communicative data graphics.

So when I see a bad one, it ticks me off even more than most poorly-done things do.

Apologies in advance to the Center for Public Integrity, therefore, who put together a lot of data on the mortgage crisis in a somewhat clumsy and confusing manner. Most of what they've done is imperfect, but serviceable. (In particular, the heat maps they rely on are not especially communicative.)

But I got to one graph that was particularly poorly done, and frankly misleading.

That's this graph:

Let's start by looking at what this graph actually shows. There are two lines here. The top line (in red) is the median value of a mortgage originated in that year (in inflation-adjusted dollars). The bottom line (in yellow) is the median income of the people who took those loans. Fair enough as a basic, first order approximation of what's going on — this is showing that loan size grew out of proportion with income.

It's as soon as we get to the framing that we run into trouble. The graph says "In 1994, $73,000 was the annual median income for a loan of $120,000." But that's not at all what the graph is showing — the graph is indicating the median income vs the median loan amount. This data isn't (and can't) give any indication of the distribution of these mortgages. Loans of $120,000 might have been going to people with higher than median incomes, while more expensive loans went to people who were less risk-averse and had lower income. They stretch this a little further with their next sentence, but it's the same basic objection, that they've not presented data about the distribution.

Where this graph truly loses it is the title, which is entirely misleading. The graph is entitled: "Increasing Percentage of Income Goes to Housing." But that's not at all what this graph shows, and moreover this obfuscates a critical point about the way the mortgage crisis played out. Mortgage brokers regularly sold graduated payment or balloon mortgages, which start off with much smaller monthly payments and incur much more expensive ones or require refinancing later on; in many cases, when the monthly payments went up at the end of the initial grace period, homeowners bailed on their mortgages, contributing to the crisis.

As a result, the size of the principal (the total amount borrowed) is not a good indicator of the amount of income actually being spent on housing. It's a virtual certainty that monthly payments track income more closely than loan size, and it's possible they track much more closely. It's really key that a lot of these loans defaulted because people were signed on to loans they never could have afforded, but were never required to bear the real cost of those loans.

Let's make it better

There's three ways they could've made this graph better.

First, they might've supported the point they do in the explanatory text, and shown the median loan amount for a band of income (or particular bands of income) over time. Seeing the average loans granted to people making $65-70K, $70-75K,$75-80K, etc. (or using quintiles) would make the distribution clear and let us know if loan size really does track income. It might be that (and it would be very interesting to see if) low income households increased their loans much more than median income families, for example. This would be a much more informative graph, though a little more complex.

Second, they might've just substituted monthly mortgage payments (and monthly median income) into the graph in place of the variables they have now, which fits the title.

Third, they could have shown three things: monthly median income, monthly median payment, and monthly payment as a proportion of principal. This both conveys the point in the title (people are spending more on housing) and that people are taking out loans far beyond their means. That's a graph worth looking at.

If I can get my hands on some data I may try making one of those this weekend.