The UI, if it’s well engineered, can shine a light on how professional the rest of your team’s efforts have been. Likewise, a badly designed UI can cast a shadow over what might otherwise be a really great application.

But before we learn how to find a good UI professional, it makes sense to understand what UI is and how it fits into a truly professional product.

Understanding Professional UI

You can assemble a world class Java / Oracle team who just built the most amazing technology, but if your UI has been an after thought, bad UI can make all that high-end technology look like it was written by a bunch of amateurs.

Not Just Another Pretty Face

The days of being able to use your Java or .NET people to build UI are over, actually they were over years ago, but sometimes it takes time for the rest of the development world to catch up to the technical realities.

Today’s UI developers are highly skilled, multi-disciplined specialists trained and experienced to not just add nice graphics and code HTML, but functionally design and improve how the application “interacts” with the end-user.

Professional UI is more than just nice looking graphics.

I recently worked with an IT manager of a major US corporation who told me, “We need to put some serious lipstick on this.” The problem wasn’t really their graphics, it was their workflow that needed a serious update and reworking. No amount of “lipstick” I could come up with was going to fix a blatantly bad design. They had let their Java staff design how the application would behave and it caused some serious confusion for the end users.

Awesome UI Is Not The Easy Path

The problem is that your users don’t think like programmers, and programmers usually don’t spend a lot of time thinking about, “Now, how can I make this easier for others to use?” No, generally their thought is, “How can I make this easier for me to code.”

It’s this kind of situation that results in a poorly designed amateur UI.

Well designed UI is not always easy to code. It requires that you take the time to really think through the user experience and workflow, always asking the question: “Now, how would our users really like to see this work?” Sometimes a quick DHTML pop-up or slide-down form is what would make the user experience much more smooth; but it takes a bit more time to build these little Web 2.0 gems than it would be to “force” your user to a whole new page or code and ugly pop-up browser window.

First Things First

The basic problem with using back-end developers to build the front-end part of the application is that typically the back-end people can really only think like back-end developers, not end-users. The Java guy starts the application development process by building a database. That is exactly the wrong way to approach an application.

An application that will exhibit professional UI should always begin with the public interface development first. Whether you prefer to use wireframe documents or just rough-code some HTML pages out of the gate, these initial interfaces will be crucial in determining what functionality fires and when; and what, exactly, needs to ultimately get persisted in the database and in what tables.

Ultimately, building projects this way allows for much better documentation, it saves a lot of time and streamlines the effort for the back-end guys.

Enterprise-class JavaScript

Here’s the scene: You’re the new project manager sitting at the conference table with the rest of the development team. You’ve just hired a new UI person to take the reins of your application’s front-end and deliver a product that will be a slick Web 2.0 production.

Mind you, the reason you hired a UI person in the first place is because your development team has been struggling with UI issues. The CSS is a mess, there are cross-browser display issues, and sometimes the DHTML works and sometimes it quits without warning. Your dev team has spent countless hours fumbling with these issues without a whole lot of success or the successes have come at a steep price in over-spent hours.

The discussion inevitably turns to the JavaScript and what is currently in-place within the application. Some of it is custom, some of it is jQuery, there’s an open-source piece here and purchased module for image display over there.

Okay, it’s a mess. You know it’s not working so you ask your UI pro for their input. The UI pro recommends a wholesale change in the JS library and a move to a full-stack framework. The rest of the dev team groans and begins to grumble. “Replace all this work!? Can’t you just fix what’s broken? That’s why we hired you!”

Your new UI pro simply replies, “I just fixed the problems. This is an enterprise-class application and it needs a robust framework to make the UI perform uniformly. You cannot piece these things together with scotch-tape and bubble gum. It’s all got to work together. Otherwise you end up with a mess of conflicting standards and multiple incompatible objects all trying to talk to each other through yet even more translation objects.”

“But we’re using a framework, jQuery!” the team lead insists.

Then your new UI pro drops a bombshell and says, “jQuery is not an enterprise-class framework.”

The room erupts into brash dissent from the developers who wrote the current UI. “Like hell it’s not! jQuery is the more widely used framework on the planet!”

Your UI pro allows the din to quiet. They’ve been down this road of discussion more often than they care to count, “jQuery is not the most widely used ‘framework’ on the planet, because it’s not a ‘framework’, it’s a library. Big difference.”

Clash of the Titans

The above scenario is one I have had to deal with on a number of occasions.

As a project manager you have a lot of things to manage with your project, one of the most important is what technologies will be implemented to build the application. If you have a Java or .NET shop, those decisions are easy for the backend, you use what your engineering staff know how to use.

But what do you do if your engineering staff doesn’t know what to use and really doesn’t know UI all that well? Guess? Use what’s popular?

More often than not when I come into a shop where a project is already underway, the backend team has chosen a JavaScript library for the front-end. Generally it’s jQuery. The question I ask is, “Why did you go with jQuery?” and the answer is always the same, “Everybody uses jQuery. It’s industry standard. It’s what we know.”

The last part is the true reason. “It’s what we know.” The unspoken reason is also, “jQuery is super easy and helps us speed through a lot of basic DHTML we don’t have a clue about how to write otherwise.”

