• filed under
• Graphic Design
• Life
• Writing

Someone pointed me at Natalia Ilyin’s brief rant about how designers can’t write—but, worse, believe they can anyway. It reminds me of the endless string of self-help books and slogans we’ve seen over the last several years—things like The Secret—that suggest if we only believe in ourselves, the power of positive thinking will carry us through.

This is bullshit.

And it’s not just bullshit for the big things, like cancer, but for the little things, too, like writing ability. Believing you’re a good writer (or designer, or marathon runner) won’t make it so.

Instead, I recommend my new, patented technique for self-improvement: The Power of Negative Thinking™.

It works like this: look at your work, what you’re doing, how you’re doing it, and focus on what about it sucks.

Chances are, you can find a lot. Absorb your work’s flaws. Study them. Learn them. Look at how other people, people better than you—which is near everyone, right? remember, we’re looking at the thing you suck at—dealt with those areas.

Now, next time you do that sort of work, pay attention to those flawed areas. That’s where you need to improve. Learn from the other people (people better than you). Do it better.

Once you’re done, look at your work, and focus on what about it sucks. And so on.

That is how you get better at something. If at first you don’t succeed, suck, suck again. Eventually, you’ll suck at something else instead.

But why listen to me? I suck at this, too.

• filed under
• Interface
• Technology

I’ve read quite a bit of speculation lately about the Apple Tablet. For some background reading, try John Gruber, John Siracusa, and Marco Arment; or, on the skeptical side, Joe Wilcox—who I’ll start with. I don’t usually make predictions like this, but I feel like I’ve got a good handle on this one so I’ll jump out on a limb.

Wilcox points out “that the company [Apple]’s most successful products pushed into established markets, even if marginally created.” The iPod joined the universe of portable audio players and the moribund market for mp3 players. There were billions of cell phones before the iPhone, and “smartphones” were already a recognized category. Tablet computers, by contrast, are few and far between; a “niche category” for which there’s little market.

But he’s missing the point. Apple products aren’t (contrary to popular belief) defined by what they look like, but what they do. An “Apple Tablet” won’t be a tablet computer, it’ll be a computer that is a tablet. The market they’re probably aiming at is regarded by many as quite vital: netbooks. Specifically, this is aimed straight at Chrome OS.

