jQuery live()

Recently, a fellow developer at Bootstrap gave a couple of talks about JavaScript and jQuery. In particular, he discussed how jQuery’s live() and delegate() methods can improve performance and reduce repetition in your code.

Normally, when using jQuery to add functionality to an element (for example, binding a delegate function to the click event of an anchor element), we’d have to write something like:

function initializeAnchors() {
	$("a").click(function() {
		functionToCall();
	});
}

However, in this example, every time a user clicks on any link on the page, all of the anchor elements on that page get processed. One way to optimize this is to call this function for an explicitly-passed anchor:

function initializeAnchor(anchor) {
	$(anchor).click(function() {
		functionToCall();
	});
}

The downside of this approach is that whenever we add a new anchor element, we would have to specifically call this function to bind that anchor’s click event to the delegate.

As a result, we would have to call initializeAnchor(thisAnchor); and initializeAnchor(thatAnchor); over and over in our code, leading to bulky code that is difficult to maintain and error-prone.

As of version 1.4, jQuery introduced the live() and delegate() functionality.
This means that you no longer need to bind a delegate to an event after creating an element.

Instead, every time an element is created that would have been selected by jQuery, the specified event is automatically bound.

Let’s try it:

$("a").live("click", functionToCall());

Now, all anchor elements that are ever created will call functionToCall() when they’re clicked. We’ve solved the problem of having repetitive code, but we haven’t solved the performance problem.

The issue is that the selection process that jQuery runs is a very expensive operation, because it must parse the entire DOM before returning its wrapped result set. The live() method runs this selection process every time it gets called (which, in this case, is every time a new anchor element is added to the DOM.)

This is where delegate() comes in.  If, for example, we know all of our anchor elements will reside within a div element with a class of dynamicAnchorsDiv, then we can use delegate() to improve the performance of our JavaScript substantially. That’s because delegate() lets you bind a target function to the events of specific DOM elements, rather than the entire tree.

This gives us:

$("div.dynamicAnchorsDiv").delegate("a", "click", functionToCall());

This code will execute functionToCall() whenever an anchor element in our div is clicked, without requiring us to bind that event ourselves and without jQuery running through the entire DOM each time. The final bonus of using deletegate() is that it’s methods are chainable, one of the greatest benefits of jQuery in general.

What does that mean? It means that we have to write less code, which lowers the risk of introducing bugs, makes updates and enhancements easier to write, and brings lots of happiness to developers like us.

Useful resources for front-end development

There’s plenty of great resources out there for front-end development, especially for those developing on the side of HTML5/CSS3 and progressive enhancement in mind. Here are some bookmarks I have on-hand whenever I’m working on a project:

  • HTML5 Boilerplate – A rock-solid default template for HTML5 awesome.
  • HTML5 Please - Look up HTML5, CSS3, etc features, know if they are ready for use, and if so find out how you should use them – with polyfills, fallbacks or as they are.
  • HTML5 Cross Browser Polyfills
  • CSS3 Please! - The Cross-Browser CSS3 Rule Generator
  • CSS3 Click Chart
  • Modernizr - an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.
  • LESS - LESS extends CSS with dynamic behavior such as variables, mixins, operations and functions.
  • Google Web Fonts
I look to these pages for finding an ASCII/Unicode equivalent before I resort to cutting up in Photoshop:
Here are some great articles/examples of code and inspiration I like to read:
Jeffrey Chew
Director of UI Design & Development

 

Why Do Software Projects Fail?

Today I was reading an article titled “Why Big Software Projects Fail: The 12 Key Questions” by Watts S. Humphrey. It was a very interesting read indeed and inspired me to follow up on the subject.

It is no secret that the history of software development is littered with colossal failures. Reasons and excuses are many and you can find them all over the place. Probably if you lift a rock in the desert you’ll find an excuse for a software development project failure underneath. There are cases where the excuses are valid but truth be told, in 99% of the cases the reason are simply human factors.

According to Watts S. Humphrey, the main problem with software development is managing visibility. In his own words:

