Colophon

After twelve years of designing and developing for clients ranging from multi-billion dollar sales corporations to sole-proprietorships on a shoestring I say the difference between good and evil lies in delivering value in every context. Efficiency in development. Pragmatism in strategy. Profitable returns on business investment.

Tools

Downloadables

Reference

Dogma

How

My primary role on Web teams for the past years has been UI Developer, working as a sort of hinge between the functional and visual roles of each project team. First, I work with designers to spot potential browser support issues or UI coding pitfalls based on art direction. Then I work with Java engineers to integrate and debug good markup, style and scripts into the application layer.

At times, the process requires a measure of diplomacy. I ask about design decisions then ask business requestors about expected returns while considering user scenarios and make suggestions for alternate approaches when there's room for improvement. My priority as a technical creative liaison is to be a reliable connector between creatives and engineers. Like ligaments and tendons in the human body.

Workflow

Over the years, I've developed an informal workflow that starts with Art Direction, moves into Page Construction, and ends with Application Integration. My involvement as a UI Developer begins by looking at the designer's choice, moves into producing HTML/CSS and Javascript pages or modules and ends when the cross-browser pages or elements have been successfully integrated into the application. Each phase has its caveats and I've got a short list I use to speed up development and reduce debug time in the last half of the project.

Art Direction

There's no shortage of tool-driven UI work on the web. And anyone who's laid hands on Photoshop has dabbled with the dark powers of the gradient tool or bevelled a few buttons now and then. I'm not running for office asking for votes to ban the bevellers and the gradient addicts. They're in their own bracket. And the businesses that like that sort of thing get just what they like when they contract (an apropos term, indeed) such service providers. My cause overlaps the interests of the providers and requesters alike; the designers and the companies they design for.

For art, first I say, "so what!". Then I ask, "who cares". In the case of poor design, the answer to both usually leads to a personal preference or a group agenda. Relationships or impulses. Take the business owner who's wife reviews the corporate web site and suggests a different color pallet to match her personal fashion preferences. Forgoing collaboration with the design team or proper review of business, branding or functional requirements, the outside opinion is internalized and pushed into production because of a relationship. The bonds of matrimony usurp those of reason, at times.

If, as a designer, I fail to kill my darlings, chances are the solution isn't as good as it could be. I'm experiencing this right now in the redesign work on my own site. For some reason I've become infatuated with a newspaper-like grid. The typography. The clean columnar layout. The thin lines and blocks. I love that "look and feel". The problem is the content and business role of my site doesn't fit that art direction. There's no reason to lay out my site in some elaborately minimal typographic columnar glory. Forcing it into that direction would create an unpleasant dissonance between presentation and its functional purpose. Most of the time it makes a difference. Sometimes, though, the users, the target audience can't tell the difference, which makes all the fuss worthless.

I'm always trying to figure out if this whole business of UI/UX and web building is worth the fuss. Always.

Page Construction

This phase is often referred to as Static Prototyping. Essentially, it's the work of converting a Photoshop file into an HTML file that looks just like the Photoshop file in each supported browser.

Big deal. Few humans know what this is or care about it. Why should they, anyway? Well, there's the rub.

Most of us UI folk have perused Mr. Zeldman's writings and have become marginally convinced that doing things in a consistent way makes more sense than reinventing the process for each HTML document. I think Web Standards is a good thing. Coding good HTML is a craft. It's not glorious, but it does reside in a category of superior nerdery deserving of a good golf clap. Good page construction makes site and application maintenance a manageable hassle. So, it's important to me, personally.

I make it a point to avoid the overuse of div's and spans and try to stick to straight-forward HTML document structure. Incorporating a nice CSS framework isn't a bad idea, either. It helps smash down the margins, padding's, line-heights and all the random nonsense proprietary to each browser before reconstructing their values to minimize cross-browser variances.

Application Integration

People do what they love rather than what they hate. If they have a choice. Java engineers included. Integrating HTML, CSS and Javascript is sometimes frustrating for these alien folk, so I do my best to help out. I typically store static pages and assets in a versioned directory of the application so I can track changes and roll back if needed. The Java team can also access the statics and use them as a reference when things go south in the application. The benefit of maintaining a static version of each major UI is twofold: 1) Java engineers cut-and-paste the markup into the app components and replace static text with JSP (or what have-you) tags to bring the thing to life; 2) I refer to them when I debug trouble spots in the application.

Priority

My priority is refining my approach during each phase in order to increase the value I add to the team. So far, I'm satisfied with the responses to this approach and I hope it's helpful to you.