The earthquake that struck Haiti was (and remains) a heart-wrenching catastrophe by any measure. When the news first broke, the outpouring of aid — in mass or by individual text message — was an illustration of human compassion. But help is still needed. As a designer, I wanted to lend my talents to the cause.

Thread & Water is a group of designers working with The Water Project, a non-profit dedicated to bringing relief to communities around the world who suffer needlessly from lack of access to clean water.  On the Thread & Water site, you can purchase T-shirts and prints created by designers. I contributed a design to the site. All of the proceeds go toward providing clean drinking water for Haitians affected by the earthquake. You can follow Thread & Water on Facebook and Twitter.

It's a worthy cause. Every donation helps, as the rebuilding process is likely to take years.

Last week, Developer Josh Kemmerling wrote about his perspective on collaborating with designers. As Josh mentioned, he and I recently collaborated on the AMD Collateral Generator project and integrated a solution he proposed early into the project. Hearing each other's expertise at the conceptual phase of the project no doubt contributed to a stronger product for the client. I'm thankful that Josh felt the freedom to speak up and offer his point of view on the project.

It's a shame that in our industry designers and developers are timid to freely express ideas to each other's camps. I believe this timidity results from the overall flow of a project, which generally begins with a discovery phase, then proceeds to brainstorming, then to creative, development, testing and finally deployment. Because the creative portion occurs before the development stage, developers sometimes are not as involved in the project until comps are completed and ready for production. This usually means that the project (up until that point) has been seen by account service, creatives and possibly one developer who may have been involved at the discovery phase of the project, which hardly ever delves into the nuts and bolts of execution methods.



What I believe should occur, whether dictated by a company’s processes or not, is full-on, two-way communication between the creative(s) and developer(s) assigned to that project during the brainstorming and creative phases. While I believe strongly that a creative needs to have a firm understanding of web technologies, they must be willing to hear the expertise of their development team and facilitate in creating an environment of freely expressing ideas. 



Developers and creatives must continue to hone their skill-sets and work on building trust in each other's expertise. Beyond this, I believe it's the responsibility of both parties to have their finger on the pulse of the latest web technologies and trends. This means there might be times when a creative will have learned of a new technology, process or technique that the developer hasn't learned yet — and the creative should feel free to pass on that knowledge. In such a situation, it's imperative for the developer to be open to hearing this from a creative and not feel like the designer is stepping onto their own turf (and vice versa). 



Communication is vital and one of the most important ingredients to the success of any project, especially between a developer and a designer. A free exchange of ideas must take place at the onset of a project. We can't afford to work in silos. Our clients are counting on the best we can produce and that comes from collaboration and freedom of expression.

Arial. Georgia. Verdana. Courier New. The list of safe, compatible fonts for the web has been very short, for many years. See them in action at Typetester. Much to the delight of designers, developers have been coming out with ways to remove the barrier between all typefaces and HTML. Although this might not be a good idea, let's take a look at:

@font-face CSS
The Solution: This CSS code allows visitors to download fonts from the site's server and display them on a webpage. When it's not supported, users see alternate html text (Arial, etc.) instead. Pretty neat stuff. Check out Font-Face.com, Mozilla's article, ALA's CSS-at-ten article, Tangerine's post, and this W3 page.
The Challenges: Licensing and compatibility are the biggest roadblocks. Many foundries don't license their fonts for the web, so you're stuck with free fonts (good luck!), this short list, and maybe these, too. Some browsers support @font-face and others don’t, and some take fancy footwork (Internet Explorer 4.0+ —  I'm talking about you and your EOT file format. Check out this post about how to achieve cross-browser support.

Typekit
The Solution: Using @font-face, Typekit offers a library of licensed fonts that consumers pay to use on their websites.
The Challenges: Browser-compatibility issues. Moderate pricing. Fonts may render poorly at 72-100 dpi screen resolution because they were designed for 300 dpi. And, while they have about 400 fonts available right now, they're missing good ones — the entire Hoefler & Frere-Jones library, for instance.

Foundry Example: Typotheque
The Solution: Typotheque is a font foundry that offers web licensing directly to their customers, who can use @font-face to implement them.
The Challenges: Browser compatibility issues. High prices  — a web license for one font runs around $26, so you better really love the way that font looks!  Also, all your favorite foundries will need to have a web license option if you want to use your favorite fonts.

sIFR (Scalable Inman Flash Replacement)
The Solution: sIFR is a flash-based solution that uses a .SWF, CSS, and JavaScript to render typefaces in HTML. Learn more: Davidson's overview, see an example, browse the official forum, and generate sIFR online.
The Challenges: Although it's compatible with 90% of browsers, it won't display your custom fonts if users have Flash or JavaScript disabled. They'll see standard HTML text instead. Plus there's no support for mobile, yet.

Typeface.js
The Solution: Typeface.js is a simple JavaScript-based solution that embeds custom fonts into a webpage.
The Challenges: You have to use fonts in TrueType/OpenType, so the JavaScript can read it. Licensing is still an issue. Very poor cross-browser compatibility: Anything before Firefox 1.5, Safari 2.0, or IE 6.0 doesn't work. Also, body copy will bog down page loading, and there's no link-hover support.

So, what should designers do? Since @font-face and sIFR both support standard HTML text replacement in the event your custom fonts don't display, I recommend trying it on the headers of your next web project. See if it's worth the extra effort for you and your client.

Creating web experiences is a perpetual process. Having a team of skilled tacticians and established processes is paramount to success. This article examines how one framework, the 960 Grid System, streamlines time to launch from two different viewpoints: The designer’s eye and the developer’s expertise.   

The Designer’s Side

Web designers will tell you that regardless of how beautiful your site design may look as a jpg, the translation process from comp to browser will make or break your design’s success. For years, designers have relied on grid systems to create harmony and balance in their designs, and while they are invaluable and fairly easy to work with once set up, recreating that same structure in a browser is a challenge, especially when you factor in page rendering inconsistencies among browsers. That’s why a CSS framework like 960 Grid System is a godsend.

960 Grid System provides designers with a variety of templates that are pre-sized and contain guides set up to either a 12-column or 16-column grid layout. These templates not only help speed up the preliminary steps of design but also ease the hand-off to the developer, as the framework provides consistencies between the comps and the code. 

Not every web designer is fluent in CSS, HTML, PHP or other programming languages, so we often rely on developers or frameworks to see us through the coding phase of a project. However with the 960 Grid System, the framework is so carefully constructed and documented that it empowers a designer to tackle the front-end development of a project, only requiring minimal understanding of mark-up languages. It also gives designers peace of mind in knowing that the things we slave over, i.e. spacing and making sure everything lines up properly (imperative for a successful grid layout), are taken care of automatically via the framework.

The Developer’s Side

At some point, web developers end up reusing the same code over and over, repurposing it for different situations and applications. When it comes to front-end code, the most reused code is a reset CSS of some sort. Once a reset is created, most developers will rewrite the same CSS, modifying it to fit their current needs.

Enter the 960 Grid System. A CSS framework made to streamline front-end production, the 960 Grid System enables developers to build websites designed on a grid efficiently and effectively. Plus it requires the developer to use an object-oriented CSS, thereby meeting better web standards and fostering cross-browser compatibility.

Springbox’s most recent use of the 960 Grid System was on a comprehensive redesign of the Unicast website. The site design called for a width of 960 pixels, so it was an ideal candidate for using the grid system. Since everything was consistent from the beginning, days of time were shaved off of both development and testing.

In the end, the 960 Grid System is a win-win: you get fewer CSS errors and less time is needed for coding and testing. What more do you need to build a nice site quickly?

Art Director Phil Coffman and Developer Josh Kemmerling co-authored this article.

Here’s a presentation I saw recently about the “fold” and whether it matters as much as designers (or clients) may think. I don’t think we should abandon our concern for the fold, but I do think it doesn’t carry as much weight as it did six or seven years ago. Plus, the point made in the presentation about how users are consuming sites on a greater variety of devices (mobile for example) with different screen sizes and resolutions is important to remember and underlines the fact that the traditional notion of the fold is changing.

Obviously, it’s up to agencies to educate clients and make layout considerations per project as to how the fold comes into play. Web standards are constantly evolving, and the old adage that “everything must be visible above the fold” needs to be examined in the light of current online conventions.

 How are you handling the fold these days?