How do I convince my company to utilize Web standards?

October 16, 2008 10:17 AM

Help me make a business case for HTML/CSS standards in my company's web-based software.

I work at a software company. One of our flagship products is a web-based content management system, and there are many parts of the program where you can create documents in a WYSIWIG format, and later export this content as an HTML file. This is a huge selling point for our product.

I've been coding HTML since I was 12, and have been very much into standards-compliant XHTML and CSS for the past five years. So it greatly pains me to see that our application generates HTML like it's 1996. Visually, it looks terrible, and programmatically, it uses no style sheets and it is an absolute nightmare to look at the source when it's exported. We have had a number of issues reported by our clients with this, but our development department patches them up on a case-by-case basis instead of fixing the root problem, which is the horribly-formed code. Every time, it's the code.

I am not a developer, otherwise I would have fixed it myself over the course of a few weekends. But I want to make a case to our development VP that we need to utilize standards-compliant HTML and CSS whenever we deal with the WYSIWIG documents. It will take a lot of work because we've built up this Jenga tower pretty high, but if we do it right then life will be much easier in the future. This would be overdelivering on our big promises, as Seth Godin recommends, and it would show that we care about the customer even when it doesn't put dollars directly into our pockets.

The problem is, I can't think of a concrete case from a business perspective. It just feels wrong to me for our software to be writing HTML this badly. But it's hard to evangelize the good news of HTML standards when you can't think of any solid reasons. They think it's better to just band-aid the issues one at a time as they arise.

BTW, we develop software for a very specific industry, and it is not available to the public, so accessibility is not an issue. I know that's one of the main benefits for Web standards, but it's of very low consequence for us.

Also, I would still be pacified if our HTML and CSS didn't pass the validator 100%, but right now I have a feeling that if we ran it through the validator we'd take down W3C's servers. Really what I care about is that it is easy to work with, works cross-platform, and looks nice for our clients, and so I figure we might as well follow a few standards while we're at it.

Am I way too hung up on this, and I just need to get over it and let them do their thing their way? Or do I have a good reason to push for us using Web standards in our development?

posted by relucent to computers & internet (10 comments total)

How can accessibility not be an issue? How do you know that client X won't be using browser X in the future? Or if it's viewed through some internal rendering engine, that they won't redesign the software to use WebKit or Gecko?

All things considered, though, this is probably not a fight that you'll win if the ROI seems low to the management. Instead, do what you can in small increments. File bugs about specific features, or ask them to make incremental improvements (like whitespace) that will make debugging easier for everyone.
posted by chrisamiller at 10:28 AM on October 16, 2008

BTW, we develop software for a very specific industry, and it is not available to the public, so accessibility is not an issue. I know that's one of the main benefits for Web standards, but it's of very low consequence for us.

In addition to what chrisamiller said, it's an issue if one of your customers ever hires someone who needs an accessible site.
posted by spaceman_spiff at 10:32 AM on October 16, 2008

So it's the HTML output that is live on the web that is so poorly formed? Not just the CMS admin interface?

Properly structured code is easier for search engines to index. Seems like this should be a big benefit to customers. It's easier to figure out why things aren't working right, thus less time debugging the code on a case-by-case basis. Hard-to-quantify benefit to your company (and less-buggy output is a benefit to customers, of course). Using HTML+CSS opens up potential new value adds, like theming. On a related point, it makes it vastly easier to produce mobile-optimized views. Anyone in your company have an iPhone? It will give you a more solid foundation for adding DOM+Javascript-based razmatazz, and make it easier to do this using existing libraries.

I'm going to go out on a limb and guess that all the HTML generation is hard-wired into the code, which is why your system is so calcified. To really do this right, they'd probably want to use a templating system, which would be easier to maintain (even if they insisted on spitting out invalid tag soup) in the long run, but would require some architectural changes up front.
posted by adamrice at 10:52 AM on October 16, 2008

I would have fixed it myself over the course of a few weekends.
...
It will take a lot of work because we've built up this Jenga tower pretty high, but if we do it right then life will be much easier in the future.

Well, which is it? I'm assuming you're not a developer, or at least one of the developers of this project; if that's the case, stay away from any argument based on your perception of how long something takes. There are few things developers hate more than an outsider passing judgment on that kind of stuff, because the reality is that you're usually overlooking a slew of technical details.

At any rate, I'm going to play Devil's Advocate here for a sec:

What you're asking requires a significant development effort, using resources that could be devoted to other projects that may directly result in revenue (new clients, increased licenses, whatever). Meanwhile, customers may be grousing about the HTML your app outputs, but have you ever lost a sale over this issue? Has a customer ever left because of this issue? If you went ahead and did it, would anyone directly involved in the sales process understand the benefit?

I have no idea how your company is run, but these are often the factors that drive code development, not "we should do this because It's Right". If you want to push the issue, I'd look for data to back up your proposal that includes dollar signs (indirectly or directly). Things like- do any of your competitors provide this? Has this issue ever been brought up in an RFP to which you've responded?
posted by mkultra at 11:21 AM on October 16, 2008

Seconding mkultra. There may not actually be a good business case for this.

That said, I would take some time (if you have the data available) to figure out, on a monthly, quarterly, or yearly basis, the number of "fixes" that need to be done that a large-scale change like this would alleviate.

If you can make any sort of case for increased revenue from this (highly doubtful), add that.

You now have some sort of rate at which this change would make the company money. The next step is figuring out how much the change would COST. This is a little more complicated. There's the direct cost of the development, but also the opportunity cost of not doing OTHER development which could increase sales. This is going to be a (more or less) fixed number... now you just need to calculate how long this change takes to pay for itself. The shorter that amount of time, the better the business case.

That said, I'd guess that if there were really THAT many changes, this is a project the dev team would already be working on. Chances are that this major of an architectural change is just not worth the money it costs, that's especially true if this is thought of as a living organism that mutates and evolves rather than taking a more versioned approach in which separate versions have their own life-cycles
posted by toomuchpete at 11:35 AM on October 16, 2008

WRT your accessibility point (and as alluded to by chrisamiller above): when I teach CSS etc, I'm constantly reminding people that accessibility covers a huge range of issues, and isn't just 'will this site work on a screen reader?' It's not just about people with physical (or mental) disabilities; it's also about things like screen size, browser capabilities and functionality... even connection speed (will this page display in under 10 minutes for a dial-up user?). That might help to make your point: the fact that people will (presumably) be using all sorts of different browsers to view your content, and the more standards-compliant the HTML/CSS is, the more likely it is to actually display properly on those browsers.
posted by littleme at 11:38 AM on October 16, 2008

One of the legs of the business case should be the reduced future effort of maintenance vs current effort to fix. If you can redo the system and cut maintenance costs significantly, that's a financial incentive to improve the architecture.

The key to pushing a change to the company is making it clear what's in it for them. Reducing costs and making customers happy by reducing the number of fixed required and reducing closure time on bugs is the kind of thing the boss will want to hear.

On preview, this is the positive side of the negatives mkultra and toomuchpete are talking about.
posted by immlass at 11:39 AM on October 16, 2008

A clarification: I don't care about the source code behind the product itself - they can do whatever they want in the code behind the UI. I am only talking about the WYSIWIG content that is user-generated. The rich-text-formatter stores horrible HTML in the database, and it also exports that horrible HTML in horrible ways.

chrisamiller:
Being a product delivered to a very specific industry, we can do things like require that our clients only use Internet Explorer. This is a good excuse for sloppy programming, but to tell the truth, many of our clients ask for crazy things and so the IE-only thing allows us to fulfill a lot of requests that Firefox and Safari couldn't handle. If someone experiences issues with an unsupported browser then we just tell them to use IE.

spaceman_spiff:
We have not yet had an RFP that demanded any kind of accessibility, and it's an industry whose software historically has not required accessibility. This could change in the future but it's not a battle I'd like to wage!

adamrice:
The HTML-exported content is not meant to be posted publicly to the web, since it's generally highly confidential information. So search indexing is out. We may in the future want to export documents that a company would want to put on their web site, but that's probably a long way off. I'd be flipping out a whole lot more if the general public was seeing this stuff!

mkultra:
I based my assumptions on the fact that none of the developers know the first thing about web standards, but that I am well-versed in them, so if I were a developer (i.e. I had a deep architectural knowledge of the program as well as a good grasp of the language it is written in) then it wouldn't take me as long. But you're right, this is probably not something I should bring up.

Thanks for all the responses so far.
posted by relucent at 11:49 AM on October 16, 2008

the few, usual immediate advantages that I could think of, given your particular situation:

- way lighter bandwidth load -> faster loading time, etc.

- easily customizable by CSS

- you could enhance the general app usability by using one of the various js frameworks available (on properly structured HTML with all the IDs in place)

- accessibility. You don't need it now, you might in a few years and transitioning from the mess you're describing will be a lot of sweat, so better be prepared as much as possible

- easier to maintain code

- easier interoperability and future expandability, e.g. your document exporting example would be way easier to implement with properly structured documents

- again, way easier to use on different media/clients by way of stylesheets, so you'll have better printouts, perhaps mobile versions, etc. etc.

- overall longer product/feature life

the case for transitioning from 1996 to 2008 HTML is fairly strong, in my opinion. I think it doesn't necessarily have to be an "all or nothing" thing, and I think - despite most vocal standards advocates - that there's no moral obligation in writing standard-compliant code, especially in your particular scenario. But the general direction as to 'where HTML is going' is quite clear, so your company should start planning a sustainable transition in that direction.
posted by _dario at 1:30 PM on October 16, 2008

dario, you just won. I completely forgot about print style sheets! Printing of these exported documents is a very important feature, and right now it is an absolute mess. Aside from the fact that it looks ugly, we are currently using an incredibly cumbersome method to print our documents which we wouldn't need at all if we developed standards-compliant exports.
posted by relucent at 1:43 PM on October 16, 2008