php-horde-feed 2.0.1-4 / usr / share / php / tests / Horde_Feed / Horde / Feed / fixtures / lexicon / http-www.mezzoblue.com-rss-index.xml

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:admin="http://webns.net/mvcb/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:content="http://purl.org/rss/1.0/modules/content/">

  <channel>
    <title>Dave Shea's mezzoblue</title>
    <link>http://mezzoblue.com/</link>
    <description></description>
    <dc:language>en-us</dc:language>
    <dc:creator>dave@shea.net</dc:creator>
    <dc:rights>Copyright 2008</dc:rights>
    <dc:date>2008-07-16T11:42:53-08:00</dc:date>
    <admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=3.35" />
    <admin:errorReportsTo rdf:resource="mailto:dave@mezzoblue.com"/>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>

    <item>
      <title>Domain Registry Scam</title>
      <link>http://mezzoblue.com/archives/2008/07/16/domain_regis/</link>
      <description>
       This morning&apos;s mail brought me a renewal notice from my domain registrar. Except, wait.
      </description>
      <guid isPermaLink="false">1425@http://mezzoblue.com/</guid>
      <content:encoded><![CDATA[
       <p>I was about to Flickr this and leave it at that, but then I remembered oh yeah, I've got a web site.</p>

<div class="image-holder-left medium">
<a href="http://mezzoblue.com/i/articles/2008/jul/domain-registry-canada-scam.jpg"><img width="420" height="210" alt="Domain Registry of Canada is a big old scam" src="http://mezzoblue.com/i/articles/2008/jul/domain-scam.jpg"/></a>
</div>

<p>This morning's mail brought me a <a href="http://mezzoblue.com/i/articles/2008/jul/domain-registry-canada-scam.jpg">renewal notice</a> from my domain registrar. The currently-dormant personal nameplate domain I've been sitting on is coming up for renewal at the end of the year, so they're <em>really</em> staying on top of it by sending me the renewal notice during the summer.</p>

<p>Except, wait. Domain Registry of Canada? That doesn't seem right. This domain was registered with a US-based company. I don't have any business with Canadian registrars that I'm aware of.</p>

<p>I've been hearing about this tactic for years, and received one or two of these in the past, so it didn't take long to conclude that, yes, this is a scam. Even though the notice is deceptively formatted to look like an invoice, the wording tells me exactly what's going on (emphasis mine):</p>

<blockquote>
<p>"When you <strong>switch today</strong> to the Domain Registry of Canada..."</p>
<p>"...and now is the time to <strong>transfer</strong> and renew your name..."</p>
<p>"Domain name holders are not obligated to renew their domain name with their current Registrar or with the Domain Registry of Canada. Review our prices and decide for yourself. You are under no obligation to pay the amounts stated below, unless you accept this offer."</p>
</blockquote>

<p>They've obviously spent time honing their text so this practice may not run afoul of the relevant consumer protection laws. The company has <a href="http://www.synuk.com/droa/">been at it for years</a> in other countries with multiple legal proceedings in the past, so they've had the time to get it right. It may be that the notice I received is technically legal.</p>

<p>But I still think they're scum, and this is a scam-like practice whether it's legal or not. They're obviously counting on people to focus on the invoice and ignore the text. (<a href="http://www.useit.com/alertbox/9703b.html">Web users skim</a>, they don't read, right?) With an official-sounding name like "Domain Registry of Canada" it's easy to understand how their targets might not pause to consider that this company isn't in fact the one they originally registered with (do you actually consider your domain registrar more than once a year?). If someone web-savvy like myself has to seriously think about what's going on here, how many average small business owners or office administrators do they sucker annually?</p>

<p>There may be legal recourse here, but I'm willing to bet that if they're still doing it after all these years, they've managed to figure out how to avoid prosecution. So there's not much to be done aside from wasting 50 cents on a stamp for their return envelope to return them a personal <abbr>F U</abbr>. Ineffective and useless to be sure, but if I can kill at least a fraction of a second of their anticipation of taking in another sucker while they open the envelope, to me that's good enough.</p>
       
      ]]></content:encoded>
      <dc:subject></dc:subject>
      <dc:date>2008-07-16T11:42:53-08:00</dc:date>
    </item>
    <item>
      <title>Design Notes</title>
      <link>http://mezzoblue.com/archives/2008/06/10/design_notes/</link>
      <description>
       Time to dive back in to the Bright Creative redesign I wrote about last week, and focus on some of the good stuff that came out of it. Most people got it; but for anyone who misinterpreted my laundry list...
      </description>
      <guid isPermaLink="false">1424@http://mezzoblue.com/</guid>
      <content:encoded><![CDATA[
       <p>Time to dive back in to the <a href="http://brightcreative.com/">Bright Creative</a> redesign I <a href="http://mezzoblue.com/archives/2008/06/03/design_rants/">wrote about last week</a>, and focus on some of the good stuff that came out of it.</p>

<p>Most people got it; but for anyone who misinterpreted my laundry list of rants from last time, that was just some healthy critiquing of my own work. It's a good idea to step back every now and then and judge what you do with a critical eye. The truth is I'm very pleased with the way this redesign came off. Here's why.</p>


<dl>

<dt>jQuery</dt>
<dd>
<p>I'd like to thank the star of our show, <a href="http://ejohn.org/">John Resig</a>'s fabulous <a href="http://jquery.com/">jQuery</a> library. No doubt you noticed the portfolio page effects, with sliding and zooming and fading and the like. Yep, that's Javascript. No Flash here. I've only been playing with jQuery for a few months now, but it's already one of those "how did I live without it?" tools.</p>

<p>To me it's the difference between avoiding Javascript as much as possible, and embracing it whole-heartedly. jQuery abstracts away the hard stuff like DOM incompatibilities, leaving me free to write fairly basic script to accomplish what I need. And the CSS-like selector syntax is absolutely wonderful. I've already learned that so it's building on what I know. I'm still not convinced I'm much of a scripter, but writing with jQuery makes me feel like I'm actually somewhat in control when it comes to Javascript. And the joy of seeing my script work as expected first time 'round across the board when testing in various browsers? Undefinable.</p>

<p>With this design I wanted to see what kind of useful user interaction effects I could pull off with some jQuery magic. I had a vague idea in mind to use sliding portfolio pages, echoing something I did with the previous design's thumbnails. But I also wanted to treat the slideable area as real content with enlarged previews and live text. I looked at a few canned scripts that seemed to do what I wanted, including some jQuery plugins like <a href="http://www.ndoherty.com/demos/coda-slider/1.1.1/">Coda Slider</a> and various lightboxes, but ended up needing a bit more flexibility. So I rolled my own.</p>

<p>There's nothing particularly new or clever about my implementation, but it came together nicely. I have a bunch of <code>div</code>s in the page source that are assigned the class <code>item</code>, and in my CSS file that class is treated as a non-scripted element by default. I'd hoped for graceful degradation when Javascript is disabled, and the default rendering without script is actually somewhat usable. It's not great, but it works.</p>

<p>Then on page load, the script does a bit of work to change that default and get the page ready for interaction, things like adding new classes and then re-positioning the <code>div</code>s based on those classes. The resulting style of the elements updated by the script is still handled in the CSS file as a new set of classes, triggered by that scripted changing of the class. That's the ideal, but I did need to script some of the positions, so there are a few spots where hard-coded pixel values ended up in Javascript. I'm sure there's a way to make it more elegant, but that's as far as I got.</p>

<p>The actual slide effect happens by giving each individual item in the portfolio a sequential position within a horizontal series of items, and then updating the <code>left</code> value of each based on which item the user is currently viewing. The current frame has a <code>left</code> value of 0, the next is 750, the one after that is 1500, and so on. Frames prior to current are negative values, ie. -750, -1500 and so on. And then by declaring <code>overflow: hidden</code> on the parent frame I'm hiding the inactive items and only showing the active item so you never see more than one at a time. This allow lets me slide things in and out of the frame without more tedious clipping calculations, something I'd far rather let the browser handle.</p>

<p>That was the quick easy way to do it, but it also led to the expandability problem I wrote about in the previous post; I can't use <code>overflow: auto</code> in the portfolio area to allow for a scrollbar when the user resizes the text, because the <code>div</code>s intended to be hidden by the overflow end up forcing scrollbars and making a mess of the page. The unscripted version allows this, but the scripted version doesn't. Oh, sweet irony.</p>

<p>The larger previews triggered on click are also added with script; in an unscripted state these are simple links to images that open in the same window, a fairly clumsy way of doing it, but at least the unscripted state is functional. Again by manipulating the classes in script, I change those links into positioned target areas that have an <code>onclick</code> event which pulls in the target image of the link as the contents of the pop-up area. There's a nice jQuery fade effect too, though the first image load usually takes longer than the fade so the effect looks more like a vertical slide-down than a fade. But once that baby is cached after that first click, watch out. Fades for everyone.</p>

<p>Something a little more subtle than the portfolio effects is the logo and primary nav hover glowing animation. This is a trick I demoed at An Event Apart last month, and I'm about 2/3rds of the way through formally writing it up. I'm using jQuery to take your basic <a href="http://www.alistapart.com/articles/sprites">CSS Sprites</a> setup and add animation effects to produce a smoother transition between off and on states. It's a tiny bit more involved than that, as you'll see if you dig into the source. But keep your eyes peeled for the article, there will likely be a pre-built function that abstracts anything remotely difficult about it. Oh, and yes, it gracefully degrades to plain old CSS Sprites.</p>
</dd>



<dt>Copywriting</dt>
<dd>
<p>Updating the copy was a big reason for redesigning the site. The previous version was built at a time when I didn't have a clear idea of what the business would be in one, two, or five years. Since that time I've figured out what it is I want to do and how I do it, but the site didn't reflect that. I'd been handing out an intro PDF to new clients for a while to fill that gap, but it's the sort of information that really needed to be directly on the site.</p>

<p>I ended up scrapping almost everything that existed before, and changing the voice from an impersonal royal "we" to a much more direct "I". This didn't come easily; it was hard to adjust to talking about myself in the informal first person on an ostensibly professional site. But I often get email starting out with "I'm looking to contact Dave Shea", or "do you guys offer such and such a service?", so I realized it was time to kill the ambiguity.</p>

<p>There were two items I felt a bit conflicted about putting out there. In my previously private PDF I had included details about pricing and process that would be helpful for prospective clients, but it's the kind of information that people in our industry don't generally publish on public-facing sites. I have some theories why this is, and they're not <em>all</em> to do with competition, but the result is the same in any case. I decided to go ahead anyway, a decision which I don't know will prove to be a good or bad idea long term; we'll know for sure if it ends up going away one day.</p>
</dd>



<dt>Design</dt>
<dd>
<p>The visual design was actually one of the least important things I needed to accomplish this time around. When I began planning this redesign, I tackled the scripting and copywriting first, and only opened Photoshop after I had a pretty clear idea of what the content was going to be. You know, the same sort of expectations you'd have of a client; I believe the phrase we're looking for here is "<a href="http://en.wikipedia.org/wiki/Eat_one's_own_dog_food">eating your own dog food</a>".</p>

<p>Somehow I ended up building a colour scheme derived from primaries, though the red, yellow and blue are not exactly full saturation, and the brown of the content area serves as more of a neutral in this case. Previously I'd been using brighter shades of red and yellow, so there's some consistency with the past, but the blue was a new addition this time for the sake of more interesting colour contrast. The overall tone is a lot darker than last time, but that feels like a good change.</p>

<p>This visual design isn't a huge departure either; the previous one had a bit of a gritty, non-pristine feel to it that I wanted to continue using. I went for broke on the texture and detail work, but that ended up causing some fun layering challenges. After the Photoshop work was done, I spent some time looking at the design wondering how in the world I'd build it out into something that would work in a browser. In the last post I mentioned that transparent PNGs would have spared me some headaches, but I don't feel like I can yet thanks to IE6. So I went with GIF images instead, which caused a lot of tedious matching of foreground and background images.  Saving a transparent GIF to sit on top of a solid colour is easy; saving one with texture that must precisely align with a second background texture while fading out into transparent areas is... not so much.</p>

<p>For example, the portfolio's white stage area sits on top of the page's background texture. Its drop shadow and frilly decorative bits have varying levels of opacity, something GIF obviously can't do. To simulate this I had to save the background texture into the image itself, which forced precise alignment of the foreground and background images. I <em>could</em> have gotten away with simply flattening my Photoshop file and saving out the background with the image as a big non-transparent rectangle, but that would have made the site's already-large image profile even larger. So I dropped what background I could by first hiding the background in Photoshop and saving a preliminary transparent 1-bit GIF to basically create an outline of the foreground area, then loading that GIF back into Photoshop and using it to create a mask for the background, then saving the combined foreground + background combo out together into the final GIF. It looks <a href="http://brightcreative.com/i/ui/portfolio-showcase.gif">like this</a>.</p>

<p>There are also some extra little details I added to try and elevate the HTML-based text to something a bit more interesting. I applied <code>text-shadow</code> to the various headers and links for Safari's benefit. Primary <code>h2</code>s on the site have a very faint PNG absolutely positioned over top that fades in the background texture a little, resulting in a semi-transparent almost gradient-like look. Getting the PNG gamma to display consistently was a challenge; my first attempt worked well in Safari, while the overlay was too obvious in other browsers. So I had to tinker with various colour output settings and finally got something that seems like a good enough compromise. The PNG is still somewhat visible in all browsers, but faint enough that I can live with it. (and I did a lot of Googling for workarounds; what you're thinking of suggesting? I tried it.)</p>
</dd>


<dt>Contact Form</dt>
<dd>
<p>Finally, one of my favourite bits from the site, the <a href="http://brightcreative.com/contact/">contact form's</a> Stress-o-meter. This was a fun little idea I had in mind from the beginning, but it was the last thing I built because I wasn't quite sure how to make it go. Design-wise, there are three levels: <a href="http://brightcreative.com/contact/?stresslevel=low">Low<a/>, <a href="http://brightcreative.com/contact/?stresslevel=med">Medium</a>, and <a href="http://brightcreative.com/contact/?stresslevel=high">High</a>. The higher it gets, the more distressed the meter looks.</p>

<p>Luckily it ended up being easier to build than I expected. There's a simple text file sitting on the server with a date in it. Every time the contact form is viewed, I have a PHP script that opens that file and reads the date. If today's date is within a certain number of days from the previous date it will display Low, and if it's above that range it shows Medium. There's a second range it checks that will show High. I'm still working on precise values, right now Medium is 5 days and High is 10.</p>

<p>That's it for the viewing part, the updating part was pretty basic too. I've created a cron job on the server to run a second script every couple of days. That script sends me an email asking me whether I want to update the meter, which is just a link to a third script that replaces the contents of the text file with today's date. If I don't hit the link, nothing changes, and the previous range checking script will compensate. That's it. Simple. I'm still wondering if various spiders are going to find the update script or not, but a permanent Low status on the meter would be the only real side effect so I'm not terribly worried.</p>
</dd>

</dl>
       
      ]]></content:encoded>
      <dc:subject></dc:subject>
      <dc:date>2008-06-10T13:23:09-08:00</dc:date>
    </item>
    <item>
      <title>Design Rants</title>
      <link>http://mezzoblue.com/archives/2008/06/03/design_rants/</link>
      <description>
       Last night I launched a long-needed redesign of my business site, Bright Creative. The site had been languishing for years, but fact is, it is a business and I do keep my contract work at arm&apos;s length from what goes...
      </description>
      <guid isPermaLink="false">1423@http://mezzoblue.com/</guid>
      <content:encoded><![CDATA[
       <p>Last night I launched a long-needed redesign of my business site, <a href="http://brightcreative.com/">Bright Creative</a>. The site had been languishing for years, but fact is, it <em>is</em> a business and I do keep my contract work at arm's length from what goes on over on this here site, so I decided to keep it rolling along instead of folding it all into one.</p>

<p>Of course then I got ambitious, so it's been in the works for months while I've tweaked. Designing for yourself is never easy, is it? I feel like I could spend the better part of a month continually tweaking and making improvements, but I finally hit the point where it was "done enough" to launch.</p>

<p>While this is design work I'm quite pleased with, I still see things I think could have been done better. It might be more interesting to write up my notes on those first, so I'm going to do this in two parts: first the rants below, then I'll follow up with another post on the parts I'm happy with.</p>

<dl>

<dt>Typography</dt>
<dd>
<p>I had this grand goal of keeping all my text in HTML and avoiding image-bound text or sIFR entirely, while avoiding looking like HTML text if I could help it. I looked for effects and typefaces that might accomplish that, and landed on Microsoft's ClearType set. The headers were going to all be Candara, and the body text all Calibri, and that looked pretty nice in Photoshop.</p>
<p>But oh, the pain when trying to get a browser to duplicate it. Firefox OS X does not render Calibri well <em>at all</em>. Seriously, <a href="http://mezzoblue.com/i/articles/2008/jun/bc.gif">what is this</a>? The kerning is all over the place, and look at that crazy overlapping of the link on the right; there's no fancy letter-spacing happening in my CSS that could explain that, it's just what 13px Calibri does in Firefox.</p>
<p>So I found a CSS hack that would allow me to keep the Calibri in Safari, and step down to Lucida in Firefox... except that the x-height of Lucida is quite a bit larger, so the type size contrast in the two versions was not equal. Since those without the most recent versions of Office or Windows don't have Candara/Calibri anyway, my fallbacks weren't going to work well either.</p>
<p>I ended up scrapping Calibri and running with Lucida for the body text. The headers are still Candara, or Georgia if it's not installed; I did save some Candara into an image for the top navigation despite it all, but the headers throughout are styled HTML text (more on that in the follow-up).</p>
<p>And after all this ordeal it felt like the finely-grained type control I had carefully planned got away from me; I have three different type sizes for body copy in various spots, when I only intended to have one or two at most. It's all still functional, and looks okay at a glance, but I still see areas where it should be a lot tighter.</p>
</dd>

<dt>Readability</dt>
<dd>
<p>I <a href="http://twitter.com/mezzoblue/statuses/825771558">put up a link</a> on Twitter last night, and one of the most frequent pieces of feedback I've had since was that text contrast was too low, the brown-on-brown is hard to read. Yep, guilty.</p>
<p>Embarrassingly enough, I spent most of my design time on the <a href="http://brightcreative.com/portfolio/">portfolio</a> and home pages, neither of which have excessive text on the brown textured background. And then when I started working on content pages like <a href="http://brightcreative.com/services/">Services</a>, I realized there was a problem.</p>
<p>Since then I've gone back in and smoothed out the background behind the main text area on content pages, so there's less distracting texture. It still suffers from a text contrast issue, but short of brightening up the entire background texture, that's probably as far as I'll go.</p>
<p>One thing further compounding the matter is the anti-aliasing method used to render the text. With sub-pixel rendering everything appeared a bit darker and thicker, and that really helped the contrast. However, the fades and animation effects I've used in parts of the site caused flickering between sub-pixel and regular anti-aliasing, a <a href="http://mezzoblue.com/archives/2006/12/12/opacity_bugs/">known issue</a> where the best fix is to manually force regular non sub-pixel anti-aliasing by setting the opacity of the parent element to 0.9999. As soon as I kicked this in, the readability took a big hit.</p>
<p>I'm not sure if/when I'll come back to this issue; it's not something I'm totally happy with, but it's also something I may end up just having to live with. (<a href="http://snook.ca/technical/colour_contrast/colour.html">Automated contrast checkers</a> tell me the brightness contrast is okay, though I think you and I both know just by looking at it that it could be better.)</p>
</dd>

<dt>Expandability</dt>
<dd>
<p>You'll notice in some parts of the site, resizing text in your browser causes it to expand gracefully, but it falls down on the home page and the portfolio pages. I always try to design for text expandability, but those two pages had to be the exception this time.</p>
<p>There were a few factors at play here. For one, my image sizes are already large (see below), and creating even more for expanding text areas was starting to feel a little silly. And absolute positioning on the home page in order to overlap textures seamlessly caused me to force hard pixel values for text area heights. I did think of trying an <code>overflow: auto</code> kludge to force a scrollbar in the portfolio, but the script for the sliding pages just doesn't allow that. Interestingly, turning off script allows <code>overflow: auto</code> just fine, so the expandability issue goes away when Javascript is disabled. That's a lovely bit of irony.</p>
<p>I don't really have a good fix for this one. I ran out of ideas, so no text expandability. But I feel really bad about that, so the guilt makes up for it, right? Right?</p>
</dd>

<dt>Markup</dt>
<dd>
<p>Yeah, so, viewing source is going to get you a whole mess of extra wrapper <code>div</code>s and such. I had a lot of images to layer, it had to happen. Did you know that you can nest your <code>div</code>s so deep that <a href="http://www.getfirebug.com/">Firebug</a> stops working properly? I do now.</p>
<p>The real shame of it is how unnecessary most of them are. With multiple background images ala <abbr title="Cascading Style Sheets Level 3">CSS3</abbr>, I could get away with far, far fewer. But alas, I live in a world where supporting IE6 is still necessary, so I'll just keep my dreaming to myself while I propagate the useless <code>div</code>s throughout my markup.</p>
<p>Also, you may notice a bunch of empty <code>&lt;i&gt;&lt;/i&gt;</code> pairs here and there. These are as semantically neutral as reusable empty <code>div</code>s or <code>span</code>s, only with less characters. That's a trick I picked up from <a href="http://meyerweb.com/">Eric Meyer</a> along the way, I think in conjunction with the <a href="http://alistapart.com/">A List Apart</a> redesign, though I'll be damned if I can find the post in question now.</p>
</dd>


<dt>Images</dt>
<dd>
<p>I still have this philosophy about using the <abbr>PNG</abbr> format &#8212; it's great for throw-away images that I can effectively hide from IE6, but for core site UI elements, it's still GIF all the way. The alpha hacks and colour profile issues just aren't worth it. So I had to find fun and creative ways of overlapping compex faded imagery with 1-bit transparency. The amazing thing about doing it this way? IE6 testing was actually fairly painless this time around. I did not expect that.</p>
<p>The upshot, however, is that I've got 556k in images for the primary UI elements alone, not to mention the 6MB of project-related images. I'm not saying all that would go away with PNG transparency, but I bet I could shave off a few bytes. This is the sort of site where heavy imagery isn't a huge ordeal, but still. A half meg of images rubs over a decade of image optimization practice the wrong way.</p>
</dd>

</dl>

<p>I think that about covers the ranting. Next up: the fun scripted bits, the design notes, the copywriting, and more.</p>
       
      ]]></content:encoded>
      <dc:subject></dc:subject>
      <dc:date>2008-06-03T11:35:50-08:00</dc:date>
    </item>
    <item>
      <title>Handoff</title>
      <link>http://mezzoblue.com/archives/2008/05/21/handoff/</link>
      <description>
       A few months back at SXSW I sat on a panel that discussed how designers and developers play nice together on web projects. One of the things I never got around to mentioning was the system I use for handing...
      </description>
      <guid isPermaLink="false">1422@http://mezzoblue.com/</guid>
      <content:encoded><![CDATA[
       <p>A few months back at SXSW I sat on a panel that discussed how designers and developers play nice together on web projects. One of the things I never got around to mentioning was the system I use for handing off my static design work to clients and their developers for integration into their dynamic systems. Since I've been thinking about it a bit more in the past few weeks, I figured I ought to put this out there.</p>

<p>I prefer to start in Photoshop, and keep most of the big picture design work there if possible. I find designing with CSS leads me to make decisions based on what's easiest to code, whereas moving things around the screen visually gets me better results. Your mileage may vary.</p>

<p>During the initial design process, my mockups for client preview are delivered as flat image files. Each is given an increasing version number like <code>home-page-v3.png</code>, and by about v3 or v4 I'm usually pushing for signoff to start coding.</p>

<p>Since most sites involve multiple page templates, I'll often be concurrently designing some while coding others. The first one or two I do set the stage, so I try to pick templates to code that involve as many visual elements and layout variations as I can so that I'm thinking about the possibilities from the start. I'll build out those first few, then package up the HTML, CSS, and various image files into a ZIP archive and deliver that as <code>code-v1.0.zip</code>.</p>

<p>The developer will take that and start implementing that, while I move on to designing and coding out the rest. I'll build new ZIP files as I finish new templates and increase the version number of the archive. Each subsequent ZIP file is meant to totally replace the old. My instructions are basically, take these updated CSS and image folders and dump them on top of the last round.</p>

<p>The HTML poses a bit more of a challenge though; the new versions do replace the old static versions, but by at this point the developer I'm working with has started integrating them with their system, so it's not quite as simple as overwriting pre-existing folders. There's more manual work involved for them; they need to run a <code>diff</code> and apply the changes to their development version. Not a huge task, but a least a little more overhead than overwriting folders.</p>

<p>There's also an assumption built into this process: I own the CSS and image folders, and will be the only one making changes to them. In cases where the developer has needed the ability to modify CSS at will, it's proven a good idea to create a separate running development CSS file that ends up being integrated with the rest near the end of the project. Images could work the same way, though I usually find those are self-correcting; if the developer needs their own image folders outside of those I've built they'll figure out how to make it all work without my intervention.</p>

<p>And there's definitely a side-discussion here about designers using version control systems like Subversion. I've personally adapted to doing so, and what I'm describing above is kind of a manual way of doing the same thing. But the advantage to this system is that it firmly places the control of the application logic in the hands of the developers, and the designer never has to see wade around inside their Ruby or PHP or Python to find the place to change a <code>div</code> element's class, for example.</p>

<p>I'm curious to hear how other people handle handoff, as this is simply my own system that I've evolved over the years as the result of preparing in advance for moving goalposts like feature requests and design changes after my work is theoretically finished. I think it handles fairly well, but perhaps there are better ways.</p>
       
      ]]></content:encoded>
      <dc:subject></dc:subject>
      <dc:date>2008-05-21T12:45:51-08:00</dc:date>
    </item>
    <item>
      <title>Image Replacement + Google</title>
      <link>http://mezzoblue.com/archives/2008/05/05/image_replac/</link>
      <description>
       At An Event Apart in New Orleans a few weeks back, something that Aaron Walter said on stage caught my attention. During the portion of his talk where he discussed image replacement and its impact on findability, he addressed the...
      </description>
      <guid isPermaLink="false">1421@http://mezzoblue.com/</guid>
      <content:encoded><![CDATA[
       <p>At <a href="http://aneventapart.com/events/2008/neworleans/">An Event Apart</a> in New Orleans a few weeks back, something that <a href="http://aarronwalter.com/">Aaron Walter</a> said on stage caught my attention. </p>

<p>During the portion of his talk where he discussed <a href="http://www.mezzoblue.com/tests/revised-image-replacement/">image replacement</a> and its impact on findability, he addressed the white elephant question that has likely occurred to most designers who have used image replacement over the past five years or so: what does Google think of CSS image replacement, anyway? But the part that surprised me is that he actually had an answer: Google's okay with it, you won't be penalized for using image replacement properly.</p>

<p>Though I've long believed this to be true, I had never heard a conclusive answer. One assumes Google is smart, and their algorithms ought to know the difference between keyword-stuffed text and plain English content written for real people. For example, I've often wondered if the potential to abuse image replacement and load invisible text with keywords was akin to, say, the potential to stuff keywords into the <code>alt</code> text of <code>img</code> elements, or even into <code>meta</code> tags. The net result seems similar in all three cases: otherwise-invisible text on a page that could unduly influence Google's ranking. Presumably whatever algorithms they use to detect keyword-stuffing on the other two elements would equally apply to text hidden with CSS.</p>

<p>Not to mention the more compelling evidence that numerous sites I've built using image replacement techniques fare well in Google's ranking. That fact alone indicates that Google won't ban a site for simply making use of image replacement techniques (though I'm sure they've banned numerous sites using the technique in a sneaky, black hat <abbr title="Search Engine Optimization">SEO</abbr> manner).</p>

<p>But again, I've never heard of an official blessing from Google. So I did some searching, and asked him for some follow-up (thanks, Aaron!), and here are the relevant resources that came out of that conversation:</p>

<dl>
<dt><a href="http://www.google.com/support/webmasters/bin/answer.py?answer=66353">Hidden text and links</a></dt>
<dd><p>The second bullet ("including text behind an image") accurately describes a few image replacement techniques. It's mentioned in the context of being a potentially untrustworthy activity, followed by a warning of the consequences of using it incorrectly. However, further down the page, the focus changes to techniques used for the sake of accessibility and why you would want to describe something search engines or users with assistive technology may not be able to access. This is a fairly accurate description of the intent behind image replacement. The article also suggests a handy rule of thumb for judging these techniques on your own: show the Googlebot the same thing your visitors see. Properly-used image replacement passes that test.</p></dd>

<dt><a href="http://googlewebmastercentral.blogspot.com/2007/07/best-uses-of-flash.html">Best Uses of Flash</a></dt>
<dd><p>See point #2 in regards to sIFR, an ideologically similar concept to CSS image replacement, which suffers from the same potential abuse vectors. As this is a Google blog, it appears sIFR has an official blessing. Also mentioned in this article is a similar guideline to the previous one: show users and the Googlebot the same content. Sensing a theme here?</p></dd>

<dt><a href="http://www.google.com/support/webmasters/bin/answer.py?answer=72746">Working with Flash, images, and other non-text files</a></dt>
<dd><p>More of the same. Provide text alternatives for non-crawlable content, sIFR's great, etc.</p></dd>
</dl>

<p>So it appears that, short of a set of stone tablets carried down from the hills of Mountain View, we do have a fairly clear answer. Using CSS image replacement in a responsible way, where the image truthfully represents the content it's replacing, is safe to use. The simple act of hiding text from users is not enough to get your site banned from Google's index.</p>

<p>(This article has also been translated into <a href="http://webreview.org.ua/?id=2&amp;action=article_detail&amp;ar_id=32">Russian</a>.)</p>
       
      ]]></content:encoded>
      <dc:subject>CSS</dc:subject>
      <dc:date>2008-05-05T14:45:42-08:00</dc:date>
    </item>


  </channel>
</rss>