Been pretty busy working at Ext over the last month. This high-quality photo by the illustrious William Wilkinson captures my mood, and the elusive David Kaneda, perfectly.

View photoset of the Ext office on Flickr.

As much as the device has saved us in terms of time it has added in mindless clutter.

That’s why I’ve stopped downloading apps for my phone. There is simply too much stuff, and I find myself constantly fiddling with settings instead of simply using the damn thing.

It’s also why I don’t use a case. The iPhone is a breath-takingingly beautiful device, but bottom line a phone is a tool, not a jewel. The first generation iPhone is incredibly durable, and in my opinion the scuffs and scratches enhance the character of the device.

I want a device that looks timeless in the way of a watch or a wallet. Something with material that ages well, doesn’t require a lot of maintenance, and accumulates character with age.

Instead of working for them, make them work for you.

If you discuss this topic with friends, I recommend using the short URL: http://jwr.cc/x/42.

The obvious starting point is Jeffrey Zeldman’s Designing with Web Standards. Originally published in 2003, but recently updated to the third edition with new sections on HTML5 and CSS3, the book offers a history of the pains people fought to establish Web Standards and why they make your job easier. Zeldman’s book will have you peppering your speech with words like “semantic,” “validate,” and “effing tables.” Not only that, but you can ponder the imponderable: Why does he wear that silly beanie? Check this book out and you might just have a new hat to show off next November 26th.

After all the standards introduction and theory, I highly recommend a few books by Dan Cederholm of SimpleBits. Dan provides thoughtful solutions for common visual layout issues. Zeldman says himself, “Dan is no standards zealot. He’s the guy in the trenches.” After Cederholm gets you off on the right foot in his book Web Standards Solutions, he will show you some great techniques for building stable, scalable websites with Bulletproof Web Design. Dan’s techniques are simple enough to comprehend, will expand your mind about elements and properties, but also make you say aloud, “Why didn’t I think of that?”

Last, a great book to buy and keep forever by your side is The Elements of Typographic Style by Robert Bringhurst. This is a book that you need to hold on to. You will read it once, but then refer to it again and again to recall the proper way to accomplish something in type. Try out The Elements of Web Typography to see if it’s up your alley. Not every writer needs to be a proper coder, but every coder needs to be a proper writer.

If you discuss this topic with friends, I recommend using the short URL: http://jwr.cc/x/3u.

I’ve created a WordPress plugin that automatically creates Lessn short URLs for published posts. Lessn, created by Shaun Inman, is a free, self-hosted URL shortener that you download and upload to your own server.

More details available on the WP Lessn Plugin page.

If you discuss this article with friends, I recommend the short URL: http://jwr.cc/x/3o.

If you ever tweet about being unhappy with the WebKit Web Inspector, someone from the WebKit team will inevitably take notice and ask you why. I might reply, “Because it’s not Firebug!” Firefox could almost have it all with Firebug, but Firefox’s main problem is that it’s not WebKit.

My fundamental problem with Web Inspector is the Elements tab. My argument boils down to this: The CSS view does not resemble a stylesheet, and the HTML view does not resemble source code.

Nor does it behave like the code you write all day. Editing a visible HTML element or a CSS property requires at least two clicks to begin–which separates it from the standard user experience of a text-editor.

For example, when I hover an element in the HTML view of Web Inspector, my cursor is an arrow and can select elements to inspect. However, in Firefox, my cursor is the text cursor just as it would be if I were back writing the original code in my favorite text-editor. A simple click puts me into place to begin editing the code. This same action in Web Inspector requires a double-click. I don’t double-click to begin editing in a text-editor, so to me, this makes Firebug feel simpler for quick debugging during development.

But there’s a bit more to it. I’ve noted my issues below:

1. HTML view is not a monospaced font.
2. CSS view is not a monospaced font. (This is mostly a personal thing. I prefer code in a monospaced font. I can imagine others do as well.)
3. CSS view does not show the full cascade of rules for a selected element. For example, if I inspect a div, I should be able to see what font-family it will inherit.
4. Toggling properties in the CSS view is more troublesome than it is in Firebug. The checkbox on the right is harder to hone in on with a cursor because your eye is already looking to the left at the left-aligned properties.
5. Web Inspector does not work when JavaScript is disabled.
6. You cannot make an accurate text selection on a webpage while the Web Inspector is open inside the window. Similarly, you cannot enter text on a webpage without the page scrolling directly to the bottom of the document, where the Web Inspector resides. (A temporary solution to this is to detach the Web Inspector from the window, but I do not prefer working this way.)
7. You cannot add new elements to the DOM.
8. You cannot select an element in the DOM from its closing tag. You must select from the opening tag.
9. More than one Web Inspector may open within the same window. This may be a feature (as you could access more than one tab at a glance) but I have often experienced it as a bug.
10. Inspected elements do not distinguish between margin and padding with different color visual outlines; instead they are the same color. This is minor but slightly annoying.

The Web Inspector has made great strides since its initial release. For example, many enhancements have been added since I originally drafted this article, such as adding attributes in the HTML view or anchors that point to stylesheets from the CSS view.

But Firebug feels much more like a text-editor, and Web Inspector like a passive, well, text-inspector. And while Firebug solves a lot of my particular issues, Safari remains my favorite browser dues to its speed. I’d like to browse, work, and debug in it all day. For HTML and CSS, I think the Web Inspector could be much better.

If you discuss this article with friends, I recommend the Short URL: http://jwr.cc/x/2h.

JayRobinson.org went from about 10 visits per day to over 5,000 per day for six straight days. WP Super Cache helped me survive my first Fireball-ing:

If you’d like to discuss this article with your friends, I suggest using the Short URL: http://jwr.cc/x/2c.

With these new computers, we’ll want to forgo the tedium of initializing settings to remove silly restrictions meant for bumbling peasants. We’ll want to customize Mac OS X to our nerdish liking. Here is how I go about mine.

Finder

• Set View Options in Finder to Arrange by Name
• Turn off Spring-loaded folders in the Finder
• Disable drives from showing up on desktop

Mail

• Configure Rules to designate color coded message lines from family

iTunes

• Dougscripts for iTunes
  • Search AmazonMP3
  • Search Google Images
  • Add/Subtract Play Count
  • “Artist – Name” Corrector
  • Number Song Names by Play Order
  • Put Track Prefix to Track Number
  • Remove n Characters from Front or Back
  • Strip Stuff From Track Names
  • Track Names to Word Caps

System Preferences

• Keyboard & Mouse: Enable right-click on Mighty Mouse, Disable Expose, Dashboard buttons
• Dock: Automatically hide Dock, Disable animate opening applications
• Software Update: Disable automatic checking

Advanced Customization

• Turn off Bluetooth and remove from Menu Bar
• Turn off feedback for Sound controls and unnecessary notifications in iChat and Mail
• Remove the Windows BSOD in Leopard
• Run Terminal commands to disable unnecessary features and animations

  Change Dock to 2D Appearance

  defaults write com.apple.dock no-glass -boolean YES; killall Dock

  Disable animations in the Finder

  defaults write com.apple.finder DisableAllAnimations -bool true

  Disable ‘snap to grid’ animation

  defaults Write com.apple.Finder AnimateSnapToGrid -bool FALSE

  Disable Info pane animations

  defaults write com.apple.finder AnimateInfoPanes -bool false

  Increase the speed of the Save dialog box (Default is 0.2)

  defaults write NSGlobalDomain NSWindowResizeTime .001

  Force Mail.app to display plaintext

  defaults write com.apple.mail PreferPlainText -bool TRUE

Short URL: http://jwr.cc/x/25

Even if you’re making simple websites, they always contain contact information — why not publish it in an hCard format? Use Tantek Çelik’s easy hCard creator to start.

Don’t have any street addresses on your site? You can still sneak one in for author contact information. Any link pointing to the author can be made into a vCard like this:

<span class="vcard"><a href="http://author_domain" class="fn url">Author Name</a></span>

There are many ways to start using Microformats today and it becomes addicting. It is now impossible for me to accept br tags inside street addresses. I hope to see more uses for Microformats in the future. For example, if you visited a site that contained an hCard, the browser could facilitate a download right to your address book.

For further reading, try Andy Clarke’s article, “A tribute to Microformats“. Also, check out John Allsopp’s excellent Know Your Microformats section on his blog, Microformatique.

Short URL: http://jwr.cc/x/24

