Monthly Archives: May 2009

Boxee, Hulu, and Corporate Lies

Posted on by
3

My favorite part of owning my own home is that have a dedicated home theater.  It’s certainly not as impressive as the basement theaters showcased on AVS Forum but I enjoy it.  I also have a dedicated Home Theater PC (HTPC) on which I run both XBMC and Boxee.  If you haven’t used Boxee, it’s a great piece of software that marries locally stored content with content from the web.  Naturally, one the great sources online for content is Hulu–and up until February 2009, Boxee had great Hulu support including forced playback of all the ads you would see were you viewing the content on the Hulu website.

In February, Hulu made the decision to block Boxee from accessing its content.  Jason Kilar, CEO of Hulu, made a passionate blog post about why Hulu was removing Boxee access.

Our content providers requested that we turn off access to our content via the Boxee product, and we are respecting their wishes. While we stubbornly believe in this brave new world of media convergence — bumps and all — we are also steadfast in our belief that the best way to achieve our ambitious, never-ending mission of making media easier for users is to work hand in hand with content owners. Without their content, none of what Hulu does would be possible, including providing you content via Hulu.com and our many distribution partner websites.

Fast Forward to May 28 when Hulu releasaes their Hulu Desktop product to copious amounts of fanfare.  While I applaud their moving forward, I can’t help but now see Hulu as a very dishonest company.

Before I get too negative here, it’s certainly possible that these content providers have changed their stance on providing alternative, non-browser interfaces to Hulu that seem better designed for a more traditional mode of viewing television content.  If that’s the case, I certainly applaud the content providers as well for embracing the future!

Unfortunately, there is evidence that the reality is that Hulu intended to compete in this space and wants to shut any potential competing technology out of its system.  Most notably is a warning dialog that appears on a mac when running Hulu Desktop stating (incorrectly) that Boxee can cause problems with the Apple Remote.  Additionally, their deliberate blocking of Boxee’s new, browser-based method of accessing Hulu through Boxee continue today.  Team Boxee has already requested that they be allowed to reintegrate Hulu into Boxee now that the situation has changed–and the response will be very telling of Hulu’s intentions.

I truly hope that this is a case of “we changed our minds,” but I fear that the situation was more about Hulu giving up 100% control over the interface than the fears of content providers.

That said, I enjoy the notion that I can now (with full support) view Hulu content on my HTPC through an interface clearly designed for television use. However, the experience is soured by not being integrated as Boxee was able to provide it.  And, of course, by the diminished respect I have for a company I appear to be unable to trust.  

TypeKit Ignites the Web Hype Machine

Posted on by
3

Taking a quick break today from the technical, I want to comment on the hype machine that’s sprung up around today’s announcement of TypeKit.  The entire post is worth reading, but the primary paragraph is:

That’s where Typekit comes in. We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Obviously, this sounds fantastic.  A legal way to use any font in our designs for the web is something that just about everyone in this business has been interested in for years.   Excitement is natural (take a look at #typekit on Twitter to see the overwhelming response).

There’s just one problem; the aformentioned blog post contains no details on how this system actually works.  It’s very light on details and, let’s be totally honest, is nothing more than a press release about an upcoming product.  I want to stress that there’s nothing wrong with being excited.  However, things take a nasty turn when the web hype machine spins up.  Andy Clarke pontificates that Typekit will change everything.  The comments on the original post are filled with quote such as:

An amazing piece of work, thanks for cutting through the issues so effectively.

Genius idea – exact solution that web needs right now! Thanks, can’t wait!

Keep it UP! Get it GOIN’! Congrats all around.

Wow this is beyond huge I’m interested to see how this all plays out.

The best news i have heard in a long time.

I don’t mean to insult Jeff or his team in any way–and I don’t want to be seen as the most cynical person on the web today; but aren’t we getting just a little bit ahead of ourselves?  Don’t get me wrong, I’m happy that they are working with the foundries and trying to find a workable solution that makes everyone happy.  But an advance press release is no reason to start a Typekit Love-Fest.

Should this solution turn out to be everything it’s promised, I’ll be the first to congratulate the team on solving one of the biggest problems that web design has faced.  Until then, I’ll leave the hype machine to its own devices and watch comfortably from the sidelines.  

Workaround: Form Submit Method Doesn’t Fire Submit Event

Posted on by
5

Recently I’ve become even more frustrated than I’ve been in the past with the disparity between Javascript Events and Javascript Event Methods.  This time it was specifically related to form submission.  Currently, despite the specification stating otherwise, browsers do not fire a submit event when a form is submitted via the submit() method.  Of course, this means if you have an event listener tied to that submit event (say, for form validation) it will never happen because the event hasn’t been fired.  However, we can work around this limitation using a little Javascript magic!

Essentially, we can overcome this limitation by using the dynamic nature of Javascript to our advantage.  Even methods that are “native” to the browser can be extended by wrapping them.  As usual, there are some differences between browsers we have to account for.  Most notably, Firefox and other browsers that adhere to the DOM Level 2 Specification support reading and writing to the HTMLFormElement object.  IE, naturally, does not allow this so we have to take a more direct approach. In the example code, we use Prototype’s Element#fire method which only allows for custom events. However, you could replace that by generating a standard event manually.

function fakeSubmit(event) {
    var target = event ? event.target : this;
    /* Fire a submit event */
    $(target).fire("form:submit");
    /* Call the real submit function */
    this._submit();
}

if(window.HTMLElement){
    /* DOM-compliant Browsers */
    HTMLFormElement.prototype._submit = HTMLFormElement.prototype.submit;
    HTMLFormElement.prototype.submit = fakeSubmit;
} else {
    /* IE does not expose it's HTMLElement object or its children
        Let the document load so all forms are accounted for */
    document.observe("dom:loaded", function(){
        for(var i=0; i<document.forms.length; i++){
            document.forms[i]._submit= document.forms[i].submit;
            document.forms[i].submit = function(event){
                var target = event ? event.target : this;
                $(target).fire("fake:submit")
                /* Call the real submit function */
                this._submit();
            }
        }
    });
}

With this in place, we can simply watch for our fake:submit event to fire and act upon it.  As I said previously, you could generate the submit event and fire it manually if you want to stick to using standard events–but this solution takes some of the cross-platform issues out of the way for you.

Edit: I’ve updated this code to fix a bug in IE6.  

Is Flash Still a Dirty Word?

Posted on by
7

One thing I don’t understand is that how in 2009 people are still put off by the use of Flash.  Seemingly dozens of frameworks have popped up to do animation using anything but Flash and none of them as well suited to the task as Flash itself.  There’s no need to recount the gross evils perpetrated in the late-90′s and early 2000′s by over-zealous marketers using Flash so we can all understand where the disdain comes from.  But today I want to ask, why does it persist?

The 37Signals Blog, Signal vs. Noise, featured a post today about the new Backpack website.  In this article, the author expresses surprise that Jason, the head of 37Signals, was not opposed to using Flash on one of their websites:

It is funny looking back on suggesting Flash for the Backpack homepage. I was a bit embarrassed. Flash is such a dirty word especially when it comes to the audience reading this blog.

Also, in the comments, you find:

Wow. You guys are developing a pretty strong reality distorting field ! ;)

and

Why didn’t you just make the final product an animated GIF (instead of using Flash on the site)?

With Flash market penetration rivaling even Javascript, why is there this notion that Flash is inherently bad?  As a big proponent of Flex, I’ve written previously about the near-ubiquity of Flash player.  With Adobe taking Flash accessibility more seriously, and many resources availble for Flash SEO, it seems that most of the common objections are becoming obsolete. Perhaps the most compelling argument that Flash is truly mainstream is that (as of this writing) Alexa cites YouTube, a site whose primary content is served via Flash player, as the number 3 most visited website globally.

As someone who is a big fan of Adobe Flex and the possibilities it presents, I truly hope that this dislike of Flash disappears sooner rather than later.  

Kickoff to Delivery: The Most Difficult Phases

Posted on by
2

Something I’ve noticed over the years of being an engineer is that project staffing tends to look something like, “Let’s get our best and brightest involved early to get the project moving–once it’s moving, the rest of the team can finish the job.“  Part of this statement shows great sense for project delivery–and the other completely opposes it.  The two most difficult phases of any project are the initial kickoff and the final delivery–and you need a different set of people for each.

Looking at the philosophy above, it is generally understood that getting the ball rolling on a project is a difficult task.  Especially in the IT world where a project may call for some new technology that the majority of your staffers aren’t yet up to speed on, it’s great to bring people in who tend to be somewhat ahead of the curve.  They serve both to lay the initial groundwork in actual code–but more importantly they support the development of the staffers that will continue the work after they leave for the next project.

The best people for this phase are your leaders, your entrepreneurs.   They’re some of your top technical people who also bring strong technical leadership to your team.  They inspire others to follow them into the project and motivate the people around them.  Most of all, they are able to charge into complex technical problems and tackle some big challenges early on and clear those roadblocks for the team while providing solid examples of how the team should proceed.

As these people move off the project, it is assumed that the team “left behind” will bring the project to its completion. However, completing a project presents the same level of challenge as starting it.  The challenges are different, but they are equally complex: fixing defects, tying up loose ends, and the inevitable realization that something that worked every time you tested it up until now has a couple of edge cases that, while not common, are possible enough that they must be accounted for in a new design. As a project approaches that end date, another personality type is required to join the team.  I call them “closers.”

Closers are methodical, detail-oriented executors.  Winding a project to completion involves fixing often very delicate defects without destabilizing the entire system (or even large portions of it).  Rather than being solid team leaders, they are usually the absolute top technical talent you have.  They’re people who have seen nearly everything that can happen as launch approaches and can maintain their calm while dealing with the challenges.  Most importantly, these closers act as a buffer between management (which is usually in full-panic mode as the launch approaches) and the rest of the team working to knock out those last few defects before launch.

We already put a lot of effort into people and process to get a project started; it’s time to pay more attention to Closing the Deal.