Those of you who read Engadget, or follow tech blogs, or are otherwise incredibly geeky, have surely heard of the Optimus Maximus. Vaporware for years, Engadget has finally got their hands on one. The verdict?

Typing on it, well, sucks.

This is a shining example of people building tech products that appeal to geeks, but overlooking the most basic, important functions. Sure, it’s nice to look at, and it sounds really cool to hot swap your keys. But, if it can’t type, then what good is it to anyone? What, I’m supposed to have two keyboards at my desk? One for typing, and one for … having little pictures? There’s a reason the iPhone is also a great phone.

At $1500 it might not matter, because only crazy people are going to buy one anyway.

My good friend Brian sent me a link to his demo reel yesterday, which he uploaded to Vimeo. I’d never heard of it before, but I was impressed with the site.

The most obvious reason to fall in love with Vimeo is the quality of the videos they are serving up. Default quality looks leaps and bounds better than YouTube’s video, but the really great part is that they offer HD video in full 720p. The quality is really amazing. For Brian, this was a no brainer — after all, who wants their demo reel to be viewed in a super compressed low quality format?

Brian used Vimeo to make himself look better, and I decided we should too. We already had YouTube search integration in our upcoming product, so I decided to take a look at Vimeo’s API and integrate some results from their site too. It only took about an hour to get everything hooked up and working, using the same system we had already built for YouTube, and the higher quality video really does make our app look better.

Since we were going for quality, we wanted to highlight the search results that came from an HD source. Unfortunately, there was no way to determine whether or not a video was HD with the current API. I decided to send an e-mail to the contact listed on the developer pages, Ted Roden. Within minutes, Ted had responded saying that he thought having an HD flag in the response was a great idea, and first thing the next morning, I had a message in my inbox explaining how the new information worked.

But the story doesn’t end there. A few hours later, after realizing how long our searches were taking, I fired off another e-mail to Ted asking for a few tips to speed things up. You see, the design of their API was such that search results only contained a video id, and a separate call was needed to get the full information for each video object. On top of that, yet another call was needed for thumbnails, and since we use two, that was 3 calls per search result. Needless to say, the overhead from all those requests added up pretty quickly, so I wanted to know if there was another way to get the same job done. Ted responded and asked what information I needed in the search results to do what I was doing, and I let him know. An hour later, he posted this to the Vimeo forums, and sent me a message letting me know that the search results could now return all the information about every video object in one call. The average time for one of our searches was sped up by an order of magnitude!

And so I just want to highlight the excellent support I received from Vimeo, and Ted. Sometimes startups can be really amazing to work with.

A while ago, the New York Times had an article about cold brewed coffee that peaked my interest. I’m not much of a coffee drinker, but iced coffee is, on occasion, a pretty exceptional summer time drink, so I filed the article in the back of my mind for future reference.

Some time later, Francisco, aware of my irrational love for Dunkin’ Donuts (or, more accurately, my rational hatred for Krispy Kreme), brought back a few bags of Dunkin’ Donuts coffee for me from his trip to New York. Not having a coffee maker, or any desire to drink it really, it sat in the cabinet for a few months, until yesterday.

The weather is already pretty nice again here in Cupertino, and combined with the discovery of this article, I had no excuse not to give cold brewed coffee a chance. Substitute taco bell cups (gross) for a couple red cups, recalculate the ingredients proportionally, and I was ready to go. 24 hours later, I’m enjoying a great cup of iced coffee that was practically free (compared with $2.80 at that other coffee place)!

A picture’s worth a thousand words, so here’s 5k (courtesy of iPhone).

A lot of people working on web applications these days seem to be oblivious to the rest of the world beyond their own team. Naturally, most of these people are using Firefox to do their browsing, and subsequently to do their development and testing as well. This makes sense, given, well, just about everything about Internet Explorer (and the fact that only about 5% of us own macs). Unfortunately, the browsing public at large is nothing like these people.

Depending on who you ask, Firefox’s share of the browser market hovers somewhere between 15 and 20%, while Internet Explorer dominates with 70% or more (and Safari is slowly building ground at around 6%). Given this, I have to ask, why on earth do developers think its okay to write Firefox only software? If asked, most of them will tell you, “Oh, I’m just a startup, I don’t have time to invest in IE,” or “the market I’m going after all uses Firefox.” I’m not buying.

Except for the most demanding of projects, making something work in IE is hardly the burden people make it out to be. Sure you have to spend extra time to workaround the missing pieces, or the flawed implementations, but if you wait until after you’ve launched a product, you’re going to have to spend weeks or months in “compatibility” development, where you write zero new features. Meanwhile, you’re turning away 80% of the potential users of your product, and many of them will never come back.

At the other end of the spectrum, it’s highly doubtful you’re really targeting people who only use Firefox. Even if you had done market research, which you almost certainly haven’t at this stage in the game, at the very least you’re likely talking about a group of people who use Firefox and Safari, in which case you really should have put in the extra effort to at least make Safari work. The differences between Firefox and Safari, at this point, are miniscule — in most cases it is trivial to make something that works in Firefox work in Safari. And if you buy the argument that Safari users are very similar on average to Firefox users, you are still excluding as much as a quarter of your potential market not working in Safari. But, like I said, this probably doesn’t even apply to you, because it’s highly unlikely you can know for sure what percentage of potential users are using Internet Explorer.

Of course, there may be exceptions. Legitimately complex applications, or incredibly focused markets, for example, might validate focusing on Firefox alone (or preferably with Safari). A good example of this is recently launched Heroku. This team has tackled a hard problem on the client side (an in browser text editor) that could be difficult to reproduce faithfully in Internet Explorer. Furthermore, by targeting Ruby on Rails developers specifically, they probably are talking about a smaller market that is likely to use Firefox more than Internet Explorer. But even Heroku, who’s goal is to bring Rails to the kind of people who don’t want to go through the hassles of deployment on their own, is probably shutting out at least some potential users who would honestly try it out, if it worked in the browser they were using. It is difficult to say how many, but analyzing their own traffic, they may be able to get a good idea. (Aside: since the rails community seems particularly Mac friendly, this might make an even stronger case for having Safari support, though, in some of my own research, it has seemed that some of the Firefox features they rely on for text selection may legitimately not have duplicates in Safari).

Ironically enough, many of the same people who would advocate Firefox only support, would outright refuse to use a service that was Internet Explorer only. Yet somehow, they cannot manage to imagine a user who would not be immediately willing to go download a new browser, and fundamentally change their online behavior, just at the opportunity to try out the “next big thing” on the web.

I don’t have anything to say today, except the fact that I’ve gotten rid of some cruft from the site, in the beginnings of bringing it back. I even linked it up to rossboucher.com instead of having it relegated to blog.rossboucher.com. Thus, in theory at least, I will force myself to use it.

Major changes: a new header image (taken at the conservatory in Golden Gate Park), no more silly navigation to a bunch of useless empty pages, and a solid color background. All in all, not much, but its enough of a refresh to satisfy my desire to redo the whole thing for a while, which allows me to focus on the more important things going on right now (which we’ll discuss later).

That’s all for now.