Skip to: Navigation | Content | Sidebar | Footer


Full Archives

HicksWorld | June 28

You get the feeling some days that Jon Hicks is taking over your life?

View on Flickr › | 8 comments

A Book About Design

June 27

A mini book review, in response to a fantastic youth-oriented design book found while out browsing this past weekend.

A good eye can't be taught, but solid design principles can. As someone who recently put together just over 300 pages of design writing (among other things), you can bet I appreciate a book that does it in a fraction of that.

Aimed at a younger crowd, the simple writing style and accompanying illustrations of A Book About Design : Complicated Doesn't Make It Good make it an ideally approachable book for any budding young designer. But don't let the intended reading age of 9 to 12 fool you, the lessons contained within are relevant to any age of reader.

The simple setup of this book allows for surprising clarity, which you can see for yourself with Amazon's Search Inside this Book feature. Textual pages sit on left-hand pages, with full-page diagrams on the right. Case in point: the mini-chapter about contrast runs three or four pages of teaser text with completely black facing illustration pages on each, and then the fifth page slams a giant white number 3 in the middle of the black pages to drive the point home.

For such a brief read, it covers a surprising amount of ground in a no-nonsense, visual way. If you can take the principles in this book to heart, you can safely sleep through the first few months of design school. That's bang for your buck. For the simple and subtle way this book accomplishes what it sets out to do, I give it a ten out of ten.

Permalink › | 14 comments

Open Source Design?

June 20

As the open source philsophy continues to make sense to me, I wonder how I should be applying the same principles to my own work.

"Openness" isn't generally a concept you'll find as a driving force in graphic design. Which is interesting, as today a designer's output has parallels to the world of software, perhaps more than to the world of art.

A few decades ago, a designer's final product was almost exclusively a physical item, such as the pasted up art board, created manually using actual tape and rulers and paper and the like. The originals would (presumably, since I wasn't around then) be retained by the designer, for the sake of extra commission when it came time to revise or reprint.

In the last decade or so, the move to online publishing has made that artboard a digital item. Anyone still working in print will ultimately go on to create a physical final product, but those of us working with the web are creating purely digital work, from start to finish.

So when I see interesting articles on the adoption of open source in the world of software, as in Steven Garrity's The Catch-22 of Open Format Adoption series, I have to start thinking about my own creative output, and how open or closed it should end up being.

It's probably important to make a distinction here—when I say I'm considering openness, I'm not saying I want to see my work re-used by those who haven't paid to have it developed. So I'm concerned exclusively with the openness between myself and the client in question, not myself (or my client) and the general public. None of this should be seen as carte blanche to re-use work I (or any other creative studio) have done for a client.

That said, there are two major forms of output I produce, the original source material (in the form of PSD and AI files), and the coded HTML/CSS templates that I end up handing off to the client. In my contracts I outline that the final code becomes the possession of the client, to do with as they please. Though I make sure to grant myself limited promotional rights for the sake of displaying previous work—an important thing to ensure, make sure to do so if you aren't already.

This means they can take the HTML/CSS and apply it to the site I designed it for, in any way they see fit. By extension, this also means they can potentially modify or reuse the templates on other sites under their control, resell them to other companies, open them up for general use for the public, or whatever else they wish to do. Some designers will inherently bristle at this level of openness; I'm okay with it, for now.

What I'm left wondering, though, is what about the source files, the PSD and AI files themselves? Should I hang on to them for the sake of charging an extra commission the next time they need to change a graphic or two? Should I give them the same access to the source as they have to the front end code, so that they can do it themselves? And if I do, how much will the quality change once someone other than me is modifying my source?

By limiting the openness to final templates, I've (intentionally or not) added a bit of a barrier for re-use. The images need to be re-created in order to change them to something else; the quality will inevitably suffer for that. By providing the originals, I can ensure a higher level of quality when changes are being made.

It's a bit of a Catch-22. Either I give up my working copies to ensure quality remains high (and therefore lose my control over the re-use), or I hold on to them tightly and just accept that quality will suffer when the files are re-used. Some will argue that work for hire means all materials produced should be handed over to those who commission them, regardless. I'd agree, provided that's in the contract; if the contract says otherwise, then it's a moot point.

I've been writing about this issue rather inquisitively to consider the options, but I've long decided my take on this issue. I agree that work for hire should mean that those doing the hiring get the full results of the work. I believe it's in both mine and the client's best interests to make source available to them, if they so desire. I'm willing to give up small amounts of control to keep the relationship open, and I'm willing to place a bit more trust in their hands that they won't drastically mess up the design in the process.

What I've found, though, is that this opens up a whole series of time requirements. Naturally, offering my input along the way can do wonders to ensure the quality remains high. But where does that input start and end? Should I be giving Photoshop tips to help them recreate the graphics in question? Should I split up each individual GIF and JPG for a site into its own PSD, so they don't need to second-guess the image-slicing process? Should I be documenting and cleaning up my PSDs in order to make them easier to understand?