Why Is Management Visibility a Problem for Software? The problem is that the manager cannot tell where the project stands. To manage modern large-scale technical work, you must know where the project stands, how rapidly the work is being done, and the quality of the products being produced. With earlier hardware-development projects, all of this information was more-or-less visible to the manager, while with modern software and systems projects it often is not.

Some people might argue that this is an overstatement and at some point it is. Managers usually have a rough idea of where a project stands although not with the precision required by large projects. With small sized projects this is tolerable and these kinds of projects are usually a success, however as Humphrey say: “… as projects get bigger and communications lines extend, precise status information becomes more important.”

Along the same line we can say that another big part of the problem is change management. When we go to a car dealer to buy a new car we can tell him the brand, the model and what accessories we want and he will probably give us exactly what we asked for. Lots of the stuff we buy in the real life is like this, we just acquire a product that someone else made for us to consume.

With custom software development, most of the times this is not true and we can’t apply the same rule.  We have to think of a software project as a living entity that evolves and changes with time. What was right today might not be tomorrow, the requirements change as our clients’ business needs change. If we don’t take this into consideration most likely the project will fail.

So, if things are like this; if the statistics are against us and most of the projects fail, are we all doomed? Should we pack our bags, go home and forget about software? Sometimes I tempted to do so and open a grocery store in some tiny town in the country… but I digress.

The real question is what can we do to win this fight and deliver a successful software project? This might sound naïve but I think the answer to that question is with trust and a sense of community and collaboration. All the parties involved, including managers, developers and client all alike need to trust each other, stay in permanent communication and have a strong commitment towards a project success. If any of these conditions isn’t met the project will most likely fail.

In my next blog post I’ll talk the current trends in the software development to help avoid these common problems, live long and prosper in this business and don’t die of a heart attack when you turn 35.

- Pablo Bessone

Easter Eggs

Part of developing a site or deliverable is adding fun easter eggs in your work. For the longest time, “Rick Astley” has been the ongoing username used in our wireframes. Sometimes, when a video placeholder is needed, you would even see the first frame to Mr. Astley’s iconic video.

When we developed our redesigned website, we also had a bit of fun.

Doctype
Back in the days of HTML4 (although most people are still living in it), it was required to declare the DTD (Document Type Declaration) after the “public” keyword. However, this is optional for HTML5. These days, the only thing we care about is to declare the doctype at all, just so Internet Explorer doesn’t drop into quirks mode:

<!doctype html>

So now, the quotes after the public keyword can be customized to however you like. As an example, if you go to html5boilerplate.com, you’ll notice that they customized their doctype with a star.

Go ahead and check out the source for our site, as well as this blog. Here’s a hint of what you’ll find:

Shake It Up
Another great feature that gives a new dimension of interactivity is the “devicemotion” event, which can detect the x/y/z motion of a device with an accelerometer. On your iOS, Android, or even Macbook with an accelerometer, try shaking your device on our “Who We Are” page.

Jeffrey Chew
Director of UI Design and Development

Redesigning BootstrapSoftware.com

Over the seven years I spent with Bootstrap, I’ve seen the company grow from a development company, to a fully evolved team that provides everything from well-defined discovery, smart development, and a refined maintenance/support process. During that time, I was able to add usability and information architecture to the many services that Bootstrap provides today. However, one of the bigger milestones for both Bootstrap as well as my career was the birth of the Creative team last year.

As with any client’s redesign (or initial design for that matter), it’s important to understand the business goals, objectives, identity, and overall brand. Our creative process includes many steps and deliverables in order to identify these points, as well as a game plan on how to achieve the client’s needs. We deemed Bootstrap Software as a client, and treated ourselves no differently.

The User Experience

As part of our research, we studied the competition as well as applying what we know about our previous site visitors. We identified the target user personas, then began to structure how we want to deliver our message using UX design and information architecture techniques.

In parallel to this, we generated and explored various mood boards to get a better idea of the look and feel we wanted to achieve.

Based on feedback and several iterations, we were able to determine the general feeling we wish to convey to our visitors, as well as how our visitors can find the information they need quickly. This brought us to two different design directions; circle and square.

As with any design process, iterations can conceivably go on forever. We tasked ourselves with defining the pros and cons of each direction, then ultimately deciding on one. From there, we took the things we liked from the other and applied more detailed iterations. The end result is the site that you see today.

