Archive for October, 2009

I don’t get paid for this

Oct 27 2009 Published by under Uncategorized

Often, just as print designers are tasked with shepherding a project from design through production, a large group of web designers also tackle the production task of bridging the gap between photoshop and a browser with html/css coding.

Or, in the very least, they have an understanding of HOW their designs and IF their designs can be realistically, technically, implemented.

And this isn’t as easy as it may seem to the unknowing manager/administrator who may appreciate the surface value of good web design but may not understand technical taekwondo and craft involved to produce it.  It’s an unfortunate situation and is directly reflected by the compensation of web designers across the board.  Sure, some simply deliver mockups to developers.  But often our commitment to the project takes us way beyond photoshop.

Show me a print designer who doesn’t concern himself with holding a finished piece in his hands, and I’ll show you a web designer who doesn’t open a browser and nitpick.  Those people don’t exist, and/or they suck and should be fired.

Competent designers (print and web) care about the finished, “live” product.  And we must naturally concern ourselves with not only design, but production.  Not because we’re paid to be developers, but because we care.

A recent Smashing Magazine post provided a nice list of hurdles that we face when bringing design to the web, listed under the heading, “adaptive to diverse users”.  And this list, in a nutshell is what makes the transition from print to web so crazy:

  • Browser
    Is the design attractive and usable with the most current and popular browsers? Is it at least usable with old browsers?
  • Platform
    Does the design work on PC, Mac and Linux machines?
  • Device
    Does the design adapt to low-resolution mobile devices? How does it look on mobile devices that have full resolution (e.g. iPhones)?
  • Screen resolution
    Does the design stay together at multiple viewport (i.e. window) widths? Is it attractive and easy to read at different widths? If the design does adapt to different viewport widths, does it correct for extremely narrow or wide viewports (e.g. by using the min-width and max-width properties)?
  • Font sizes
    Does the design accommodate different default font sizes? Does the design hold together when the font size is changed on the fly? Is it attractive and easy to read at different font sizes?
  • Color
    Does the design make sense and is the content readable in black and white? Would it work if you are color blind or have poor vision or cannot detect color contrast?
  • JavaScript presence
    Does the page work without JavaScript?
  • Image presence
    Does the content make sense and is it readable without images (either background or foreground)?
  • Assistive technology/disability
    Does the page work well in screen readers? Does the page work well without a mouse?
  • This is not a comprehensive list; and even so, you would not be able to accommodate every one of these variations in your design. But the more you can account for, the more user-friendly, robust and successful your website will be.

Additional reading:

Dear Print Designer Doing Web Design
This is a very “blue-collar” list coming from the perspective of an XHTML/CSS coder who’s job it is to implement designs.

The Way to the Web, Print Designers!
More often than not, the reflexive approach that I’ve seen print designers take on the Web is to treat it as a vehicle for print-based design practices: fixing type sizes, specifying typefaces, ignoring usability and expediency, and perhaps most notoriously making the assumption that, over time, users will come around to a print-focused way of consuming content.

One response so far

Abandon your Quest for Hypothetical Perfection

Oct 13 2009 Published by under Uncategorized

Another great excerpt from Curt Cloninger‘s book: Hot-Wiring Your Creative Process

The Development phase:

“You can repeat the steps of the development phase forever, but at some point you will have to abandon your quest for hypothetical perfection, go with your best guess, and proceed to the implementation phase.

1. Build
2. Test
3. Revise
4. Implement

5. Market
6. Maintain and Improve

As Apple CEO Steve Jobs famously observed, “Real artists ship.”  An architect who never gets hired to design any actual 3D buildings is call a “paper architect.”  It doesn’t matter how ingenious his blueprints are: unless he actually gets some buildings built, the history of architecture will not remember him.  By the same token, real designers implement.

It doesn’t matter how well the design succeeds in the hypothetical test environment of the development phase.  How a design weathers the implementation phase is the true test of its success.”

No responses yet

Hasty blurry and ill conceived

Oct 09 2009 Published by under Uncategorized

  1. Predesign
  2. Design
  3. Develop
  4. Implement

Skipping the predesign phase and diving straight into the design phase is like taking a hasty, blurry snapshot of a still life and then devoting weeks meticulously painting from that blurry snapshot.

…As Joe Jackson sang, “You can’t get what you want till you know what you want”

Above was a quote from the Curt Cloninger‘s book “Hot-Wiring Your Creative Process“.  Below is another:

“At the end of the day, knowing grid systems, color theory, and the history of typography doesn’t necessarily make you a creative designer any more then knowing a pinch from a pint and how to operate a Cuisinart makes you a creative chef.”

Cloninger by the way, is also a lecturer of Multimedia Arts & Sciences at the University of North Carolina at Asheville

I’ll share more nuggets from his book as I progress beyond page 14.  That’s what my blog is for, right?  Referencing things from other people and producing nothing original?

No responses yet