I've been discovering that the time I spend supporting the source is a not-insignificant factor. While I think those hiring my services deserve to have access to my work, I also prefer not to spend half my waking hours supporting that work when I could just do the updates myself in a fraction of the time.

So what's the actual solution here? I'm still not sure; I've been trying various things to make it worth the while of both myself and the client. It may be releasing the work as unsupported source, or it may be charging a nominal fee for giving them access to the source and some of my time to support it. I'm pretty sure there isn't a one-size-fits-all solution, at any rate. Some will need the extra support, while some clients will have design departments with Photoshop users who are probably more knowledgeable than I am when it comes to working with PSD files.

What do you do? How does it work for you?

Permalink › | 42 comments

Dating Requests

June 10

No, not that kind of dating. Due to popular demand, a quick explanation of the date boxes on this site's home page.

Whoa. I don't know what happened, but all of a sudden I'm getting three or four inquiries a day about the little date boxes on this site's home page, which have been around for, what, a year now? Some want an explanation, others want permission to use them. So this is both at once for my reference and yours.

Markup

Fundamentally, only two HTML elements are needed to pull this off. One container, and an additional element to surround the day. In my case I've opted for spans. (You could add a link, but I haven't because I only just now thought that might be a good thing to have.)

<span class="calPage">
  Jun 
  <span class="day">8</span>
</span>

You may prefer different markup; I'm sure there are a thousand interpretations out there of the best or most semantic way to represent a date in HTML. Of particular note is a microformat called hCalendar which, taking my best shot, might look something like this:

<span class="vevent">
  <a href="/archives/2005/06/08/simple_templ/" class="url">
    <abbr class="dtend" title="20050608">
      Jun <span class="day">8</span>
    </abbr>
  </a>
</span>

It's doubtful whether this is an appropriate use for hCalendar though. I'm sure someone will clarify in the comments.

CSS

Anyway. So now that we have some basic HTML to work with, the CSS needs to do its thing. Making use of Sliding Doors and a couple of strategic images, the container span gets the top edge, the date container gets the bottom, and both are set to display: block; and constrained to a fixed pixel width to make it work. Plenty of font styling later, and this is what you have:

.calPage {
	display: block;
	font-size: 10px;
	line-height: 1;
	text-align: center;
	text-transform: uppercase;
	text-shadow: #fff 1px 1px 1px;
		// only safari renders text-shadow
	color: #BDBDBD;
	background: url(/i/ice/deco-date1.gif) 
		0 0 no-repeat;
	margin-top: 0;
	width: 35px;
	padding-top: 5px;

	position: absolute;
	top: 20px;
	left: -40px;
}
.calPage .day {
	display: block;
	font-weight: bold;
	font-size: 20px;
	letter-spacing: -2px;
	text-indent: -3px;
	text-shadow: #bbb 2px 2px 0;
	color: #ddd;
	background: url(/i/ice/deco-date2.gif) 
		bottom left no-repeat;
	padding-bottom: 5px;
}

Because the markup is so thin, the complexity has been moved to the CSS. I'm not going to explain the basic font formatting or box model in any detail, since that's more or less copy-and-paste-able. What does need a bit of explanation is the positioning.

These dates are placed with absolute positioning, not floats; this is probably why some have been having trouble figuring them out. The positioning is based on the parent elements which contain the dates, because those have been positioned as well.

A quick refresher on this concept is over at Stopdesign, Making the Absolute, Relative. Basically, the parent element (in this case, <div class="post">) is given the position value position: relative;, but not actually positioned with top or left values. The sole reason for doing this is so that when I later absolutely position the dates, they don't start positioning from the top left corner of the page, they start from the top left corner of the container block, which is div.post.

Movable Type

And because it's also been requested, here's the Movable Type template code to have it generate these:

<MTDateHeader>
  <span class="calPage">
    <$MTEntryDate format="%b"$>
    <span class="day">
      <$MTEntryDate format="%e"$>
    </span>
  </span>
</MTDateHeader>

Permission

So here's my permission to use this date formatting for whatever purpose you wish. You'll want to create your own images, because the background images I use (1, 2) blend in with this site's slightly off-white background; they won't do much on a white background. But otherwise, feel free to play with the markup and CSS in this article, and re-use it elsewhere.

Permalink › | 23 comments

Simple Templating

June 8

Simple static site templating with a CSS focus.

I use a very lightweight templating system of my own devising on this site that strikes me as something that might be of value to someone, somewhere. No database required, although you could certainly use one in conjunction with this method if you feel so inclined.

This is pretty basic stuff, so feel free to skip this one if you're an old hand at server-side scripting. Then again, it sets up a lot of the CSS tricks I use around here, which may prove interesting even so.