Gruber goes on in some detail about how he thinks the product will be transformative; I suspect he’s mostly right. Google (and others plan to build netbooks/tablets that are based entirely on the browser. An Apple netbook building on the CocoaTouch community offers a great deal beyond “just” web functionality without sacrificing the simplicity of something like the iPhone OS (or Chrome OS). It can be a netbook, an eBook reader, a portable video player, and anything else an enterprising software programmer can think up, all in one device—indeed, as the iPhone already almost is.

To me, there’s two big ifs. The first is 3G support: If Apple could snag the sort of internet anywhere deal the Kindle has, that’d be amazing, but even with a monthly plan it would be an impressive offering. Let’s hope it can work off AT&T’s network, though. If the iPhone alone is bringing them to their knees I’d hate to think what this might do.

The second is data entry. The likeliest method for this is an onscreen keyboard, but that still seems fundamentally inelegant for a tablet, which (unlike an iPhone) would probably be too large to comfortably hold and type on at the same time. Apple’s had Inkwell sitting in the closet of OS X for a long time now. Maybe they’ll ship it with a stylus? Or maybe I’m just too fond of handwriting.

Anyhow, that’s my two cents. Thanks for reading.

• filed under
• Flash
• Web Design

I’ve seen the meme that “Flash is dead” made increasingly often lately (e.g. here), and as someone who works with Flash on a regular basis, I wanted to address it a bit.

Flash is (should be) enjoying a much reduced presence on the web in future: technologies are coming into general use that dramatically reduce the places where you’d need to use it.

The Flash Site

Fully Flash sites, featuring piles of animations and visual effects were one of the first cases of Flash on the web (I’ve done a few). They’re especially popular with ad agencies and design companies that don’t know the web very well (or haven’t updated their site in a while). For this sort of stuff, we can really stop using Flash.

The effects that are possible with Flash that’d you’d want to use (moving/scrolling elements, sliders, fading in and out, etc.) are easy to do with jQuery/jQuery UI or prototype/scriptaculous or a half a dozen other JavaScript libraries. The sorts of things that aren’t feasible with this arrangement are generally things that shouldn’t be done or are just showing off (the latter of which is fine if you’re a Flash design agency, as 2advanced is). For almost anything that resembles a website, a standard HTML/CSS/JS stack should really be able to suffice.

Why not make a Flash site anyway? They’re slow to load, slow to run, hard to make properly accessible, bad for search engines, and just generally a pain. Also, they’re typically bastions of non-standard interfaces. After all, if you wanted a standard website interface, why would you be using Flash in the first place?

The Web Application

There are a number of (usually graphics-intensive) web applications that run based on Flash, like the Aviary suite, or Photoshop.com. Adobe’s Flex framework is really aimed at building web applications, though it has broader uses as well.

This is an area where Flash is losing ground. JavaScript-based web applications are becoming more and more capable, but for graphics manipulation, support in JavaScript really doesn’t exist yet. (The outlines do, via <canvas> and SVG support, but until IE picks up one or both of these, it’s still not there yet. More on this later.)

Flex does have another advantage, which is Adobe’s AIR environment, which lets Flex apps (like TweetDeck) serve equally well on the desktop or in the browser. There are alternatives to this (most notably, the Cappuccino framework and its Atlas IDE, and some mobile platforms (Palm’s WebOS and the iPhone) allow web apps to run as or emulate native functionality. But for the moment, AIR is the only such environment that’s cross-platform across desktops and on the web (though, notably, not on the iPhone).

Games

It’s possible to do some limited games using only HTML/CSS/JS, but in general, graphics-rich gaming is going to be the province of Flash for the foreseeable future. It’s technically possible to do some serious stuff with Canvas—but the amazingly lousy support IE has for it hampers performance far too much for serious games. And, frankly, the Flash games community is so large that I’d expect it to be one of the last communities to adopt an alternative approach.

Interactive Graphics

Much like with games, lack of Canvas or SVG support in IE limits what’s possible with interactive graphics (maps, charts, tables, etc.). A rich graph like this one would be nearly impossible to make work, and work cross-browser, without Flash. Like graphical web applications and games, this is waiting for Canvas and SVG support to become richer and more widespread.

Font replacement

sIFR is probably the most common font-replacement technique on the web now. There are JavaScript alternatives like Cufon, which relies on SVG (sensing a trend?) or FLIR, but Cufon isn’t cross-browser and FLIR generates non-selectable text (images).

There’s also the @font-face CSS system, which is facilitated by services like Typekit, and unlike sIFR (or Cufon or FLIR), its feasible (even encouraged) to use this on body text. However, there are licensing issues, font format issues, browser adoption issues, FOUC issues, and more. Take a look at Nice Web Type for some more information.

Video

Flash runs most of the video on the web, including every major video sharing site (YouTube, Vimeo, Viddler, etc.), not to mention Hulu. HTML5 included this nifty <video> element that was supposed to make Flash video on the web a thing of the past. Unfortunately, the whole thing got mired in the codec wars, and Microsoft has yet to give any hints of whether they’ll support H.264, as Apple and Google advocate, or Ogg Theora, as Mozilla and Opera want—or if they’ll stalk off in a huff and tell everyone to use Silverlight.

In the meantime, supported video codecs will be officially unresolved in the final definition of HTML5, and so long as Firefox can’t adopt H.264 (its patents don’t expire for another 15 years) and open-source alternatives remain prohibitively poor*, we’re stuck. Which is to say: Flash video is here to stay for the foreseeable future.

So what have we got?

For web design, Flash is toast. We shouldn’t be seeing fully Flash sites in almost any cases. For graphics-rich content—some applications, most games, many interactive graphics—Flash is still clearly the way to go. sIFR, though a royal pain to use, is also still often the best option for font replacement (more fonts can be licensed for it, more browsers support it). And for video, there’s not even a probable replacement in the works. Even in cases where a replacement exists, cross-browser issues are going to plague it for years to come, whereas Flash comparatively just works right everywhere (assuming you can get it to work).

Regrettable as it is, Flash isn’t going away.

---

*from the Ars Technica article: “If [YouTube] were to switch to Theora and maintain even a semblance of the current YouTube quality it would take up most available bandwidth across the internet,” according to a manager at Google. If true, that’s prohibitive.

• filed under
• Print Design
• Web Design

Aisle One has a great article about the utility of grid systems today. You should read it. It pokes holes in a lot of silly misconceptions about grids.

I want to explore one of his points a bit more, though. He talks about the idea that “grids can impede creativity.” That’s false, for sure, but I think it’s particularly important why it’s false. Ellen Lupton (who he quotes) puts it this way: “To say a grid is limiting is to say that language is limiting, or typography is limiting.”

All of these things are, indeed, limiting. But they are limiting in helpful ways. We observe rules of language because, having agreed upon them ahead of time, they help us ensure we are not misunderstood. The rules of typography have been developed over centuries of printing (and calligraphy) to aid the human eye in clearly reading and interpreting letters on a page.

That’s not to say no one breaks the rules (of either English or typography). But to do it effectively requires extreme skill, because you’re working without a net. A master writer may violate a point of grammar or use a word incorrectly because it lets her tease more meaning out of it, rather than less; a great typographer may set text with intentionally irregular spacing or on top of itself or other lines to achieve an effect. But for most people, and in most cases, it is better to follow the rules.

So it is with grids. A grid system is extremely flexible, but it provides constraints that promote good design. It encourages hierarchies and prioritization of content, standard sizing of elements, and a good, clear flow to the work. To the extent that a grid limits you, it mostly prevents you from doing bad things. The grid frees you to be creative without having to worry as much about those things. That’s an unalloyed good.

• filed under
• Web Design

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.

• filed under
• Life
• Writing

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?

• filed under
• Life

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.

• filed under
• Life

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?

• filed under
• Graphic Design
• Typography

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.

• filed under
• Browsers
• Javascript
• Web Design

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.

• filed under
• Web Design

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.

• filed under
• Typography
• Life
• Writing

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.