Are Tables Important?

I was talking to a former co-worker about Inc Magazine’s cover story about Markus Frind and his very profitable, but godawfully ugly dating website plentyoffish.com.

My co-worker (a programmer) loaded up the website. He took a quick look around and opened the source of the ratings page. Giggling like Bevis he could not believe what he saw: a gradient bar that was coded as [gasp!] an HTML table with bgcolor attributes.

It looked like this:

And was coded like that:

<table border=0 cellspacing=0 cellpadding=0 width=100%>
<tr height=5><td bgcolor=#204080><img width=1 height=5 border=0>
</td><td bgcolor=#202F70><img width=1 height=5 border=0></td>
<td bgcolor=#3F2060><img width=1 height=5 border=0></td>
<td bgcolor=#5F2050><img width=1 height=5 border=0></td>
<td bgcolor=#7F1F4F><img width=1 height=5 border=0></td>
<td bgcolor=#90103F><img width=1 height=5 border=0></td>
<td bgcolor=#B0102F><img width=1 height=5 border=0></td>
<td bgcolor=#CF0F1F><img width=1 height=5 border=0></td>
<td bgcolor=#E0000F><img width=1 height=5 border=0></td>
<td bgcolor=#F00000><img width=1 height=5 border=0></td>
</tr></table>

He was going on and on and on about how tables are bad, and mwu-ha-ha-ha — look at this.

I was fully expecting him to take umbrage at the logo, the overall look and feel of the site, at the grotesquely skewed photo thumbnails. But no, all he was seeing is that Mr. Frind “used a table”.

I tried to tell my co-worker that despite “tables” or ugliness this website generates tens of millions of dollars of profit to its creator, that it has as much web traffic as Yahoo while being served a small handful of very powerful servers, that it was created and maintained by a single person who gets to keep most of the profits – but to no awail. The kid could not get over “tables”.

A famous hacker JWZ once was asked about his feelings about “an open source groupware system”. In a famous rant that followed he produced some of the best advice importance that I’ve ever seen:

“So I said, narrow the focus. Your “use case” should be, there’s a 22 year old college student living in the dorms. How will this software get him laid?”

While I’ve never heard of HTML tables (not the furniture kind) playing any role in getting laid, plentyoffish.com must have resulted in a mind boggling amount of action.

Plentyoffish.com, being a technological and aestetical abomination that it is, is firmly rooted in the lower, fundamental layers of Maslow’s Hierarchy and my Web Heirarchy.

At the most basic people need oxygen, water, food, to take a dump/whiz, sleep, sex, and a predictability in environment.

On the web people need hypertext, images, search, speed, and community features. If you provide all of these for a topic that is important to people, you will be successful. Start thinking about “html tables vs divs” first, and likely you won’t get to the important stuff.

Doing it another way – saying, look, I’ll do a site just like plentyoffish but prettier and without HTML tables does not work very well: Frind’s competiors at okcupid.com who set out to do just that are not succesful in toppling plentyoffish.

Ugliness for the sake of ugliness is not a good thing. In the long run people want things to be pretty, like Apple products and not ugly like Microsoft products. But taste, being pretty high up in the pyramid of needs only becomes a factor after all the basic needs are met.

Facebook Cookbook: Build Your Facebook Empire

Now you can build Facebook applications that truly stand out among the thousands already available on the platform. This book’s easy-to-follow recipes not only give you useful ways to design and build scalable applications using Facebook’s development platform, they also provide you with strategies for successfully marketing your application in this highly competitive environment. With plenty of examples and practical solutions, Facebook Cookbook answers some of the hardest questions Facebook application developers contend with — including how and where to get started.

  • Learn to build an application architecture that scales to accommodate a sudden influx of users
  • Get tips for designing applications with hosting and deployment costs in mind
  • Find out how to use Facebook’s various integration points
  • Discover which widgets and controls to use for building the most attractive user interface design
  • Understand the differences between standard HTML, JavaScript, and SQL, and the versions used on the Facebook Platform
  • Learn how to target large defined groups on Facebook, including those who want to find jobs, hire employees, market a business, advertise, and more

