[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 Shawn K. Quinn
> Subject: RE: [thelist] Site check: Staples.com
> 
> >
> > Half the stuff is OOB functionality that you can't change (either
> > because it's proprietary, or you don't have time/budget), then 
> > you need to interface into all sorts of legacy backend systems, 
> > and then you need to quantify the benefits of the application 
> > (and at the same time, possibly deliver a better
> > experience to your users: amazon.com uses cookies too you know).
> 
> And there is absolutely none of this that requires Javascript to do a
> redirect.

There may be some reason why it's there (it might be some functionality
supplied OOB by an application), and there's no compelling cost/benefit
reason to change it

 
> > Where exactly do we spend /another/ couple of hundred thousand dollars
> > on extra staff to customize all of this for the 2
> 
> Try 1,000, 10,000, 100,000, or 1,000,000, if you're just going to pull a
> number out of thin air.

The company I work for builds enterprise web apps. I have some idea of how
much these things cost. There's a lot more to building a big web app than
whether or not you use javascript or cookies. An example application has
about 60 different integration points, supports >1,000 transactions per
second, and requires over 50 servers for the environment. Given the
complexity of this type of system, and the type of cost the owner is up for
in building it, systems to automatically generate the UI are important. Now,
in the design phase considerations about the type of functionality the end
user will need to have will be discussed and signed off on. This would
include an analysis of the types of users the site's already getting and the
type of functionality they have enabled. At this point the cost/benefit of
requiring certain functionality should be discussed and determined.

> It's rather well known that letting any
> old site run Javascript on your system is poor security practice

No, it's not a "poor security practice". It's a risk, like everything you do,
and every piece of functionality you want from your software. Risks are there
to be managed, avoided or passed to something else. What might not be
acceptable to you is perfectly acceptable to me - I certainly have javascript
enabled in my browser.

> So, over
> time, I will have more money in my pocket than the guy that just spent
> $300 on the latest version of Microsoft's latest OS and $100 to $1,000
> to get all the viruses cleaned off his computer *again*.

I think that's largely irrelevant to someone running a large web site. Anyone
running a large scale public site would be obtaining metrics on what browsers
people are using, and what functionality they have enabled. My experience is
that people with your setup are in a tiny minority.

Cheers
Ken