The web is littered with broken static layouts that don’t scale with resolution or font size. The need to fix this crap is becoming more pressing as display resolutions increase. The problem is far beyond aesthetics – even today, many popular sites become horribly broken and unusable when font sizes are increased. I’ve illustrated the problem with screenshots and I’ve outlined a few solutions that all web designers should consider.

Before I start, let me say that I’m not mad at any of the sites I mention. I’m just mad at technology.

What do I mean by static layouts?

Websites are viewed by people under wildly different conditions: different operating systems, browsers, resolutions, and font sizes. Most know this, but designers seem to build sites that only work in specific environments. We’ve grown past designing for single browsers as we did in the dark ages, but what about different resolutions and fonts?

Some sites declare themselves to be a static width, say, 700 pixels. That looks fine if your browser is maximized and you’re using a 1024×768 resolution; but what if you’ve got your browser sized to only half the width of the screen? Then you get a horizontal scroll bar. Reading with a horizontal scroll bar is synonymous with pain (which is bad).

What if the resolution is 1920×1200 and the browser is maximized? Then that 700-pixel site becomes a tiny sliver in the middle of a huge browser, and the visitor becomes frustrated that you’re wasting all of that screen space.

Even more insidious are layout elements containing text which are precisely sized using pixels. Pixels do not scale with the font size, so as fonts increase (or decrease), your layout will become out of wack.

But who cares – who increases their font size anyway? I’ll tell you who — ask any elderly person with a laptop. The screen is too small and the resolution too high to be able to read text. Solution? Boost those font sizes up. In fact, I suspect a large number of people want to boost their fonts up but are badgered into chronic, worsening eye fatigue because most webpages just don’t work with bigger fonts. But the number of people increasing font sizes will only grow as laptops keep getting higher resolution displays.

How bad is it? Oh it’s real bad

I’m sure everyone has run into layouts that are fixed width; you’ve seen them, they’re annoying, they prevent you from resizing your web browser.

But the problem with font sizes is not well known. If you cruise the web with fonts turned up, I’m sure you’re familiar with the horror. If you don’t, I’m going to illustrate it with some screenshots of websites viewed with font sizes increased.

Ever seen one of those little “digg this” buttons? They’re literally all over the web, and they’re usually sized in pixels.

I’m assuming that’s 240ish diggs, not 2000, but it would be great if I could actually see the number. Keeps me from clicking it every time I see it.

Even worse

Google Adwords from OSNews, sized in pixels. Google/OSNews/whoever is sure wasting bandwidth showing me ads I can’t read.

Worst of all (this belongs in the hall of shame)

That’s a screenshot of me trying to set a flight date on orbitz.com. This shows just how harmful static layouts can be. The little, obtrusive popup calendar is sized in pixels, meaning the designer assumed all people would be using the same fonts as them, at the same size. The result? Almost all of the calendar is cut off and it’s shamefully unusable. Where are the rest of the dates? Orbitz lost real business because of this — I literally closed my browser when I saw that, disgusted, and found another site to book a flight.

What to do about it

If you’re a web designer, read below. If you’re not a designer, email the owners of broken sites and tell them to read below.

Making a site that’s completely fluid with CSS and modern browser quirks is hard; don’t kid yourself. However, making a site that’s good enough and that will not cause visitors to curse you and your children is not difficult.

Variable width / fluid layouts

If you haven’t already, make your site at least somewhat variable-width. This means define your width as something variable, e.g. “width:100%”.

A few artsy sites can get away with fixed-width layouts, but everyone else should design for flexibility. I realize some sites don’t look good when they’re really wide, and some look bad when they’re too small. That’s why CSS introduced the max-width and min-width properties: give your a site range of widths so it will work under many conditions.

A minimum width of 500px and a max width of 1000px or 1200px is usually enough to be usable by most people (see it in action). Internet Explorer doesn’t support these properties, so you may have to do a few backflips and incantations to get them working.

But I want my width to be the size of a print paragraph!

If you write essays and want the page to read like print (such that there is a “readable” number of characters on each line), fine – just make sure the layout is sized using characters (i.e. em units) and not pixels. If a user increases their font size, your page’s width won’t grow if it’s defined in pixels.

Coping with font sizes…

… is actually pretty easy. It’s easy to debug because it’s so easy to test. Open your website, and hit CTRL++ a few times in Firefox, or CTRL+[scroll wheel] in Internet Explorer, and you’ll quickly see how your site behaves under different font sizes.

If you put text inside of a graphical container, make sure that the container can stretch to accommodate what’s inside of it. Do not make one big bitmap image, set it as the background for your text, and hope the text doesn’t flow out of it, like these guys did:

Instead, use containers that are fluid and can cope with content that changes. It may be a little more CSS and markup, but you can put all kinds of content in there and the containers will display beautifully.

If you have text in a menu, make sure that menu can stretch both horizontally and vertically.

This is admittedly hard for horizontal menus, but a horizontal menu should be treated just like a line of text. If the browser gets too small or the text gets too big, it should wrap to the next line! You can see both good and bad form on the same site — the popular registrar namecheap. They have two horizontal menus, one right on top of the other. The bottom one wraps the text (good behavior), the top one doesn’t (looks terrible when fonts are big). Go figure.

I realize that there are many more fancy things you can do, like wrapping layout elements to the next line instead of simply resizing them as the browser window is resized. But that stuff is dang hard. If you’re just worried about not pissing people off when they visit your site, the tips in this article should do you just fine.

Spend a little time, try to help fix any sites under your power that are broken. Maintain the sanity of the web.

Released a new version of InstallPad today, tons of new stuff. InstallPad is a program I’m working on that helps you download and install Windows applications very quickly. It’s especially useful when you’ve just reinstalled Windows.

The source is now open, and there have already been some significant contributions. The license is an interesting one which took me some time to find/make; read more about it.

A few of the changes:

• Graphical preferences
• Alternate download URLs in case the main URL is down
• Picasa and Quicktime added by default
• Support for “installing” .zip files by extracting them to a configurable folder
• Launch only one installer at a time, so they don’t step on each other’s toes
• Comment applications

Still just one file?

InstallPad remains a single-file deployment (well, two if you count the applist.xml), and it doesn’t install itself anywhere. It is getting more and more interesting adding features to InstallPad without adding other files. For instance, a zip library comes with InstallPad, but since it’s licensed under a modified GPL, we can’t include the source.

So what do we do? A compiled DLL of the zip library is embedded as a resource, loaded from a bytestream at runtime, and the library is invoked via reflection; all this because we didn’t want an extra DLL sitting next to InstallPad.exe. The preferences file (installpad.exe.config) is also extracted to your application configuration directory the first time it’s run so you can have persisted preferences, without a (visible) extra file.

Go download and try it. If you find it useful drop me a line.

I hate the startup’s name and domain (iscrybe.com) but their demo is very cool looking. Not sure how usable an app this would make, but it sure is sexy, and I love the offline work mode. Sounds like they’ve got some scientists bringing research into the product. For instance, they use a zoomable user interface to keep context while navigating (a UI concept developed at my university)

Watch the video:

at first I thought this was an ajax calendar, but it’s Adobe Flex.

Found via Techcrunch

While I have my own views on the matter, I found an interesting argument at the (outdated) Bnoopy blog that describes what a good engineer is. Criteria I think we can all agree on: good communication, tendency to tinker, and passion for coding.

The author usually asks some questions to see if those criteria are met: does the engineer have a blog? A personal webpage? Contributions to an open source project?

Whoa, what do blogs and personal webpages have to do with anything?

Blog => interested in and dedicated to writing

Personal homepage => build it yourself & experiment with technologies, instead of being content with what generic services can make for you

Open source => you will hack for free if something needs to get done

As soon as I read that I thought: signals! Economic theory spends a lot of time arguing about how candidates with high ability signal their ability to employers. A college education is traditionally considered an effective signal. Maybe blogs, homepages, and open source contributions should be paired with education if you’re trying to communicate to companies that you rock. I know Google and IBM are starting to take more interest in those who’ve hacked OSS. Get to it!

