We’re working on another project for a magazine, and as we’re laying out content pages we’re having to address the (admittedly minor) issue of how to display photo and illustration credits.

On most news or magazine sites, like Newsweek or the New York Times, when an article has a photo or illustration, they have to identify the owner of the image — not always the creator of the image, but often just the rights-holder.

Annoying.

The way these credits are usually presented within a web site bugs the heck out of me. As a consumer, I don’t care at all who owns the image I’m looking at. I just want to take it in, and the captions are almost always a distraction to me.

In fact, I have a hard time imagining that they add anything significant to most readers’ experiences — except to the one-in-a-million visitor who is interested enough to want to track down the owner of an image for their own purposes.

I understand that rights-holders require some sort of recognition, and I stipulate that providing the information — even if only for the sake of that one-in-a-million user — has some small value. That having been said, I propose that user experience should trump the irrelevant-to-most indication of who owns a particular image, at least in its current format.

The Back Story

The usage rights of images that are published, whether online or in real-world publications, is rarely straightforward. Even though a publication has commissioned a photo or an illustration, it doesn’t mean that they own that image outright, and it doesn’t even mean that they can publish the image in whatever medium they choose — or even for as long as they choose.

For example, a magazine may commission a freelance photographer to take photos of an event. The publication needs to negotiate ahead of time with the photographer what rights they will have to the photos, whether they are just for publication in the magazine, or if their usage rights extend to digital (i.e., the magazine’s web site). Of course this usually happens pretty swiftly — there are standard contracts for this kind of thing. The magazine could buy the photos outright, but this is usually much more expensive, and not worth it to the publication unless it’s a major event or topic that will have long-term interest.

The practical outcome is that the images you see are rarely owned by the people publishing them, which is why most of the time there will be some credit text near the image, letting you know who actually owns it. (Or, probably more accurately when you really get down to it, letting you know that the entity publishing the image doesn’t own it.)

A Modest Proposal

We have to have the credits, we’re agreed, but let’s hide them until the user interacts with the image in some way, like mousing over the image in preparation for clicking it. Then we can present the image credits to users who are much more likely to be interested in them.

And, hey, as long as we know this about them, there’s no need to restrain ourselves regarding how much information we choose to show, and how it appears. (Nothing except good taste, of course.) We can take up even more space with our appearing/disappearing element and offer much more information than we normally would.

(The examples to the left are my idea of what would happen when a user places their cursor over an in-content image; the second being a thought toward making the credits even more useful for those who are interested in them. Does direct access to the source image hurt any rights owner’s bottom line?)

There is a Value Add to be Had

To my mind this benefits every single party involved:

1. the General Readers benefit from a less-cluttered reading experience;
2. the Interested Readers (who want the credits) gain exactly the same benefit, but still have access to the information they may want;
3. the Content Publisher benefits from increased reader satisfaction brought on by a less-cluttered design;
4. the Rights Owner benefits by only having their name revealed to people who can be said to be at least minimally interested in the image presented, plus (and this is a stretch, but it matters to people), by not having their name visible everywhere, they drop the risk of being constantly and directly related with an annoying design feature.

Thanks to Twitter and Facebook, the number of people creating and sharing online content is going up (and up and up), which naturally means that the relative technical sophistication of the general population of contributors is going down. But the one thing you absolutely need to provide every time you share a piece of online content is the URL — a fairly technical piece of text that tells a web browser where to find the piece of content you’re sharing.

I would hazard to guess that most people who consider themselves savvy web users know what a URL is, and might even be able to tell you what it stands for (Uniform Resource Locator). We also probably know that a URL is what’s displayed in the address bar of our browser (whether we ever actually enter a URL in the field manually or not).

The less savvy users among us often aren’t aware of the address bar at all — or, to be fair, they can probably see the field, but they don’t know what the text in it means, much less how it can be manipulated to take them to sites they want to visit.

Counterintuitively, the problems that arise when sharing URLs usually don’t come up when dealing with less-savvy users. There’s a pretty simple reason for this: The less-savvy users aren’t using the address bar. They are using tools that have been provided expressly for the function of sharing content.