If you have experience building simple web applications with HTML, Facebook Cookbook will guide you though Facebook’s toolkit, so you can build applications with the potential to reach millions of users around the globe. Learn what it takes to design applications that stand above the rest.

7 Things You Can (Mostly) Do Without in Your Web Business

I’ve spent a lot of time in meetings about websites. Not as much as I’ve spent building websites, but a sizable chunk of my career. I mostly spent that time listening and not being listened to. But now that I’m older, have “Sr” in my title (it stands for Senor), a beard, those cool designer glasses, and have a lot more weight in meetings. Mostly due to the fact that I got pretty fat.

Previously I wrote about the evils of redesigns in The Russian Tea Room Syndrome, and about how web developers are like cooks and prison inmates. Restaurants are a notoriously difficult businesses to run, mostly because there are a lot of amateurs who do not understand what is not important. It’s not what’s important. Everything is important. It’s knowing what can be cut, especially in the beginning, that makes some restaurants succeed when others fail.

Here’s my list of 7 things that seem like they are important in websites, but really aren’t. These are not deal breakers. These are the things to think about last.

1) Looks. It’s nice to have a clean and beautiful design. But making a site pretty is not going to make you more money. Just look at plentyoffish.com – probably the ugliest dating website in existence. It does not stop its maker from raking in 10 mil a year without any hard work whatsoever.

2) SEO. SEO is the alchemy of the web business. I’ve seen more sites get sandboxed by Google than gain pagerank from SEO efforts. Most big url rewriting efforts create broken links, which are bad no matter how you look at it. Don’t break urls, if you can – make them descriptive, and try to make your site linkable (i.e. GET instead of POST search forms), but that’s about all that might help you. Spending a lot of money on SEO is just plain stupid.

3) Performance. Everybody hates slow and crashing websites. But unless this lasts for years, it’s not a deal breaker. Twitter suffers from worst imaginable performance trouble. Livejournal went through a long stretch of bad performance. Even the big dogs like eBay and Amazon have a slow spell or outage or two. MS Windows became the most popular OS in the world not because of its stability. Of course it’s currently losing market share to Apple, but this precess took decades. If anything, it looks like Twitter outages make its users miss the service so much, that when they get back in the twitter their brains out after bitching about the outage for a bit.

4) Good branding. A good name, url, and logo are not going to make you more money. They are just not that important. As long as it’s not too embarrassing, like therapist.com it’s going to be ok. If you look on Alexa, icanhascheezburger.com has almost as much traffic as tvguide.com.

5) Pure CSS markup and web standards compliance. I’m sick and tired of being told that “tableless” design is somehow important. It’s not, it’s not, it’s not. Go to google.com, amazon.com, ebay.com, nytimes.com and view the source. You will see tables galore. Wasting time eliminating tables is just plain stupid. And all-div completely web standards-compliant XHTML markup is not going to make you any more money. I refuse to feel bad about using tables. And perfectly validating XHTML is only going to help page scrapers.

6) Keeping the site ad-free. Site users are ok with ads. They really, really are. If you have what they want they will suffer through the biggest ads you can throw at them. “Half Page Godzillas”, “Skyscrapers”, “Page Killas”, “Shrieking Flash Sound Diddlers” – whatever you call your most annoying ad – despite heated assurances from the users, it’s not going to make most of them leave. Some will and more will follow, but it’s not as drastic as you might think. If you have something unique. I’m not advocating horrible Flash ads. “Flash Sound Diddlers” are not more effective in selling stuff than tasteful Adsense ads which will not have anybody at all leave. You can use ad money to buy more servers, more content, ads of your own. This will bring in more users.

7) Widgets. If your entire web strategy is based on building widgets, well, you are in trouble. You are entering an frenzied and very crowded market. Widgets are the bastard child of old school web “badges” and “push technology.” Widgets sometimes work great for increasing pagerank, just like the “web awards” that were given out by some sites in Web 1.0 times. They might get people to link to you, especially if these people are Myspacers that are constantly looking for shiny things to line their pages with. But in the big scheme of things widgets are not a great way to spend ttime and money.

