Endikos

I had my camera with me all day today as my family went to church, lunch, a birthday party with a little train yard, and then back home.   To top it off, today was an awesome wintry day with snow on the ground and hoarfrost covering all the trees and plants. I’d like to tell you that I was able to shoot a whole books worth of awesome photos, but for various reason I barely got two or three shots that turned out poorly.  At home, however, I went looking for interesting things to shoot again.  Not wanting to bore you with another shot of the dog, I went to the basement to see if there was something cool to shoot.  My wife is reorganizing her fabric collection.  What you see here is a small portion of her crafty hoard, but I do enjoy the color and pattern to these fabrics.

Didn’t get out of the house today, so I went around looking for something quasi-interesting just sort of hanging around the house…

I’ve rediscovered a passion for photography.  I’m sure it’s in no small part due to the fact that I work with a rather talented guy that does inspiring work.   So I decided to take on a project that will force me to spend quality time with my new Canon 7D. This is by no means a new idea, there are people all over the web doing this, but I will be shooting and publishing a photo a day for the next year.

To kick things off, I found myself in a local coffee shop today while waiting for my lovely wife.  I snapped a few frames off, and liked this one the best.

In my last article on video transcoding I made mention of a little utility I’d assembled called “Cyphon”.  After I discovered the awesomeness of Handbrake’s command line interface, I decided I wanted to build something that would allow all the video guys at my employer to encode videos for various target platforms simply.   Leave the gazillion-encode-variables-degree-in-transcoding-required stuff to me.  Not everyone should have to worry about that.  Of course Handbrake does an excellent job at taking most of that away anyway, but I still found myself tweaking options to get the best output I could.  I also wanted to encode something Windows users could watch with a default install of windows.  This meant I’d also have to bring in either ffmpeg or mencoder, and mencoder seemed to do the best job at encoding WMV files.

So now to wrap everything into something all my video guys can use, including myself.  I have several options, and they boil down to variations on two major themes:  1) Build some sort of intranet web service where the end user uploads something and gets transcoded video to download a short while later; 2) Build a distributable application that each person can use natively.

For various reasons, I chose to build a little distributable application.  Now while I am a programmer, I’m not really a systems programmer.  I prefer web development and scripting languages, although I do know Java and enough C to build working apps if I have to.  And as lovely as Cocoa and Objective C are, I haven’t learned them (yet – I’m in the process of learning them). Fortunately, I dont necessarily need to know Cocoa or Objective C to write a simple and effective app for OSX (Sorry Windows and Linux Guys, all the video folks here run Macs ;-).  Enter the dynamic duo of Platypus and CocoaDialog.

Platypus lets me  use ruby to write the logic of my app, and CocoaDialog lets me present windows with user-selectable options or notifications to the user.  So now I can knit together a ruby script, handbrake, and mencoder together using platypus and cocoadialog to make video transcoding an effortless task for my video guys.  Platypus even lets me make the icon droppable, so I could make my script do video transcoding in batches or one-at-a-time.

My employer has been kind enough to let me release Cyphon to the world licensed under the GPL, v2.  I’m releasing the bundled app as well as all the original source files I used, including the platypus profile, so you can see what options I used, and how I stiched everything together (the Platypus profile wont work for you right out of the box, as it will have my home directory’s path hardcoded, you’ll need to tweak that to reflect your source paths before it will work). If you just want to make tweaks to the running app, right-click or alt-click the app, choose “Show Package Contents”, go to Contents, then Resources, and look at the “script” file.  You’re probably most interested in “@@encoding_options” beginning at line 22.  There are a few of things you’ll want to keep in mind: 1) I know this will work on OSX 1.5 on an Intel platform, other platforms are questionable.  2)  If you throw a source video at it that doesnt have an audio track, it will barf.   This will be a future fix.  3)  It’s made to be able to accept quicktime MOV files.  I don’t know if anything else will work, because I havent tested it.  4) Keep in mind we have a very specific set of needs, and it meets those needs well. It may not meet your needs without significant work ;-)

All that said, here are the downloads you’ve been itching for:

1. Cyphon v1.4 for OSX 10.5, Intel Platforms
2. Sources for Cyphon 1.4

A few days ago I was growing somewhat despondent while trying to find a way to convert a large quicktime MOV file that had been encoded in 720p HD into several other formats.  After fumbling around for a while and thinking I was going to have to use the commercial (and excellent) Adobe Media Encoder, I found an unexpected gem that wound up exceeding my needs and allowing me to do something truly cool.

Before I unveil the final solution, allow me to tell you a bit of what I’ve discovered along this little journey and a few of the specifics about what I needed to accomplish.

Read the rest of this entry »

[Note: This post has been moved to ThreeBit Media, my consulting website.]

Back in my first Designing For Email post, I discussed workable dimensions and some common-sense techniques when you’re approaching designing for email.  Most of that still holds true, but I’ve discovered an unpleasant lack of support in a few email clients for an important bit of CSS: floating, clearing, and margins.  The lack of this one bit makes good design wholly in CSS nearly impossible.  I’m officially peeved.  What’s really weird is MS Outlook.  Outlook 2003 supports floating just fine.  Outlook 2007 does not.  So what does this leave me with?  Table-based design.

Yeah, I know. Seriously.  After all this time when CSS has (finally!) become a standard method of layout.  When people are finally getting the whole point of separation of concerns when it comes to content versus layout, and browsers are getting good support, and for the most part I can get my designs to be pretty consistent across browsers without much effort as long as I closely follow the rules…  I’m having to retrofit my CSS-based layout into a table-based design.

As I was coming to grips with this I did a sanity check by looking through the last few months of my inbox and looking at the adverts (non-spam) I’d recieved.  A quick look at the source confirmed that they were ALL table-based.  Dang.  And now the fellow across the hall is making fun of me.  He knows how dirty I feel for having to violate standards to make something layout correctly.   Oh well.  For what it’s worth, I did stumble across the Email Standards Project, which is what confirmed that Outlook 2007 and Gmail (!) both lack support for floating/clearing.  So, have fun dusting off the table-based design knowledge you’d accumulated and then happily buried when CSS finally became a viable alternative.

[Note: This post has been moved to ThreeBit Media, my consulting website.]

When beginning the architecting of the site I’ve been working on I knew I would need to address two issues (among many others, but for now we’ll just cover these two): 1) How to structure a multilingual website physically, and 2) How to address the sitemap.xml structure for the site as a whole.

First I had to decide how the site should be physically structured.  Would a subdomain-per-language be good, e.g, en.mysite.com for English, es.mysite.com for Spanish, and ru.mysite.com for Russian?  Or would it be better to use directories for the distinction, e.g. www.mysite.com/en/ for English, etc?  If I chose the subdomain route it would be easy to build sitemap.xml files for each domain.  But how would I structure the sitemap.xml if using directories?

I chose to use directories for a couple of reasons.  One, I knew that google treats subdomains as entirely separate websites.  I didn’t wish to do this because semantically these were three translations of the same website, and I felt that should be reflected in their structure.  Two, I didn’t want to have multiple datasets when dealing with analytics, either multple log files to analyze or one of the myriad javascript-based analytics packages.  Yes, I’m fully aware that there are ways to glom datasets together, or otherwise make analytics packages aware of your structure… this was just pure personal preference.

OK, so now I have my structure in place, how do I build the sitemap.xml?  I don’t want one huge monolithic file for the entire site.  Even though at current count there are only around 100 html files per translation (not huge by any means, but also not insignificant), I would just personally prefer to keep the translations in their own separate sitemap.xml files.  Those of you familiar with sitemaps will have been shouting at your monitors by now “Use a sitemap index, dork!”, and you’d be right.  I just wasn’t sure that Google would support this.  Google didn’t seem to mention it anywhere in their webmaster tools documentation (though I could have just missed it).

I’m happy to report that Google does in fact support sitemap indexes, and I’m fairly certain that MSN and Yahoo! do as well. So, simply build yourself a sitemap_index.xml (the filename is arbitrary) file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <sitemap>
      <loc>http://www.mysite.com/sitemap_en.xml</loc>
      <loc>http://www.mysite.com/sitemap_es.xml</loc>
      <loc>http://www.mysite.com/sitemap_ru.xml</loc>
   </sitemap>
</sitemapindex>

Then build your individual sitemap files as you normally would.  You can find the full specifications for sitemaps at sitemaps.org, and a nifty utility to help you automatically build sitemap files at the google-sitemap_gen project.  Dont forget to include your new sitemap index file in your robots.txt file!  Enjoy.

[Note: This post has been moved to ThreeBit Media, my consulting website.]

My company is about to launch an email newsletter and I began to wonder about what layout dimensions I should shoot for.  I’ve not given it a lot of thought in the past, but as I’m building a template for repeated reuse, I’m now giving it a few neuron cycles. There are a couple of major issues with designing for email that are reminiscent of the especially difficult browser-compatibility problems that have caused multitudes of web designers to rage and wail and burble incoherently.  These issues are essentially this: 1) email clients don’t give you a lot of room to work in; and 2) email clients are not full-featured browsers.

Let’s talk about physical dimensions first. An email client is designed and navigated differently from a browser.  The “chrome” on most modern email clients include not only the toolbars and menus, but an entire left-hand column used to navigate mail boxes and other features.  This column alone consumes a couple hundred pixels of horizontal real estate.  Vertically, the space is usually split in half so that the user can see a list of messages in the upper half and then view them in the lower.  When all this is taken into account while still designing for a small common screen resolution on the order of 1024×768, you wind up with a usable viewport more in the neighborhood of 650×300.

Now take into consideration that the (X)HTML rendering capabilities of email clients are not necessarily on par with fully-featured browsers.  For security and speed, most email clients have a very limited set of supported browser features.   Most won’t display flash, few support animated gifs, and JavaScript support is typically limited.  Thanks to spam, you’re not even guaranteed any images will display at all, but fortunately, most of the time plain-jane images will load just fine.

So here are a few guidelines for (X)HTML-formatted documents delivered via email:

1. Keep your overall width between 600 and 650 px.  This should be old-hat to those of us that were designing around the turn of the century, and will be an interesting excercise to the neophytes.
2. Remember that the “fold” on an email client is likely going to be around 250-300 pixels down the page, so make sure you have something above the fold that will make your user want to scroll.
3. Keep it simple.  Avoid JavaScript.  Use well-supported (X)HTML and (inline or on-page) CSS only to aid your presentation.
4. Keep it standards compliant.  The same “failing gracefully” principals apply to email that apply to browsers.  However, there’s the additional “standard” of making sure you have a text-only version of your email ready to fly along with the HTML-formatted version.

Finally, a note about content.  A rule that used to apply to physical newsletters is also applicable to email newsletters.  A friend of mine used to tell me that “A good newsletter can be read between the mailbox and the trashcan”.  Be brief in your email content and link frequently to expanded content on your website.  Enjoy!

UPDATE!  I’ve discovered that Outlook 2007 and Google’s Gmail don’t support floating and clearing.  This makes design using pure XHTML and CSS very painful.  I’ve got new post about this issue and my dismay here.

[Note: This post has been moved to ThreeBit Media, my consulting website.]

I discovered recently that Firefox 2 can’t handle negative CSS z-index values.  Apparently it throws any element with a negative z-index applied to it beneath the body.  I discovered this after I had already positioned elements on a page and found some improperly indexed elements on testing IE.  So instead of reworking all my existing z-index values, I just gave the offending element a negative value.  This worked in Firefox 3, IE7, Safari, and even IE6.  I thought all was golden until a co-worker’s brother called and said “Do you know your site doesn’t work in Firefox 2?”.

Frankly, it never even occurred to me to check different versions of Firefox.  I know this seems obvious, but Firefox had always been so consistent for me, I hadn’t thought about checking multiple versions.  So I loaded up FF2 on my Windows VM (I normally run a Mac with windows installed in a Virtual Machine to do cross-browser testing and other windows-specific things), and sure enough, we have a whole lot of nastiness. Dang. So now I rework all my z-index values like I should have in the first place, and all is good again.

This has been a public service announcement. Carry on.

[Note: This post has been moved to ThreeBit Media, my consulting website.]

I could just say “Use trailing slashes!” and be done with it.  But that would leave you, dear reader, underwhelmed and grumbly.  You may have already read this article on A List Apart regarding using trailing slashes.  In that article the author mentions three reasons for using trailing slashes when linking to directories (and I quote):

1. We’re doing ourselves a favor, as this is the correct way to do things.
2. We’re doing our server a favor, as this means less disk access.
3. And most importantly, we’re doing our visitors a favor, because they’re no longer losing a few seconds while our server tries to find first a file and then a directory. And in this industry, you and I both know that a few seconds is a long, long time.

Now this article was written in 2002 when most everyone was still on dialup and servers were much slower in general. So number 3 doesn’t really apply anymore.  In this article, I’m going to give you a new reason number 3, and go into more detail on number 1, to help you understand why this is the correct way to do things.

Read the rest of this entry »