Stated another way: The users who use the tools designed expressly for the task of sharing content aren’t causing as many problems as the users who know how (and like) to do it themselves.

So, what’s the issue with savvy users? My guess is that the biggest problem is we move too fast, and we forget that the URL we’re copying and pasting from the address bar may very well not reflect the state of the page as we’d actually like to share it.

Here are a few sample cases I’ve identified:

(For the record, I’ve seen mistakes like these made on many different kinds of sites, from high-profile news sites, to commercial blogs, to popular web communities of long-standing.)

1. Inadvertent Deep-Linking

You’re reading an article about YouTube’s legal problems on Slate, and you decide to share it. You copy and paste the URL from the address bar and write a fantastic blog post about it:

http://www.slate.com/id/2249124/pagenum/2

The problem?

The URL you just shared reflects the fact that you just finished reading the article, and anyone who follows it will be taken to the last page. Sure, it doesn’t take much effort to find the article’s navigation and head to the first page, but it sometimes causes a moment of confusion as the reader realizes they’ve entered an article through the wrong door. (Or, even more annoyingly, they might not notice at all, and miss the fact that they’ve only read part of the article.)

The giveaway?

If the URL makes reference to a page number somehow, chances are very good you won’t be linking to the first page.

The fix?

You can either head back to the first page and copy the correct URL, or, more simply, you can edit the URL you already have by removing the pagenum/2 (or similar) portion of the URL. In most cases you could probably just change the 2 to a 1, but sometimes sites start counting their page numbers at 0, so you aren’t guaranteed to get the result you’re looking for.

2. The Accidental Anchor

You’re reading about the Large Hadron Collider on ScienceBlogs and you click through to read the comments on the post. It’s a great post, so you hit your is.gd or bit.ly bookmarklet and shoot it out to the Twitter-sphere:

http://scienceblogs.com/startswithabang/2010/02/looking_for_new_laws_of_nature.php#comments

The problem?

The URL as sent will automatically jump the reader down to the comments portion of the page, requiring whoever clicks it to scroll back up to the top of the page if they want to read the post. (Or, worse, they will already have started reading the blog post before the page fully loads, and then the browser jumps down, totally interrupting their reading experience.)

The giveaway?