CRUD Ain’t Hard

And now for a little exercise in armchair software architecture — the most despicable coder’s pastime. Dear non-coding readers: despite its name, this blog is still mostly not about programming. Just skip this post or something. Dear coders, many of you will probably disagree with me. I am not a very good or accomplished coder myself, and you probably should not be taking your advice from me. But then again, I could be right, so keep your mind open.

You might have been aware of the very popular, but uptime-challenged social networking tool called Twitter. They have one of the best problems to have: too many very active users. The site is so popular that it constantly goes down and displays and “over capacity” screen that the users have nicknamed The Fail Whale.

Rapidly writing and displaying short chunks of text with high concurrency on the web is not one of them unsolvable problems in programming. It’s not easy, but with right people and tools Twitter could be rewritten inside a month. Twitter founders should do some soul searching. Meanwhile the critical mass has already been reached, the niche for bloggers who want to SMS instead of blogging is big, and even horrible uptime can’t this service. I use it myself.

There is a lot of speculation in the blogocube about whether the reason behind the Fail Whale is the wrong choice of technology — the highly hyped and sexy Ruby on Rails and if it can “scale”. Or is it just simple incompetence?

To me Ruby on Rails falls into a class of technologies that are affected by what I call “the VRML syndrome.” Basically, if I wait long enough the hype will go away, the recruiters will stop posting job listings requiring 4 years of experience in a 4 month old technology, books as fat as my two fists will stop being published, and I will not have to learn it.

What’s the problem with Ruby on Rails? Well, it’s the same problem that slightly affects the content management system that I am currently working with (Drupal), and is the reason why I completely gave up using Microsoft web technologies which are saturated with this shit. See, software craptitechts all of a sudden decided that writing CRUD applications is too difficult for regular developers, and complicated GUI tools and frameworks need to be created to help the poor things. CRUD stands for “Create, Read, Update, Delete” and is just a funny way to say “a browser-based application chock-full’o forms”.

The default way to build these is to rather simple. You hand-code the html forms, then you write functions or classes to deal with the form input — validators and SQL queries for creating, updating and deleting. Then you write some code that will query the database and display the saved data in various ways: as pages, xml feeds, etc. None of this is difficult or non-trivial. Bad coders don’t do a good job of validation and input sanitizing resulting in the Little Bobby Tables-type situation, but these things are not very hard to learn and there are great libraries for this.

Ruby on Rails makes it very easy to create CRUD apps without hand-coding forms or writing SQL. RoR goes to great lengths to abstract out SQL, not trusting the developers to do it right. SQL is more functional than procedural, and thus a difficult thing for many programmers to grasp, but it’s not that hard. Really. SQL is located far enough levels from the machine that abstracting it out becomes a horrible thing due to the Law of Leaky Abstractions. Even when you have full control of SQL queries optimizing them is sometimes hard. When they are hidden by another layer it becomes next to impossible.

In short, RoR makes something that is easy (building CRUD apps) trivial, and something that’s hard – optimizing the database layer next to impossible.

In Drupal there are two modules, CCK and Views that allow you to create CRUD entirely through web interfaces. This is a feature that exist in just about every major CMS, it’s just that in Drupal it’s a little buggier and overcomplicated than necessary. These are fine for small websites and are really useful to amateurs. The problem arises when these are used for high traffic websites.

I think that a lot of people will agree with me that writing HTML and SQL queries using GUI tools is amateur hour. You just can’t make a good website with Microsoft Front Page. You can’t, you can’t, you can’t. But in Drupalland it’s all of a sudden fine to use Views to build queries for high traffic sites. Well, it’s not. Dealing with Views and Views Fast Search has been an ongoing nightmare for me. Hell is not even other people’s code in this case. It’s other people’s Views.

RoR, Views, CCK are one level of abstraction higher than you want to be when building a high performance application. The only way the can be an “Enterprise” tool if your enterprise is a) run by a morons that require 100 changes a day AND b) has very few users. In short, if it’s an app for the HR department of a company with 12 employees – knock yourself out. If you are building a public website for millions of people – forget about it.

Your, Deadprogrammer.

P.S. Yes, I know, you can abstract just about everything and reduce your software application to a single button labled “GENERATE MONEY”. You have to be a very smart LISP developer for that.

Web Archeology.

While looking for some hardware in my junk pile I unearthed a stack of Zip disks with old backups. On them was a reasonably complete copy of the long lost “Dead Programmer’s Cafe” circa 1996-1997.

I think this was the first version of the logo, back when I hosted my site at silly.com, my first Internet provider. My High School buddy helped me get an account there for which I am forever grateful. Believe it or not, but a shell account cost about 4-5 bucks a month and you could even do web browsing with Slipknot. Far out.

The logo represents an alpinist scaling a Cray machine.

This is a later version of the splash page when the site was hosted at akula.com . All the cool pages back then had black backgrounds and neon or chrome Photoshop effects.



Later an espresso cup made an appearance on the coffee page and on the splash page together with an IBM card punch.

These webpages served me well. A girl who lived in my neighborhood found my first homepage and sent me an email. We got married a few years later. Her friend learned that I knew minimal HTML and helped me get my first web job. Information Superhighway is great and the future seems to be indeed bright enough to require sunglasses. Thank you, Eugene, Julie and Senator Gore!

Creative Time Wasting 404

Dear readers, let me vent some useless thoughts about HTML and share the fruit of my procrastination with you today.

It occurs to me that HTML code has finally become a third rate citizen of the World Wide Web. Back in the day, there were horrible WYSIWYG editors that mangled poor HTML, raped it by adding their own non-HTML tags and in general produced bloated and unreadable mess. They still exist today. But now most sites are script generated, so rarely do you see clean, beautiful and handcrafted HTML code when you view the source.

One of the worst offenders is Microsoft, of course. It gave FrontPage, an unholy product of a dying company called Vermeer Technologies (I’ve read in this book that the price of FrontPage was huge and number of copies sold – miniscule) an eternal life as a part of the Office Suite. Other Office programs always produced horrendous HTML. And now, they don’t even want developers to touch HTML directly. They added extra layers – Server Controls (again, plans for VTI extension and FrontPage come to mind) and Web Forms to isolate them from the language that can be learned in 20 minutes and mastered in a few years.

I can’t say that positive things did not happen. For one, fewer people write in old skool all-caps HTML tags. All lowercase tags are so much more readable.

Also now it’s probably safer to put little Easter eggs and funny notes in HTML comments. Are there more of those around? I don’t know. But the oldies but goodies are still out there.

Famous hacker JWZ’s enigmatic page contains this haughty comment:
<!– mail me if you find the secret –>
<!– (no, you can’t have a hint) –>

Smarter people than me tried, but failed to find meaning in in the 404 lines of what seems to be a hex dump. Former Livejournal user mcgroarty, for instance, wasted a good chunk of his time on this. Where is his blog now, by the way? Does anyone know?

What I noticed though is that the page is not static as mcgroarty probably assumed. It changes with time. More than that, it seems like it is not the same data – it probably cycles through different files. You can clearly see that if you look at http://www.jwz.org through the wayback machine. Meanwhile you can see the old design featuring the Jamie’s cool terminal graphics likeness. You can see the old design get resized, then get replaced with the 404 line nightmare. Then “mail me if you find the secret” gets added. Enough people send emails and JWZ, always eager to save some time, adds “(no, you can’t have a hint)”.

Are these 404 a cruel joke – meaning not found?

I suspected that the 404 lines show chunks of the old green image that I mentioned, or are generated from web collage. When I looked at the famous animated compass gif (the one that replaced the Netscape diddler when you typed in about:jwz or went to JWZ’s old homepage in Netscape 1.1 and some other early Netscape version I think) I found another hidden message from JWZ:

“You have a lot of free time on your hands, don’t you?
Tell jwz@jwz.org that you found the secret message!

http://www.jwz.org/
about:jwz

“Some people will tell you that slow is good — and it may be, on
some days — but I’m here toò tell you that fast is better. Being
shot out of a cannon will always be better than being squeezed out
of a tube. That is why God made fast motorcycles, Bubba.”
— Hunter S. Thompson

Oh, Jamie, I have very little free time. But whatever free time I have I usually end up wasting on stupid things.

This does not seem to be the solution to the 404 line homepage puzzle, but the heck with it.

Russian-speaking readers can entertain themselves with reading comments over at tema.ru. There are a couple of hints of hidden links, a few sprinkles of profanity, showing off about Photoshop mastery. Outstanding advice to journalists that was there in the earlier version is gone. I also remember seeing a completely blacked out page about his photo equipment there (you needed to do control-a trick to see it) in a very old version of the site. http://www.design.ru has its share of rowdy commentage.

Another Disjointed Post In Which The True Owners Of America’s Senior Citizens are Revealed

I have about 30-40 very exciting posts planned, but don’t have the time or willpower to actually sit down and write them. Besides, I should really be working on two very interesting projects.. Three very interesting pro.. No, actually five. The Spanish Inquisition should really give me some Ritalin. Anyways, meanwhile I need to dash off a small observational post. I mean without these and cat pictures a blog is not a blog, right?

I am using SharpMT, a very nice little Movable Type client, to write this. I hope having a client that is similar to awesome Semajic will improve my blogging frequency. But I am very much annoyed at the fact that in this day and age almost all of what The Joel calls “real-time spell checker(s) with wavy red underlines” do not understand html markup and wavy-underline all a href= ? I mean, the spellchercker in this MT client is bad enough to not understand the word “blog”, but Outlook and Outlook Express are not any better.

Hmm.. Where was I? Oh, right, observational post. Last Monday was a miserable rainy day. I was already a little late for work when I boarded my train. The train was slow as usual – people who are already late are not in a hurry, right? And then the conductor uttered the two words that make every NYC Subway rider groan. “Sick passenger”.

You see, if somebody faints on a train the train usually stays in the station until an EMT arrives. The EMT arrival times are amazingly fast in NYC and MTA even has a few of its own paramedics stationedat major stations, but the delay in getting the “sick passengers” of the train makes the trains stack up and forces the dispatchers to rerout them sometimes causing major delays. There is a passage about the “sick passengers” in Randy Kennedy’s awesome Subwayland : Adventures in the World Beneath New York. One of the interesting observations there is that the highest percentage of “sick passenger” incidents happens on Modays. Amen to that.

The train that I was on was rerouted to Penn Station. I got out right next to the theater that plays “Monty Python’s Spamalot”. The street was full of actors dressed up as knights and there was a SPAM truck involved in distribution of free Spamwitches. As I was already pretty late I did not even have time to indulge in taking a picture with the knights or in free luncheon meat.

Later in the week I finally had a big ol’ titanium screw screwed in where I used to have a tooth before. Now I have a titanium wedding ring, titanium watch, titanium glasses, titanium coffee tamper and a titanium implant.

Next day I was standing in front of a drugstore counter waiting for my antibiotic and painkiller prescription to be filled out. The drugstore had a really cool ScriptPro Robotic Prescription Dispensing System. It works kind of like one of those mainframe tape retrieval systems – a robotic arm moves around in a glassed in cabinet, scans compartment barcodes and dispenses pills into bottles. To think of it, I think I’ve seen modern backup handling systems like that too. I always wanted one of those for my bookshelves.

Two oldtimers seated in the corner were obsessively discussing their prescription plans. What drew my attention was an interesting choice of words they used to describe their relaionship to the plans – it was always “belong to”. Not once did they say “what plan did you have” – it was always “what plan did you belong to”.