Friday, July 10, 2009

Leave the Poor Table Alone

Traffic SignSo, I realize that with some clever hacking and a butt-load of time, you can do just about anything with divs and CSS, but I think the anti-table thing has gone way too far! I've even seen people display tabular data without using tables. I mean, great. Look at you. You're fancy and all, but what have you accomplished? Tabular data is what tables were designed for in the first place.

So, why are people so steadfastly opposed to tables in HTML layout? Well, I've seen oodles of reasons including things like speed of data transfer, separation of content and layout, ease of redesign, no spacer gifs, lower html complexity, accessibility for persons with disabilities, etc.

Of course, there are sites out there that demonstrate all of the things that can be accomplished using nothing but divs and CSS and they're really great to look at and enjoy; I've learned a lot about CSS from them. But, just because you can doesn't mean you should. I mean, when was the last time you heard about someone doing something with "nothing but" and it wasn't a stupid human trick? Mac Gyver could take down a swarm of enemies with nothing but a Milk Bone, some shoe string, a little fertilizer, and duct tape; I, on the other hand, carry a Glock.

But, here's the real issue: whether you use tables or not, there're right and wrong ways to do anything. Just like there are wrong ways to use tables for layout, there are wrong ways not to. My point is that you can very cleanly and appropriately use tables for layout and still use CSS for almost all of your actual presentation.

As a result, I've yet to come up with a compelling reason to eliminate tables from layout altogether. For example, using a table for your overall layout can give you cross browser compatibility that is very difficult and effortful to achieve with CSS and divs. CSS and DIVs are rendered differently among the several browsers; however, CSS and tables are relatively consistent.

I've found that often times, I can use only one table and achieve exactly the layout I was looking for when a div design would require 3 or 4 levels of nesting. In this case, it is actually cheaper and less complex to use tables than it is to use divs and it took me a tenth of the time.

While I agree there should be a separation of concerns within the definition of websites to keep content, presentation, and behavior separated, using tables to position elements only is a very minor violation of this principle. In fact, using tables in this way is exactly the same as using divs this way. Afterall, any time you use an HTML tag your intent is to describe something about the way the content is displayed. Then, you modify that behavior with CSS. Really, the only thing you can't do with tables and CSS is fundamentally change the position of items.

I suppose that's where people are coming from when they mention redesign. Now, that may be the case and I don't really know that much about it. I'm not a web designer; I'm a software engineer. I spend a very small percentage of my time concerned with layout as there are usually much bigger fish to fry; however, I've never been on a redesign project that didn't require HTML changes.

As a result, it never made a difference whether the page was tables + CSS or divs + CSS; we always had to rewrite some HTML. Furthermore, it's generally in a template somewhere. In fact, many times, it has been easier for me to reposition elements on a page because I was using tables for layout rather than divs. The CSS required to move stuff around and make it cross-browser compatible is often a royal pain in the ass, but it's pretty easy for me to move a one line server side include or a user control in .net.

I never really understood why people used spacer gifs. I don't use them and never have so I don't know what that has to do with tables. I also don't know what tables have to do with accessibility. I've read some things about readers not being able to do anything with graphics because they can only interpret and present text. Divs, tables, plain text, whatever . . . it's all the same text so I don't really know what this has to do with tables for layout.

In my years of experience, I've gone through the dogmatic anti-table phase and I've gotten over it. I simply cannot come up with a good reason to eschew tabular layout. Most of the time, I can do what I want with divs and CSS and I do. When something is difficult with a div, I usually throw a table at it. As a result, I get the job done faster and I save clients money and they ultimately get the same quality software. I've also not had any complaints about accessibility, maintainability, or load times. To me, it's a win-all-around kind of thing, so until I can find solid arguments against tables, I say leave the poor table alone. It's another tool in the toolbox; use it if it makes your life easier.

Monday, July 6, 2009

Sign Placement Takes an Engineer

Traffic SignI was driving into work this morning and I noticed a sign off to my right. It was a temporary sign which evidently was warning us drivers of some upcoming event. It was too small to contain the entire message so they broke it down into pages which displayed for about 3 seconds each. The first page I saw read:
July 12, 2009
From 6:00 AM
To 7:00 AM
Interested, I eagerly awaited the next page. About 3 seconds later the sign read:
Exits 6 and 7
But, before I could find out what was happening during that block of time, I passed the sign. What in the world did that third page read? Should I plan on staying home? Should I leave home? What's happening?

Well, I started thinking about it and it occurred to me that it was pretty dumb to put that sign on the side of the road right after a curve. Why not put it after the curve in the ensuing half mile straight away?

So, I looked into it. If you take a look at the image above, you'll see the approximate location of the sign. I drew a line segment starting at the sign, passing the west most occluder, and ending at the median between the northbound and southbound lanes.

Then, I traced the median all the way up to the approximate angle where I could no longer see the sign because the visual angle was too narrow.

Next, I traced the fast lane (the longest route within the "polygon of visibility"). I measured it out in google maps and it turns out that the sign was visible for 448 feet.

The speed limit at this point on GA 400 is 65 miles per hour (approx. 95 ft / s). That means that the sign was visible for just shy of 5 seconds.

I'm sure by now, you've done the math and come to the same conclusion. If the sign pages rotate at a minimum of 3 seconds per page and the maximum visible time at or above the speed limit is 5 seconds, then it is only possible to read 2 pages of data. However, the message must be at least 3 pages in order to be complete.

There's no way to reasonably expect drivers to read the entire message and therefore most people passing that sign today will have no idea what the full message is. Evidently, when it comes to sign placement, it takes an engineer.

It Takes an Engineer

EngineeringI'm pretty excited about this post. Not only is it my first blog post in a while (I've been pretty swamped lately and haven't had a chance to write anything), but it's also the first new section I've started in a long time.

This entry marks the first post in a series of posts I call, "It Takes an Engineer." It's about all of those things we see in daily life that would be better if they consulted an engineer first.

I'm sure, if you're reading this blog, you probably know what I'm talking about. It's the stuff that makes you stop and say, "what the hell were you thinking when you did this?" Or, "you really thought this would be intuitive?" Or, "if someone thought about how this was going to be used, I wouldn't have to fix it all the time."

Well, this is going to be my venue for venting on this topic so I hope it provides enjoyment to all. If you have anymore good examples, let me know and I'll blog about them too.