It’s that time again - time for a design refresh. I never pass up a chance to work out my puny design muscles, and a blog is no exception. The blog engine is still Wordpress, now with all its crap trimmed out.

eightpence.com is the new domain name — it’s easier to say and type. I grew weary of clarifying when I told people the old url, philisoft.com: “phil-soft? philo-soft?” “no, phil-i-soft”…. well, no longer!

What’s with the huge dragonfly? I like it, geeze get off my back! It’s colorful. Took me a dang long time to make.

This is the first ever design that needed no drastic modifications (no markup changes) in IE. I admit I did a little jig when I discovered this. Although, when working with IE, you always end up discovering something fun. This time I stumbled upon the fact that IE can’t display dotted borders (it displays them as dashed). Wow.

I’m also doing a content partition. By default posts coming across the main page will be mostly web stuff, development in general, and startups. This is in an effort to increase the signal to noise ratio. If you still want to read everything (like random posts about the deliciousness of milk), view/subscribe to the everything feed.

I’ve rewritten all urls here to eightpence.com (found an accessible mod_rewrite tutorial while doing so), and everything should be seamless. Let me know if it’s not.

And yes… that dragonfly is infinitely scalable. Go vectors!

Bonus points: click on archives.

A few people have been asking me what the heck I’ve been doing, and what’s this startup nonsense I’ve applied to ycombinator with.

Well, the idea is so ingenious and yet so trivially obvious, that I’ve kept quiet on it to prevent hordes of companies from rushing to implement it. The premise is simple: why do you buy a phone? To press the buttons! That’s why every phone has them right there on the front: big, round and pushable. I’m writing software that will multiply button presses by an order of magnitude, and as a result user satisfaction will increase two to three fold.

Currently, we have to dial 10 (maybe 11, including the one) digits for someone in the country, and a few more to get to another continent. That’s not enough! I’m writing software (in Ruby) that will sit on your phone, and when someone dials your number, will prompt them to enter an additional 15-20 digits. That way you have really cool phone numbers like 13975890751723091855709181230978, and you can change the last few digits whenever you want, instead of being stuck with the same phone number all of your life.

While this idea of obfuscation and friendly user interaction is not new, we’re taking it to a new level. We’ve got a patent filed for defining periodic intervals during the phone conversation (say every 1 minute) to prompt the caller for another string of arbitrary numbers! The fun never stops with our system.

There are billions of phones out there, and our software will run on all of them. $$.

Make it an effort to land on every square of this card:

Design a sound product by playing bingo. Motivating; so is this job ad (coolest ad ever?):

When people have created an account with one of our products, they should shed a tear because the experience is over. They should write ballads and march from town to town reading them to anyone who’ll listen. They should hang signs from highway overpasses proclaiming our good name, hold 3-day block parties and call up radio stations to dedicate cheesy songs.

They should obsess.

Most of all, they should tell their friends about us. And if those friends don’t sign up for our services they should go find new friends, because who needs unsupportive friends?

Caustic rant by Steve Yegge against the Agile programming methodology, and how Google is good “agile” (without the capital A).

Excerpts:

Well, people pretty quickly demonstrated that XP was a load of crap. Take Pair Programming, for instance. It’s one of the more spectacular failures of XP. None of the Agileytes likes to talk about it much, but let’s face it: nobody does it.

If you’re feeling up the day after a big deliverable, you’re not going to code like crazy; you’re going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.

One of the things Steve likes about working at Google is that their development is responsive, and yet isn’t XP. They manage to do this without paying much attention to deadlines, whereas deadlines are used as a driving force in Agile development.

If you’re in the habit of pre-announcing your software, then the general public usually wants a timeframe, which implies a date. This is, I think, one of the reasons Google tends not to pre-announce. They really do understand that you can’t rush good cooking, you can’t rush babies out, and you can’t rush software development.

While Google can afford the luxary of no public deadlines, most companies doing projects for customers need some kind of launch date.

Even without (hard) deadlines, Google still manages to get things done, and quickly-

Google drives behavior through incentives. Engineers working on important projects are, on average, rewarded more than those on less-important projects.

Fun read.