Come gather ’round people wherever you roam
And admit that the waters around you have grown
And accept it that soon you’ll be drenched to the bone.
If your time to you is worth savin’
Then you better start swimmin’ or you’ll sink like a stone
For the times they are a-changin’.

It always happens. Something comes along and catches on with the new kids, while the old fogeys pooh-pooh it as nothing special. Change comes, and only the agile survive. The gesture-based interface made popular on the iPhones and iPads is the change this time around.

I’m not going to insist the specific iOS gesture interface will be the final winner, but I am going to insist that a gesture-based interface will be. If you don’t believe me, hand a gesture-based device to a child and see how quickly they figure it out. Any interface that can be picked up that quickly by a bright toddler is going to succeed, no matter what you or I think about it, and no matter how hard you fight against it.

And if we (web designers and developers) want our work to stay relevant as time marches on, we have to listen to Dylan. We had better start swimming or we’ll sink like a stone. Or like a WordStar. We need to stop thinking in terms of specific interface actions, and shift into more portable semantic abstractions.

Stop Hovering Around and Get Semantic On It

Stop thinking in terms of “hover.” There is no cursor in a gesture-based interface, so hover-based actions no longer make sense. Apples’ iOS turns that event into “touch and hold”, but future interfaces may even dispense with touch, so don’t count on that being the replacement as the gesture-based interfaces mature.

That’s right. The gestures aren’t completely worked out, yet. Apple has a leg up on defining them, but first doesn’t equal winner in this game. If things are going to keep changing, how can we cope today?

We can come out of our denial, first of all. Remember when the mouse was sneered at? Remember when the WordStar folks claimed “the mouse is the ideal computer interface — for those with three hands”? I’ll bet you don’t even remember WordStar, do you?

And that’s my point. We need to change our thinking, now, or we’ll be tomorrow’s WordStar.

Instead of thinking about cursors and pointers, about specific interface actions like “hover” and “mouseout”, think instead of semantics. For example, what we think of as a hover action today (touch and hold in iOS) is really a “more info” action. When you design, define it that way: “triggering MoreInfo on this link will show a further set of menu selections” or “triggering MoreInfo on this term will bring up a definition of it.”

Don’t stop with hover. Continue this process for every action. When you write your scripts, don’t name the objects after specifics like “hover” or “tap” or even “rollover”. Name the objects after the response, such as “MoreInfo” and then apply that object to every UI element that triggers it.

Not only that, use those terms in your presentations. Speaking to clients in terms of “action/response” can help keep you from getting bogged down in implementation minutia during the presentation (“Should that be left-click always? Shouldn’t it be right-click for left-handed people? What if there are 1/3/9 buttons on the mouse?”). You’ll keep your meetings on track, and have more time to build.

The complaints are justified — what it does to links is insufficient for some vision-impaired users, and justified text looks horrible without good hypenation, which Safari doesn’t do, just to name the two most obvious.

But that can be fixed.

The proper way to adjust Safari’s defaults is through a custom user style sheet. But that doesn’t work here, because Safari doesn’t load the user style sheet when the Reader is engaged. Hopefully Apple will fix this bug (and yes, it should be considered a bug) in the near future.

But that doesn’t mean you have to wait until they do in order to change the reader style defaults. It just means you have to go a little deeper to do it.

1. Open your Applications folder
2. Right- (or control-) click on Safari
3. Select “Show Package Contents” from the contextual menu
4. Open the “Contents” folder
5. Open the “Resources” folder

There you will find the file “Reader.html,” which is the template for displaying pages in Safari Reader. In order to change it, you will need to open it in your usual text editor. (Neither Pages nor TextEdit are up to doing this. I used BBEdit to change mine, but Text Wrangler, Textmate, or Coda should be up to the challenge as well. You may be warned about the ownership of the file when you make changes to it.) All of the styles you want to change will be inside the style block with the ID “article-content.” For example:

.page a {
text-decoration: none;
color: rgb(32, 0, 127);
}


is the code block that sets the colors and removes the underline from the links, and

.page {
font: 20px Palatino, Georgia, Times, "Times New Roman", serif;
line-height: 160%;
text-align: justify;
}


is where it sets the text to be justified, instead of ragged-right.

If you want the links underlined, change “text-decoration: none” to “text-decoration: underline” and if you want ragged-right paragraphs, change “text-align: justify” to “text-align: left” and save the file (the system will prompt you for the password when you save the file). Your Reader will now pick up your new settings.

The usual warnings apply to making this sort of change. It’s best to save an unchanged copy of Reader.html to fall back to, and any changes you make may be erased by a future update to Safari, so you might want to store a copy of the changed file in your documents folder, as well. But, hopefully, the next time Apple updates Safari it will fix the bug that prevents user style sheets from being applied to Reader. If/When that happens, I’ll follow up with instructions for creating a sheet to do that, as well.

(Edited 6/14 to correct “left/right” typo. Mea Culpa. Meus bardus.)

class Post < ActiveRecord::Base
end

Oh thanks, now I’m enlightened. No fields, no scope, no getters or setters. What is going on here? Where is the business logic?

It’s a common enough reaction from Rails newcomers, but it completely misses the point.

There are no fields, etc., shown because they are all supplied by Rails by default. You don’t need to write them, and their operation is so obvious you don’t need to see the code for them. There’s no business logic because as yet he hasn’t supplied any; any attempt by the system to automatically create some at this point is doomed to fail because of insufficient information.

You want to see the database fields you’ve created, check the schema.rb file—that’s where you’ll find them. You want your code to access them? Post.fieldname does that; set the value by assigning to it, get the value by reading from it.

To be sure, the context of the article is not supposed to be explaining either Ruby or Rails, but rather what the next generation of PHP frameworks have learned, either from Rails or from their own past. But when he extols the development in Doctrine 2 that allows you to override the default getters and setters with entries in a class file located in a special location in the hierarchy, he doesn’t appear to realize that the Ruby file he was just complaining about being empty performs that same exact function. (Instead, he implies that you can’t do it at all in ActiveRecord, which is patently untrue.)

To override the default getter for the field “date”, for example, you would create a method for date in the existing file (why you’d want to override the default getter for a database field, is another question). Or to create a new field based on it, let’s use “creation_year” for an extremely simple example, you would create a method entitled “creation_year” which would take the date created and pull out just the year. In like manner, to create a custom setter for a field such as, say, “permalink” (to keep with his blog example) you would create a method entitled “=permallink”—Ruby-ese for creating a setter— and inside that method place the business logic for creating a permalink.

I suspect the source of this error is he expected Ruby to work like PHP. It doesn’t, but often it takes a while for newcomers to the language to understand that. Ruby may bear a superficial resemblance to it on the surface, but trust me; it’s horse of a completely different color. It might even be a zebra.

The fundamental point I was making, that the future of web development lies with web application frameworks and not in traditional CMS’s, relies on two rather finely drawn (I cheerfully admit) lines.

The first is on the difference between implementing a CMS and developing for the web. To implement a CMS you typically need specialized knowledge and skill concerning which modules to employ to achieve the aim. The user group got hung up on this distinction, I suspect because many of the CMS implementors thought I was denigrating what they do. I wasn’t. I was simply saying that particular skill set is different from a developer’s skill set. It’s the difference between a production designer and a graphic artist — the graphic artist creates the images the production designer uses. The one who implements the CMS (I’ll call that particular skill set “systems integrator,” for lack of a better term) has a specialized knowledge that comes into play as the modules are assembled to make a web site. The developer’s skill set creates the modules the systems integrator selects from. In the world of the CMS, both skill sets are required, and they are generally found in different people.

The second line is between a traditional CMS and a framework. This line is becoming even finer, as more CMS’s (such as Radiant or Expression Engine) are developed that rest upon published frameworks (such as CodeIgniter or Rails). For my purposes, I’ll define the CMS as a collection of software modules that require no (or minimal) coding in anything other than the standard languages of the web (HTML and CSS) to implement. Wordpress, for example, requires little or no knowledge of PHP (the language it’s written in) in order to be installed and used.

I received a lot of push-back when drawing the first line; it seemed to me a lot of the noise was being generated by the implicit assumption that I was saying the systems integrator skill set was somehow inferior to the developer skill set. This isn’t the case at all.

What I was saying was that the systems integrator skill set wasn’t interesting to the developer. This isn’t saying it’s inferior; I could say the same thing about the developer skill set not being interesting to the integrator. It’s not interesting, because at root it’s not relevant to what they do best. Just as excellent graphic artists can make bad production designers, excellent developers can make bad integrators, and vice versa.

These days it’s possible to put together a CMS that adequately meets 80% of most customer’s business needs from a free or low-cost CMS, using off-the-shelf modules. If a developer plans on making more than a subsistence living in that market, it can only be by giving up or seriously limiting the amount of time spent doing what a developer does best (if satisfactory extensions are free, there’s not a good economic case for getting paid to write them from scratch) and instead turning into a systems integrator. Some developers can do this, some can’t, but even those who can do this only succeed by, in effect, ceasing to be a developer.