If the URL you’re sharing has a hashmark in it (#) it’s very possible you’re linking to an anchor point that will jump the reader farther down the page than you’d prefer.

The fix?

Eliminate everything after the hash mark and you’re good to go.

The caveat:

It’s becoming more and more common to use information after the hash mark for other purposes, for example, a photo gallery’s main page may be located at this URL:

http://thefarmonadderley.com/index.php/galleries/gallery/type/the-farm/

… but since the gallery is powered by javascript, it uses the information after the hashmark to indicate which photo to load first:

http://thefarmonadderley.com/index.php/galleries/gallery/type/the-farm/#4

If your intent is to link to a specific photo, you obviously need to keep the hash mark, but it’s something you need to consider before quickly dashing off your Tweet: Should the information after the hash mark be there?

3. The Session- or Context-Specific Link

Some web sites or applications pass information to themselves via the URL, including a very popular one. Say you simply must share the latest Danielle Steele novel with your book club pals. If you found the page via Amazon’s own home page, the URL you end up sharing may look something like this:

http://www.amazon.com/gp/product/0385343183/ref=s9_simh_gw_p14_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-2&pf_rd_r=05THFNDRZ3KKPBVZ518Q&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846

The problem?

For our purposes there is a ton of unnecessary information in that URL, information that is only useful to the web server and not at all useful to the visitor. As we like to say, the URL isn’t very human-readable.

The fix?

It will be different for every site, but in Amazon’s case everything from /ref onward is unneeded by us and can be eliminated, leaving you with this:

http://www.amazon.com/gp/product/0385343183

Which, admittedly, isn’t a very human-readable URL. Fortunately, Amazon does something smart. If you search Google for the title of the book, you are directed to this URL:

http://www.amazon.com/Big-Girl-Novel-Danielle-Steel/dp/0385343183

… which, while it still has numbers that mean nothing to you and I, it also has the title and author’s name of the book. Much friendlier.

Anyway. That’s my little rant about URL sharing. Was it worth a thousand words? I’m not sure — but I feel better.

I have way too much stuff.

My old apartment was huge, in retrospect, especially for just one person. There was a lot of storage space, so I never considered not buying something because it wouldn’t fit in my apartment.

This has led to my current situation of trying to move into a new place with at least 33% too much stuff.

Anybody want a coffee table?

I have picked up some new projects since last I blogged — one for a start-up non-profit in Brooklyn that aims to improve science education in public schools, and one for a large, well-known publication trying to bring their web site into the new decade.

The budgets for each are very different, and my role on each is very different; each will be both easier and harder than the other.

But both of them are very cool, and I’ll get around to telling you about them some time.

The new facebook sucks> NOW LET ME IN.

I WANT THE OLD FAFEBOOK BACK THIS SHIT IS WACK!!!!!

I was just learning,why would you mess it up?

This event is likely to be remembered for a long time as the moment when we (the “savvy” users) were reminded of how ignorant many users are about the general workings of their web browsers, and the web in general.

And that Facebook is the new walled garden.

12 hours after the snow started, I’m looking down on clean streets and a light dusting of snow falling.

Maybe it’s just because I’m from Wisconsin, but I don’t think so: we got our knickers in a twist over this?

It’s a beautiful day, but it was quite brisk out, and if you haven’t been there, Republic is a very open restaurant with lots of concrete and flat surfaces. I’ve only ever been there in the summer, and it has always been very cool on the interior, which perfectly suits the fresh food on its menu. The restaurant in my mind has always been a cold experience — as I pictured it in my head I had a hard time integrating the desire to eat good noodles with the desire to not be cold.

In the end we decided to eat noodles, and Republic defeated my expectations by being incredibly warm on the inside. Not just warmer than I expected, but distinctly warm, with the prominent sound of a heater working hard to fill the big space with heat.

Part of me wonders if this isn’t a deliberate choice on their part, to counteract the impression of a cool interior space by overheating it just a little. One practical side effect is, being so warm, the diners are free to choose from the entire menu — I had expected to have to restrict myself to the hot items on the menu so as to counteract the coldness within myself.

We’ve installed some mobile-browser-sniffing PHP so that iPhones, Blackberrys, et al, will automatically see this version of our site. And, in a nod to best practices, there is a link at the bottom if you would like to return to the normal site.

For the moment, the site is formatted specifically for the iPhone. We’ll be working on making that a little more flexible.

IE6 is hanging on for one reason: Corporate IT environments. IE6 is the product of a Microsoft that, in 2001, was still trying to monopolize the web — not necessarily the content of it, but the creation of it. This was also right around the time the web was embraced as a way to decentralize information, and a lot of very big companies dedicated a lot of resources to building tools that may have been “web-based” (and therefore decentralized) but used proprietary technologies and coding techniques that made them inaccessible to anyone not using a browser that didn’t support these non-standard means.

Not such a big deal in 2001, when IE had clearly won the browser wars of the 90s, but a very big deal now. Users are much more aware of their alternatives and seemingly much more comfortable making a change. (The incredibly speedy rise in the popularity of Google’s Chrome speaks loudly to this.) They may not know why we as developers prefer one browser to another, but finally the experience of using a better browser is winning users over.

Yesterday I went to see the Frick Collection with a friend. It’s this particular friend’s favorite museum and I had never been; I have to say that I was blown away.

What makes the Frick special, is that unlike most museums, it is simply one man’s collection — the art he collected throughout his life and the house he built to display it. I say “house,” but the building takes up an entire block of Fifth Avenue, across the street from Central Park. (The lot cost five million dollars when he bought it in 1913.)

There are some incredible individual pieces, but the entire experience is amazing. It’s curated as a collection, and the house looks and feels much like it did when he lived in it, so it has an intimate feel that you never get from The Met or MoMA. Additionally, they offer free hand-held audio guides, which are extremely well done. Listening to the staff talk about the works enhanced the experience 100%.

I highly recommend it.