Corporate Web Standards

In: Articles

By Scott Gledhill

Published on July 16, 2007

We’ve all heard the fairy-tales about the prince kissing the princess, but the story just ends there; they both live happily ever after, riding off into the sunset, never to be seen again. But in real life, that’s just the beginning of the story—after the kiss and the sunset comes the hard work and the real relationship.

It’s a similar situation when getting a large organization on board with web standards. Upper management might have given standards the green light in your organization, but what unfolds next can be just like that first kiss—it’s only the beginning of a much longer relationship, and, just like real life, it can be fraught with troubles.

In the Beginning

Now that web standards have become the norm for corporate websites, many in-house developers are discovering a new phase of acceptance and implementation within many large online organizations—corporate web standards.

If you work in a large company, you may recognize some of these common scenarios:

• Your company has embraced the initial concept of web standards. You hire standards-aware developers and develop standards-compliant websites.
• Your website content is created by non-developers—producers, journalists, or any content-management system (CMS) users who are not advocates of web standards.
• Only you and the other front-end developers appreciate the benefits of web standards and accessibility.
• You work with multiple teams on large projects—but you don’t work for web-standards ideologues such as Clearleft, 37signals, or Happy Cog.
• The sales and marketing teams in your company do not feel a general need to make the web a better place, they just want to make money from your websites.

Those initial stages of converting your company to web standards are much like trying to score that first kiss with the princess. You seduce them with the business benefits of web-standards development, and the rest of the arguments we have all read, written, and preached to anyone who will listen.

Getting corporate web standards in place is a sign that the real relationship is about to begin. The honeymoon is over, and now it’s time to figure out what has gone wrong and why the prince and princess now seem to be constantly bickering—when they were meant to live happily ever after.

Life in the Castle

Most of us would kill for a fresh start—a website redesign allowing you to start a project with a blank canvas, fresh code, and no limitations or legacy issues to limit your implementation or creative freedom. We would develop accessible, usable, and standards-compliant websites that should ultimately stay that way as we move on to our next challenging project.

Once the site is complete, the code and products will maintain themselves through a CMS that does not alter your perfect code, initial templates will scale to allow new content to be added without any dramatic changes to architecture, and maintenance will be a breeze.

What? Who said it sounds too good to be true..?

The Ugly Reality

So what really happens when you let your website out into the live environment? You leave it alone for a few weeks and suddenly you discover:

• It doesn’t validate anymore.
• It breaks in major browsers you know you tested it in.
• There are JavaScript errors everywhere.
• Accessibility steadily declines.
• There are unclosed <p> tags littered all over the place.

My past development experiences have now taught me to stop and think about the bigger picture when dealing with large corporate websites. Problems like those mentioned above can be prevented—but first let’s see how they might occur.

The Perfect Project

Last year, I lead the development of a project where we had to produce eight large media websites, all to be completed in six months. This roughly translated into launching one website every three weeks, for six months in a row.

Not the ideal build, but business constraints do create some interesting development scenarios. The plan was to take a bit of extra time developing the initial templates for the first website, creating modular, re-usable components and templates, and then roll this out into the next seven websites over the remaining months.

The project was treated as top priority within the company and a core team was hand-picked from the mainstream business. We were all looking forward to getting our hands dirty with this project; this was our chance at a blank canvas and a fresh start.

The team consisted of producers, usability experts, designers, and many developers, and we were isolated from the rest of the company and moved into a separate building so we could concentrate solely on the task at hand. It was the perfect project.

The Reality of Implementation

Initial stages of the project began and soon enough chunks of the project would be completed, neatly packaged, and passed off to the next stage of design or development. It was a finely tuned assembly line—we weren’t cutting any corners, and were planning each step logically and carefully during those initial phases.

The code being produced was clean and semantic. Scalability was always our main consideration for future-proofing a project of this scale, so the initial templates were coded with care and developed with modularity in mind.

After a few weeks, the pressure began to build in our isolated building. As the launch date of our initial website approached, scope creep became a big problem. Stakeholders who signed off on designs beforehand would start to see final, assembled products and make fundamental architectural changes, as they had not fully understood the signed-off documents they had approved only weeks earlier.

As a reaction to these new demands, more teams were thrown at the project. New developers were brought in and parallel builds began on two projects at one time. This resulted in more progress, more templates being produced, and a much more aggressive build to remain on schedule.

The code became an angry, growing beast. The teams, sitting right next to each other in a small room, would be much too busy to take a break and discuss naming conventions, class names or IDs, and basic architectural concepts that had been developed at the inception of this project.

Cascading-style-sheet (CSS) bloat became a serious issue as developers were rotated on and off the project. The best solution for some templates was CSS skinning—simply adding another band-aid stylesheet onto the page which overwrote troublesome styles—and this became the preferred solution, instead of sorting out the underlying issues.

In the end, each site ended up different from the last. The scalability we intended at the beginning of the project did not exist, updating the websites was confusing, and templates were not modular or making sense to any of the regular staff that actually had to maintain the code on a daily basis.

The End Results

It may all sound horrible (or maybe horribly familiar), but this project was hardly a disaster. Most of the stakeholders involved at the beginning were extremely pleased with the results, and most of the developers walked out of it more experienced and with new skills learned in an intensely, short period of time.

All deadlines were met, with very few delays or glitches that might have been expected to occur with a project of this order of magnitude and timeframe. In an ordered chaos kind of a way, everything came together in the end—the team worked well, and we still had fun working on the project.

The code was good, but not perfect. This is where corporate web standards must be taken into account, and we really needed to assess what had actually been achieved.

With this project we succeeded in:

• Eliminating all table layouts from a majority of the network.
• Using the XHTML Transitional doctype for the first time on a project.
• Creating XHTML documents that were semantically rich.
• Increasing the general usability of navigation on the websites.
• Using lots of JavaScript with accessibility and search-engine optimization (SEO) in mind.
• Raising the baseline standards of development within the company.

We still talk about this project a year later. We complain about the code that is still difficult to maintain and ways we could have made it better, but the important thing is that we now have a new foundation upon which we base our standards. Every website we produce now has higher standards than those eight websites ever had in the past. We have moved progressively in a new direction for standards within the company without many of us collectively realizing it.

The Sometimes-Evil Witch

Corporate Web Standards Are Not Always Bad

Corporate web standards—doing work that is less than perfect—may seem like a negative thing to some people, but you have to understand the context of where we have come with web standards to actually appreciate that it is a good place to be as a developer within a large organization.

When I first started with my company more than three years ago, I was updating websites that were all table-based layouts, and working with developers who not only didn’t know web standards, but also mocked them. Since those initial days of maintaining these horribly unusable and difficult-to-maintain websites, we have managed many huge wins:

• Management listened to us when it came to hiring good developers.
• Our websites work in most browsers, not just Internet Explorer.
• We were allowed to start fresh with more projects.
• We hired information architects and started thinking about our users.
• CMS developers would listen to us, and not change our code anymore.

This paved the way for the web-standards talks with management, which led to projects such as the one mentioned above, that changed the development environment for the future.

Maturing Web Standards

Looking back a few years, our goals now are at a much higher level than they were back then:

• Validation errors still occur.
• Websites do not work perfectly in every browser.
• Accessibility is not perfect and can be improved.
• Download times are sometimes slow.
• JavaScript is not always being used properly.
• Usability challenges arise when introducing new technologies such as AJAX.

This is a much better place to be than where we were three years ago, but complacency is not what brought web standards to this level in the mainstream, and it’s not what will fix these problems that plague our websites right now.

So what can you do right now about the issues of corporate web standards in your organization?

Finding Your Way Out of the Forest

Baby Steps

Working in a large company, there are likely to be a lot of little things that keep you from producing—and more importantly, maintaining—a picture-perfect standards-compliant website. It’s not just one big issue, but multiple factors that contribute to a greater whole, and it can be a bit intimidating when taken altogether.

The answer is to take baby steps. Stop and have a look at all the problems that prevent you from doing the work you want to do, then start figuring out which ones need to be fixed first.

One at a time, you can slowly start to make improvements and see changes being made in people’s attitudes towards web standards, accessibility, and in technical implementation across your large corporation. Eventually you may see results grow and improve as you gain momentum and keep fixing these small issues, but it’s wise to start small at first.

Don’t be a Control Freak

In a large organization, you can no longer control every tiny detail of an entire development, and if you try, you are going to step on people’s toes. It’s not realistic to expect that you can do everything, and attempts to do so can set you up for disappointments or failure.

Concentrate on your area of expertise and take responsibility for your section of the project. Control what you can and take care of your area, but once you hand it over to another team (e.g. back-end developers), accept that you may only have limited control over the final outcome.

Pick your Battles

You will have to make decisions about what you are prepared to give up on a project, and what you are absolutely not going to back down on. It’s a matter of picking your battles before you start the fight, and deciding what issues must make it through to the end of the project.

Is the site accessible, except certain pages beyond your control? Are validation errors happening that you cannot fix? These are issues that cannot be avoided in some companies and are not worth losing sleep over.

Just Do It

Red tape and skepticism can hold back a lot of positive, creative work being done in a large company.

Perhaps the answer is to simply identify the problem that bothers you, and fix it on your own. Often you won’t get full support until you can prove the problem can actually be fixed, so you might have to just hack up a solution when you have the time. A developer I work with decided to do just that.

