What Are You Doing Here?

Well, more often than not you’re looking at technology-based articles or screencasts. One of my most popular posts, with several hundred unique visitors is the Google Sync vs. MobileMe article and its ensuing follow-up. The screencasts, especially ones that teach web or Photoshop-related topics, regularly receive a good number of visits as well. This is a good thing, because these are definitely the paths I’d like to pursue when moving forward with this blog. There are only 4 pages on the site: About, Portfolio, Archives, and Contact. About and Portfolio get the most views, despite not being updated since the site has gone live. Archives seems like a huge gateway for people to find what they need, though I believe the ability to sort this page by certain criteria (popularity, # of comments, etc) would be a massive usability improvement.

Trimming the Fat, the Message, and more…

Taking a bird’s eye view of the site, it’s definitely geared towards technology; both physical things like electronics as well as intangibles like code and video. There’s a bias towards Apple, for sure, but not in an anti-Windows way. Occasionally I’ll post personal (life) things, reviews, and little bits of fun Photoshoppery. So, thematically, it’s all over the place. I think the first thing I’d like to do is narrow my focus down a bit to a few key points. I really like the way Tumblr handles this, where everything falls into 7 categories:

• Text
• Photo
• Quote
• Link
• Chat
• Audio
• Video

Taking that a step further is a company like Panic, whose blog uses different treatments depending on what category a post falls into. Observe: http://www.panic.com/blog/

So I think my new site will have a small number of vague primary categories (as opposed to my current, very specific 30+) and then pertinent subcategories for people who want more granular control over their browsing experience. Another option would be to keep the vague primary categories and then fill in the gaps with tags or Wordpress 3.0’s new taxonomy system. All of this will be covered in a later step, for sure.

The homepage will no longer be simply just the blog; a years worth of data has proven that’s the best way to increase the bounce rate well above average. I intend to create a page that briefly tells people who I am, perhaps showcases some recent work, and then gives a few samples of things from other areas of the site.

In a nutshell, here is how I would describe myself:

I’m a web designer by trade, passionate about cutting edge technologies and semantic markup. I love utilizing video not only in the form of screencasts to teach but also in personal or corporate projects as a means of communication or just having fun. I work with all types of clients, big and small, and love discovering great new things to share with the community.

I have to make sure I build my brand around that core message, which shouldn’t be too hard since I practice what I’m preaching.

What Am I Found For?

Most of the terms I’m found for correlate to what I discussed in the first paragraph: apple vs google, mobileme vs google sync, etc. I also get a lot of traffic from “How To…” searches in regards to web development on Mac. A surprising number of people also Google my full name to get to the site. Not sure if they’re looking for one of the other Andrew Gormleys out there in the world, but it’s hard to imagine as the people who find me via that search term tend to stay on the site for an average of 5-6 minutes. In this regard, I think I’ll just keep doing what I’m doing, but start to trim the fat and work on more concise post titles for easier findability.

Summing It Up

I now have a really good understanding of my audience and what it is I’d like to say from a messaging point of view. Fortunately these two things are very similar in nature so it’s not a matter of sacrificing one or the other, but simply making the two more cohesive.

The Next Step

In the next installment, I’ll actually start diving in concept art and mapping out ideas for the new site. This is where I think things will start to get really interesting, so stay tuned as I continue on my journey to a great new site.

Preface

It would probably help if you read Cameron Moll’s most excellent article Good Designers Redesign, Great Designers Realign on A List Apart before continuing with this or any other article in the series.

Establishing The Audience

The first thing I always do in situations where a realign is in order is check Google Analytics as well as my server log files (in this case, via Urchin) to get an idea of what people are up to when they come to my site. I decided to also check the main RSS feed to see if people are consuming content that way, since that’s usually how I like to manage my information intake.

Using the window of time April 5th, 2009 to April 5th, 2010, here are the a few points that I’ve gleaned:

• Average unique visitors per day: 52
• Average pageviews per day: 137
• Average bounce rate: 72.2%
• Average time spent on site: 00:01:54
• Average pages per visit: 2.34
• Current number of RSS subscribers: 230
• Average number of RSS subscribes: 137

Sadly, that was more traffic than I expected to be receiving on a day-to-day basis due to my sporadic updating and varying types of content. The bounce rate is definitely something that needs to be addressed, as 72% is pretty terrible any way you present it. More often than not bounce rate is tied to usability issues: unclear navigation, display issues, and much more can all factor in to bounce rate. I like that there are actually RSS subscribers, even though it was difficult information for me to ascertain. I may end up implementing FeedBurner for the RSS feed simply as a way of more easily tracking who has subscribed to the site.

Next up, I want to see what my user’s capabilities are. This includes everything from their web browser to screen resolution to operating system. The numbers were pretty much on par with what I thought they’d be:

Then I decided to break down the top three browsers into their respective version numbers to gain a little more insight into who’s been checking in:

The site is optimized for all but two browser versions featured above: IE 5.5 and 6. It’s almost mind boggling to think that anyone in 2009 or 2010 has used Internet Explorer 5.5 – those folks are outliers and won’t be considered as part of my target audience. I’ve also already made it clear that IE6 isn’t supported on any current or future incarnations of my site. Currently, users of those browsers can still view my site content; moving forward with the new design they’ll be presented with a polite splash page encouraging them to get with the program.

What was really surprising were the amount of visitors using the latest version of Safari. The 23% of users running version 3 were from April 2009 to roughly July 2009 (Safari 4 was released in June). In the past 6 months, nearly 96% of all Safari visitors are running the most current build. I suppose that’s the benefit of proactively pushing out updates to your users (Microsoft, take note!).

Here are a few of the other stats worth noting:

• Operating systems were split pretty evenly between Mac and Windows (both roughly 46%). Some surprises in the OS list include: PlayStation 3, PlayStation Portable, and Blackberry
• Most common screen resolution is 1280×800. Smallest screen resolution (not including mobile) was 1024×768.

To Sum It All Up

My everyday visitor is running a recent version of Firefox or the most current version of Safari on a Mac or Windows PC with an average resolution of 1280×800, making it safe to assume they’re using a laptop. If they don’t leave immediately from the homepage, they tend to browse at least 2 pages of the site, spending roughly 1 minute on each page.

Moving Forward

In my next entry, I’ll start to address the goals of the site and what messaging (if any) I’d like to change to better convey what it is I offer. This will likely also touch on a bit of branding as well, though the only visuals we’ll be working with will most likely be graphs. Look for that article coming soon.

The Foundation: Text Editors

There are a veritable plethora of text editors for Mac and nearly everyone you ask uses a different one they’re fanatical about. This speaks volumes of the quality and diversity of the software available, but in the end it really comes down to your personal preference.

The best way to describe TextWrangler from Bare Bones Software is to say that it feels like TextEdit on steroids. You can use it as a simple text editor for sorting out content, but it also supports syntax highlighting for over 30 programming languages, one of the most robust find-and-replace actions of any text editor out there, and the ability to open and save files via its built-in FTP browser.

Though no longer under active development, Smultron is another free text editor that feels decidedly more Mac-like in its appearance. It utilizes an always-open sidebar similar to iTunes where you’ll view small (but resizable) thumbnails of all your open documents. Some extra niceties that Smultron has over TextWrangler is the ability to edit in full screen mode, view code in split view, as well as a pretty nifty snippets manager for quick access to frequently-used code.

You can’t talk about Mac text editors without a very vocal show of support for Textmate. It’s easily one of my most used applications and for very good reason: it’s literally packed with features and functionality, some of which can’t be found anywhere else. The web development features that are particularly useful include a built-in code preview (using Webkit), inline W3C validation for all of the HTML-ers, code snippets, and bundles, which can be written freely by anyone and add even more functionality to the editor. Textmate isn’t free, but for all it does, the $55 price tag is a steal.

Moving and Shaking: FTP

The clear winner for free FTP program (and possibly coolest icon) on the Mac goes to Cyberduck. It supports multiple protocols including: FTP, SFTP, WebDAV (MobileMe), Amazon S3, and even Rackspace Cloud Server access. It has excellent OS-wide integration and, perhaps more important, plays well with most text editors. You can right click on a remote file from within Cyberduck and edit it with your favorite text editor, then once you save it Cyberduck automagically uploads the file back to the remote server with no intervention needed on your part.

The guys over at Panic know great design, which is why it should come as no surprise that Transmit is one of the best looking and most functional FTP clients on the Mac. One of its killer features is the ability to create droplets: think of them as mini-Transmits that allow you to upload files without even opening the program. Additionally, it supports nearly every protocol you can think of and sports advanced editing of a variety of files remotely (most notably images). All of this packed into an elegant, intuitive UI makes Transmit the best $29.95 you’ll ever spend.

A relative newcomer to the Mac is Flow, a robust FTP program that was a big part of the last MacHeist and has been gaining more and more momentum. When you launch Flow, you’ll immediately notice it breaks away from the standard FTP interface for something that’s considerably more Finder-esque. Compound that with some advanced features not found in many other Mac FTP programs like multiple connections for simultaneous file uploads, right clicking to copy remote URLs, and bulletproof QuickLook integration and you have yourself one fine file transferrer. $25 and it could be yours.

Save the Environment

As far as I’m concerned, the only testing environment you need to set up on your Mac is MAMP, which stands for Macintosh, Apache, MySQL, and PHP. The latest version clocks in at a hair over 200MB. It’s self-contained and can live anywhere on your hard drive, essentially making it the ideal portable development environment. All of your webpages are viewable in the htdocs folder contained within the MAMP directory and can be accessed, by default, simply by visiting http://localhost:8888 while MAMP is running. Get MAMP absolutely free now and start your rapid development.

Test Your Code, Not Your Patience

The bane of any web developers existence is Internet Explorer and while we might not like it, it needs to be accounted for. Boot Camp is a good idea in theory, but would severely break your workflow should you have to reboot every time you made a change. That’s where virtualization comes in: boot up Windows (or any other OS, really) from within OS X for rapid testing and debugging.

Sun’s VirtualBox has come a long way over the years and in many respects can stand toe-to-toe with the paid virtualization clients out there. It fully supports multiple versions of Windows all the way back to 2000, many distros of Linux, and even BSD variants. It’s fast, intuitive, and gets the job done while leaving your wallet intact.

Holy layer of abstraction, Batman!

I won’t get into the Parallels vs VMware Fusion speed debates (though I already have) because with each new version released one becomes faster than the other. Priced identically at $79.99, these programs offer incredible speeds, loads of configuration options for power users, and enhanced graphics capabilities (for when you take a break from coding for a quick frag-fest). You can sometimes get Parallels at a discounted rate if you follow software sales like MacHeist or MacUpdate Promo (actually happening right now, including Parallels!), so some users opt to wait for that and save a bit of green. Beyond minor aesthetic details, each of the programs behaves similarly and in the end should cut your Windows testing time down significantly.

That’s All, Folks

Hopefully with all of the aforementioned tools you’ll be able to quickly and effortlessly jump into Mac web development while keeping your bank account at a respectable level.

What does this mean for most people?  In a word, nothing… yet (ok, that was two words).  The fact of the matter is that until we have full browser support for the H.264 video codec, which is currently only available in Webkit-based browsers like Google Chrome and Safari, this seamless and superior technology will never be experienced by the majority.

I don’t anticipate Internet Explorer ever fully supporting the video standard or the code to actually implement it (c’mon, 8 versions in and they’re just now figuring out how to render web pages correctly), but for this to be anything close to a victory over Flash, Firefox needs to get with the friggin program.  While it’s true that Firefox does support the code to get it working, the videos need to be encoded using Theora as opposed to H.264—which, in short, requires two versions of the same file, doubling the necessary server space.  You can see how this would be a problem for a company like YouTube, whose server farms are probably running at max capacity with a ridiculous 12,000 videos views per second.

So, while I personally think it’s great that those of us who opt for Webkit browsers will have an overall better user experience, not to mention that videos from both YouTube and Vimeo are now accessible to mobile platforms without the need for Flash, I would love to see this technology rolled out to the populace as a whole, which will require a massive amount of feature requests and a miracle.

First Things First

Obviously the first thing you’ll need is a high quality source file. (Note: any file will do, but encoding from the original, lossless source always yields best results). In my case, I was working with an HD video file that I just finished editing in Final Cut and exported using Compressor. If you’re exporting from an editing suite and not intending to serve up an HD version of your video, then exporting a standard DV file will work. If you’re taking the video directly from a video camera like a Flip Mino, Kodak Zi8, or even your phone, then chances are your videos are already compatible.

A Brief and Incomplete History of Video Codecs and Containers

Working with video can get overwhelming very quickly if you’re unfamiliar with the terminology or concepts, so here’s a quick breakdown of video as well as the two types we’ll be dealing with: MP4 and Ogg.

It’s safe to assume that if you download videos from the internet, you’ve encountered a few of the more common extensions: MOV, MPG, AVI and unfortunately WMV. Those files are known as video containers. Think of a video container as you would a ZIP file: an all-in-one package that contains the content you’re really after. In the case of video containers, the files within are known as streams or tracks and represent a variety of things including video, audio, subtitles, and more.

Ogg is a free, open-standard container format supported natively by Firefox 3.5+, Google Chrome, Opera and most distributions of Linux. You can also watch Ogg content on OS X or Windows easily enough by installing the appropriate codecs. For our purposes, we’ll be dealing with the OGV container, which is specific to video. Within the OGV container, we’ll have two tracks: the Ogg Video track known as “Theora” and the Ogg Audio track known as “Vorbis”. Ogg file formats are on their way to becoming the standard way that Wikipedia delivers audio and video information, in hope of establishing this patent-free codec as the <video> standard.

MP4 is the container format of choice for Apple and most mobile platforms and is supported natively by Safari (Webkit), Flash video players, the iPhone, some Android phones, and also Google Chrome. Within the MP4 files we’ll be working with, we’ll again have two tracks: “H.264″ for video and “AAC” for audio. H.264, like Theora, is a video codec, but the comparisons end there. H.264 offers a plethora of options and features that are a result of it’s evolution over many years. If you’ve ever watched a trailer on Apple’s site, a BluRay movie, and HD video on YouTube, or downloaded a movie/television show through iTunes, then you’ve encountered H.264 in one of it’s many profiles. H.264 profiles are the key to its versatility, as different profiles best serve different mediums. The Baseline H.264 profile is supported on the iPhone and some Android phones, while the Advanced Profile is used by BluRay discs for the ultimate in video quality.

So, to recap:

Ogg

• Ogg is supported natively by Firefox 3.5+, Google Chrome, Opera, and most Linux distros
• Ogv is the container we’ll be working with
• The video track within an ogv container is known as “Theora”
• The audio track within an ogv container is known as “Vorbis”

MP4

• MP4 is supported natively by Safari, Google Chrome, iPhone OS, Android OS, OS X, and Flash video players
• MP4 is also the name of the container we’ll be working with
• The video track within our mp4 container is known as “H.264″
• The audio track within our mp4 container is known as “AAC”

Acquiring the Encoders

I’ll preface by saying that I had a hell of a time finding a reliable GUI-based Theora encoder. The Quicktime plugin was buggy and didn’t always output files as expected, even resulting in a few crashes. Firefogg, a highly recommended Firefox extension, simply did not work for me while dedicated encoding programs that I looked into, particularly Episode and Sorenson Squeeze, were both absent of the Theora codec entirely. This left me with the command line alternative: ffmpeg2theora. For those of you not comfortable working in the command line, fear not, as the calls to output a Theora video file are quick and easy. For exporting the H.264 video, I used the free (and incredibly nifty) Handbrake, which is available for Windows, OS X, and Linux.

You Down With Ogg?

After installing ffmpeg2theora, you’ll have to open either your terminal (OS X/Linux) or command prompt (Windows). From there, you can type “ffmpeg2theora –help” to get your bearings or just base your settings off of mine. After playing with a few variations of settings, the ideal preset for my project came out to look like this:

ffmpeg2theora –videoquality 6 –audioquality 4 –max_size 416×232 –optimize InputFile.mov

• videoquality X — where X can be any number from 0 to 10
• audioquality X — where X can be any number from -2 to 10
• max_size tells the encoder what the output size should be. If removed, input and output source size will be the same.
• optimize adds some time to the encode process, but gives you the best possible balance of quality and file size
• InputFile.mov can be almost any type of video container. A shortcut to inputting it is to simply drag and drop the file into your Terminal/Command Prompt after writing out the above settings

My uncompressed input file was 106MB at a resolution of 1280×720. Using these settings the file size came down to just a fraction above 16MB. I easily could’ve gone lower than that, but didn’t want any visible video degradation and anything below 20MB seemed like a reasonable streaming video size.

H.264 U

Encoding with Handbrake should be much easier for the average person since there’s a nice, clean interface in which to work. After launching the program, select your input source and, from the Preset Drawer, select “iPhone and iPod Touch”. This setting isn’t specifically for these devices, but more a good starting point from a compatibility point of view. From the top down, choose these settings:

• Container: MP4
• Make sure “Web Optimized” is checked
• Video Codec: H.264
• Framerate: Same as source
• Constant Quality: This is (very loosely) akin to Theora’s 0-10 scale and can be tested by enabling live preview in Handbrake to view your settings live on the video before committing to a lengthy encode. Power users could also simply specify a Target Size or Average Bitrate.
• Under the “Audio” tab, make sure that the Samplerate is 44.1 as 48 is overkill for web video.
• Click on the Picture Settings icon and then adjust the video to your desired size. You may also crop here if necessary.
• Finally, before submitting the export, you can click on the Preview Window icon to get a live, 5-60 second preview of your video with the settings you’ve chosen applied.

Going from the aforementioned uncompressed file I was able to get the MP4 down to 17Mb, which is a space savings of roughly 600% with relatively no visible pixel degradation or blurring.

The Code To Get It Done

The HTML5 code to embed a video is super simple and very much akin to using the <img> tag:

<video src=”MyVideo.ogv”></video>

You can take it a step further and add a width and a height, just like with images:

<video src=”MyVideo.ogv” width=”640″ height=”480″></video>

There are also a number of options you can add on to your video tag, they are: controls, autoplay, autobuffer. They’re all pretty self explanatory, and equally easy to implement. For example:

<video src=”MyVideo.ogv” width=”640″ height=”480″ controls autoplay></video>

The above line tells the browser to use it’s native controls for video and autoplay as soon as the page is done loading. You could swap autoplay with autobuffer to have the video begin downloading right away and then have the user initiate playback using the native browser controls. The options aren’t endless, but they’re certainly nice to have.

The only thing remaining is specifying which video will work in which browser. Rather than wasting away precious bandwidth by loading two movies and letting the browser decide which one it can handle, all you have to do is use the <source> element of HTML5 to tell the browser which video to download. The source element looks like this:

<video width=”640″ height=”480″ controls>

<source src=”MyVideo.ogv” type=’video/ogg; codecs=”theora, vorbis”‘>

<source src=”MyVideo.mp4″ type=’video/mp4; codecs=”avc1.42E01E, mp4a.40.2″‘>

</video>

So from that you can see that the video element no longer links to the file, but still contains the video attributes like width, height, autoplay, etc. Inside the video element we have two source elements that give us the path to the video as well as the video type, respectively. Note that the type attribute is wrapped in single quotes, which is a little weird, but this is due to the fact that the codecs have to wrapped in quotation marks for this to work.

Beware of the Mimes

I ran into a hugely frustrating issue where my development server simply wasn’t playing the OGV video natively in Firefox or Chrome, yet when I tested my code locally everything worked perfectly. I tried different character encodings, files permissions, and much more before I figured out that it was a simple issue of the server not understanding what the hell an OGV file is in the first place. There are two ways to remedy this issue:

1. If you’re the server admin *and you know what you’re doing*, you can edit httpd.conf and add the following lines to cover all variations of OGG media (one per line, do no include commas): AddType video/ogg .ogm, AddType video/ogg .ogv, AddType video/ogg .ogg
2. If you’re not the server admin but have FTP access, create a file called “.htaccess” in your root directory and add the lines you see above in the same format.

Note that the first method is a server-wide change whereas the second must be done on a domain-by-domain basis. Once I established my Mime types, it was smooth sailing.

In Summary

HTML5 video is exactly what a lot of people have been waiting for and, beyond learning a little bit about video encoding, should be comfortable territory for any proficient HTML coder. The only obstacle at this point is Internet Explorer, which seems to have no intention of supporting either file type now or in future versions. Though it would be easy enough to write a Javascript workaround to fallback on YouTube in the event of IE, the native implementation and seamlessness are really what make the HTML5 video element shine. In the web development world, where working drafts take years to be approved and the inhabitants argue fruitlessly over the minutiae of doctypes or trailing slashes, HTML5 video feels like an evolutionary first step in the right direction: An open web that utilizes open source tech to solve usability conundrums.

You can view my finished page here.