I’m tempted to start winding you up like Dale did, but I’m too worried that you’ll come over to my house and beat me up.

So, nice work!

A couple of questions for you, though:

1. I’d love to know the composition of the team that works on the Movies.com site.
2. Do you have a developer style guide/bible for ensuring that everything looks and is coded consistently? If so, perhaps you could share how it is maintained and any tips for making it successful.

First ESPN.com and now Movies.com Mike Davidson: A Brand New Movies.com has more details….

… it didn’t validate and the Validation Police (VPD) came and put it on the impound server…

I did not visit Dale’s website, so I know nothing about him or what he works on. (This is because I am at work and I try to keep my superfluous web surfing down when I can, you know, in favor of getting work done.) My guess would have to be, that he does not work for a larger company making websites where not only do many different people have their hands under the hood, but also many different exterior sources of content (such as CMS and ad servers …) are generating code.

In an environment like this, it takes time, and lots of it, to get everyone and everything up to speed.

During that time, these people are being payed money, real money, to get real work done. Disney is company, and like all companies, they like to generate revenue and be profitable (say what you will about certian movies that flopped :-p ). To generate revenue, you need to ship a product or provide a service.

A page that validates vs a page that does not validate 100% is indistinguishable to 99.9% of the people viewing it.

So while there are some lingering validation issues, if the users are not going to notice, why not ship the product and start reaping the benefits of it right away? It is a huge advancement over the old site. It probably uses less bandwidth, but since it doesn’t validate, there is no need on saving money there!

Should we just take all websites that don’t validate off the web? I am sorry, but I like browsing websites that fall outside of the realm of a web developer’s weblog.

These are the realities of working for a company, especially the larger ones like Disney.

We should be applauding Disney for going as far as they have, and raising the bar for it’s competitors.

Movies.com seems slick enough. I’m all about the progressive coding techniques. Not enough people understand that sometimes we can’t be 150% obessessed about our code.

One comment regarding your blog design, though. Your comments are visually distinct, but the numbers showing up to denote which comment we are looking at (the big serif numbers) are white and are completely lost in the white background. Perhaps a light green like your sidebar?

~ Josh

Yeah, don’t worry about winding me up. It’s usually quite easy to send validatorians crashing down to earth by showing them links to their own numerous validation errors, but we don’t really have to do that, do we? By the way, there were 27 errors in Dale’s site at the time of this check.

Let’s just nip this in the bud before it gets crazy though. The point here isn’t validation… it’s writing progressively better code.

To answer your questions though, yes, we have ways of maintaining code quality and consistency but it’s probably worth a separate blog entry. It’s not a picture perfect system, but it allows people of varying skills to all participate and contribute in the success of the finished product. Do we make certain sacrifices to get things done? Certainly.

Additionally, there is not one such system for all of Disney. That would be too restricting. Generally, each business unit is governed by their own rules.

(Editor’s Note: This is now fixed. Chad thanks you.)

Looks great. Well done!

All the best,

—
Ian

We do try to serve most JS externally, but there are a few reasons why sometimes it needs to be served inline:

1. Our ad system inserts content dynamically on our edge-servers whereas the actual content from the CMS comes from head-ends. So certain content just needs to come from certain places.

2. Some of our javascript, especially the Motion-related stuff, is served dynamically and may necessarily be different every time it is served… therefore, externalizing it isn’t always an option.

Ugh. Did you happen to read the post at all?