Welcome to ShooFlyBuzz, the company weblog. We use this space to talk about what’s happening with ShooFly, but more generally to talk about web design, the challenges we encounter, the tools we use, websites we like, and provide some training on the care and feeding of your own website.

If you want to send in feedback, leave a comment, send an email, or tweet @shooflydesign.

Yeah, I guess I basically feel the same way Derek Powazek does about SEO. In short: the good stuff is obvious to good web developers, and the rest of it doesn't work. There are a lot of companies out there setting up link farms, Google bombs, and other disreputable artifacts that are ruining search on the web. They need to be ignored and to go out of business.

The rest of us can continue to try to build well-made, relevant, and good websites. Make good things, tell people about them, lather, rinse, repeat. I like that formula.

You can't say it much more simply than this:

Google does not use the keywords meta tag in web ranking. That's straight from the mothership's mouth. I'm often asked what to do about keywords on pages, and this says definitively that Google just ignores the keyword meta tag; they have for years, and see no reason to stop.


I'm starting to build new websites with Drupal 6 now that the juiciest modules (CCK and Views especially) are nearing stable releases, but Drupal 5 is still very widespread, so I expect a lot of people will be using it for at least a matter of months, maybe years.

Drupal 6 offers a nifty and useful javascript effect on administrative tables: the table headers stick to the top of the browser window as you scroll down. This is especially handy on pages like the user permissions page with its bajillion checkboxes. Drupal 5 doesn't have this, but with a little bit of code, you can get it. I've made a little module that, when installed, will add sticky headers to the user access page in Drupal 5. It requires jQuery Update 5.x-2.0 or later.

Download Sticky Headers module »

Once you've installed and activated both jQuery Update and Sticky Headers (they're both in the User Interface package on the modules page), you should be able to look at your user permissions page (called Access Control in Drupal 5) and get a scrolling table header to help you keep your place.

Some notes:

  1. This module works by injecting an HTML class (sticky-enabled) into the table tag used for the user permissions page. The included javascript file looks for that class and does its magic.

  2. I made it work by overriding theme_user_admin_perm() from the core user.module. The function is named phptemplate_user_admin_perm(), so if you want to override that table in your theme, you'll need to make sure your function is named mythemename_user_admin_perm() or you will run into naming conflicts.

  3. With this module enabled, you can add the functionality to other forms throughout Drupal. With themeable forms, you just look for code that looks like this:

    $output = theme('table', $header, $rows, array('id' => 'whatever'));

    And in your theme where you override that function, add the sticky-header class like this:

    $output = theme('table', $header, $rows, array('id' => 'whatever', 'class' => 'sticky-enabled'));

    From there, it should just work.

  4. The colors in used for the sticky headers are hard-coded right now. If I didn't hard-code it, the background on the sticky header was transparent, which made it hard to see. So for now, it's always black on white. In the core themes, you probably won't notice.

  5. I don't think I'm going to try to add this to the Drupal repository. It's useful, but I don't know if cluttering things up with a small backport module like this is a good idea.


Most of the time when I build a website and use a content management system, I use Drupal. I recently finished a site that had basic needs, and decided to give WordPress a go. As I was going through it, I had questions about how to do certain things, and I'm going to post all the answers here.

  1. If there are javascript or other auxiliary files in the theme, and you want to link to them, use bloginfo() function, like this:

    <script src="<?php bloginfo('stylesheet_directory'); ?>/jquery.js"></script>

  2. If you want a page to look different than the other ones, or if there's some code that needs to appear on a particular page that can't be edited by regular users in the WordPress UI, you can make a special template for it. First, start the template with a comment link this one:

    <?php /* Template Name: A Special Page */ ?>

    Then when you create the page, there will be a Page Template selector in the right sidebar. Choose the template you created, and you're in business. I used this to set up a PayPal form and a bit of Javascript on a couple pages.

  3. In your template files, you can check whether you're the home page with the is_home() function, which returns true if you're on the home page (duh).

  4. The WordPress template system has many file names that are magical and recognized for certain purposes, and which can be called by certain functions. Here are a few of them. The complete list is on the WordPress Codex:

    • header.php - included in other templates with get_header()
    • footer.php - included with get_footer()
    • sidebar.php - included with get_sidebar()
    • style.css - the main stylesheet, but also contains the metadata for your template
    • single.php - used for single posts
    • page.php - used for single pages
    • archive.php - If it exists, this is used for anything that's browsed and isn't a single post (date archives, category archives, etc). Otherwise, index.php is used.
    • comments.php - included with comments_template()
  5. To include different selections of posts from the database, use the query_posts() function. For example, you can pull two posts from one category and then the five most recent posts from the entire pool of posts, and display them in different parts of the page.

  6. The WordPress Codex is a large and generally helpful resource. While developing a theme for WordPress, I spend a lot of time with the Template Tags page.

WordPress is very capable for building a complete website, or for just bolting on some quick page editing to an old school, no CMS, website. I like that WordPress feels relatively small and fast compared to Drupal. I do prefer Drupal for general content management and development for websites where blogging is not the major focus, but it's nice to have both tools available.

I've generally not been a fan of HTML email. The main reason is how much easier it makes phishing, link obfuscation, and other evil email scams. That said, I realize that it has a lot of good uses when employed for the forces of good. But making an HTML email that works as designed in Outlook, Apple Mail, Thunderbird, Gmail, and other email applications and services is difficult to impossible.

The Email Standards Project is trying to change that by raising awareness on the issue of email standards in the same way the venerable Web Standards Project did back in 1998 through to today. The web is a much, much better place to work and play because of web standards, and it would be a great thing for the same situation to come about with HTML email standards. I support the Email Standards Project, and so should you.

That about says it, doesn't it?

I was building a module for a site I'm working on, and I gave a module the same name as the current theme. One of the modules purposes was to make some blocks for the sidebar, so I included an implementation of hook_block() in the module. In Drupal development, this means you called the function modulename_block() -- if you already have a theme by this name, Drupal could also see this as themename_block(). Anyway, when I enabled the new module, all blocks on the page were gone. This is an issue other developers have seen, and the advice seems to be "don't do it".

So don't do it. I broke the block functions out into a separate module with a different name, and all was well.


At ShooFlyDesign, we love Ze Frank. In today's installment of the show, he talks about web developers. Beware.

Update August 28, 2006 -- I am again questioning the ability of Photoshop Elements 2 to produce remotely accurate colors using Save For Web. I'm following my own instructions, starting with sRGB IEC61966-2.1 documents, and getting the dull colors again. This is rather disheartening. I'm leaving this discussion up here because it did work for me once, but there must be a something more subtle I'm continuing to miss. Maybe someone will see article and be able to shed some light on the issue.

At ShooFlyDesign, we do all kinds of web work. One very common bit of work is converting other people's designs into working websites. As a result, we receive lots of Photoshop documents. Because we're working with graphic designers who are very careful with where they pixels are placed, and how they look, color is not something to be trifled with. This is true in any somewhat artistic endeavour -- everyone wants the colors they choose to look the same wherever the document is reproduced.

Because we're interested in keeping our costs down, ShooFlyDesign has not invested in Photoshop CS or any of the other full versions of that venerable software. Virtually all our work is done for the web, and Photoshop Elements does the job admirably for a small fraction of the cost of Photoshop. We use version 2.0, which was the first version to run natively on Mac OS X. It's not the current version, but so far we haven't needed to upgrade. Elements can't read or save CMYK images, and is missing many of the advanced automation and image adjustment features of the full version of Photoshop. But for most people, it has plenty of power, and with certain add-ons, it can be very powerful indeed.

Although we don't need to deal with CMYK images in Photoshop, we do need to be able to output accurate color to the web. Photoshop Elements includes a Save For Web command, but if you're not careful, the images it saves will have colors that look desaturated and rather dull. I'm certainly not the first person to notice this. The difference isn't the same as the difference between color and black and white, but to a reasonably discerning eye, it's pronounced.

The reason, I think, is that Save For Web strips out the ICC color profile information from your original document (the information that tells Photoshop how to render color on your screen) when saving to JPEG, GIF, or whatever1. Most web browsers ignore color profiles (Safari is an exception), so stripping them out is generally a fine thing to do. Photoshop Elements has the ability to save the image without the ICC profile, looking the same as your original, but only if you follow certain steps. This has been a source of many headaches over the years, but finally, I've figured out a procedure that lets us output correct colors from Photoshop CS2 documents.

The Procedure -- How To Keep Your Colors Looking Good

There are two main variables you need to control:

  1. Photoshop Elements' Color Settings preference, found in the Photoshop Elements menu in Mac OS X. Set it to "Limited Color Management". Doing so will tell Photoshop Elements you only care about the sRGB color profile, which is the one used for keeping colors consistent on the average person's screen, across computer platforms (Windows, Mac, etc). I was inclined to think that "Full Color Management" would also work, but alas, it seems not to. It seems to me the three available modes (None, Limited, Full) might have been better named "Always Ignore", "Always Use sRGB", and "Always Use Adobe RGB".

  2. The source document's color profile. This should be sRGB IEC61966-2.1. Although Photoshop Elements can open and work with any RGB document, if you start with Adobe RGB, there's nothing you can do to save that image to the web that will preserve the original colors2. The full version of Photoshop can convert between profiles easily, so if you're working with other designers, ask them to work in sRGB.

Once these two things are under control, you can use the Save For Web command to yield color as accurate as Photoshop (any version) can produce without ICC profiles embedded. I tested this in my copy of Photoshop Elements, and a copy of Photoshop CS2 belonging to a less frugal colleague, and the results are identical.

What Can Go Wrong

If you start with Adobe RGB, you get dull colors. If you work in Full Color Management mode, regardless of the color profile you start with, your colors will be dull after you Save For Web. That part, in particular, is just amazing to me -- if Limited Color Management can do it starting with sRGB, Full Color Management should be able to do it too. Unless there's some subtlety to color management I'm missing, this is a bug.

For the record, in Photoshop CS2 (and probably earlier versions), you don't need to fuss with all this document ICC profile, color management setting nonsense. The full version of Photoshop will apparently do whatever it needs to do internally to make your images look right on the web. You can start out in Adobe RGB -- CS2 will change the profile internally and match the colors as best it can when saving the image. It's really irritating to me that Photoshop Elements (as of 2.0 anyway) doesn't have this particular aspect of Photoshop's brain. Perhaps Photoshop Elements 4, which is presumably based on CS2, has fixed this behavior. If it has, and it's not any slower, I will have a very compelling reason to upgrade. Alas, as of today there is no downloadable trial of Photoshop Elements 4 for the Mac available, so I can't test it.

Two More Things

To add to the potential irritation, the procedure can be slightly different if you're working on documents you create yourself. New documents created in Limited Color Management mode will not have an ICC profile attached. This means the whole business of ICC profiles as used by Save For Web can be safely ignored, because there's no profile to strip. However, if you use bits of other images with color profiles, you'll need to switch to Full Color Management before copying those pieces into your new Photoshop Elements document, or the colors will be imported into your document looking dull. With Full Color Management turned on, Photoshop will confirm that you want to copy, say, a bit of image in Adobe RGB into your sRGB or untagged RGB document, and that you want Photoshop to try to convert the colors to match. If you have Limited Color Management turned on, you won't get this opportunity. Once the other image is imported into your document, you can switch back to Limited Color Management.

When I first started noticing this problem, I would copy the image slices I was working with into GraphicConverter and use its "Merge color profile into image" checkbox in its Save dialog. This effectively does the same thing that Photoshop CS2 does when you Save For Web there -- it matches the colors as best it can to their untagged, non-color-managed equivalents. And GraphicConverter is even cheaper than Photoshop Elements! If you have no choice but to use Adobe RGB originals, GraphicConverter might save your bacon. Its results are not quite as accurate to my eyes as Photoshop or Photoshop Elements configured the aforementioned way, but they are definitely much better than Photoshop Elements configured incorrectly.

  1. You can tell Save For Web to embed the ICC profile, but unless the browser or other viewing software can use the ICC profile, this does nothing but make the bigger.
  2. Well, okay, there is one procedure that works, but it's a pain, and if you have a lot of images to work with, it gets old awfully fast, especially if you want to keep your document's layers intact. In essence, you have to copy your image (either merged, or one layer at a time) from the Adobe RGB document into an existing sRGB document while in Full Color Management mode.

Tunecore looks like an interesting, and much-needed, service for people who are interested in digital music distribution through iTunes and other music services, but don't have a CD.

I've just read about it now, but I want to post now and ask questions later.

We get a lot of email here at ShooFlyDesign HQ. A lot. We also write a lot of email. And we prefer our email without the HTML -- which is what allows people to make text bold, colorful, add images and whatnot. We're just plain text folk here.

One of the weird things about HTML messages, and how Apple Mail deals with them, is that they can mess up replies. Specifically, the leading (line spacing) is broken, resulting in lines that are spaced just far enough apart to look funny, but not as far apart as separate paragraphs should be.

Most email messages that come as HTML also feature an alternative, plain text, encoding. It's possible to switch between these using the View > Message > Plain Text Alternative command. Switch to plain text, hit reply, and everything is jolly.

Apple Mail will display HTML mail encodings by default, on the assumption that users prefer that. And these days, it's possible most do -- the kids like the colorful text and stuff. However, if you have a taste in email similar to ours, you may want to force Apple Mail to display the plain text version if it's available. There's a hidden preference available for it. Quit Mail, open a Terminal window, and paste in this line:

defaults write PreferPlainText -bool TRUE

Restart Mail, and you will always see a plain text version of a message first. For more information on this topic, including ways to force plain text in other email applications, see Why HTML in E-Mail is a Bad Idea, where I found this solution. The page's filename is amusing: evilmail.html -- calling HTML mail evil might be taking it a little far, but we certainly prefer to avoid it.



Subscribe to ShooFlyBuzz