One of the best things you can do to set the tone of a blog post and encourage people to read beyond the heading is to include an image. Most bloggers understand this, because an awful lot of them use images in their posts. But "misuse" of images is more common than "use" of images, if you have the perspective that the purpose of an image in a blog post is to communicate.

Here, then, are 6 rules (I could have called them guidelines, but then no one would argue with me) for using images in your blog posts which deserve a yellow flag when violated:

1. One image per post.

Blog posts are usually short; 300-800 words is a commonly suggested length. That small amount of text simply does not create enough screen real estate to accommodate several images without looking cluttered and unreadable (you DID want people to read your post, right?). The idea of "less is more" has never been more applicable. In cases where multiple images are truly called for (e.g., you have a series of photos showing attendees at an event), you can use one anchor image with a link to launch a Thickbox slideshow (or similar). This is also a good technique to use when you need a large image to show critical detail.

2. Put the image at the top of the post.

Put the image where visitors can see it immediately, right below the heading of your post. I personally like to align the image to the right at the top of the first paragraph: the image is where they can see it and connect it to the heading, but it doesn’t block their entry into the post text as it might if it were aligned left.

3. Make sure the image relates to the heading of the post.

An image should not leave your readers wondering what the connection is with the post, either before or after (or if) they read it. The image should immediately and clearly support or illustrate an idea in your post heading. Most people view disconnects and non sequiturs as annoying, rather than intriguing. If you can’t find an image to relate to your heading, consider changing your heading.

4. When looking for images, bring along your sense of humor.

A little humor or irony in an image (as long as it’s obvious: reread no. 3) can draw people into the post. It’s a bit like telling a little joke before a speech. Of course, if the "joke" is inappropriate or misleading, then you’ve created another issue. So don’t do that.

5. Crop and size images appropriately before uploading.

Any time you see an image that seems to take forever to load in a post, chances are you’re looking at a big image that has been scaled to fit, rather than sized to fit (i.e., the blogger uploaded a 1200-pixel-wide image and scaled it down to 220 pixels wide in the blog editor, instead of resizing the image to 220 pixels before uploading). Get an image editor and learn to use it to crop and size images, at minimum.

6. Don’t use clipart or stock photos. Unless they’re pretty good.

A lot of clip art and stock photography is trite and awful and over-used. But some of it is clever and very good and it perfectly illustrates your concept. Put your photo-editor hat on and refuse to use the former. Under no circumstances should you use an image of a multi-ethnic and gender-balanced group of young people with perfect teeth dressed in business casual gaping in awe at the screen of an open laptop in a brightly-lit conference room.

Tags: Communication, Design/Development

Although I design and develop on a Mac Powerbook, I mostly ignore Safari for two reasons:

1. Safari is about as standards compliant as browsers get, so it rarely needs any special attention.
2. Safari is used on fewer than 4% of all computers (and it seems to have peaked).

I use Firefox almost exclusively (although I’m now experimenting with Chrome for Mac), because it’s very standards compliant, and it gives me about 99% of the same results as a PC version of Firefox. Using FF in my development process means I have the biggest browser covered (that’s right, FF has over 46% of the market, with IE6-IE8 combining for just over 37%). I use crossbrowsertesting.com to hunt for problems in IE. Ideally, I want my work to look the same in all browsers (but I’ll settle for “close” in IE6).

That said, I try to keep in mind an old saying in the web design business: The most important browser to develop for is the browser on your client’s screen. One of my clients is an ad agency, and they are completely tied to Safari (I’m pretty sure they’ve heard of Firefox, but…). So, looking good in Safari is a priority on their projects. Rarely is there a need for a hack, but occasionally it happens.

There seems to be only one reliable CSS-only way to target Safari (incidentally, it also targets Chrome, which has almost 3x as many users), outlined way back in 2007 by Dustin Brewer. You can put this in your style sheet to enclose Safari-targeted rules:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Chrome rules here */
}

But then you have a hack in your style sheet. I find it’s easier to maintain (and find) hacks by putting them into a different file, and your basic style sheet is more likely to validate. I experimented with using the above selector in the header to point to a different stylesheet, but had some issues (don’t remember now what they were). Finally, I settled on putting the following in the header, following the basic style sheet link:

<style type="text/css" media="@media screen and (-webkit-min-device-pixel-ratio:0)">
<!––
<?php include("includes/safariCSS.php"); ?>
––>
</style>

This displays the contents of an include file, displaying CSS rules in the header as an "internal style sheet." The contents of the php include file consists of CSS rules, but is not a CSS document. Internal style sheets in the header are usually to be avoided due to maintenance and consistency issues, but by using an include, the Safari CSS for all pages is editable in one file.

By the way, the CSS rules from the include appear in the header for all browsers, but the “@media…” statement means all but Safari and Chrome ignore the styles. Given that I’ve done websites with some extremely complex CSS and only needed 2-3 rules targeting Safari, I don’t think this approach risks adding much overhead.

View a Demo | Download Demo Files

Server Side Scripting Reminder: Because the include is PHP, which renders on the server, the files will not work locally on your computer. To see the results of your experiments, upload the files to a server that supports PHP.

Tags: CSS, Design/Development, PHP for Designers

Update 2/4/2010: I had reason for some support help from HostGator, so I tried out their chat support. It’s an entirely different experience. Dedicated attention from a single support tech who stays with you until the problem is resolved. The result? The problem was resolved quickly and efficiently.

Update 1/8/2010: when I returned to HG’s contact page this morning (still not resolved and I need to get beyond the ticket system), I noted that the email addresses did carry the instruction to "submit a ticket by emailing us." Like most people, when I want help, I tend not to see the details but go straight to the info that looks like it will get me help, without reading (or even seeing) the supplementary info: when I see an "Email Us" heading, I expect the process to act like email. There is a usability lesson in that for me as a web developer/information architect.

This is not the first time I have complained in my blog about Hostgator’s support ticket system. Last time, a nice person from HG even responded to that post, but nothing in the system has changed since then, so nice responses that seem to offer understanding don’t amount to much.

On HG’s behalf, let me say they are very reliable, and I don’t have more support issues than I’ve experienced with other webhosts. I’m just not happy with their support system and/or processes, and probably all that can be traced to whoever is managing their support function.

What’s the issue? HG seems to have a single support channel: a ticket system. And no way around it when it does not fit the need. Here’s the story:

4:28pm: I submit a ticket on a problem with a hosted site after spending half an hour trying to determine for myself what the problem might be and what I need to do to fix it.

4:35pm: Representative A responds and requests more info.

4:41pm: I respond with requested info.

5:36pm: (note increased time) Representative B responds with partial fix and partial explanation.

5:39pm: I respond with questions to clarify what happened.

5:43pm: After noticing that some problems remain, I respond outlining remaining problems.

7:38pm: (that was one long dinner break) Representative C responds with additional partial fix, but no requested explanation.

7:42pm: I respond with remaining issues that are apparent.

7:59pm: I share repeated error that has been showing up in error logs.

9:28pm: I’m still waiting…

(Note: times are in HG’s time zone, an hour ahead of mine)

Does anyone besides me see a problem here with lack of continuity in HG’s support responses, both in terms of time and personnel? Anyway, I see such a problem, so I decided to go to HG’s website and send an email to the support contact email, with a little "constructive critcism." Copied from my email:

I’m a fan of Hostgator. I currently host a few dozen websites on Hostgator. I spend a fair amount of time telling my clients how reliable and rocksolid Hostgator is.

But that may have to change, because HG does not have its support act together. At this point, I have several support issues behind me, and the record shows this is the usual experience:

1. submit support ticket to the support dept
2. receive first response in approx 10 minutes, from rep A (so far, so good)
3. respond and receive next response in approx 1 hour, from rep B (not so good)
4. respond and receive next response in 1-2 hours, from rep C (not even close to acceptable)
5. there may be 2-3 additional cycles, extending the support process up to 5-6 hours

The upshot is that relatively simple matters can easily take 2-3 hours (more is not unusual) to resolve. Between the lack of continuity (because of extended times and different support reps) and the slow response times, the support, well, it sucks.

(BTW, my one experience with support from your billing dept shows response times always in the 10-15 minute range, with greater continuity with support personnel)

Can you not see the value of going to a different system for a customer for whom the first response does not resolve the issue? I guarantee you are about to lose at least one customer entirely, or at minimum, cease to see any additional growth in this account.

Would you like to guess what happened to this email? It was directed to HG’s ticket system. That’s right: an email complaint about HG’s ticket system opened a ticket. I’m currently awaiting a ticket response on my original ticket, AND this ticket. Can anyone here spell "INFLEXIBLE?" Can everyone here say "It’s time to look for a webhost with a better support system?"

Tags: HostGator, Support, Webhosting