Around 1998 or so, I maintained a semi-large site for a local ISP which grew pretty quickly, so templating was largely a matter of global find and replace. It was painful, to say the least, and the discovery of server-side includes, or SSI, was a rather important event for me back then.

If you're not familiar, SSI was a method of allowing one file to include another. The practical upshot of which is that you can keep common site elements in one place (like, say, your site's navigation). You need to change a navigation item? Change one file. Blam, you're done. Convenient.

Thanks to SSI equivalents in server-side scripting languages like PHP and ASP, you can go further than just static files, too. Variables may be passed back and forth, and certain files may be included on some pages, ignored on others. It's pretty powerful stuff.

My system on this site (which uses PHP, but once used ASP, so the concepts themselves are portable if not the code) consists of taking a comprehensive HTML file, and deciding what's meat and what's filler. The filler can easily be pulled out into a separate file, leaving only the meat within each individual page, which is as minimal as possible. On this site, I've determined that the page headers, sidebars, and footers are all filler. The sidebar and footer appear next to each other in the markup, so I've combined them into a single file.

So a typical page might look something like this:

<?php
	$pageTitle = "page title here";
	$pageClass = "secondLevel nosidebarPlease archives";
	include($_SERVER['DOCUMENT_ROOT'] . '/includes/header.php');
?>

	<h1>mezzoblue</h1>
	<div class="contentarea">
	  <p>This is where the page content would go.</p>
	</div>
	
<?php	
	include($_SERVER['DOCUMENT_ROOT'] . '/includes/footer.php');
?>

And that's about it. No navigation, no sidebar, nothing but the content. Everything else is offloaded to external files. What might one of those files look like? Let's open up header.php and see:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" id="www-mezzoblue-com">
<head profile="http://gmpg.org/xfn/11">
 <title>mezzoblue  §  <? echo $pageTitle; ?></title>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

 <link rel="stylesheet" type="text/css" 
   title="mint" href="/css/wintermint.css" media="screen, projection" />
 <link rel="stylesheet" type="text/css" 
   title="mint" href="/css/wintermint-print.css" media="print" />
 <link rel="Shortcut Icon" type="image/ico" 
   href="http://www.mezzoblue.com/favicon.ico" />
 <link rel="alternate" type="application/rss+xml" 
   title="RSS" href="http://www.mezzoblue.com/rss/index.xml" />
</head>

<body class="<? echo $pageClass; ?>">

<div id="container">

<div id="intro">
 <div id="pageHeader">
  <h2><a href="/">mezzoblue</a></h2>
  <h3>Design, Typography, and the Web</h3>
  <h4><abbr title="International Standard Serial Number">ISSN</abbr> 
    1708-0789</h4>
 </div>

...

...and so on, right up to the line where the h1 would appear, were the HTML flattened. So everything you see up to that point when you view source, that's all being generated by the header include file. There are some things going on in this included file that deserve a bit more explanation.

First of all, the page title:

<title>mezzoblue  §  <? echo $pageTitle; ?></title>

Within this line, there's a snippet of inline PHP that simply ouputs the value of the $pageTitle variable where indicated in the markup. If you'll recall the earlier example of a content page, there's a line that sets this variable:

$pageTitle = "page title here";

This way, I can easily specify the title of any page within the page itself. Likewise, I've decided to give myself the ability to apply custom body classes for any page on the site:

<body class="<? echo $pageClass; ?>">

And again, the values for this script come directly from the page itself:

$pageClass = "secondLevel nosidebarPlease archives";

There are similar variables set up for the footer as well, but the last thing I'd like to touch on is the custom CSS method I use.

Because I find it handy to be able to import a style sheet on a whim, and because the head element is locked up inside header.php, I need to take a similar approach for these as well. Sure, I could just use the variable method above, but what if I want more than one CSS file? It has happened, so I'd better prepare for that contingency.

Arrays are a natural fit here. Stocking them is relatively easy; as with the other variables mentioned, this code just needs to land before header.php is included in the page:

<?
	$customCSS[0] = "/css/custom.css";
	$customCSS[1] = "/default.css";
	$customCSS[2] = "/css/articles/june-2005-1.css";
?>

And of course, something ultimately has to be done with those files in header.php:

<?
if ($customCSS) {
  $counted = count($customCSS);
  for ($i = 0; $i < $counted; $i++) {
   echo " <link rel=\"stylesheet\" type=\"text/css\" 
	title=\"mint\" href=\"" . $customCSS[$i] . "\" 
	media=\"screen, projection\" />\n";
  }
} ?>

Basically what this last snippet does is count the number of values in the array, and add a link for each one. Setting it up this way allows me to add as many CSS files as I need, without having to think about it.

This method of templating is just one way of doing it that happens to suit my needs rather well. You could also reverse the process and store your include files in one main site index file, which then loads content from a database; in that case, the individual files wouldn't even have to exist if your server was capable of mod_rewriting. But we'll leave that for another day.

Permalink › | 61 comments