Therefore the developer has to step out in a different direction. One possibility is to build completely custom coded websites, while another is to develop and sell modules for the systems integrators to use.

If a developer chooses to go the custom-code route, a framework will provide a solid foundation to build off of. Frameworks provide stub code and basic functionality which can easily be extended to cover the precise needs of the site at hand, without incurring the burden of unnecessary code. Built-in or otherwise available framework modules to handle user authentication, for example, form the basis for a more complete user profile system, only requiring the custom features of the user profile required by the community site under development to be written by the developer. The framework does the heavy lifting, while the developer supplies the chrome and the custom business logic, tailored to 100% of the site owner’s needs. Instead of off-the-rack, the result is a custom-tailored fit.

This road isn’t easy. Off-the-rack suits fit most bodies reasonably well, so the potential market is smaller. But at the same time it’s more lucrative, so the two balance. And with a good framework, a creative and knowledgeable developer can provide enough of a value add to make the time and cost more than worth it to the customer. If the “standard” CMS yields 80% of the goal, a good framework under it can often make the other 20% easier to reach.

If the developer chooses to build and sell CMS modules or extensions, the market is tighter. There will be a lot of competition from low- (or no-) cost alternatives exerting downward pressure on the market, still it’s possible for a developer to make a living there. But in taking that route, the developer still is using a framework. In this case, the internals of the CMS itself form the framework that is used to build the extension. Sometimes that’s explicitly designated as a framework, as with Expression Engine or Joomla, and sometimes it’s just a published API, as with Wordpress or Drupal. But whether it’s officially named that or not, it’s still a framework.

So what’s the “action list” for you as a developer?

• Look at the framework first. Don’t (please, just … don’t) write your own framework from scratch. There are plenty of Open Source ones out there to contribute to; find one you can live with and while you’re learning it, fix some bugs and add some features to make it better. It’ll be easier to add the features you want to an existing framework than write an entire framework from scratch around those features.
• What CMS choices are built on it? This will feed into the next decision you make. If there are some good CMS choices on the framework, it will make it easier for you to write extensions for others to use, expanding your reach and your market. And, hopefully, your bank account. (Yes, money isn’t everything but the lack of it makes it hard to buy new hardware.)
• Decide — Custom Code or CMS extensions. Make this decision on top of the best framework you can find. The framework itself will provide some of the tools you’ll be using to build the modules, after all, and no one likes working with inferior tools.

There’s you road map. Start your journey.

Robert Vining, newly minted chief spokesman and admin for All Together As A Whole is finding that out, right now. He writes about it in this blog post.

I’ve been there, Robert. You made the right choice.

In a nutshell, he was told he was going to be removed from helping with the joomla.org forums unless, now that he’s in charge, he bans an individual from an unaffiliated website. (It says “independent” in the tagline, in case you’re easily confused.)

Now let’s note that this person was banned from joomla.org, and from all appearances the banning was certainly with cause. But note also this individual has not given cause to be banned from the site Robert administers. And that’s the crux of this.

Let me speak to this from direct experience. I used to organize chess tournaments; my events were among the strongest held in my state every year. And more than once I had to listen to players from a neighboring state expressing “sympathy” for me for having to put up with another player from their state. And every time one of these “helpful” people said that, I responded that the person in question is better behaved in my events than most other players, including themselves. I don’t know what their issue was, and I don’t care. I just know that when he was in my house he behaved himself well, and I wasn’t going to let them litter my yard with their garbage.

I loaned money to a player once, and was instantly told (by my partner, no less) that I was making a mistake, and I’d never see the money again. And the next day, before play began, I got my money back.

This is the lesson I learned long ago, from direct experience. Behavior in one location, among one set of people, under one set of conditions, does not dictate forever behavior in other locations, among other people, under other conditions. And to assert otherwise is dangerously stupid.

I’m leaving names other than Robert’s out of this for a reason. The point here is one of principle, and is not in any way personal. Let me say that I would certainly have voted in favor of the original ban, had I had a vote, so in no sense is this aimed at criticizing the original ban, nor should it be seen as excusing or condoning the behavior that caused the ban. Let the joomla.org ban stand unchallenged, by all means. It is instead aimed at the presumption behind further opinions expressed during discussion of this by two members of the project leadership that this person should not be allowed the chance to prove he has changed and that he can participate somewhere else without giving offense. In effect, they assert he should never be forgiven.

I find that attitude dangerously arrogant, and deeply offensive. Almost as offensive, in fact, as the original conduct. People can change. I have first-hand knowledge that people can learn how to behave themselves. Not only have I seen it around me, I’ve seen it in myself.

We all know that we can blow it for ourselves by our own conduct. That’s how it should be. But how comfortable can we be around people knowing they’ll turn on us, and turn us out, when our only offense is to have the grace to give someone whose only transgression is words a second chance?

I honestly don’t know. And that worries me.

(Full Disclosure: I edited this post after it was published. I broke what was paragraph #3 into what is currently paragraphs #3 and #4, to make it more readable.)

It’s a lie.

And that’s a problem. Apparently, he made those wonderful claims of his without ever once checking the reality of them. Most of those sites that supposedly don’t show anything, actually do. As this set of screen captures shows.

Which means he wasn’t interested in truth at all, nor even in the experience of web users, as he claims. All he wanted to do was complain because that Big Meanie over at One Infinite Loop in Cupertino didn’t want to let him bring his own toys to the iPad and iPhone party. Boo hoo.

Let’s get something straight right up front. I ain’t no fanboy. I don’t own an iPhone, nor will I be queueing up on day one to get an iPad. I’ve been an Adobe customer for as long as I’ve been an Apple customer, since Photoshop version 2.x. I even stayed an Adobe customer after they deliberately killed the best illustration program I’ve ever used (Freehand — after two earlier failed attempts they finally managed, not to beat it in the marketplace, but rather they kept buying companies in a repeated attempt to get it off the market). I’ll admit to a point of view, here. I’m amused by the flash fanboys who can’t seem to realize their own playground is just as proprietary, just as limited and controlled, as Apple’s.

Yes, it’s amusing to watch Adobe, from their closed proprietary yard, cry foul at Apple’s closed proprietary yard (pot, meet kettle) but that’s about it. The world, and the web, will do fine, with or without Flash. Right now, there are far more examples of bad Flash use than bad HTML5 Video use, but I’m sure that will level out eventually — flash developers have certainly not cornered the market on ineptitude. It only seems that way, sometimes.

Professionals know the iPad is just another device we have to deal with, just like we know Flash is just another tool in the box, and no tool is the right choice for every device, and probably never will be. So we plow around the rocks in the field that we can’t lift. For simple video, the solution is fairly obvious: do your video in H.264, because that will give you the widest access to your customers. As John Nack pointed out in a post on a more official site Flash will deliver H.264 as well as native flash format. So you do the video in H.264, and use Flash as the ancillary system to deliver the H.264 to the clients that can’t see it natively. Problem solved, the same way we’ve been working around IE’s limitations for years (thanks for the practice, MS).

John raises other issues about why Flash is such a hog on OSX, and while they may or may not be true (I admit I don’t know) I really can’t see why I, as a professional web builder, should care. It is what it is, and I have to deal with it the way it is, not the way John Nock or Steve Jobs, or anyone else, for that matter, wants it to be. And the way it is, the performance of Flash on OSX is sub-par. That’s reality, and it’d be far more productive to fix that than stand around pointing fingers.

The first question to ask is do they test the software at all before they supply it to the customer. It’s possible they don’t, in which case they have a point that testing will take more time, and my only advice, to both the developers there and to their customers, is “Run Away!” It’s irresponsible and unprofessional to make people pay for untested software.

Let’s assume they actually do test the software before releasing it to the customer. So, now we have the question of “When?” Most likely, they’re waiting until the end of the development process. Which means that if a bug is detected at that point, not only is there a lot of code to sift through to find it, there is also the very real risk that other code has been built upon the original buggy code and it may have to be reworked as well as just the buggy code itself. Making the cost in time required to both find and fix the bug much higher than it would have been if the bug were caught earlier.

Obviously, then, the earlier in the process the bug is detected, the easier and cheaper it will be to fix it. One way to detect it earlier is to move testing farther up in the process by breaking the testing up into stages, and testing what’s been developed in that particular stage. Then you catch the bugs earlier, making it cheaper to find and fix them. But if you do that, you’ll still need to retest everything from the previous stage, to be sure you haven’t broken something along the way.

It’s cheap-er but not cheap-est. The logical extreme of this approach will be to test all code immediately after writing it. But there’s still a cheaper way to do it.

Let’s take a step back from the word “testing” and consider the entire development process. Before writing any piece of code, the developer must first know what the code is expected to do. (The idea of starting to write and just going where the code takes you, like fiction writers do, just doesn’t scale.) This idea is captured in the documentation somewhere (the precise where and format is procedure-dependent) and then the developer starts to write the code. And, at some later point, tests are devised to make sure the code does what it is supposed to do.

This means documentation of what the code will do is written, then it and/or the code itself is later studied to derive tests to be performed on it. What if we combined those steps into one? We’ll think about what this particular piece of code to be developed will be doing, and instead of writing it out in english or pseudo-code or whatever, we document it by writing a test that says when this input is received, this output should be produced. It will take less time, because the same person that writes the spec will write the test, so no time is spent transferring the knowledge from one to the other.

But we can find a better way even than that to speed the process: if the developer who will write the code writes the tests, it will help fix in the developer’s mind a clear image of exactly what the code should be expected to do, making the coding itself take less time. (A good developer will consider the problem and the edge cases anyway, all we’re doing is writing them down in the form of the test.) And, while doing the actual coding, if there are determined to be better ways to handle the task than the one originally chosen, adding new tests or editing existing ones will perform the same clarifying function for this new direction. What’s more, if the tests are used as the documentation of the expected function of the code, the documentation will always be current, instead of having to be updated at a later point (or worse, left to “rot”).

Tests only take a few seconds to run. (One major project I’ve been involved with has over 2000 tests written so far, and the entire suite takes a little over a minute to run, testing several thousand lines of code. Any one segment of the testing is done in a mere handful of seconds.) If the tests are written first, and done right, the developer can have confidence that the task is complete, because the tests say so.

There’s a little startup cost, in terms of time, when you first begin this approach, because it will take a little time to get up to speed on writing tests, but it won’t take long. Good developers see “edge cases” for their code rapidly, so test cases will not be difficult to come up with at the start, and will take less time with every cycle. Developing the ability to find these cases quickly and easily through this practice will only make for a better developer. There really is no downside to this practice.

We’ve seen writing tests before coding leads to finding bugs faster, fixing them more cheaply, developing finished code faster, and I’m not done, yet.

How many times have developers “fixed” a bit of code, only to break the code somewhere else? (Come on, be honest, we’ve all done that a few times.) Or added a new feature that breaks an older one? Rerunning the entire test suite on a regular basis (called “regression testing”) will catch those events quickly, again when the bugs are most easily found and fixed. This means the code resulting from this practice will be better code, as well. Setting up the entire suite to be automatically run on every check-in will precisely locate the files where the bug was introduced. No more hunting through thousands of lines in hundreds of files. Again, a speed gain, not a loss.

When a bug escapes detection and is found “in the wild,” the first thing to do is write a test case for that bug. Then code the fix, rerun the tests and see that not only has the bug been fixed, but no new bugs were introduced. Keeping the bug test cases around will prevent the bug from resurfacing after some later changes. Once again, higher quality code is achieved.

Management Summary: Far from costing you time, not only does the practice of writing tests up front ultimately speed up your development, it will also raise the overall quality of the code and make maintenance easier. The only possible way it won’t is if your developers are perfect, and never make mistakes. Didn’t think so.

Don’t have the time to write tests? Son, I’m too busy not to write tests.

As I look at my deploy.rb file I’m reminded of the old Tom Lehrer ditty, “Lobachevsky”:

I am never forget the day I first meet the great Lobachevsky.
In one word he told me secret of success in mathematics:
Plagiarize!

Plagiarize,
Let no one else’s work evade your eyes,
Remember why the good Lord made your eyes,
So don’t shade your eyes,
But plagiarize, plagiarize, plagiarize -
Only be sure always to call it please ‘research’.

So here is the result of my ‘research’ (where I remember where I got the code from, I will also quote the source; where I don’t remember, I apologize in advance):

First, there are the Passenger-specific recipes:

desc "Restarting mod_rails with restart.txt"
task :restart, :roles => :app, :except => { :no_release => true } do
run "touch #{current_path}/tmp/restart.txt"
end
desc "Starting mod_rails with restart.txt"
task :start, :roles => :app, :except => { :no_release => true } do
run "touch #{current_path}/tmp/restart.txt"
end

desc "stop task is a no-op with mod_rails"
task :stop, :roles => :app do
end


This code block is one of those I found so long ago I’ve forgotten where I picked it up from. Passenger is usually run in ‘production’ mode, which means the server needs to be restarted whenever a code change is mode. Rather than taking apache down, this a accomplished by “touch”-ing a file called “restart.txt” and when the server notes the change it reloads the code. This code block will do that, except when the no_release option is active (no_release after all means no changes have been made, so there’s no need to force a restart).

I put the same code in for “start” as for “restart”, not that it’s needed. I was just being anal about having a recipe for that; if I ever find I need that function (as opposed to restart) I’ll have to work out first of all if it’s possible even to do it in capistrano. Likewise with “stop;” the recipe is a placeholder for functionality I’ve never needed.

This next recipe came to me from Matt Darby who in turn got it from Darcy Laycock:

desc "Make sure there is something to deploy"
task :check_revision, :roles => [:web] do
unless `git rev-parse HEAD` == `git rev-parse origin/master`
puts ""
puts " \033[1;33m**************************************************\033[0m"
puts " \033[1;33m* WARNING: HEAD is not the same as origin/master *\033[0m"
puts " \033[1;33m**************************************************\033[0m"
puts ""

exit
end
end


(when using, preface the deploy namespace with:
before "deploy", "deploy:check_revision"
so it runs before the deploy.)

The one qualm I have with this recipe concerns the "rev-parse" -- when I get the time and inclination I'm going to look at using "ls-remote" instead. Not sure at the moment which way is "the right way" but this works so changing it isn't high on my priority list.

The principle here is to stop me from wasting time. I've been working for days on some changes, and they're committed to my local repo, but somehow I forgot to push the changes up to origin, but instead I just deploy. And I sit there waiting for the deploy to finish, only to find the new version has the same bugs as the old. This recipe checks the local repo against origin and if they're not the same, drops you out of the deploy with a message that you forgot to push before deploying.

(I toyed with the idea of just automatically doing the push instead of the message, but decided that wouldn't be a good idea, as I might need to do something else before/after the push, and even if not, typing one extra command line didn't seem a huge penalty to pay for absent-mindedness. Feel free to disagree with me.)

I pulled this post-deploy recipe from the ehaselwanter-radiant-capistrano-extension:

after "deploy:cold", "deploy:radiant:bootstrap"
after "deploy:migrate", "deploy:radiant:migrate:extensions"
after "deploy:update" do
run "mkdir #{latest_release}/cache"
#run "cp #{latest_release}/config/database_eyecatch.yml #{latest_release}/config/database.yml"
run "chmod -R g+w #{deploy_to}"
run "[ ! -d #{shared_path}/assets ] && mkdir #{shared_path}/assets; true"
run "[ ! -d #{shared_path}/galleries ] && mkdir #{shared_path}/galleries; true"
run "[ ! -d #{shared_path}/uploads ] && mkdir #{shared_path}/uploads; true"
run "ln -s #{shared_path}/assets #{latest_release}/public/assets"
run "ln -s #{shared_path}/galleries #{latest_release}/public/galleries"
run "ln -s #{shared_path}/uploads #{latest_release}/public/uploads"
end


I’m using a few other recipes from that file as well, but I’m not convinced about them, and am still looking to revise/replace them, so I’ll not post them here.

Also, I’m rather interested in taking a peek at Giovanni Intini’s set of recipes but the link there doesn’t seem to work.

I’m still looking for useful recipes, so please point me to others, especially for bootstrap and migrations, as the ones I’m using aren’t yet reliable enough to publish.

Some designer’s deal with this by choosing to submit to the lesser evil. The frustration of having to scroll horizontally is higher than the frustration of having to scroll vertically, so they fix the width of their design. They choose a width that will fit within the vast majority (75-80%) of their visitors’ windows. What width they choose depends upon their intended audience: if they make it too narrow, the frustration of those with wider windows grows, and if they make it too wide, the number frustrated horizontal scrollers improves.

There’s no perfect number, so they try to balance them as best they can. So, how would someone practicing Reactive Layout approach this problem?

We would start by reviewing the principles, looking to apply them. “The web is not paper” tells us window sizes can change, but also that layout can change, as well. Unlike with paper, the web does not force us to stay with one layout, though we can if we want. “The Web is a two-way medium” gives us another hint: the user’s browser can help us by telling us what the window size is. We don’t have that information now, but we can have it for the asking, in multiple ways. “Unity is not unison” gives us another hint — maybe every browser doesn’t need to see the exact same layout to make the site work. And the Hippocratic-sounding “Do No Harm,” while it doesn’t directly help us here, it constantly reminds us that whatever we do shouldn’t break things for others.

Stretching Exercises

One way we can approach the problem is to make our design stretch with the window. The way to do this is to convert all horizontal measurements to percentages of the window width. For example:

body { width: 90%; margin 10px auto; }

This results in the body being centered in the window. If the window width is 1200px, then the body is 1080px wide, if the window width is 900px, then the body is 810px wide. The content for the page is then flowed inside this container, and the page gets longer when the window narrows. Boxes placed inside the body should also be sized as percentages to preserve their elasticity:

#menu { width: 25%; padding: 0 2%; float: left; }
#main { width: 66.5%; padding: 0 2%; float: left; }

This would result in two boxes placed side-by-side, and they would stretch with the window. (Note the percentages add up to 99.5%, not 100%. This was intentional, though the fraction itself is arbitary. It’s necessary because of rounding errors that can happen when working in percentages. When sizing a box by percentages, remember that the final size of the box will be in whole pixels, no matter what the math works out to. If the browser rounds up, the box may become a pixel wider than you expected, and that would mean there wouldn’t be room for the second box, and the design would break. If you deliberately make your percentages add up to less than 100%, you avoid this sort of breakage.)

The advantage of using this method is simplicity; you have only one layout to work with and tune. But the disadvantage of this method is that it can create extremely long reading lines. And while this isn’t fatal, you can do something to limit the damage:

#main {
width: 66.5%;
padding: 0 2%;
float: left;
column-width: 13em !important;
column-gap: 1em !important;
column-rule: 1px dotted black !important;
-moz-column-width: 13em;
-moz-column-gap: 1em;
-moz-column-rule: 1px dotted black;
-webkit-column-width: 13em;
-webkit-column-gap: 1em;
-webkit-column-rule: 1px dotted black;
}

This code takes advantage of the column-flow rules in CSS3. WebKit and Mozilla based browsers will recognize the vendor-specific rules, but as the specification gets approved, more browsers will recognize the standard-compliant rules at the front. By placing those rules before the vendor-specific ones and marking them as important, we future-proof the CSS, indicating that the standards-based interpretation should be used, when available. Not all browsers support them, but those that don’t won’t be adversely affected by these rules (“Do No Harm”). And those browsers that do support these rules will take advantage of the extra room to create more columns (“Unity is not unison”).

This isn’t a solution for every layout, however. Long stories will be broken into two columns, with each column possibly flowing outside of the window, causing even more vertical scrolling. I prefer to use this particular approach only when I’m fairly certain the text will be contained within a single window, but if you decide to use it even when there is a potential for longer stories, be kind enough to your readers to place a link at the bottom of the story’s block that will automatically take them back to the top of the story. Saves them scroll time.

Follow The Script

A second technique you can apply here is javascript-based. It was given the name “Switchy McLayout” by Mark van den Dobbelsteen when he wrote about it for A List Apart and I kept the name as a nod to him when I wrote my MooTools plugin.

Follow the links for details, but the basic idea is to read the window width with Javascript (The Web is a Two-Way Medium) and attach a class name to the body tag based on the width. That class name can be used in the CSS to change the page layout (Unity is not Unison — narrower pages use fewer columns, so the main content doesn’t get squished).

Not everyone has Javascript enabled, so the proper way to implement this is to select a “default” state (Do No Harm). Then we use the classes and the specificity rules to make changes in the default layout like this sample from a past layout of mine:

#sidebar {
display: block;
clear: both;
float: none;
padding: 0 0.5em;
border: none;
}
body.wide #sidebar {
width: 23%;
float: right;
padding: 0 0.5em;
border-left: 1px dotted #999;
}

This describes the sidebar as a block that displays where it falls in the regular flow of the document unless the window is wide enough to support an extra column, when the sidebar will float out to the right edge instead.

The advantage to this approach is that it leverages the flexibility of CSS to provide multiple layouts for the same markup (see The CSS Zen Garden for hundreds of inspiring examples of just how much flexibility there is in CSS) and uses Javascript to determine which layout should be used.

Of course, no advantage goes unpaid for. Visitors with Javascript disabled get your default view. Of course, if you select the default view in accordance with the principle of “Do No Harm,” that in itself won’t be an issue. But a further disadvantage is the creation of multiple layouts. Even though you can limit this effort with proper forethought, it is still an effort. Is the extra effort worth giving a better, friendlier design to a portion of your audience? That’s a question only you can answer. My task is to tell you how to use it, you have to decide for yourself if you’ll use it.

Questioning The Media

A third approach to this is using media queries. Media queries are a Candidate Recommendation for part of CSS3, and are supported by some browsers (as of this writing, all current versions of the Big 4 support it, I believe). How do they work?

@media screen and (min-width: 800px){
#sidebar {
width: 23%;
float: right;
padding: 0 0.5em;
border-left: 1px dotted #999;
}
}

The style block above sets out style selectors and rules to be applied if the window is less than or equal to 800px. It basically does the same thing as the previous javascript example would do, if the threshold for the “wide” class was 800px.

The advantage of this technique is that it works even when Javascript is turned off. The disadvantage is that users of less-than-current browsers won’t see any styles inside the media queries. The odds are great that, for today at least, you’ll reach more visitors with Javascript than with media queries. But time is on the side of media queries, because while people who surf with Javascript turned off will probably always do so, people do upgrade their browsers, so eventually more people will be served by media queries than by Javascript.

Once again, you’ll have to weight the effort of this against the benefit to your visitors for yourself, but even if you decide not to do it for now, I’d recommend playing around a little with this code to get familiar with them. You will (eventually) find them useful, perhaps even indispensable. For one thing, they may be the most reliable way to target cell phones and PDA’s in your audience.

The complaint is that people aren’t seeing the ads on web pages, so the proposed solution is “don’t let them see the web page until after they see the ad.” My first reaction: Your only synapse just died of loneliness, didn’t it?

