Everything I Learned About Web Programming...

[le_bebna_kamni]

I'm currently undertaking my first completely professional web design contract -- not helping out friends for pocket change and favors, not designing for a non-profit organisation, but producing for a local company for a modest fee. I'm happy with what I've done so far, but I'm ready for the project to be done because of the various kinks and complications that come with not knowing the terrain of a contractor.

Here are a few lessons I've learned so far:

1) Good graphical design on paper isn't the same as good graphical design on the web. Be cautious when working with clients who have the first, but not the second.

I've run into this issue twice so far: a client who is a graphic designer, who has a very specific idea of what they want the web page to look like. They may even deliver it in a beautifully-rendered Photoshop document, and it looks great in static form.

The first major problem that most non-web designers aren't aware of is that what looks good on a static page, isn't always reasonable to code on a web page. Anyone who's ever tried coding something like this may know what I'm talking about:



In Photoshop, it takes about 3 minutes to make this mockup, minus typing the text. But on the web it requires some long, crazy work-arounds, then *hours* of troubleshooting the workarounds because of the differences between browsers.

Browsers also resize, unlike Photoshop documents. Notice the two diagonal stripes of lace in opposite corners of the page of the mockup below: 2 minutes in Photoshop, 30 hours of web work if you don't immediately know the solution, and even then possibly 10 hours if you do...and don't count on it being cross-browser beautiful. This mockup requires web divs that float exactly in the upper left and lower right corners -- i.e., they actually have to move, depending on the width of the browser -- and then progressively slide *behind* the text as the width of the screen becomes smaller:

wide browser view:


narrow browser view (notice lace is now partially obscured by the content):


I've coded both (although these are not the actual pages, just quick and silly mockups for layout illustration). On paper, they might look like a really good idea, but they're a web designer's nightmare.

The second problem is that non-web designers don't understand that web pages, no matter how well coded they are, almost never look the same across multiple browsers. About the only exception to this is a page coded entirely in Flash...which is another bad idea for so many reasons I won't go into.

And I think non-web designers are slightly more difficult customers than people with no design experience whatsoever. Most non-experienced clients are usually pretty satisfied with changes to their proposed layout if you explain that it's a very difficult task to make what they're asking for. The graphic designer, on the other hand, made the mockup in 30 minutes and doesn't understand why you're claiming it will take 20 hours to get it to look like that.

This isn't to say that you shouldn't take graphic designers as clients -- on the contrary, it often makes my job 100 times easier if the client has a good idea of what they want, and I have reasonable confidence that it won't be the web equivalent of orange polka dots with magenta plaid. But make sure they've also done a web page or two, or you may be stuck with very complicated visual designs that you'll regret 15 hours into a 5-hour project.

2) Don't count on the job finishing when you expect it to finish

This one has particularly come back to bite me. When the client and I met, we originally agreed on a two-week project. This was both because the client expressed a need for haste, and because I wanted to complete this job, allow a couple weeks for unexpected revisions, and fit one more contract job in before the semester started.

I budgeted my time reasonably well -- so far I've gotten most things done in approximately the time I had anticipated. What I hadn't counted on was a client who is slow to respond to emails and phone calls and who is much less clear about what they wanted from when we originally sat down to negotiate. Needless to say, two months later I'm still working on the same job, I'm trying to do programming around my class work while I'm unsure if my other client is still interested or if I can even handle another client during the semester.

My recommendation: whatever your generous time allowance is, triple it, even if you don't include it in billable hours. And if you can, insert a contractual clause that allows you to break off the contract with minimal penalty to yourself if it runs significantly over schedule. Don't use it if you don't absolutely have to -- that's a big hit to reputation you're taking if you have a dissatisfied client -- but it's an important out if a project drags on to the point that it's jeopardising other paying work.

If your client doesn't explicitly ask for it, don't offer to support Inernet Explorer 6.0.

