Art

• Video: the return of the adorably deadly Mini Cannon (set to “O Fortuna,” no less).
• Miniature Art on the Tip of Pencil by Dalton Ghetti. It’s like a combination of painting on a grain of rice and wood carving. (via StumbleUpon)
• Cool: Art using Rubik’s Cubes as pixels (viaS StumbleUpon and @designboom)
• Where Science, Art and Photography Intersect – 25 fascinating photos done with long or multiple exposures with flames, light, water and more.
• How Star Trek designers envisioned the iPad – 23 years ago!

Privacy

• Just how private is private web browsing? Maybe not as private as you think. (via @AltBrowser)

Scott Pilgrim

• Scott Pilgrim movie trailer recreated with panels from the original comics! (via @radiomaru)
• Scott Pilgrim Versus The Unfortunate Tendency To Review The Audience – If you don’t like the movie, that’s fine…but is it really necessary to insult the people who do like it? (via Comics Worth Reading)

Cool! Readers can see that the link is broken before clicking on it!

But what’s the best way to label the links?

The plugin uses strike-through by default. You are marking something that’s gone, but strike-through usually means the text is being crossed out. That’s fine for a link in a list, but something like “Catering was provided by MyNiftyFoodCo” implies that the name of the company is wrong, not that the website is gone.

Just making something italic or changing the color doesn’t work either, because it’s arbitrary. Nothing about an italic link (which could be a title), or a random other color, suggests that something might be missing.

What I’ve come up with is to reduce the contrast on broken links. It combines two familiar schemes:

• High contrast for new links and low contrast for visited links.
• “Graying out” inactive items in software.

So here, I’ve got bright blue for new links, darker blue for visited links, and broken links as black (well, very dark gray), the same color as surrounding text. I’m keeping the underline in place so there’s still some indication that it’s a link, but it’s not as strong as the label for one that’s still functional.

It’s still not ideal, since color is the only difference, but it should cause less confusion than the strike-through.

First item cross-posted at LiveJournal.

Apparently the design was a big hit as a poster at SXSW.

For those who haven’t seen it, the MDC is a great developer resource for web developers, describing lots of standards along with Mozilla-specific information.

(via Rhian @ SFX, who notes that the image is available for use under the terms of the Creative Commons Attribution-NonCommercial license. These wallpapers are also covered by the Mozilla Trademark Policy.)

• Get rid of the non-working compatibility cruft for Netscape 4 (some of it was actually making things worse in NS4)
• Make navigation easier.

I decided early on that I wanted to move to that old standby, the tab bar across the top of the page. I toyed around with using fixed positioning so it would stay in place like a toolbar, but couldn’t get same-page links to position themselves correctly. I also realized that the tab bar needed something above it, or else it would blend in with the browser’s toolbars. Solution: another old standby, the site logo above the tabs

After trying some more out-there ideas, I ended up with the rest of the page looking about the same as before. Having the logo at the top meant that I didn’t need a giant logo on the main page, freeing up space to add something I’ve meant to do for a long time: Post more obvious links to each of the main Flashes.

Something interesting I noticed: I’m now considering IE6 a second-tier browser. I’m building for IE7, Firefox, Opera and Safari first. I no longer care about minor issues in IE6, just major ones. I realized this when I decided to use an alpha-transparent PNG at the top of every page. Sure, I was able to use PNG Behavior to get it to look right in IE6, but that requires scripting, and it’s not the same as native support. (Now that I have that linked on every page, though, I can use alpha-PNGs anywhere without additional effort.)

I also decided to switch from XHTML, which I’d started using in the 2000 redesign, back to HTML 4.01. The site had never benefited from using XHTML, and HTML still has wider support, so I figured if I was going to be changing code anyway, I might as well take the opportunity.

I posted the new layout last Sunday, and I swear, within 10 minutes someone had sent a comment on it.

Monday was time for fixing bugs. Not surprisingly, the biggest ones were both in IE. They were two related bugs involving floats and italics that had the opposite effect in IE6 and IE7. They were also intermittent, only affecting particular pages and only with certain window sized, which is why I hadn’t caught them before launch.

IE6 encountered the Peek-a-boo Bug. On certain pages, text next to a floated image would not appear. IE7 encountered another disappearing content bug, in which the floated image itself would stop displaying below any line with italics. (What is it with IE7 and weird problems with italics?) It turned out both could be fixed by setting width or height on the article DIV, instead of letting it take the size of the container (which includes the footer), so I just made it 97% (since 100% confused IE6 even more) and had done with it.

Finally, I’ve added some enhancements for certain browsers using experimental CSS3 features. People visiting with Firefox or other Gecko-based browsers will see rounded corners on the tabs (it looks much better than the square-cornered version, but isn’t necessary), along with people using nightly releases of Webkit (with any luck, the feature will be in the next version of Safari). Really neat was box-shadow, so far only in Webkit. I was finally able to add the drop-shadows to the article and sidebar the way I wanted to back in my last redesign in 2002! I’m looking forward to seeing other browsers implement it.

• Bugs or “missing” features in the new browser (whether incomplete support in the new browser, or proprietary features in the familiar browser).
• Broken code on the website being handled differently.
• Different defaults where behavior isn’t well-defined in the specifications.

A big problem is that when you get into the code, a lot of pages aren’t as specific as the authors think they are. When you write code and test it on one browser, you’re not testing that the code is correct, you’re testing that that browser makes the same assumptions you do.

It’s like ordering pizza.

No, really. Let’s say Internet Explorer specializes in Chicago-style pizza, with a thick, chewy crust. And let’s say Firefox specializes in New York-style pizza, with a thin crust. But each can make the other style of pizza on request.

So you call up Internet Explorer and ask for pizza. They deliver you Chicago pizza, and if that’s what you wanted, you figure your order is fine. If you actually wanted New York style, you make sure that next time, you tell them you want that style of pizza.

But let’s say you like Chicago pizza. You get used to calling up IE and just asking for “pizza,” until one day you’re busy, and ask your roommate to order it. He likes to get his pizza from Firefox, so he calls them up, asks for “pizza,” and you get New York style. That’s not what you wanted. Obviously, Firefox pizza is inferior, because they got the order wrong! Well, no, it’s not, and no, they didn’t. They delivered what they were asked for. If you’d told your roommate to ask for Chicago style, Firefox would have been perfectly happy to deliver that style of pizza.

The moral of the story: always be specific with your code. Make sure it’s asking for what you think it’s asking for (validation helps here). And if something doesn’t do what you expect, make sure you didn’t leave that expectation out of your order.

See also: No, Internet Explorer did not handle it properly

(Expanded from a comment I posted at Mozillazine.)

What I like about this is that it manages to get the idea across clearly even though it doesn’t use the actual Windows name or logo. “Win” is enough to get the name across, and the overlapping colored rectangles immediately call to mind the look of Windows 2000, Windows Me, and Office 2000. Sure, it’s one redesign back, but it’s still recognizable.

As for why they made their own logo? Well, it’s all hardware, with no drivers needed, so there really isn’t any point in putting it through the OS compatibility tests. You might as well label a monitor as being “Designed for Windows.” But not everyone knows what is and isn’t OS-dependent. Even those who do are more likely to buy it if they have that reassurance. I’ve looked at devices that I was 90% certain should work with any OS, but bought the one that specifically mentioned Mac or Linux compatibility because it filled in that last 10%.

Of course, even if you don’t recognize the specs, you can identify them easily by the column headers:

• Opera is red
• Browser 1 is blue
• Browser 2 is orange

Hmmm….

Interestingly, I’ve got a project I’ve been working on off-and-on for a couple of weeks, and I’ve already put together a design using just color to represent different browsers.

It looks like I may have been on to something.

Update August 8, 2005: Apparently there are countries in which it is illegal to mention a competitor by name in ads, which might explain the tactic. Also, Opera has taken down the page, replacing it with a note that “This page is under development.”