Interaction Design
The look and feel is only half the battle when it comes to design. What the user sees has been established, now how about when the user starts clicking around? One of the continuing mantras said throughout the discovery process was “no flash”. The whole Internet industry is abuzz with “HTML5”, and we wanted to flex our muscles as a company to show some of the latest and greatest your browser has to offer.

It’s easy for a designer to get carried away with how a site should behave in their mind. This is when it’s important to sync with a front-end tech lead on what we can and cannot do, according to the browser scope of the project. Storyboarding the site interactions is important to convey these ideas, either by conceptual or detailed wireframes.

In the past, we were accustomed to developing the “pixel-perfectness” from browser to browser. However, the industry is gradually seeing the importance of delivering speed and good UX over visual or functional consistency. This is why progressive enhancement is Bootstrap’s approach today over yesterday’s idea of graceful degradation.

Progressive Enhancement
As a front-end developer, I was no stranger to browser sniffing and conditional behaviors. I still cringe when I think about how much Netscape 4’s DOM differed from Internet Explorer. As part of progressive enhancement, the idea instead is to set a baseline that all browsers can understand, then go from there. We use a couple of tools in order to achieve that “reset”, then feature detection:

Because we want to develop our site using HTML5 semantics, it’s great that Modernizr includes an HTML5 shiv that will allow “oldie” browsers like IE6/7/8 to interpret tags like HEADER, NAV, SECTION, etc. For anything more complex, we use Modernizr’s feature detection to determine if the user’s browser can handle certain code. Because our site is almost completely based on CSS3 transitions, here’s one we used multiple times:

if (Modernizr.csstransitions){
     // do some awesome stuff
}

CSS3
Everyone talks about HTML5. In layman’s terms, when a user sees something that is accomplished without flash, it’s easy to say “oh, that’s HTML5”. Well, that’s partially right. By definition:

HTML5:
(n) 1. The next version of HTML. Its core aims have been to improve the language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices

In general, HTML5 is the combination of HTML, CSS, and JavaScript. A good chunk of the “magic” in Bootstrap’s new site is in CSS3, both rendering and animations. Because we chose the “circle” route, the site heavily uses rounded corners on elements. If you look at the http requests on our site, the only images that are loaded are the employee images, carousel images, and logos.

Another added benefit of CSS3 transitions is that animations are hardware accelerated. If we tried to achieve the same kind of animation on the “Who We Are” page using JavaScript, the page would get choppy. We made use of the “translate3d” attribute for transitions especially so webkit browsers will take advantage of the acceleration. Try using one of the dropdowns, then repeatedly clicking one of the options.

Google Chrome Frame / IE[x]
The benefit of progressive enhancement is that the site will still generally look fine even on the most stubborn of browsers (i.e. IE). Short of forcing the user to switch to a different browser entirely, another option we give our users (for those viewing our site in IE7 or below) is to install a plug-in called “Google Chrome Frame”. This was developed by Google, and is a plug-in for Internet Explorer that generally makes it behave like Chrome. The added bonus is that it automatically updates, just like Chrome. It installs in seconds, and the user can see all of the new and fancy things that Chrome has to offer, while still browsing comfortably in a browser they have grown used to using.

Although realistically we still need to support the browsers our clients task us to develop for, we hope that this “solution” catches on. As we’ve developed more HTML5-friendly sites, the more we’ve realized that IE[x] is the new IE6. Paul Irish, one of the developers on the Google Chrome team and leading front-end developers of the industry, has a great write-up on this.

Responsible Web Development
Whether if we’re developing a generally small site like ours, or an enterprise level web application, we always hold ourselves to the best practices of web development. The front-end in particular is rapidly becoming more robust, and can become unwieldy and harder to maintain when losing focus on how it is built. And with this great power, it means that much more responsibility that falls on the developer.

Wrap-up
Any project can easily stray off the path, especially in our own site redesign considering this project has a very close emotional attachment to all members involved. That is why our process played a crucial role in moving forward with our milestones and eventual site release. It also doesn’t hurt to have a stellar team working beside you every step of the way.

Jeffrey Chew
Director of UI Design & Development