DCSIMG
Make a (visible) difference - A Regular Joe

A Regular Joe

Make a (visible) difference

Some time ago one of my collogues stepped into my office and asked for assistance.

The project he's working in, is a maintenance project for some commercial site that is already on-line.
The client wishes to lunch a huge campaign, and for that occasion he'd like the site to be redesigned.
Of course he want it done for yesterday, and if possible even the day before.

The problems are many: the code is massy, there's no common sense in the CSS file, there are weird combinations of inline style as well as CSS classes; Furthermore, some of the styles are hard coded in the code behind, some in JavaScript, and so on...

I was called as a "last minute help" before all hell break loose and the client goes ballistic.

The first thing I did was to redesign the first page. I've stripped it off it's styles and wrote them back using methodological CSS classes and inline override styles.

I didn't do much. Just rebuild the class, added the correct colors in the correct places, and aligned everything the way it should be. Less then a couple of hours, and I was done, with a couple of coffee breaks in the middle (I like coffee, I must say).

the impact, how ever, was huge. The client calmed down. A couple of smiles appeared on my collogue's face, and the system went to a more productive state of mind.

So, what's the point?

There are several results, or goals, you want to achieve when you modify the UI. It might be a new design, new branding, accessibility, and so on and so forth.

No matter the reason, it is always a tedious task. You always have to deal with the conflict of "What to change first?", and "Should I change the UI, or should I re-write from scratch?".

When you have no choice but to change the existing code, start with some fast and noticeable tasks. It'll give you a good idea on what else should be changed, and if the current path makes any sense.

Use tools to identify HTML elements and style (such as IE Developer Toolbar, which I plan to write about later).

Use "search-and-replace" mechanisms to replace (or remove completely) obsolete or bad style and classes definitions.

Don't be afraid (that's a good advice to any field). Remove styles, remove classes. There are millions of tools to preserve versions of your code, you can always go back. Remove a class to see if the element still inherit some CSS definitions from somewhere else.

 

Make a visible difference to the UI, so you'd know you're on the right path, so you will actually see a progress.
So your users or clients will see that you're making a change, you're going some where. I promise you, they will come back to see it finished.

Comments

urig said:

Hey Joe.

It would be great if you could write more about "using methodological CSS classes and inline override styles". Writing CSS in an orderly fashion across large projects is an interesting challenge.

Thanks,

Uri

# March 26, 2008 10:45 AM

Joe said:

Sure. Will do. Right after Tech-Ed.

# March 26, 2008 6:12 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: