Working on web-based projects over the years, there have been many times that I wanted the capability of using a single linked file throughout multiple PSD documents, much in the same way Adobe's InDesign has this function for large multiple page documents. This would have saved untold hours of mundane and repetitive work, as a simple copy change such as "Main" to "Home" in a large site's navigation would require only one file to be changed, instead of every single page. Unfortunately though, this was merely a dream until a discovery I had a few weeks back.

Recently, a large non-profit came to Springbox to redesign their site, a digital treasure chest of information and opportunities on a specific topic affecting millions. As you might imagine, the breadth of the content on the site was huge, with a rough estimate of more than 300+ pages.

Having worked on a large redesign recently, I had a strong desire to find a new system to allow quick updates to commonly used elements throughout the site, such as the header, the footer, a general tout layout and the styling of a call-to-action arrow. As these elements are used virtually on every page — particularly with the arrow being used 10+ times on multiple pages, changing these individual items can literally take up hours of time — even on only a handful of pages.

At this point, I must admit my great love for a half-solve to this issue — the introduction of smart objects in Photoshop. If you have not worked with smart objects, or just want a great refresher on the subject, go check out Viget Lab's great article.

Moving along, I say that smart objects are half-solve because these embedded linked files are only applicable to one page. For example, make a custom arrow, turn it into a smart object, then make copies of this smart object and distribute them to the rest of the page. A few days later the client wants to change it, just go in, change the smart object once and it will automatically change this for all instances of the smart object on the rest of the page. Magic! I love smart objects. I really do. So now we just needed to expand this functionality to reach 300 or 5,100 pages.

At this point, I did the obvious: I fired up Google to see what the internets had to offer on the subject. I found others were searching for a solution as well. All of this searching led me to the work of Mike Hale and Jeff Transberry who wrote a script to do just what I was looking for.

So here's the new workflow for a sample project, Goodness Inc., after downloading the script and installing it via the Adobe Extension Manager:

Example Site Layout and Content

Step 1  

Design the homepage with folder groupings for Header, Hero Area, Footer, etc.

Step 2

Select the Header folder in the Photoshop layers palette and choose "Convert to Smart Object."

Step 3

Double click the icon for the Smart Object in the Layer Palette, thus opening up the Smart Object as a separate document.

Dialog Box for editing a Smart Object as a separate document:

Content of Header Smart Object:

Folder Panel content of Header Smart Object:

 

Step 4

Save the Smart Object in a new folder within the project file, which I label "Universal Elements" or whatever is easiest for you to distinguish.

Step 5

When I am ready to bring in the header for a new page on the site, I go to File --> Place --> then browse to the "Universal Elements" folder and select the file.

 

Step 6

I now open up the Window pallete options, and pull up the "Links" window. I see that this Smart Object is actually a linked object. From this "Links" window, I have a few options: I can refresh the panel to get the latest link info, re-link the object, or I can edit the original.

 

The Window > Links panel, as relative to the selected layer, in this case being the "Header" smart object.

 

I then repeat the process of placing the element in all pages that need it.

Follow-Up Steps

If a week later, the nav copy needs to change from "HOME" to "MAIN," I can now edit the single source file "Header.psd" located in the "Universal Elements" folder, edit the file and save it. Then I will need to open each unique page's PSD, open the links panel, and refresh the links to see that the new element is present. Lastly, I can now save all the updated jpegs.

Not a one-step magic fix, but a timesaver nonetheless.

I do hope that in CS5, Adobe steps up their game and makes an integrated solution for this, as well as a "Character / Paragraph Style  //  CSS for multiple PSD documents" solution, but that's a different conversation.

In the meantime, a huge thanks to the great work by Mike Hale and Jeff Transberry!! This has saved me hours and hours of frustrating, repetitive and mundane copy changes. Thanks guys!

And as always, if you find an even better way to use / tweak the insights I have shared here, I'd love to hear them!

Lastly, there are rumblings of Illustrator being able to do a lot of similar things (symbols, multiple art board documents, xml-driven text fields), some of which you might soon find in a follow-up article here on the Insight blog.

DISCLAIMER: I can only verify that this works on Macs, running CS4.

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.