This is an absolute must for modern developers -- not simply because IE6 is buggy, no longer supported, and Microsoft has more or less admitted that they were trying to break the web standard to get other people to adopt Microsoft's standard. It's also an incredible development time sink and a lot of frustration -- don't give yourself more problems than you have to take on. I highly recommend that if you must support IE6 that you double your estimated development time, because you really do need to develop the equivalent of two separate sites: one for IE6 and one for everyone else.

I've programmed for IE6 before, but it's been a couple years. So I forgot about the weird margin and padding bugs; I forgot that IE6 can't handle the transparencies of .png files, and the design given to me can't exist as a design without the images being transparent .pngs...otherwise it doesn't work. I forgot about certain aspects of IE6's and Javascript's turbulent love-hate relationship.

And I mistakenly included it in the list of browsers I would make sure the page is compatible with. Now I'm going to have to creatively rewrite most of the site, without having included it agreed-upon cost. Doh!

If you don't want to leave IE6 users completely out in the cold, you may want to try one solution that I read once: promise graphical support for modern browsers, and textual support only for IE6. Give IE6 users a functional, clean, but plain stylesheet and save the beautiful CSS and javascript tricks for everyone else.

4) Pad, pad, pad

My client has a limited budget, so I told the client that I would give them a fixed cost up front for all but one feature of the website. I'm not the kind of person who believes in over-charging for work done -- if I bill for 15 hours, it's because I worked somewhere between 14-16 hours, not 8. I might change my mind when I've been doing contract work longer, but right now I still believe that to be a fundamental rule of client trust...now with a few new caveats.

When I gave the original price, I was absolutely spot-on with how much time it would take me...the first time round. I even had a clause for additional charges if the client wanted revisions. But it's amazing how many things (like IE6 and finding out your client uses a different version of Photoshop so the visual elements aren't *quite* the same) that require a complete rewrite and don't fall outside of contractual obligations.

Suddenly a 10-hour job has become a 30-hour job (10 additional hours for each rewrite), and suddenly I'm getting paid a third of what I would charge for that amount of work. My suggestion: if a client asks for a fixed price, see if they would be willing to accept a range, plus or minus about 15-20%. If the client doesn't want a range, go ahead and pick the higher end...experience is leading me to believe that projects are more likely to run over than under.

But there's another reason to pad: income taxes. I was aware of the nasty cost of income taxes on the self-employed, having done taxes for a few friends who are contractors. But it had never occurred to me that if you're going to lose a third of your income to Uncle Sam, regardless of whether you make $100 or $10,000 from the job, you should make sure that the money you have afterward is enough to make the job worth your time.

I think I've been lucky in my first contract overall. I'm working for a small company, and I believe the client is reasonable and considerate and not overly litigious. I've had the benefit of talking to other contractors, like Matt Arnold, who does a lot of visual design projects in a multitude of mediums. Their experiences have helped me avoid pitfalls, like clients who expect free revisions when they change their minds, or clients who get the finished product and then don't pay for any of it (the demo site is hosted on my own server, and by contract the files change hands *after* payment is received -- not a luxury everyone can employ, but in this case it was possible). I even had foresight to ask for reusability of my own code in other projects.

Lessons learned. More still to learn. I'll keep you posted. ;)

Comments

[jodybrai.livejournal.com]

As one of the "Not even sure if the client still wants anything" people, I want to extend an apology for how terribly slow I've been at getting you my first rough idea of what we talked about. As my life may very soon be going through some terribly drastic revisions of its own, go ahead and count me out for a while.

At the point that I finally get my act together to the point that I can take you up on your offer of designing the site we discussed, I will fully understand if you no longer have the time to take on the project, or if the price has gone up with your increase in skill.

I hope I haven't caused you too much stress.

Best of luck with the new semester!!
Jody

[le-bebna-kamni.livejournal.com]

I appreciate the help. If it makes you feel any better, I figured that things would be slow to get started...plus Matt still has his graphical magic to do before I take over coding, so I anticipated it would probably get around to my part of the project *after* I was done with the semester. :)

The person I'm referring to was someone I whose need I think may have been somewhat more pressing...