Tired of the old, legacy JavaScript produced from a large third-party vendor for an ad-server solution, he decided to sit down and rewrite their JavaScript code. It’s extremely important that we implement this correctly for our users, and also for our clients that choose to advertise on our websites.

The problem occurred when Firefox upgraded their browser to version 2. Fifteen to twenty percent of visitors to most of our websites were Firefox users, but the JavaScript being used to serve the ads would break in Firefox 2, rendering as text on the website, below the Flash advertisements. We would end up with five separate ads on the page, producing large strings of JavaScript code all over the website and pushing content down the page. The vendor was informed many times by developers who were fairly upset about it, but no steps were being taken to fix the problem.

While still working on his daily projects, this developer rewrote the third-party JavaScript in his spare time, tested it, and tested it again. Eventually, once he was confident that it worked and could be applied as a solution, he needed some help within the company, as the code would have to be applied on the vendor’s side—but now that he actually had a working prototype he could propose it as a solution. This was more than enough to convince management of the efficiency of the solution, as well as to truly spotlight the problem occurring with so many of our users. Once he had this buy-in from management, it was easy to pass these changes on to the vendor and fix the problem.

Personal Sacrifice

One issue in pushing standards-acceptance in the corporate workplace actually lies with us, the standards developers.

One hopes that you are not the lone voice calling for better standards support any more—you should now have a group of supportive web developers around you, all fighting for the same cause of improving the online experience and codebase for your products. But those same traits of passion and pedantry that have pushed web standards into the mainstream can also cause problems within the company in these advanced stages of web standards development and implementation.

We all like to comment our code in different ways, use different CSS layouts, and apply different naming conventions to our classes and IDs, but this won’t work if you want to work within large project teams and develop to a company-wide set of standards.

It can actually be quite a difficult step for many developers to swallow their pride and give up personal coding conventions, and instead agree on standards that work better for the group as a whole. Once recognized and agreed upon, a general standard can really make a world of difference when developing and maintaining projects across a large company.

Restoring Order to the Kingdom

A company can be quite large, which means you get to work with many different people all day, deal with different personalities, and attend many meetings with multiple departments. This is where the power lies in working for these large organizations. These same large companies that create the problems of corporate web standards in the first place can also be the ideal place to find the answers.

Talent

When you work in a large team, chances are that you are going to work with some highly talented people. You may have just learned how to code an accessible JavaScript widget, but someone else has written the tutorial that you used to learn how—and in a large company, that person could be sitting in the next cubicle.

What is the specialty of the developer sitting beside you? Whether it’s JavaScript, exploiting CSS3 implementations, or simply being the best browser debugger in the team, these skills are there waiting to be utilized.

Tight deadlines, extreme pressure, and late nights are where I have found out just how good some of my co-workers really are. I have come out a better developer and general practitioner of the web, and learned things I hadn’t imagined I’d encounter before.

Collaboration

Large, complex teams mean large, complex projects. This doesn’t mean you have to start from scratch and make the same mistakes every time you begin a new website.

With your talented pool of developers, a library of code should be developed to ensure that you only have to agonize over those JavaScript components when necessary. Once documented, each developer should be enhancing or adding code to a central library when they have downtime, to help out with future projects.

Collaborating on the housekeeping issues is a great way to spread the work as well. Naming conventions, commenting on code, and which browser needs to be supported this week is all stuff that shouldn’t be done by one developer; it needs the knowledge of many to be able to tackle all of the minute details.

Enthusiasm

Sometimes I wonder if it’s really worth coding a section again when I know the editors are just going to throw tables and inline JavaScript into the code via the faulty CMS.

It’s far easier to get stuck in a rut while working alone where you don’t get external stimulation once in a while. But in a large company, there is no shortage of people available to compare notes with, ask for help, or simply shoot the breeze for a few minutes—all of which can help keep your passion for the job alive.

Finally, Life After the Sunset

So life is still not perfect after that first kiss, and the honeymoon stage dies quickly—soon you’re left doing each others’ laundry and fighting over whose turn it is to control the television remote.

But that doesn’t mean that everything is terrible and that you should give up as soon as you hit a bit of turbulence. Just like issues in real-life relationships, these issues of corporate web standards occur once you have found something great and stuck with it for a while.

The acceptance of web standards into the mainstream development community has created a new set of problems for many of us to deal with in our professional careers, but it’s a good place to be, if you consider how far we have come with web standards in order to be complaining about this next phase of problems.

It’s those little bumps and the occasional disaster for which you have to find a solution that give you meaning and inspiration in what you do for a living. A perfect fairy-tale life would be…well, boring.

Related Topics: Client Management, Web Standards, Web Maintenance, Web Teams, XHTML, HTML, CSS, Planning