What I read there surprised me. I realized I use the same machines at home and at work as my web design idols. Web design is not a processor intensive job–most of what you need is an Internet connection and a text editor. But for some reason I had always envisioned Jeffrey Zeldman sitting down to some monstrosity of technology like Hugh Jackman in Swordfish.

But no, they use 24″ iMacs, the same as I use at work and home.

The apologist or procrastinator in all of us would say that ambitious project “just needs to wait” until we get a maxed-out MacBook Pro or Mac Pro with dual 30″ displays. But all that separates us from our idols is good old fashioned elbow grease.

This Thanksgiving I’m thankful I know that the only thing separating me from my dreams is the time and effort I’m willing to invest.

My preferred technique for image replacement on headings or links:

#myID {
        background: url(myImage.png) no-repeat;
        height: ...;
        width: ...;
        text-indent: 150%;
       overflow: hidden;
       white-space: nowrap;
}

This works much better than the Farhner technique. It won’t draw a dotted outline all the way across the left side of your page. It’s also much more future-proof considering the vast screen dimensions we’re likely to use. (Just imagine looking at some of your websites on a display with 16,384×12,288 resolution. All those words that were pulled 9999 pixels to the left would be visible.)

Though I’m not sure what to call this method—I’ve never seen this documented any where— I remember I first learned it by studying Tim Van Damme’s CSS. Before and after examples below.

Short URL: http://jwr.cc/x/23

Code

First we create an object, specifying a width and height. An object looks like this:

<object width="640" height="496">
    <param name="" value="" />
</object>

In order to trick Internet Explorer into reading this correctly, we have to talk to the ActiveX controller. So we tell it our codebase and classid. Whenever you’re going to insert a QT movie, use:

codebase = "http://www.apple.com/qtactivex/qtplugin.cab"
classid  = "clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"

Better browsers were designed to use the embed element for media. So we nest an embed within the object so that all browsers see the media file.

An embed can be a self closing element, or not. It doesn’t need parameters, just duplicate all your key/value pairs here as attributes (except for codebase and classid which are only for IE). Your embed may look similar:

<embed
    width       = "640"
    height      = "496"
    type        = "video/quicktime"
    pluginspage = "http://www.apple.com/quicktime/download/"
    href        = "my_video.mov"
    src         = "my_poster_image.png"
    bgcolor     = "#333"
    controller  = "false"
    autoplay    = "false"
    scale       = "aspect"
    target      = "myself">
</embed>

Conclusion

The final code will look something like this; a fine, hot mess:

<object
    width    = "640"
    height   = "496"
    codebase = "http://www.apple.com/qtactivex/qtplugin.cab"
    classid  = "clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B">
    <param name = "href"       value = "my_video.mov" />
    <param name = "src"        value = "my_poster_image.png" />
    <param name = "controller" value = "false" />
    <param name = "autoplay"   value = "false" />
    <param name = "scale"      value = "aspect" />
    <param name = "target"     value = "myself" />
    <embed
        width       = "640"
        height      = "496"
        type        = "video/quicktime"
        pluginspage = "http://www.apple.com/quicktime/download/"
        href        = "my_video.mov"
        src         = "my_poster_image.png"
        bgcolor     = "#333"
        controller  = "false"
        autoplay    = "false"
        scale       = "aspect"
        target      = "myself">
    </embed>
</object>

Note: Remember to add 16 pixels on to the height of your object and embed to accomodate the QuickTime controller. Otherwise it will be clipped off. For example, a normal 640×480 video would need to have an object and embed container height of 496 pixels. You will also need to accomodate for this in your poster image if you wish to offer a refined experience.

Not all these attributes are necessary, and in fact you can make the QT player exhibit different behavior if you experiment with it a bit. This document from Apple.com is helpful: Including QuickTime In A Web Page. Read the whole thing.

I’ve made a 1.3MB .zip file with video, poster image and code so that you may experiment. Download or see the Demo.

Short URL: http://jwr.cc/x/20

But it also has another great use: creating videos for the web. The GUI is a little clunky for this purpose and doesn’t even have what you need. I prefer to use the CLI, or Command Line Interface. On a Mac, use Terminal.app to access the command line.

I often use HandBrake to take client’s video files and add them to their website in a format that streams quickly and looks great. HandBrakeCLI takes a crummy Windows Media video file and turns it into something awesome for the web. Here is my command:

./HandBrakeCLI -i ~/Desktop/my_original_file.wmv -o ~/Desktop/my_new_file.mp4 --encoder x264 --vb 1800 --ab 128 --maxWidth 640 --maxHeight 480 --two-pass --optimize;

Explanation

Let’s explain this command and ease your apprehension about using the command line by breaking down each individual argument in the command, line-by-line:

 1) ./HandBrakeCLI
 2)     -i ~/Desktop/my_original_file.wmv
 3)     -o ~/Desktop/my_new_file.mp4
 4)     --encoder x264
 5)     --vb 1800
 6)     --ab 128
 7)     --maxWidth 640
 8)     --maxHeight 480
 9)     --two-pass
10)     --optimize;

1. Before you run your command, use the Change Directory command (cd path/to/handbrakecli) to make sure you are in the same folder as the HandBrakeCLI file is located. Technically, this file path starting with ./ means to stay in the current directory.
2. The -i means input file. The next part lists the path to your original video file you’d like to convert (I find it’s easiest to work from the Desktop).
3. The -o means output file. The next part defines the path where you’d like to place your final converted video. Technically, this file path starting with ~/Desktop means to the Desktop folder of the current user (you!).
4. The best codec for the web is H.264 video, using x264 encoder.
5. Video Bit Rate is specified in kilobits per second.
6. Audio Bit Rate is specified in kilobits per second. For most small videos, 128 is fine. If the video is mostly talking go ahead and bump it down to 96.
7. Set the maximum width.
8. Set the maximum height. The best part about these two lines is that the aspect ratio will not be changed! HandBrakeCLI will try to fill the larger value without exceeding the latter.
9. Two passes over the video is better than one.
10. Your client won’t give a jack how fancy you think you are unless you include the most important part: --optimize. Optimize means moving important data to the beginning of the file so it’s downloaded first, allowing the video to start quickly.

It’s all smooth sailing from here. If you want to process many videos in one go, just separate the commands by putting a semi-colon at the end before you start a new one.

Resources

To try this out, you’ll need to download HandBrake and the HandBrake Command Line Interface.

For a quick idea of best practices for compression, I like Vimeo’s compression guidelines. If you want to know more about codecs and video on the Web in general, check out Mark Pilgrim’s awesome overview at Dive Into HTML5.

Short URL: http://jwr.cc/x/1t

Also featuring HTML5, CSS3 & jQuery

I got tired of the boring look of a standard Apache web directory. So instead of browsing folders the default way, I built a small index.php file in the root, grabbed all folders dynamically, injected them as HTML5 and styled them with CSS3. Since I work with Coda all day, I chose to emulate their Sites View interface. Coda is a great text editor/FTP client for Mac OS X. If you’re not familiar with Coda, check it out at Panic’s website.

About the Coda-fied web directory — my code is completely self-contained and portable. It also uses no images for style. All gradients are generated with the CSS3 gradient proposal, best supported by WebKit. The screenshot thumbnails can be generated dynamically. Below is a preview, and a few notes on how it’s made, and a link to the working demo.

Hover for alternate view.

Let’s get started.

1. First we need to write the PHP grab all folders in the directory and create links from them. (Notice it ignores those pesky ‘.’ and ‘..’ folders that show up in all directories by default.) The unflappable Paul Redmond helped me with the PHP code.
2. Next, style them with CSS3 and beautiful, beautiful WebKit properties. I commented my code so that you may find it helpful.
3. Use the WebKit2PNG shell script to make background images for all folders in the directory. This has to be done manually, but a smarter person could probably set this up to automate by porting the code from Python to PHP or other language.
4. Add jQuery slider to adjust height and width.

Before you jump right to the demo, remember that it works best in the latest version of Safari or WebKit Nightly, and works pretty well in FireFox 3.5 or greater. Thanks for taking a look. I hope you enjoyed it as much as I did.

View the working demo.

Short URL: http://jwr.cc/x/1i

I’ve created a WordPress plugin to fix an issue I have with the WordPress Dashboard: the HTML editor is not a monospaced font. I don’t like reading code in 13px Lucida Grande, so I wrote a plugin to add a stylesheet with 12px Monaco.

As with all WordPress Plugins, it is available with an open GNU General Public License, so you are free to modify and distribute as you see fit.

I may add more in the future. More info on the plugin page.

Short URL: http://jwr.cc/x/1h