Why should you expect web ads to be different from print ads? Few if any of us consciously look at print ads, either.

That fact was brought home to me years ago. Back in a previous life, before I got seduced by web building, I was a subscriber to Information Week, and they sent a researcher to my office to test the effectiveness of their ads. It was a simple study: take this copy of the magazine, hit your two favorite sections of it, then answer some questions.

The questions were about ads that had been placed around the stories, and I failed. I remembered the stories, no problem. But I didn’t remember seeing a single ad on the pages I looked at. I knew there were ads there, could even tell the researcher where they were on the pages, including the two-page ad spread in the middle of one story. I just didn’t remember what the ad was about. My mind had classed it as “irrelevant” and moved on.

Now we have made the discovery people do the same thing on web pages, and somehow it means traditional web ads are bad, and we need a more intrusive model (intrusive is my word, not theirs, though their word — interruptive — is hardly less pejorative).

All this proves is they Just Don’t Get It. My visit on the web isn’t about them, it’s about me. I want some information, or a product, or a service. Drop a video ad in front of me to block me, and I’ll just move on to the next site on my search list. Do it often enough and I may just stop coming to their site at all.

The main purpose of advertising is to give me a good feeling about the product/service, right? Well, like most people these days, I already think I waste too much time looking for things on the web. Delay me in this quest, and just how do they suppose I’ll manage to come up with a good feeling for them?

The ad agency doesn’t care; they’ve already got their money, and in any case, I won’t hold it against them. But just what will be my disposition towards HP, for example, if I’m detoured from the information I’m seeking because the ad agency felt their ad was more important than my search? If I’m nice, all I’ll do is make sure their sales rep gets needlessly delayed in my waiting room for a few hours before not making a sale.

The arrogance of you advertisers is one of the wonders of the modern age. No, your message is *not* more important than my search for information. No, you do not have the right to interrupt my business to try and sell me something I’m not looking for at the moment. You wouldn’t think of grabbing random passersby off the street and forcing them against their will into a small room to pitch a product to them. Why do you think I’ll take to hijacking my web search and holding it for ransom any better?

Your excuse is “It’s like a TV commercial.” No, it’s not. It would be if what I was coming to see was a video. But you’re putting it in the Wall Street Journal, not a video site!

Still, if that’s what you want to do, I guess I can’t stop you. Oh, wait a minute. It’s my computer. I get to choose the sites it goes to and the software that runs on it. I give this new trend 30 days before blocker software is available that redirects the intrusive ad into nothingness.

See? That’s the trouble with being intrusive. With the print-style ad placement, I usually don’t see the ads, but occasionally, I’ll have a look. I’m not always single-mined about the search for information. Sometimes I’m looking for something new and different, so I’ll deliberately look at the banners or the page ads. I can do that because I have the choice.

That’s what clever and well placed ads get you. They get you my attention, when I’m in the mood to give it. And from that, they get you my business.

I suspect I’m not alone in choosing to look at ads occasionally. But take that choice away from us, and we’ll choose “never” over “always” every single time. Ok, so maybe that means we lose once in a while, when we miss something we would have looked at otherwise.

But you, advertiser? You’ll lose every single time. And so will you, site operator, as inescapable intrusive ads encourage us to find (or even create) other outlets.