There 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:

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

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

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.

When I first switched to Linux, I also attempted to switch to Gimp—which is generally considered to be Linux’s Photoshop. My experience with Gimp, especially versions before 2.5, was not great, and I switched back to Photoshop pretty quickly.

One of my freelance clients publishes a newsletter every month, and I convert the PDF into JPG images to use on the site as a sort of low-fi online version. I discovered pretty quickly that Gimp’s conversion routines did a terrible job. Eventually, I found a solution using ImageMagick, which I had used previously in my bipolar gallery scripts.

Converting images is super easy with ImageMagick’s convert command, and as it turns out, convert can also handle PDF files.

Here’s the commandline I use:

convert -density 300 -size 4100 sourcefile.pdf -quality 100 outputfiles.jpg

Basically, this converts each page of the pdf into a 300ppi JPG with a maximum dimension of 4100 pixels and a JPG quality setting of 100% (or no compression). Each page is saved as an individual JPG named outputfilesXX.jpg (where XX represents the page number, starting at 00).

This gives me much higher-quality starting images than Gimp provided, which I can then resize as needed.

convert has a huge array of features beyond this simple example, and is worth a look if you need to do image manipulation from a script, or batch operations on images from the commandline.

Back 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 »

If 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 »

I don’t remember when I first heard about Linux, or even Unix, but I do know it was a long time ago. My first impression was that Unix was an OS for mainframes and comp. sci majors. When I learned that it was capable of multitasking and running a GUI, my brain nearly fell out. Years later, when I learned of Linux, I got basically the same impression—it seemed like trying to run a mainframe OS on a little desktop box.

At a time when I was spending countless hours of my life endlessly tweaking my Amiga and whatever crap PC I had on hand, or trying to devise the perfect partition/directory structure, spending 3 hours compiling something just to get the machine to boot up seemed like a colossal waste of time. As time went on, the idea of Linux as desktop OS was becoming less ridiculous, but there still seemed to be a giant learning curve. It was hard enough keeping Amiga and DOS cli commands and syntaxes straight, much less learning an entirely new one!

A few years ago, I finally got a Macbook at work, running OS X, which is Unix based. As I learned more about the Mac—and kept running into brick walls of broken or missing functionality—I started to dig into the command-line. I got a little more comfortable with it as time went on, to the point where I was seriously considering a personal switch to OS X, and finally ridding myself of an unfortunate dependence on Windows.

Read the rest of this entry »