This is the first post in a two-part series designed to help individuals and business owners avoid ethically questionable web agencies and make smart decisions regarding their presence on the web. After reading this, be sure to check out part two: 5 Reasonable Goals for Building a Website.

The air is still. The sun is high and hot. From the windows of the nearby saloon, nervous eyes watch unblinking as you stare down your opponent in the middle of a wide, dusty road.

The clock tower affixed to the nearby town hall ticks steadily toward noon and the town undertaker, dressed in a sharply pressed black suit, stands by impatiently with a horse and a large, wooden cart.

You find yourself in a showdown with the sleaziest man in the west: Tricky Ol’ Sites McWeb. You should have known better than to sign a deal with the likes of him but now it’s too late. He’s got you dead to rights in an environment with very few laws and nearly no clear standard for what’s fair. And now it looks like this is the only way out.

But how did it come to this?

Sadly, this isn’t the first time Ol’ Sites McWeb has taken advantage of a newcomer to his world and it won’t be the last. Although standard business laws apply to those who would sell you a settlement on the web, there is no lemon law for websites, no Federal Division of Web Creation to enforce good coding practices, and almost no way for the average consumer to know whether or not the product they’ll be receiving is of good quality until it’s too late.

By then, in the worst cases, certain vendors will have protected themselves so well that, not only are they safe from liability for the mess they’ve created, but they’ve made it almost impossible for you to leave them without a very ugly showdown.

Fortunately you can avoid this. As is the case in any type of sales situation, all it takes is some simple preparedness. The only problem is that the average consumer often has little to no idea at all about how to prepare before dealing with website sales folks. Luckily, it is that particular problem that we intend to fix in this two-part series.

And don’t get me wrong. There are plenty of fantastic web agencies out there fully committed to doing right by their clients 100% of time. But the world of web can be very much like the wild, wild west, and it’s up to you the consumer to know how to separate the real cowboys (and girls!) from the varmints.

In order to do that, there are two simple questions you’ll need to be able to answer:

1. How can I know whether my website vendor has my best interests in mind?
2. How can I know whether I’m receiving a quality product?

As you might expect, there’s a lot that can go in to answering both of those questions. In our journey we’ll attempt to answer them with as much good information as possible while trying hard to avoid lots of useless jargon. We’ll focus on the first question today and then explore the second one more in Part II. Are you ready?

Here goes:

Your Best Interests

Tricky Ol’ Sites McWeb, if you haven’t realized by now, is a metaphor for the dark side of the website vendor industry. Webmakers like him can usually be identified by a few common characteristics. They won’t always take on all of these characteristics. Nevertheless, each one should be avoided at all costs. They are as follows:

• Distributing poorly designed products.
• Using extremely low prices to lure in clients without informing them of the serious quality sacrifices being made to facilitate those prices.
• Using systems that deliberately isolate clients from their own websites.
• Registering domains and server space under their own names rather than under the names of clients (resulting in the web vendor being the legal owner of the site rather than the client).
• Building websites on top of proprietary systems so that clients are unable to change web vendors without building a brand new site from scratch.
• Assigning blame back to clients for problems actually resulting from poorly-written or outdated code.

The worst part about it is that, in many cases, clients are not sufficiently informed to realize that these things are happening to them. Only when the client finally becomes frustrated enough by their vendor’s slow response times and impersonal dealings do they reach out to new vendors who then face the difficult task of breaking the news that a transition is not going to be easy.

Luckily, there are some questions you can ask your potential web vendor that will allow you, regardless of your level of expertise, to detect warning signs early and quickly learn to separate friend from foe. Ask these 5 questions terrible web agencies hate and save yourself from wasted money and endless frustration.

Question 1: Will I be able to make changes to my website easily by myself?

This question packs a punch because it cuts straight to the core of how willing potential vendors are to allow others to see the code they’ve created. It can also help you determine whether or not they consider themselves (rather than you) to be the owner of the website, and whether or not they are deliberately trying to force you into a dependence upon them. Even if you don’t actually want to make changes yourself you should still ask this question.

A possible good response would sound something like this:

“Absolutely. We’ll build your site on [name of commonly used platform here] that has a simple, clean, dashboard where you can log in and edit your content in an editor that makes updates as simple as writing an email or editing a Word document.”

A possible bad response would sound something like this:

“We’ve found that the average website owner eventually decides they’d rather not have to edit their own content. That’s what our website maintenance package is for. Any time you need something changed, just send us an email and we’ll take care of it.”

How you should react:

Some common platforms include WordPress (far-and-away the most popular), Joomla and Drupal. The point is that you should be able to easily take your site with you. If their response sounds closer to the one labeled as “bad,” this doesn’t necessarily mean they are out to get you, per se. But it does mean they’ve already made development decisions that weren’t geared toward making things as easy for you as possible. You should ask a good follow-up question like…

“If I request content changes, can you guarantee that you’ll make those changes within a week?”

A week, by the way, is generous. If the answer to that follow-up isn’t a resounding “yes,” it’s time to take a step back and look at the facts. If you can’t expect to be able to edit your own content or have it changed in a timely manner, this is not a vendor with whom you’ll want to do business. If they do answer yes, make sure that “yes” gets written into your contract. By the way, we should be clear that there is nothing wrong with website maintenance packages. We offer them ourselves, and many of our clients choose to implement them. The problem arises when you’re forced into these ongoing agreements and have no choice in the matter.

Question 2: How will you go about making my website “responsive?”

This question is all about compatibility with mobile devices. It’s also very poignant because it allows you to assess two important factors at once:

1. Whether or not potential vendors care to keep themselves informed about modern development techniques.
2. Whether or not they have the experience to use those techniques correctly.

Make sure, when you ask this question, that you actually use the word “responsive.” Here’s why:

“Responsive” is the term in the web development industry that means a website can adapt to varying screen sizes. With a well-made responsive site, users will have a great experience on your website whether they choose to view it on their computer, tablet, or smart phone. Any web development outfit worth their salt should immediately know what that word means and how to answer your question.

Since the question is looking for two things, let’s talk about possible answers for each piece.

A possible good answer for whether they can give you a responsive site:

“Responsive design is one of our specialties. In fact, we don’t even do websites that aren’t responsive, unless there is a rare need for a separate mobile site.”

Or…

“We can definitely make your website responsive but it will cost a little extra.”

A possible bad answer for whether they can give you a responsive site:

“We don’t do responsive design because [insert any reason at all here].”

Or…

“What do you mean by responsive?”

In this case, confirmation that they know what responsive design is and that they actually do that kind of thing is what you’re looking for. Any version of “no” or “I don’t know what that means” is absolutely unacceptable. All legitimate modern professionals currently know what this means, understand why it is important, and are versed in how to properly implement it.

To help you understand why this matters, as of June 2013, web traffic on mobile devices accounted for a full 35% of website visits, according to research reported on PR Newswire, which happened to be a full 5% increase from the previous month. According to Nielsen, 50% of all local searches are performed on mobile devices, whose searches will overtake searches made by PCs by 2014. Deliberately not optimizing the average website for mobile traffic in this day and age is akin to burying your head in the sand. In fact, in my experience, being uneducated about responsive design tends to correlate with the inability to write good code from lots of other perspectives as well.

As for the second part of our question…

A possible good answer for how they will implement responsive design:

The technical version –

“We use something called CSS and media queries to create breakpoints that trigger layout changes.”

The simplified version –

“If you grab the edge of your browser window with the mouse and start making it smaller, you will see some pieces of your page change size along with the window and you will see other pieces of the page re-organize themselves so that the design can make sense within a smaller space. This way, regardless of the screen size someone has when they visit your site, they’ll see something optimized for them.”

Notice that if you hear the words “CSS,” “media queries,” and/or “breakpoints” somewhere in the answer, these are good signs. Most important, however, is the description about page elements responding to changes in screen size to become automatically adapted to different kinds of devices. Press them to confirm that this is what will happen if you change the size of your browser window.

If you don’t hear the word “CSS” in the response, it’s good to follow up with something like:

“I heard the right way to do that is with something called CSS. Is that what you use?”

If you don’t get a “yes,” then that’s a red flag.

A possible bad answer for how they will implement responsive design:

“We’ll create a mobile version of your website. If someone visits your website from a mobile device, they’ll automatically be sent over to the mobile version.”

While this may seem like an acceptable solution at face value, it really isn’t. It used to be. But not anymore. Here’s why:

For one, in order for this to work, there has to be code on the website that detects mobile devices based on a special identifier each device gives to the website when it accesses it. That implies two things. First, that piece of code has to be regularly maintained to keep up with all new devices that are created and, in some cases, for every new version of the same mobile device when the new version comes out. More often than not, this maintenance doesn’t happen.

Second, sometimes by mistake and sometimes on purpose, devices can misrepresent what they are when they visit websites. Anyone in that category will not be given the correct experience when they show up to your site.

Another problem is that there are tons of different mobile devices out there, all with different screen sizes. A mobile version of a website would still need to be screen size adaptable in order to give the best experience to visitors across various mobile devices. From that regard, mobile sites tend to fail pretty hard when accessed by tablets which are too large to be dealt with as phones and too small to be dealt with as desktop computers.

Lastly, having both a desktop version and a mobile version of your website usually means that any time you want to make a change, you will have to make that change in twice as many places. This, of course, means that every change will take twice as long. If Tricky Ol’ Sites McWeb is clever enough to build a mobile website that can do magic things like automatically update itself whenever you change content on the main site, he ought to be clever enough to do responsive design the right way since it would save him a lot of time and effort.

The crux of the matter is this: Why would you choose to create two versions of a website when all you need is one? It’s more work and more money unless your strategy uniquely requires it. To be fair, there are instances when a separate mobile website is better for a business than one website that is responsive to mobile devices, but even then it’s almost never for the exclusive purpose of making your main site compatible with smaller screens. It’s the exception and a marketer would be able to better determine what’s best for your business than your web designer.

Question 3: Are you going to build my whole website using HTML tables?

HTML, if you didn’t already know, is the coding language used to create the structure of your website. It denotes where the items on the page will be placed in relation to each other.

Admittedly, it shouldn’t have to matter to you as a consumer what any of the HTML elements do, let alone the table element specifically. However, it is becoming increasingly necessary to ask questions like this as lazy developers continue to allow modern technology to pass them by without adapting their methods to the changing landscape.

Here’s a possible good response:

“No. Using tables like that is a very old-fashioned way to do things. We’ll use lots of different HTML elements to create your website. There might be a table here of there, but only in places where the table element is appropriate. We won’t use it for overall site structure.”

Here’s a possible bad response:

First, you may witness an indignant look come across Ol’ Sites McWeb’s face. Keep a lookout for this. After snarling for a moment he might go on to say…

“These days a lot of people are criticizing tables for no good reason. Tables are how we’ve always built websites. They’re a valid HTML element and they still work. There’s nothing wrong with them.”

And McWeb is right about that. But it’s not about there being something wrong with a table. It’s about using a table the wrong way. And believe me, this matters.

Now for a history lesson.

You see, back in the ‘50s, computers were these huge clunky things covered in physical switches that occupied entire rooms and didn’t do much more than math. As time went by they improved. Today, a computer the size of your pocket can communicate across robust networks in various ways simultaneously, allow you to play games utilizing motion graphics of near photo-realism, and even remotely automate systems in your home.

Like the computers they run on, coding languages improve over time. Back in the 90’s, our primary tool for site structure was this thing called the table element. Now, however, there are myriad choices that aren’t tied to the same drawbacks of using the table.

One specific drawback to using the table is that you can’t create a responsive site structure with it. And we’ve already talked about the importance of responsive design. In essence, a table creates a layout very similar to what you’d see in a spreadsheet using rows and columns separated by lines that can be made invisible if you want. The problem is that this kind of a layout completely locks you down.