One of my primary beefs with jQuery is that it hides the nuts and bolts of true JavaScript coding and forces you to code it’s way instead of in a natural object-oriented fashion the way JavaScript was designed to work. While jQuery’s syntax is fast and easy, it’s not really JavaScript, it’s a language called jQuery that’s built on top of JavaScript.

Why is that a big deal? Well for starters, I’ve worked with engineers who said they knew JavaScript but the reality was if you removed the jQuery library from the application, they were hopelessly lost.

jQuery was really the only “JavaScript” they knew how to write. Ouch.

Super-Awesome Power At Your Fingertips

If you’ve been programming in UI for any length of time then you’re familiar with Javascript’s built-in getElementById function that is used to return a single element within the DOM tree by simply passing in the element’s ID. YUI’s getElementsBy is quite simply getElementById on some serious steroids. Not only does this powerful function allow you to snap-up a single element, but it can grab a whole array of elements chosen and filtered any way you like, all in a single call.

But wait, there’s more! getElementsBy also allows you to manipulate each of the elements within your array with an optional function you supply!

Setting-up Your Page to Use YUI

First you’ll need to download and copy the core YUI files to a directory on your site. I usually like to have a /javascrpt or /js folder inside my document root that holds all of my JavaScript files. The core YUI files you’ll need will be found inside the /yui/build directory. I like to copy YUI’s /build folder to my /javascript folder and rename /build to /yui for convenience.

Now add for following code inside the <head> ... </head> tags of your page:

or you can have your page load the YUI files directly from YAHOO! using this script tag instead of the one above:

Now you’ll have all of the various YUI Core, DOM and Events functions at your command. Let’s look at what the getElementsBy function params look like:

var Dom = YAHOO.util.Dom;
var els = Dom.getElementsBy(
    function(el){ ... },
        tagname,
        parentroot,
        function(el){ ... }
);

All of the YUI functions live in the YAHOO namespace. As such, I like to pair down my code by assigning all of the Dom and Event functions to a simple reference var, like Dom. This way, I can access the YUI DOM functions with a simple Dom.getElementsBy() as we see in line 2.

Note that getElementsBy can work with or without returning anything. If you do return elements, note that unlike getElementById, getElementsBy always returns an array() of elements. Even if you will only be returning a single element, keep in mind that it will be referenced as els[0].

Line 3 is where the real fun begins. You begin gathering your elements with a simple boolean function that returns true or false. Let’s say I want to toggle a check or uncheck for every checkbox within a form. A good boolean function to use here would be return (el.type == 'checkbox');. Notice that el is an element that will get passed into this function to be tested. If the element has the attribute of type="checkbox" the function will return true and add the element to our els array.

Notice that only the first attribute of getElementsBy is necessary. The second and third parameters can be set to null. However, setting these parameters to null will cause getElementsBy to process EVERY ELEMENT on the page! This is not very efficient, especially for really large pages. That’s where the second and third parameters of this function come in handy. In line 4 of our code we can specify a specific tag name, such as input. In this way, the getElementsBy function will ignore all elements except input elements which it will then pass to the boolean function we built in the previous paragraph.

Even with this optimization, you still might want to further define where to begin your elements search. getElmentsBy allows you to optionally specify a third parameter, a root parent element to search within. If all of the elements you need to process are the children of a specific div for instance, passing in the ID string or element reference of the containing parent will limit even further where within the DOM getElementsBy needs to look.

So, with these three parameters supplied to our getElmentsBy function, we can collect a very specific set of elements, in our sample case we’re looking for all of the checkboxes, anywhere within the DOM of our page.

Putting getElementsBy to Work

Here’s where getElmentsBy becomes a real time saver. Normally, once you have built your array, you’d need to write code that loops through each of the elements within your array to do something with each element of the array; in our case we’re setting the checkbox elements to either be checked or unchecked. So why not just apply whatever function to each element as it is being added to the array built by getElmentsBy? Brilliant!

The final param of the getElmentsBy function is designed to do just that. Using this optional function, we can apply code to each of the elements being added to our final array. And we’re not just limited to checking or un-checking chekcboxes here. Anything you can do inside a function can be applied to any, all or some of the array elements.

Use this final function to selectively add an event listener, set element values and/or attributes (which is what we’re going to do with our checkboxes), or whatever.

var Dom = YAHOO.util.Dom;
var els = Dom.getElementsBy(
    function(el){
        return ( el.type === 'checkbox' );
    },
    'input',
    'myform',
    function(el){
        el.checked === true;
    }
);

One Call Does It All

So let’s show a simple function using getElmentsBy that checks or un-checks all of the checkboxes on a form.

Here’s the example:

and here’s the code:

Click me
One
Two
Three
Four
Five
    

Copy and save the page as myfile.html to see how it works!

Conclusion

While other JavaScript libraries indeed have similar functions, I really like the inherent flexibility of getElementsBy. The beauty of YUI is that it works like JavaScript is supposed to work, it’s written they way JavaScript is written. And you don’t have to memorize a whole new syntax or funky var language to use the power of YUI.

____________________________

K. Beau Beauchamp is a professional UI developer with over 15 year’s experience in graphic design, marketing communications and object-oriented UI programming. Beau can be contacted via email here.

Ж