The traditional question for web designers to ask before starting a project is, what screen size should we design for? The answer usually comes from looking at a table of browser statistics showing the screen sizes that web users currently own.

The problem with this approach is that users don’t always size their web browser windows to fill their screens. Actually, many users do, but they shouldn’t — especially with ever-increasing screen sizes. After all, the purpose of a large screen is not to let you view one thing at a time, with more empty space around it — it’s to let you view more things at one time. It’s just like a large desk or workbench that lets you spread out several documents or tools for easy access. Most people don’t buy large desks so they can read large pieces of paper, but so they can lay out several pieces of paper side by side.

To accommodate this, web designers should not view their job as “how to fill up those big screens.” Instead, they should design a site at the smallest reasonable size and then let users arrange that how they wish within their workspace.

An even better approach is to design a site that can automatically expand and contract to correspond to the user’s window (not screen) size. If a user wants to view a number of smaller windows, the site will look good; if a user wants to view just one large window, the site will also look good. This is called “liquid design,” and although most designers don’t approach their work in this way, I always advocate for it. “Fixed” designs are still more popular, but with computing devices ranging from 40″ flat-panel displays to 2.4″ phones, I’m hoping more designers come to realize that the best person to decide what size to make the site is the end user.

In The Mythical Man-Month, Fred Brooks distinguishes between aspects of programming that are hard because we don’t manage them well enough, versus aspects of programming that are inherently hard. This has stuck in my mind over the years as I’ve thought about how to improve my techniques.

Today I was thinking about one inherent problem, which is the level of specificity that programming requires. I don’t think most people understand this, so I wanted to take a shot at explaining it. To make this a little more concrete, let’s imagine that you’re designing software for a robot, which will help with your cooking.

You don’t like chopping vegetables, so you decide to program your robot to carry out that task. First, you program it to distinguish a vegetable from other objects in the kitchen. In this process, you realize how many different shapes vegetables come in, and how difficult it is to tell a vegetable apart from other objects. But eventually you limit yourself to 10 different vegetables and teach your robot to recognize them.

Next comes chopping. The basic up-and-down motion of the knife is easy enough to program, but there are a lot of decisions to be made during the chopping process. How large should the pieces be? What shape? This varies by the recipe and maybe by the vegetable, so you end up creating a chart that your robot can refer to when beginning a new chopping task.

You’ve spent more time on this than you expected, but now your robot is working pretty well. You set it to work on a bag of potatoes and turn your attention to other things. OOPS — when you look again, the robot has chopped a few rotten sections of potatoes along with the good sections. Your robot doesn’t know how to recognize bruises or spoiling, so you have to teach it that, too. Unfortunately, a rotten potato looks different than a rotten tomato, so you need more charts explaining all the possibilities. Eventually, by trying some different vegetables and watching the robot carefully, you get it to correctly identify and reject rotten vegetables every time, without throwing away too many good vegetables in the process.

Satisfied, you leave the room to work on something else, and come back in a few hours. OOPS — the bowl that the robot was using is full, and the chopped vegetables are overflowing onto the countertop and the floor. Now you need to teach the robot how to tell if the bowl is full, and what to do when that happens.

I think you see the problem now: software (whether in a website or a robot) only does what we tell it to do, and no more. The key is thinking, in advance, of every specific instruction we will need to provide, for every possible scenario. But this is difficult because our own minds are very adaptable and don’t require so much planning.

This is where my job as a programmer comes in. If a client asks me to build a robot that “chops vegetables,” I need to translate that to a robot that “identifies particular vegetables, divides them into particular sizes and shapes, rejects pieces that don’t meet particular standards, and stores them appropriately.” To the extent that I can think of these requirements in advance, I can offer an accurate time and budget estimate, and build a product that the client is happy with.

By the way, I have a narrower definition of “bug” than most people, and that’s easy to discuss using this analogy. When you found that your robot was not discarding the rotten vegetables, was that a bug? I would say no, because nobody had bothered to tell the robot about rottenness. That’s a problem, but it’s not the robot’s fault! If, on the other hand, you had programmed the robot to recognize a particular kind of rottenness in a particular vegetable, and it still failed to do so, then you’d have a bug — a piece of software that’s not doing a task it was specifically designed to do.

The good news is that once we get that robot working, it will chop a heck of a lot of vegetables without further intervention. The bad news is that it falls upon us to define in advance every detail of that task.

I’ve always been fanatical about backups, based on the mantra that in the computer age, one should never have to do the same work twice. My standard policy is that I keep all project files in a version control system, back up my computer daily, and make an offsite backup monthly. This works great with the development model where I create all the files in a website on my computer, then upload them to the remote server. My computer is, essentially, the master copy and the server files are secondary.

When my favorite hosting company had an incident recently, losing data for two of my clients’ sites, I realized that this model is quite outdated. Modern websites consist of much more than the developer’s files. With a content management system, my clients are adding content and files from different locations that are only collected in one place on the server. And with a social networking site, users are adding content constantly, without which the site would be worthless. Without an automated backup of the site’s database and root directory, replacing content added by the clients is time-consuming, and replacing content added by users is impossible.

My solution is a new system I’ve created for my clients. It allows me to configure automated backups of the database and the root directory, at different intervals if needed, as frequently as once per hour. I and/or my clients can receive email notifications of every backup, and every backup failure. The backup files are saved at a different datacenter than any of the sites, and are available to clients any time at a password-protected web page. Clients can even log in and run a manual backup at any time.

This should bring my backup strategy up to the level of my current website development. I can’t say I’m looking forward to using it, but I do like knowing it’s there!

This week I achieved a goal that’s been simmering on the back burner for a while: getting started with iPhone app development. Apple calls each of its new products “revolutionary,” but the iPhone platform (which also includes the iPod touch and the upcoming iPad) actually is, because it creates new ways to interact with the device. Beyond moving a mouse or clicking a button, the iPhone responds to movement, multi-touch and even puffs of air directed at the microphone. Because of the latter, virtual musical instruments are a popular app genre, and since I’m a musician that’s where I put my foot in the door.

My app is designed for aficionados of jug band music, a form of traditional blues and jazz played on homemade instruments. The app includes a washboard, spoons, kazoo and jug. The trick is that they each play like the real instrument: you rub the washboard, tap the spoons against your knee, hum into the kazoo and buzz your lips into the jug. I made a demo video to show how it works.

Programming for this device was pretty brutal, because most of my experience is with the loosely-typed PHP, and the iPhone runs on the strongly-typed Objective C. Simple commands that would have taken me less than a minute in PHP took me hours in Objective C, until I started thinking in terms of data types. The syntax was killing me for a while — figuring out where to place an asterisk, an at-sign or a square bracket — but I’ve experienced that in moving from JavaScript to Perl to PHP over the years. I’m working on a second app now, and the new challenge is memory management, but I’m getting the hang of that, too.

I was especially curious about the infamous App Store approval process, which Apple uses to ensure quality apps and, some suspect, protect its business interests. But I didn’t have any problems here. The code-signing process was cumbersome, but I followed all the tutorials and my app was approved on the first try. If you have an iPhone or iPod touch and can spare $.99, you can buy a copy now. Who knows, you might even get hooked on jug band music!

As a web developer I’m constantly looking for ways to improve my techniques, and one big change I made this year worked out better than expected. For the two large sites I built from the ground up this year (and a third, smaller site), I used Object Oriented Programming (OOP) for the first time.

I’d tried wrapping my mind around OOP many times over the years, and it always seemed like something useful for game programming, not web development. But it finally clicked when I found this user comment in the PHP manual, and I decided to give it a try at my next opportunity.

On the first project, I spent an extra 20 or 30 hours up front just thinking about how I wanted to use this technique. I ended up with a Base class that handles routine things like escaping quotes in database values and dealing with the discrepancy between saving a new record and updating an existing record. More importantly, I had to figure out what code would live in the Base class, what code would live in the other classes (like Order, Customer, etc.) and what code would live in the page scripts (like store_checkout.php). Eventually I found the right balance, and the second project went more quickly than it would have without OOP — a pretty fast return on investment. Since then, I’ve found updates and enhancements to be, maybe not quicker, but more reassuring because I know that all the related code is in one class.

My favorite thing about this approach is that it allows a greater degree of abstraction in my code. I always use Contemplate to separate design, content and functionality from each other. But OOP makes it easy to further separate functionality into data processing and data storage. It’s been easy to put SQL code only in the classes, and as a result, I only have to change a few files if my database structure changes. In fact, I quickly extended my Base class to store data either in a database or in a session — which is useful for something like a multi-page registration form that doesn’t create any records until the last page — and this distinction is completely abstracted from my page scripts, which only care that the data is being saved. If a new technology ever comes along to replace SQL databases in web development, and these sites are still around, it will be relatively easy to convert them.

I still have a couple adjustments to make in my programming style (for example, expanding my naming conventions to accommodate the variables I use for object instances) and I may be overusing static methods (which, beyond being organized into classes, are no different than traditional functions). But I’m sure that I’ll continue using this technique into the coming year and beyond.