Web Design Tips and Tricks

Can You Trust Your Webmaster?

Get Web Design Tips and Tricks on mps-web-design.com. Can You Trust Your Webmaster? topic will increase your understanding on Web Design Tips and Tricks. We at mps-web-design.com only provide news, articles, information in Web Design Tips and Tricks. Web Design Tips and Tricks at mps-web-design.com provides the most up to date news and articles. If you have questions please do not hesitate to contact us.

Last week a friend of mine told me about a problem that she was having with her webmaster. She no longer trusted this person who was in charge of her ecommerce website.

Their relationship is similar to most webmaster – client relationships: the webmaster understands the complexity of web design and search engine placement and the client relies solely on her/his expertise. The client’s lack of technical knowledge and dependence can make them an unwitting victim of unscrupulous webmasters. That is exactly what happened to my friend.

Now, most webmasters are solid, upright citizens working hard for their clients. But the few bad apples... well, ruin it for everyone. 

Webmasters are privy to many types of secure data. Some of the information that I routinely receive are client credit card numbers, home addresses, secret words or questions, usernames and passwords. Clients seem to be willing to hand over whatever information is necessary for securing their domain names, hosting service, payment gateways, and security certificate setups. In addition, I also have access to all customer purchase information: addresses, phone numbers, email addresses, credit card information, and login username and passwords.

With that in mind, security breaches and misuse of data become a possibility. Relying on a webmaster, whose moral base is, “whatever it takes to make a buck” will quickly develop into a disaster for the client.

Disaster struck my friend’s business. Her webmaster set up the website and email accounts and hosted it on his web server. He controls the entire process leaving my friend out of the loop. She submits changes to him as she does not even have a username and password. If the webmaster was competent and trustworthy, the relationship could continue like this for a long time. Unfortunately, he was not.

Maybe a mistake, maybe a design error? NO. This webmaster was siphoning her client list and selling the client list to spammers. Further investigation showed that an employee was also providing the webmaster with bulk mail lists.

How did she find out she could no longer trust her webmaster? She heard it from her customers, her bread and butter. Customers were complaining that they were receiving massive amounts of spam after signing up for information on my friend’s website. Knowing that she has an anti-spam policy in place, she began to investigate.

After setting up a dummy Hotmail account, she went to her website and submitted the Request for Information form. Then she waited to see if she received that request. Eventually, she received the request, but not from the original email, but a forwarded copy from the webmaster. It seemed that the webmaster had pointed the form to his email address.

This resulted in one fired employee, one distraught client, loss of customers, loss of revenue, loss of brand recognition, the additional expense of setting up a new site on a different hosting company server and a forced domain name change. The domain name change was forced because the webmaster refused to change the name servers (the way the web finds your site) to point to the new address of the site.

Does this happen all the time? No. Does it happen enough to call a webmaster’s credibility into account? Yes. That is the rub. Those of us, who are working to maintain a client’s trust, find we have to account for the bad apples. We have to prove we aren’t one of them.

Following these simple rules will bring you piece of mind when hiring a webmaster:

• Ask for and CHECK references. (Don't just go to their site and see their clients, pick up the phone)
• Ensure that the contract includes specifics:
• Design and Optimization details

  • Completion date
  • Specific recourse if the site does not meet the completion date
  • 50% retainer (do not pay for all of the work up front)

• Put all requests in writing.
• Specify in the contract a date for turning over the website to the client
• Once the site is turned over, (even if the webmaster still supports the site):

  • Change all the passwords
  • Change the user permissions
  • Administrator should be the owner
  • Test all forms to ensure that you receive the contact information
  • Stay vigilant, listen to your customers
    

This post comes a bit late in the whole web 2.0 cycle. I feel that it bears repeating because I have come across sites that don't follow some basic principles when pulling in 3rd party data from sites such as flickr, twitter et. al.

APIs and data portability

The blessing of popular and easy to use APIs and the data portability of web 2.0 applications has had an unfortunate side effect, and that is that some implementations that use these services do not integrate appropriate contingency design should these 3rd party services fail.

Caching data calls to APIs is a good bit of contingency design. Many APIs will require caching - like that of Amazon - but I suspect this is intended to help limit resource use of the API host, not the site using the API. The reasons a person using API accessed data on their website would want to cache the data are:

1. To speed up the load time of their website
2. To have a back up plan if the API call fails

A simple implementation to handle those two cases would be one that caches an API call for a given amount of time and one that freshens stale cached data and triggers an error should an API call fail.

Caching is good contingency design practice

As I said above, this post is a bit late to the party but it is worth writing as recently I have come upon at least three sites where firebug and other widgets have revealed issues retrieving API fetched data and the site loading times have been horrible.

A decent implementation idea would be to roll your own caching wrapper and agnostically plug it in to a stable caching tool, perhaps something like Cache Lite for PHP. In this manner you have a reusable, caching library independent piece of code that can handle caching/flushing and refreshing of data which could function to handle the two cases discussed above.

And that's it. It's been 541 days since my last post. Wow. I hope this is a re-start of a new phase of blogging. Right, and it looks like I had not built the commenting functionality into this version of the site. What a surprise. I'd still like feedback so if anyone has any email me at mike at this domain and I'll pop a comment right into the database. Off to build some commenting functionality... Comments should be working now.

More Articles: