Workaround: Form Submit Method Doesn’t Fire Submit Event

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?

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

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.  

Emergence Drowns in a Waterfall

In July of this year I’ll be taking a class to become a certified ScrumMaster.  It will be the first industry certification that I’ve earned in my career–I’ve frankly never found them to be valuable so I’ve avoided them.  But as much as I’m passionate about building quality products, I’m even more passionate about the processes that enable building quality products.  And besides, what’s cooler than a title that identifies me as Master.

The classical model of software development follows the Waterfall Model–that is, each process completes a set of deliverables and they “fall down” to the next tier.  At least, that’s the theory.  In practice it usually works more like a set of walls that each group throws their deliverables over as they’re completed–and the team who receives that deliverable is asked to follow that deliverable explicitly.  The further “downstream” you are in the waterfall, the more frustrating this process becomes as you get further and further away from the true objective of the project.

Often we find that when we fill the requirements, we don’t really meet the objectives and happen upon a better way to meet the objective: this is called Emergence.  While attempting to reduce uncertainty downstream (often quite unsuccessfully), the Waterfall also restricts our ability to act on the Emergent Properties we discover in a system as it is built.  In my opinion, this restriction is the single largest cause of poor software design as it causes us to accept our requirements time leaps of faith over development time observations.

Emergent properties are very powerful tools to guide the way to great products and they should be embraced.  Scrum and other Agile methodologies support these properties while the Waterfall, with all pun intended, drowns them.  

Defining “Support” for Legacy Browsers

Jonathan Snook recently posted an interesting article titled Old Browsers: Do they still exist that explores the often hotly-debated topic of when it’s ok to pretend a legacy browser no longer exists.

My pragmatism comes into play, like that little devil and angel on my shoulders telling me each side of the story. The fact is, these are old browsers. Why haven’t these people upgraded? Why are all these people still using Firefox 2? So what if it’s a little (or a lot) broken for them. They should upgrade.

I think most of us as designers and developers would agree with that sentiment; they should upgrade!

The problem, as is often the case, comes from outside the design and engineering teams responsible for building these sites.  It comes from business folks and QA teams that truly believe that “support” means 100% equivalency across browsers.  Any designer or developer will tell you it’s a pipe dream and inevitably some concessions are made–but I’d be very interested to hear how much money is spent every year in this industry on trying to come as close as possible to identical cross-browser experiences.  This problem can be defined simply as a lack of consensus on the definition of “support.”

My classic argument has always been:

Cross-browser consistency is nice–but in no way critical.  The vast majority of any audience is only ever going to see your site in one browser so let’s instead of striving for identical experience let’s strive for working experience.

The core of the problem is that we, as stakeholders in our projects, are by definition not users.  As a stakeholder, we open the site in multiple browsers to test, we know the expeirence we want to deliver–and it’s easy to become frustrated when one browser behaves differently.

But to focus on the differences across browser is to ingore the truth: Your users aren’t going to see your site in every browser.   Users will experience your site in their chosen browser and any feature that is inaccessible in that browser will simply not exist in their eyes.  It’s called Progressive Enhancement, and its not a revolutionary concept.

It is, however, what can allow us to deliver a consistently working and functional experience to all users while still providing the “bells and whistles” to those who stay up to date.

Macro-level Support, that is, support for a site, is not about cross-browser consistency–it’s about cross-browser functionality.  It’s an important distinction.