[thelist] Site check: Staples.com

[Ken Schaefer]

> -----Original Message-----
> From: thelist-bounces at lists.evolt.org [mailto:thelist-
> bounces at lists.evolt.org] On Behalf Of Anthony Ettinger
> Sent: Wednesday, 21 September 2005 2:46 AM
> To: thelist at lists.evolt.org
> Subject: RE: [thelist] Site check: Staples.com
> 
> 
> 
> > > Unless there's a payoff, there's no point spending
> > the money.
> >
> 
> Oh...but there is a payoff, if you're a large site.
> 
> Using divs and 1 css file will slim down your site
> considerably, saving you in bandwidth costs.

This wasn't a tables -vs- divs argument. The argument is whether the site is
"broken", and whether a site owner needs to support every different user out
there with every different possible level of functionality enabled. I'm
arguing that it's only worth doing this /if/ there is a sufficient pay off in
doing so.

Furthermore, the argument you do posit is simplistic at best and disingenuous
at worst.

a) If you already have an investment in a product (whether it be a CMS,
existing content or whatever) then converting things costs money. That money
could be spent on other things. You might save some money on bandwidth, but
does that justify the expense? That's a case-by-case question. You can't just
say, universally, there's a payoff for doing "x"

b) Bandwidth is one of those things that gets cheaper and cheaper each year.
And there's more and more of it each year as well. For a lot of companies,
saving 1 or 10 kb/page is meaningless IMHO given the cost of actually
implementing that change. 

c) There's a lot more involved in running a large scale application than just
the UI. I've said this before, but perhaps it's not really something that a
lot of designers are aware of. Spending $10,000 on some UI changes to save
bandwidth -vs- buying a new 64bit server that can address 64GB+ of RAM -
which do you think presents a better ROI? Who knows - that's something that
can only be addressed on a case-by-case basis, but people have to make these
decisions all the time. It's not about "well, site x can save $100,000/year
on bandwidth by making $10,000 worth of changes". They could generate
$200,000 more business by spending that $10,000 on a new server that will
give them an extra 1% of uptime.

An enterprise web app (and this is small scale) that I've done some work with
had over 50 servers (12 load balanced web servers, a clustered session state
server, and numerous other boxes), over 60 integration points with other
systems (internal and external) and supported >1,000 concurrent transactions
per second. It's an n-tier app that's supported by clustered 8-way DB
servers. So, given a complex system like this, the owners always have to
weigh up "what's the best place to spend my $ on". Is it new servers? More
bandwidth? Changing the layout of the pages? A more efficient middle-tier?
Scale out the DB layer? Better monitoring software? New automated patch
management solution?

Cheers
Ken