Imagine that all of the items on your web page are sitting inside of spreadsheet boxes. Now imagine you want to scale your screen down to a smaller size. Stuck in this permanent grid, the pieces on the page now have no way to re-arrange themselves to respond to the new, smaller screen size. The best they can do is shrink or disappear off the side of the page.

So if you had, say, four columns of content containing pictures and text (a fairly common thing to do for developers who build in tables), the only way these elements could respond to a smaller screen is to become awkwardly tiny and/or break the layout of the page. You end up with pictures that are too hard to see, paragraphs with only one word per line, videos that break their borders and stick off the edge of the page, and so on.

In fact, even if you don’t think you need your website to be responsive right now, too many tables can turn future upgrades in to a process whereby the developer has to do everything just short of re-creating the entire website from scratch in order to do them.

Tables, while they have their place, are no longer the standard for website structure. If your potential vendor insists on using them for site structure, it’s only because Ol’ Sites McWeb decided to stop following new standards in the industry somewhere around 2001.

You can bet these old techniques will become a pain point in the future. Not to mention the fact that if you do ever decide to change vendors, your new developer will likely be unhappy about the product you’ve given her to work with and she will probably suggest that you let her make you a brand new site rather than re-write 90% of it just to fix problems.

Question 4: Will the domain name and hosting package be registered to me?

This question is all about dependence and, to say it bluntly, hostage taking. Unless there are some kind of crazy, extenuating circumstances involved, you should be the owner of your website.

In case you’re not already up to speed on these terms, a “domain” is a name like “www.example.com”. You will have to pay a small annual fee (usually averaging about $12.00 USD a year at the time of this writing) to have that name actually associated with your website.

A “hosting package” comes into play because your website files will have to live on a special computer that can be accessed by people browsing the internet. This special computer is called a “server” and it normally costs a monthly fee for a company that owns servers to let you put your files on one or more of them.

Sites McWeb will often put his own name on these documents under the guise of making things easier for you. But then, when it comes time to leave McWeb for another vendor or to otherwise take control of what ought to be yours, you quickly realize that the law is technically on his side and he has created for himself what we might call a nuclear option.

McWeb will have set things up so that he can legally smash your website to bits just out of spite if you decide to leave him. He’ll likely be the legal owner of the code base, the domain name, and the server space where your website lives. Once your dealings with him have ended, all bets are off and you might not be able to take anything with you.

It’s crucially important then that you receive a reasonable response to the question of direct ownership.

A good response might sound something like this:

“Of course! You will be responsible for paying the annual fees but this way you can do whatever you want with your site after we finish working on it.”

Or perhaps…

“The domain and the hosting package will be registered to you but, if you want, we can list our address for billing purposes. That way you can keep us on a monthly retainer and we’ll make sure the annual fees are taken care of with part of that money.”

Or even…

“The domain will be registered to you but we host all the websites we create on our own servers. This way you won’t have to worry about an extra monthly hosting charge. Don’t worry, however, because if you ever decide to leave us, your new vendor will easily be able to transfer your files to another server.“

That last piece about easy transfer is critical. If they don’t offer it voluntarily, you should press for it and even get it in writing. You should also confirm that their servers will be able to quickly and efficiently handle the amount of traffic you expect your site to receive.

A bad response might sound something like this:

Anything not listed in the good response section.

As Admiral Akbar of Star Wars fame would say: “It’s a trap!”

It’s also important to follow this question up with something that gets potential vendors to confirm that they are not going to build your site with proprietary code they don’t want other developers to see. Try this:

“And will the code you write be licensed to me? If I ever ended up having to go with a different vendor, I’d need them to be able to access the code.”

If your potential vendor is unwilling to honor that request, you have just detected a bona fide Sites McWeb.

Ok. Last question:

Question 5: What are your plans for handling problems with Internet Explorer?

The thing you should know here is that, for the last very long while, Internet Explorer (the default web browser that comes with Microsoft Windows) has deliberately ignored a lot of the rules about how browsers are supposed to take code and turn it into a website that users can see.

