This face was bred for Beauty. I cannot smell a thing.
(Tiger, the Persian cat in the film Over the Hedge)
We are fortunate to be working with talented designers at mStoner, and equally skilled programmers at Global Image. Design is about beauty. Programming is about functionality. A talented designer considers usability and interaction during the design process. And a skilled programmer considers how best to preserve the look and feel of a design as he or she is programming.
But design and programming are very different disciplines. The programmer literally slices apart every element the designer created. Each component must individually be made functional.
Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.
(Frank Lloyd Wright)
And this is where skilled project managers meet with the obsessive client representatives to hash out the idiosyncrasies of implementation. The culmination of this process is a document called the Functional Specification (or Functional Spec, for those conserving syllables).
Yesterday, the re.web Implementation Team had our first conference call with our project managers—Patrick diMichele and Michael Burks—regarding the Functional Spec. An exciting two hours later, and we have a first draft covering 5 of the 12 layouts to be built within the Cascade CMS as part of our implementation contract.
Getting back to the difference between designers and programmers, here's a real-life issue we are addressing:
William and Mary decided on Concept One for our new homepage. One of the elements of this design is the Rockwell font in the tactical navigation bar (starting with Information For), the primary navigation bar (starting with About) and other text on the page, such as Education Unplugged, Events, William and Mary News and Read More News/RSS.This raises implementation questions. Since Rockwell is not a font available on all computers or browsers, should these elements all be created as graphics? Or should some of them be created as styled text with some magic web toolkit to make them display correctly. A few web programmers addressed this specific issue in 2004, creating just such a magic web toolkit dubbed sIFR.
One two-hour conference call down, and I can't yet give you the definitive answer on implementation of the Rockwell font. We will probably use creative combinations of graphics and sIFR on different layouts for different purposes.
We just thought some of you might like to know what's going on behind the glass, as we sit around the speaker-phone in our conference room,
posted by Andrew Bauserman
2 comments:
Beauty is in the eye of the beholder.
http://www.w3.org/WAI/
Maybe my eye is jaundiced, but using graphics, flash, and magic toolkits to implement a special font seems ugly.
Rockwell surely won't represent in *all* browsers.
Anonymous,
Thanks for the comment.
I notice that the Monday by Noon page you cite makes reference to CSS Naked Day. This provides me the opportunity for a quick side note.
In my rough draft for this blog post (an email to myself on April 14 - yes, I'm a procrastinator!) I included a link to CSS Naked Day. It ended up on the cutting room floor as I pared for length and focus. I guess the link has now made it in after all :)
One of the bloggers I read semi-regularly is Chris Shiflett, who participated in CSS Naked Day this year. I'd love to see more sites participate as a means for demonstrating the effectiveness of semantic xhtml.
I also noted another recent post on Monday by Noon with a reference to the Progressive Enhancement philosophy of web design. (I've pointed to the wikipedia reference). Coincidentally, this is another link in my draft which fell victim to paring down for this post. Progressive Enhancement is a philosophy Mark Windley and I definitely share.
In writing our Function Specification document, the larger concern is not which implementation option we choose (such as how to implement a specific font) - but making sure we define every element of every layout that needs functionality! This is another difference between designers and programmers: The designer knows what behaviors he or she intended a layout to have. The programmer, on the other hand, desires to assume nothing. He or she wants a Functional Specification that explains what every element on every layout does. When all of the items on the list do what the Functional Spec defined, the client gets billed :)
So, it's back to the Functional Spec for me..
--
Andrew Bauserman
Post a Comment