Coffeemonk

Two Basic Principles of SEO

750 Volts

Websites exist for sharing information.

Whether it’s news of your latest big product release, general info about your company or industry, or a story about your day in the park with your dog, chances are you’re putting it out there for people to read. Since the days of Lycos, AltaVista, Yahoo, and, of course, Google, search engines have been a big part of that goal.

Building your site to entice search engines to index and favorably place your pages has gone from the brute-force spider-baiting methods of the late 90’s, to the… well, brute-force spider-baiting methods of the 2000’s.

SEO has become an acronym, but many SEO companies still seem focused on keyword bombing, link farming, and site “build-out.” This approach does kind of work, so these guys can get away with it up to a point and sell their clients on their “success,” but it usually means leaving two things behind: 1) your customers, and 2) sane, usable content.

There is a better way. It is possible to build search engine friendly sites without making your site look like a dictionary or random pile of keywords. With a little bit of time and effort, a good understanding of your site’s real goals (“getting a top search ranking” is not a real goal), and some thoughtful copywriting, you can serve your customers a readable, usable site and still rank well in your target searches.

As I see it, there are two basic principles of SEO:

  1. Understand how the spiders see your site’s pages,
  2. and create compelling, accessible, usable content, and organize it so spiders can see it.

I’ll talk about these a bit more in-depth, but not necessarily in great detail–this post is merely intended to offer an overview, and perhaps a better general approach to SEO, not blow-by-blow implementation guidelines. With that disclaimer in place, let’s continue…

Read the rest of this entry »

Tags: , , ,

Designing For Expandable Content Boxes

Designing for Expanding GradientsThere are many issues to deal with when designing for the web, and one of the most fundamental—and seemingly hard to understand or remember—is the simple fact that the end user ultimately has control over font size, not the designer. I’ve seen many gorgeous designs that are completely untenable if the fonts are enlarged by even a single point size.

In this post, I’m going to look at a singular expression of this problem, but it should be remembered that this is just one possible example. The possibility of font resizing should be considered when designing any and every piece of a website.

The Concept

For our example, we’ll consider a simple content box, self-contained and isolated from the rest of the webpage—a bordered box with some text and a nice varied-gradient background, like so:

Jack
All work and no play makes Jack a dull boy, don’t you think?

The Problem

In a situation like this, when constructed in HTML, the size of the container must increase as the font-size increases (unless you’re OK with locking it down and having the text spill over or disappear behind the box borders). Sounds fine, right? The problem is that, as the container changes shape or size, so must the background.

The background can be set to start in the top, center, bottom, left, or right; may repeat vertically, horizontally, or both, or may remain fixed to the start position. With a background not designed to tile, the tiling becomes obvious. With a non-repeating background, the background color of the page or element will be exposed. In either event, without sufficient forethought the result will likely be quite ugly.

Some Examples

Normal font size, non-tiled background.

Jack
All work and no play makes Jack a dull boy, don’t you think?
Enlarged font size, non-tiled background.

Jack
All work and no play makes Jack a dull boy, don’t you think?
Enlarged font size, tiled background.

Jack
All work and no play makes Jack a dull boy, don’t you think?

The first box is our “normal” example, included again for comparison. As you can see in the second box, we run out of gradient, and in the third box, the tiling is very obvious. Neither situation is desirable.

Possible “solutions”

There are, of course, various ways of dealing with these issues, either during HTML production, or within the design itself.

One Big Image

Kind of an old school solution, the content area can always be created as a single image including the borders, background, text, etc. This is, of course, terrible for searchability, and terrible for vision impaired users unless some other concessions are made in the HTML.

Text as Image

Equally old school, with the same issues as the “One Big Image” solution, this also comes with its own unique issues. Effectively, we’re talking about saving the gradient to it’s own file, and saving the text as a separate image file. Really the only benefit to this solution is that the gradient background could then be re-used for multiple (of the same sized) content boxes, with the text image laid over them.

Do It in Flash

With the widespread acceptance of Flash—and javascript packages like swfObject that make it easier to build in alternate (non-flash) content—building complex content boxes in Flash is no longer an unreasonable proposition. Using flash also opens up many other possibilities (like subtle visual effects, or more complex interactions) with hardly any more overhead than a large background image. The potential problems with Flash are, once again, searchability and usability for the vision-impaired. Still, these issues should be addressed by judicious and appropriate use of alternate content.

Improve the Gradient

The final solution would be to simply improve the gradient such that it reasonably accommodates the foreseeable problems with the particular content box.

Enlarge the Gradient
First option is simply to enlarge the gradient—take whatever it is you have done, and extend it beyond the borders of the content box so that as more of the gradient is exposed, it doesn’t look like crap. Big thing here is that the extended gradient should still work well with whatever content is over it—so don’t graduate to dark colors if the copy in your box is also dark. This solution probably gives the designer more control over the gradient as a whole, but also means that if the box expands beyond an expected point, you’ll just have the same issues all over again. So, you have to put some thought into how and where the expansion will occur, and how much of it to reasonably expect.

Fade it to a solid background color
If you you can modify it so that it graduates to a solid color on one or more sides, your gradient might be able to be locked into an appropriate corner of the box, with that solid color applied to the background. Then the gradient image will just fade right into the background color and the box can expand however much it needs to.

Make it Tile-friendly
If you can modify the gradient such that it tiles well and doesn’t interfere with the content, go for it. Tiled backgrounds save on bandwidth, download times, and storage space on the server. Tiled background do NOT, however, save memory usage on the client machine (at least the last I heard…). Tiled backgrounds also allow for “unlimited” expansion.

Recommendation: Improve the Gradient

Of the main “possible” solutions, really the most recommended is improving the gradient (or preferably designing it with these things in mind in the first place). Flash is a good option for very complex content areas, but is overkill for the simpler elements. Improving the gradient gives you more control, while keeping the HTML flexible, usable, accessible, and SEO-friendly.

An Example

Normal font size, improved background.

Jack
All work and no play makes Jack a dull boy, don’t you think?
Enlarged font, same improved background.

Jack
All work and no play makes Jack a dull boy, don’t you think?

Conclusion

Obviously, I’m no designer, and the examples I’ve shown here are super-simplified for our purposes. In the real world, there are usually even more complex considerations, but those dealt with here are fairly fundamental. If you’re going to be designing these nice little content boxes with pretty, complex backgrounds and big, bold fonts, you have to remember what happens to that fantastic design when it gets in the hands of the HTML guys and finally in the browsers of the end users—neither group is kind.

If you have questions or other possible solutions to this type of background image problem, or if you have other examples of how well thought-out design is a prerequisite for building good HTML, please share by leaving a comment.

Tags: , , , , ,

Photoshop Guides and Pixel-Precise Alignment

Getting Guides RightBack when I was strictly a front-end guy (meaning HTML/CSS/JavaScript, ya potty-minded sleezebags!) I had to muck around in Photoshop every day. A big part of my job was taking files—usually from people who had little to no idea how I did my job—and cutting them up into building blocks for a webpage. Over the years, I’ve seen a lot of sloppy Photoshop files, and have figured out a few things that a lot of designers apparently never seem to notice.

When I started, table-based layouts were the gold-standard, as they were really the only way of exerting any form of control over a layout, HTML-wise. Because of the way tables worked, elements in web layouts had to be sized and aligned to pixel-perfection, otherwise, things just ended up looking all screwy. Unfortunately, back then, getting pixel-perfect layouts was like winning the dollar lottery with a fifty cent ticket. (It didn’t happen, see.*) Today things are a bit better, and the rise of CSS allows for both more and easier layout control, and for a somewhat reduced requirement for pixel-perfection.

This is definitely not to say that designers should be let off the hook—if you’re executing a gridded layout, or a series of thumbnails and the edges don’t line up or the thumbnails aren’t all the same dimensions, then you’re being lazy, or sloppy, or both. The fact that Photoshop gives you fairly elegant tools to avoid these problems means that there’s really no excuse for it.

That being said, there are some things that can make a designer’s job harder. I’m planning to post a few of the Photoshop tips, tricks, and guidelines I’ve picked up as a web developer, starting with this one, dealing with a particularly annoying and quirky behavior of Photoshop’s guides.

Read the rest of this entry »

Tags: , , , , , , ,

Keyboard Shortcuts: The First Words in Productive Computing

Keyboard ShortcutsIf there’s one thing I’ve learned about becoming a more productive computer user, it’s this: keyboard shortcuts are the holy grail. In my average workday, I would guess that I could shave over an hour off my time on a lengthy project, just by learning and judiciously applying keyboard shortcuts.

Obviously, this will be most effective for people who already spend most of their time with their fingers on the home row (writers & coders), but many of the best mouse-centric programs often have single-letter or one-handed shortcuts that are very beneficial.

Though I’m planning to write a few posts dealing with specific applications that I use every day, and my favorite or most frequently used shortcuts in those applications, there is also quite a bit that is available by default in most modern operating systems. In this post, I’m going to try to give you a few common shortcuts that will work on Windows, Mac OS X, and Linux.

Read the rest of this entry »

Tags: , , , , , , ,

Linux Toolbox: alias

Linux Toolbox: AliasI’m going to kick off the Linux Toolbox with a relatively simple one.

Command: alias
Purpose: create command-line shortcuts
Benefit: save time and effort by simplifying complicated, commonly-executed commands.

If you spend any time at the Linux command-line, chances are that you are going to type the same commands repeatedly. Or, there may be long or complex commands that you enter only rarely, but you don’t want to have to look up every time you need them.

Alias allows you create temporary command shortcuts within the current terminal session.

Read the rest of this entry »

Tags: , , , , ,

How I Remember the Milk (or don’t)

GTD with RTM and Relax!Let’s face it. My record at getting things done is not exemplary. If you looked up procrastinator in the dictionary, you would most certainly not find my picture, because I never managed to send it in. On the other hand, I desperately want to be productive. There are so many things I want to do, that I can’t find the time to do them, and when I can, I can’t think of what to do!

A few years ago, I was introduced—mostly through this dude—to the GTD phenomenon. As seems to be the case with a lot of GTD’ers, I’ve flirted with a few different implementations of the system. I was obsessed for a while, also, with ubiquitous access to my crucial data—email and calendaring—so this would be a crucial part of any GTD system for me as well.

When I first found Remember the Milk, I dismissed it as a limited, web-based to-do list. Over time I heard and saw more positive mentions in GTD circles, and eventually, after attempting to setup my own linux command-line-and-text-file based system (more on that later), decided to give RTM a shot. A couple of items (I think the first and fourth) in the list at the bottom of this post set me on the path of a workable, personalized GTD implementation. I’ve continued to tweak it a bit, and feel like I’ve arrived at a system that works well for me (when I remember to use it—funny how that works, eh?). Anyway, enough setup, let’s get started.
Read the rest of this entry »

Tags: , , , , ,

© 2009 Coffeemonk. All Rights Reserved.

This blog is powered by Wordpress and Magatheme by Bryan Helmig.