As you can imagine, this has been very frustrating for developers because lots of people use Internet Explorer. This means we’ve traditionally had to spend a lot of time writing special exceptions for the weird things that different versions of Internet Explorer do.

Let me just take this moment to encourage you to download Mozilla Firefox or Google Chrome if you happen to be using Internet Explorer.

Truthfully, in recent days, Microsoft has been getting better about how newer versions of Internet Explorer conform to the rules. This makes developers happier but we still have to account for all the people that might continue to visit your website using an older version of the browser. The three versions in particular that continue to cause trouble at the time of this writing are versions 6, 7, and 8.

This means that the decision you’ll need to face as the website owner is how far you’re willing to go to accommodate users who are, for various reasons, trapped in the past.

Here’s a possible good response regarding IE:

“The amount of people that still use IE6 and 7 is so small that we have deliberately made the decision not to support those browsers anymore. However, we will make sure your site is compatible with IE8.”

Or potentially something more like…

“We’ll support as many versions of IE as you want but you’ll have to pay a little more for each version below version 9.”

Here’s a possible bad response regarding IE:

“We’ve never seen any problems with IE interpreting our code.”

Translation: They’ve either never checked their code on Internet Explorer or they invented their design and development techniques over a decade ago when IE6 was cutting edge and haven’t updated them since. This implies tables everywhere in your site structure and an unfamiliarity with modern technology. I can almost guarantee that they’ve never created a responsive design in their lives.

Keep in mind that once you’ve found a potential vendor who is willing to acknowledge the importance of strategizing about Internet Explorer, you’ll need a way to determine what’s best for your target audience.

As a general rule, unless you need to support a wide user base specifically located in China*, or you expect nearly all of your website visitors to find you during their work shifts at the local bank, you probably don’t need to worry about IE6 or 7. IE8 is another matter entirely and if support for it comes as part of the package, there’s no reason to demand that your website not support it.

*Note: China is currently home to a vast concentration of IE6 users due to a large amount of pirated copies of Windows XP that have never been updated.

If IE8 support does happen to cost extra, your web vendor is probably part of the community that is (rightly) working on subtle ways of pushing IE8 into obscurity. Truth be told, it is more likely that you should have IE8 support as opposed to ignoring it, at least at the time of this writing. But if you really dislike paying extra for beneficial features, here are a few keys to help you decide whether or not dropping support for IE8 is a good idea for you.

You may not need IE8 support if the following are true:

• Your target audience is under 35 years of age.
• Potential users are much more likely to view your site at home than at work.
• You know that your target audience is somewhat computer-savvy.
• Your product is business-to-consumer rather than business-to-business.
• You personally do not use Internet Explorer.

If you don’t find all of the above statements to be true, it is certainly worthwhile to make sure support for IE8 is part of your deal.

Where This Puts You

Once you’ve found a vendor who is willing to allow you to be the owner of your website, can provide you with a system that allows you to make changes on your own, will deliver a responsive site built the right way with a modern site structure, and will strategize with you about how best to meet the needs of your target audience, it’s a good bet you’ve avoided Ol’ Sites McWeb.

All that said, it’s one thing to know whether a vendor is up to snuff. It’s another thing entirely to understand how to judge the actual quality of of the product you’ll be receiving. So that’s what we’ll be covering in Part II of this series. In the meantime, please share these 5 questions terrible web agencies hate with your friends and colleagues.

For now, you should feel sufficiently versed in the traps of the tricksters. You have been well-armed with an arsenal of fog-dispersing questions that will make the shadiest sort squirm. Of course, when presented with tough questions, McWeb will try his hardest to weasel his way out. Just remember that if you ever feel like a potential vendor is using your lack of technical knowledge against you, the problem is not with you. It’s with them. Don’t sign that deal!

Search engine optimization, web analytics, a fair price — What kind of goals are reasonable when building a website? Find out by reading Part Two of this series: 5 Reasonable Goals for Building a Website.