Working with legacy websites

September 13, 2007

Topics: Accessibility, Web Development.

This is a task which comes up over and over again for many developers. There are a lot of jobs in maintaining web sites. Our work doesn’t always come with the dream experience of a brand-new web site. Even if a new web site is a major goal, there will inevitably be large quantities of legacy content which will need to be worked into the new accessible design. Working on legacy websites can pose a number of subtle challenges.

If you can’t redesign, what can you do to work towards a more perfect site?

I’ve written on this topic before, but it’s a subject which comes up frequently enough that it deserves something more. That article, written for Yuri Filimonov’s search marketing blog, was targeted at an audience that might be working on improving the accessibility of a legacy site without any major redesign. As such, I focused on simple content or style based changes which, for most sites, can be made without making substantive changes to the site.

They’re valuable changes, although superficial in terms of fundamental degree of change. In user interface design, “superficial” can be pretty substantial, after all — as I heard Peter Merholz say in a speech last night, the fundamental experience of most users is a division between a user interface and “magic” — everything else that happens. As a developer, we know what underlies the user interface — most users don’t care. Superficial changes to an interface can make a huge impact for the user experience.

Nonetheless, for a truly accessible web site it’s important to go beyond the superficial. One important facet of many web users with disabilities is that they have an experience with the site which exists on a different level from that of most users. Why? Because the user agents or interface devices used, whether a screen reader, a text browser, a keyboard, a pointer or some other device require interaction at a different place in the normally three-tiered software model. The basic model is data, logic, and user interface. An accessible web site has to go a little further: the data, the logic, the user interface and, finally, the accessibility tool which needs to operate that user interface.

One way of viewing the shift from an inaccessible website is adding “hooks” into the standard user interface which provide the critical information a disabled user needs to be able to successfully navigate the site. It’s not a perfect viewpoint: as I’ve written several times before, accessibility is the removal of barriers to access. But either view is a simplistic model. Adding alt attributes is an additive practice; but the addition of that element removes a barrier, if the attribute is attached to a navigation link. It’s a balancing act: understanding when an addition overweights the balance is the critical understanding most required.

So, back to the subject of legacy websites.

There are many possible ways in which a web site redevelopment project can be approached. First, if you’ve been told that redesign is not an option you need to know why. Is it because the content management system produces the majority of the code and they can’t afford to either replace their CMS (Content Management System) or fix the back end? Well, that may be insurmountable — at least, for now. Is it because their marketing and branding (or legal) departments won’t approve a design change? That is hardly even worth calling a problem.

Any site which has been developed using table elements for layout can be redeveloped without them, without making any substantial changes to the design. Any site which has been developed using font elements to control headings can be redesigned using appropriate heading elements. Any site which has been developed using br elements to separate paragraphs can be fixed.

If redesign isn’t an option, re-building still might be.

Yes, it may be more challenging to perfectly reproduce a design using all-new code. Yes, in order to reproduce certain design decisions you may have to use techniques you wouldn’t have otherwise chosen. Yes, it may be less satisfying creatively to build a web site where you have absolutely no ability to make new design decisions. Do these matter, ultimately, if the final product provides substantially better access for users?

Also on this subject: Mel Pedley “5 Steps to Reworking a Legacy Site”. Mel’s article focuses on the planning process to consider when approaching a major re-development.

10 Comments on “Working with legacy websites”

  1. Yeah, conveying that information to the client can be one of the biggest challenges.

    The challenges created by websites like MySpace (I don’t know Piczo) are very different — the impression created can be a complication. I haven’t encountered it myself, really, but I can imagine that clients who are experienced with things like MySpace or other “design your own” services may have a serious misconception about the challenges and tasks in best practice web design.

    Largely because they have no sense of ‘best practice,’ perhaps…

  2. Its even harder to redesign a mess as it could be put, if the customer cannot understand what is wrong.

    “Well it looks ok in my web browser.”

    I think it raises more challenges these days with website like Myspace and Piczo, because to the average person it makes building websites look as easy as move this, do that, put that here done!

    If only it was that simple.

  3. Making something from nothing is definitely the best job, but actually I find the process of fixing websites to be pretty satisfying. I’d be stretching it if I claimed I found it fun, but I really do like being able to remove one more badly developed site from the world.

    For me, turning down a job is something I’m more likely to do because of the client than because of the site. However frustrating the work itself could be, if I’ve got buy-in from the client and a good working relationship the process will be just fine.

  4. I agree with you, Mike. It my little corner of the world I would turn down a frustrating project, too. In fact, I have turned a couple of them down by effectively pricing myself out of the competition. I know that I am very fortunate because I don’t pay the bills with my website design work, and I am pretty sure you don’t, either. With that freedom it’s easier to just move on to another project that is fun!

  5. I think that unless the job was going to be fun I’d just have to turn down the work. There are enough fun jobs out there without having to mess around with some tables laden behemoth or some other frustrating steaming heap of a site. If, however, the project site wasn’t built with tables, or had stuff like font-tags, and was just a plain old HTML (HyperText Markup Language) site that needed refining and CSS (Cascading Style Sheets) styling, I’d probably go for that in a minute.

    To me personally a big part of this trade is the pleasure of making something from nothing happen on screen, the power of CSS, the magic of PHP (Hypertext PreProcessing). But this is me, and my situation differs from that of most web developers. So, “Jobs from Hell” I can do without.

  6. @Ryan — It becomes very noticeable when you pop out of styles and suddenly the page structure is impossible to identify. I just can’t understand why people use styled spans to create headings…

    @David — the scary thing with server-side problems, too, is that frequently you won’t learn about them until later on in the job. They aren’t always obvious from the front-end!

  7. @Joe – Yes, I checked a mock up of a design and popped it into no-style mode, and I noticed that the designer just used spans with a large font size to make ‘headings’. I currently trying to tell him why this is a bad technique on a few grounds.

    @David – that just gives me the chills. I don’t want to know what the size of that file is.

  8. @Ryan — Yes, the unstyled view can really expose the logic of your content. I use that as one of my steps in checking the underlying accessibility of a site.

    @David — Yikes. What an awful piece of development. I don’t think it’s fair to say that this is the fault of a site which “uses server-side technologies.” More the fault of a site which “uses server-side technologies badly.” That’s a good example of a legacy package which is simply beyond correction.

    It’s certainly true that starting over can sometimes be the only way to go.

  9. When the site uses server-side technologies it throws up a lot more problems. A number of times I have been approached by companies who just want a new design, but on examination of their code it is an awful jumbled mess of PHP (Hypertext PreProcessing) and HTML (HyperText Markup Language). One site I had some through recently had one file with over 25,000 lines of jumbled PHP and HTML. For some reason the developer had found it essential to individualy echo out each tr and td. Needless to say, a complete redevelopment was suggested. Something like that just cannot be fixed.

  10. While reading about the three-tiered system, one thing that popped into my head that I wish so many designers would do before making the new design live, and that would be to view their page style-less. This hits on the logic of the design.