Blog

A website, once built and launched, is a forever-moving target that requires patience and a good deal of regular maintenance in order to become and remain successful.  The only thing that’s certain when you deploy a site is that someone, somewhere, will have trouble with it and will call you to resolve the issue.  9 out of 10 times these troubles are user error– someone is using an old web browser, has unrealistic security settings, didn’t read your one-sentence instructions, etc.  Modern web applications have some serious requirements of the end-user– someone trying to view, say, Facebook might have javascript disabled because they think it’s a security concern or something….  and so they have problems with the site and conclude that “Facebook Doesn’t Work”.  But browsing the ‘net with an old browser or with some unconventional security settings is somewhat akin to watching TV with a black-and-white set and then saying “My cable company sucks” because the picture isn’t in color.

Sometimes problems are not user error, however.  In either case, it requires patience and collaboration to get to the source of the problem.  I recently had a problem with a client that could have been easily avoided, and it seems like this is a good time to demonstrate the 2 ways this problem could have been dealt with:  first, how it actually went down;  second, how it should have gone down.  Here we go:

How It Went Down, a Dramatization

Client:
Some customers have called us complaining that the Widget you built for us last month doesn’t work.  I refuse to pay for something that doesn’t work.  Fix it now.

Me:
I’m sorry to hear that your widget isn’t working to your specs.  We’ve invested another hour into this and have tested it with Explorer 6, 7 and 8, Firefox, Chrome and Safari on Mac and Windows and can’t seem to duplicate the problem.  It has worked perfectly in every case, so it’s difficult to fix because we can’t seem to duplicate any problems with the information we have.  Can you provide us with some more information?  How, specifically, is it not working?  Have you tried it yourself?  Please try it yourself and let us know what the result is.   If you get an error, send us a screen shot.

(2 months of radio silence ensue)

Client:
The Widget you built us 3 months ago has never worked.  We refuse to pay for something that doesn’t work, and we refuse to pay for that extra hour you spent not finding anything wrong with it.  Fix it now.

Me:
As I said before, we need some more information about this in order to help out.  Try duplicating the problem yourself and let us know what happens, and send us a screen shot of the error.  Also try talking to the customer and see if you can find out what browser one of these people is using, what operating system and, if Explorer, what version and what level the security settings are at.  This is a very complicated Widget that makes your store software talk to Google Maps and then outputs all the content with javascript, so there are some links in the chain that can break and we need to know which link is breaking and whether it’s a link we have any control over.  At this point, we’re becoming unwilling to continue troubleshooting for you, since you’re refusing to pay for it and aren’t providing us with the information we need to effectively troubleshoot.

(1 month of radio silence ensues)

Client:
The Widget you built for us 4 months ago has never worked.  We’re moving on to another web person.  Why is it we always have trouble with our web people?  This happened the last time too.  I guess web people just suck.  And we refuse to pay for the Widget because it never worked.

How It Should Have Gone Down

Client:
Some customers have called to complain that the Widget you built for us isn’t working correctly.  I tried to duplicate the problem myself, and I can’t seem to do it– it seems to be working for me.  I’m using Firefox 3.6.7 on a Mac.  So I talked to one of the customers and sent them to www.supportdetails.com.  I’ve attached a screenshot of the customer’s operating system setup.  Turns out this person is running IE6 with javascript disabled.   The customer says he’s doing a search with your widget but gets a blank screen instead of results.   What can be done about this?

Me:
Nice detective work.  Unfortunately, your Widget is a modern web app and it requires javascript in order to show the Widget’s search results properly because they’re rendered with AJAX, which is how we’re able to show them so quickly without reloading the whole page.  Further, IE6 isn’t supported by most modern sites anymore, and the user base is only in the 5% range… but we’ve gone ahead and performed a temporary workaround for you by adding some simple detection features that warn the user about their browser, their need for javascript, and serve up a link to the free IE8 installer along with some instructions for turning on javascript (it’ll be on by default when they install IE8, btw).   That should buy some time while you think about this alternative:  we could write something that performs the detection and then outputs the results in a less-elegant manner that doesn’t rely on javascript if a user doesn’t have javascript enabled.  This would take a few hours, so I’d say it’s only worth it if this app is so crucial to your business that 5% of your end users being unable to use the Widget will impact your sales in a significant manner.  Just let us know how to proceed.

Client:
Excellent work, let’s leave it like you have it.  Thanks!

Summary

The second scenario is so much easier for everyone!  And it’s far better for the client’s business.  In a nutshell– running a website comes with some responsibilities.  You maximize your ROI when you take the time to learn how your website works and then use that knowledge to proactively interact with your customers and your web contractors.