Concept your design on paper is the single most important step to begin with. Draw it out. Scratch what you don’t like. Redraw it. Think ahead about the models and controls while you do this too.

This page is a good example. Even something simple like creating a tool to reconcile records across to tables needs a plan of action.

Step 1

Step 2

Step 3

Profit!

Zeus’ flagship feature was its checklist. The checklist was an itemized form of everything that was shipping that week. Customers could fill out the form and notify the store which items they wanted to pick up on Wednesday (when comics book typically arrive). And as far as I could tell, Zeus was the first store to offer this feature. I’ve seen some crop up here that there, but they were largely static, cumbersome to use, and were constructed out of tables.

Three things: customers noted that it wasn’t the greatest for mobile devices, and a digital comic publisher had a mobile app that customers were using in lieu of our checklist, and most importantly customers couldn’t tell which comic book they wanted by name alone. Often they would have to go to the store and pick up other titles they missed.

We’ll do it live!

While I’m already building a long list of bugs (bandwidth being a whopper), I certainly like the results so far. It’s already in my opinion a better solution than a the iPhone app offered (which wasn’t even usable on iOS4 for several weeks) and future updated to the web app will hopefully offer customers an optimal process in shopping with Zeus Comics.

But I would propose something different entirely. Instead of using a js library to help browsers properly render a soundly constructed html5/css5 webpage, short of making sure it doesn’t look like “total ass” on IE, just let the page render as it lay.

By now, web designers are largely aware of the rendering quirks of various browsers. Little things like not adding margins to floating divs for IE’s sake, or not applying –webkit gradients to divs that contain text fields, are a part of mental mine field map that goes into our work.

Using a javascript library to get around this isn’t the answer. Remember that script that lets IE6 properly render PNG transparency? It might have been relevant to a couple of years ago when there were still a vast majority of users that used IE6, but most web designers have abandoned even trying to support the browser, much less trying to make every pixel line up properly or make every image look decent. At some point (if our bosses let us), we move on.

Sadly, we moved onto other scripts that do what html5 is supposed to do already.

Here’s my advice. Write your site to work just fine without any javascript (or css for that matter) needed. If you can still use the site, you’re good to go. Using ajax history to browse back and forth with the browser chrome? Make sure it works without javascript and move on. If you’ve got some killer CSS mojo for your site, just write it. Write that widget that does that thing with the stuff, but to say that we have to cover every contingency is unreasonable.

When did we go from saying “to hell with bad browsers” to using libraries to keep these browsers on “the same page?”

Older browsers won’t go away (I still see Netscape occasionally show up on Google Analytics), but the support we give them can.

I like to look at these barbaric browsers like the Klingons in Star Trek XI. Their survival was in jeopardy and Kirk was having none of it. Eventually, he came around and now we’re stuck with the Klingons and their foreheads forever.

Don’t let this happen to bad browsers. Let them die.

1. Links

• Stop Forking With CSS3
• Taking Advantage of HTML5 and CSS3 with Modernizr

Seriously, if YouTube accepts .wmv, .avi, .mkv, .mov, .mpeg, .mp4, .flv, .ogg, 3gp and outputs to multiple .flv, mp4, 3gp… OMG, why then is the link I just tapped not available?

I understand that once uploaded, videos take time to convert for display. Having uploaded some from my own iMovie library, waiting for YouTube to do its magic without a progress bar is torture. But once it’s done and properly playing on the website, the video still has to become available for HD (if available), mobile, etc.

As we become more connected on more networks on new devices, our content experience should become more homogeneous. Websites should get closer to looking the same on our desktop computers as they do our mobile devices. Instead, because of mobile phones and netbooks (more specifically, their wireless connectivity) web designers, who once enjoyed building for higher display resolutions and bigger bandwidth, find themselves thrown back into building sites that are “dial-up” friendly. It’s a whole new browser war sans Netscape Navigator.

Which brings me back to YouTube on the iPhone. Video codec H.264, briefly put, is designed for both high-def and small bandwidth playback. Since YouTube offers multiple versions of the same video, it has to take the original video upload and convert it several times. And since the only way to view YouTube on Apple TV or the iPhone is with h.264, YouTube needs to make additional conversions/transcodings.

In the end, content for the web isn’t just for the browser. It includes phones, game consoles, dvr (TiVo), and any future devices we don’t yet know we need. And all of them need the same content in their own specific formats.

All of this means that the next time I see something along the lines of “@amboy00: too funny! http://tinyurl.com/pqhugm,” I’ll probably have to wait until I get back to my desk to see the funny.