Recently Filed in Technology

Note: This article assumes you're familiar with common web technologies, so if client-side vs. server-side is a bit of gibberish, start here.

We can never know exactly what environment a respondent will be using to complete our web surveys, so how do we add bells and whistles without the forms breaking? (Seriously, never. I've had IT people give me rigid specs on their employees' systems, only to have the server logs show other configurations.)

There's a range of tools for processing the surveys on your web site, and while you may not be writing code, understanding the landscape can be helpful. Forgive me going back to some basics, but people tend to have different holes in their knowledge, so I'm trying to cover all the bases.

When you access a web survey or other page, you use a browser such as Internet Explorer, Safari, or Firefox. This downloads a collection of HTML, CSS, and scripting files, which are interpreted by your desktop or phone and browser for display. The combination of device + browser + personal settings (installed plugins, large fonts, security) results in a huge range of possible environments in which a survey needs to function. Which is why widow/orphan line breaks are the last thing we worry about.

Because we're not binary beings, we have text domain names such as:
   practicalsurveys.com
to reach Websites, but what really directs traffic around the Internet are the corresponding numeric identities, IP (Internet Protocol) addresses:
   209.197.67.60

In addition entering IP addresses as destinations, whenever you (or your e-mails) travel the Web you're also leaving little IP address footprints wherever you go. Because of this, survey managers sometimes want to use the respondent's IP address in one of two ways:

  1. To prevent ballot box stuffing by only allowing one response per IP address
  2. As a supplemental source of information

Before you join them, let's look a bit more about exactly what the respondent's IP may or may not tell you.

A common concern is how to deal with duplicated survey responses. In practice, this is an issue when the benefit to multiple submits outweighs the effort of making them. For most surveys, the challenge is getting people to complete once.

One of the great things about the Web is that almost any functionality is possible—it's just a small matter of programming (and budget and time and compromises). Sometimes you can imagine a widget which will make your respondent's or visitor's experience smoother or richer. Sometimes it's a function which will make your site easier to manage.

For Web surveys, there's a huge range of tools and services, so someone may already offer your dream feature. However, there are times when you just need something custom.

As great as the Web is for surveys, there are times paper is a better fit (and phones and in-person too of course). When paper is what you need, people often look to scanning as a "no data entry" solution. While you can get close with some surveys, as with all technology there's fine print.

These days, most of us do more in Excel than the VisiCalc creators would have dreamed. Following are a few of my favorite tricks for working with data in Excel (the raw side, not the chart side). This article includes:

Comma Separated Values (AKA comma-delimited ASCII) are one of the most common formats used to exchange information. This is because they're compatible with applications on just about any operating system—going back to DOS days. On many computers, a .CSV file will be automatically associated with Microsoft Excel, and when you double-click on the file it opens using the automatic settings.

This is great—unless you have certain types of data such as East coast Zip codes.

Some surveys have very infrequent responses, going days or even weeks without a submission. Rather than heading out to your Web host to keep checking for responses, it can be handy to just get an e-mail alert when someone completes the survey.

A few premium services such as SurveyHost and KeySurvey provide this feature, including sending e-mails with an individual's answers and only under certain conditions (such as marking "Contact me"). However, low volume surveys often don't justify that type of budget, so here's another way.

Most survey products and services let you specify a Thanks URL for when respondents finish. By sending respondents to this script, you can get an e-mail alert upon each completion. It's written in PHP, so you can use it with both Unix/Linux and Windows Web servers.

Download the Zip file with the script and instructions.

"Piping" at its most generic refers to moving information in, out, and around a survey. This makes it a very useful technology for any dynamic survey (Web, telephone, kiosk), potentially enriching the respondent experience or increasing data quality.

It's also one of the many survey terms that can mean different things to different people, so before you assume your survey tool does what you want, make sure you're using the same definitions as your vendor. This article covers four main approaches to piping:

Just because you have a Web server doesn't mean it's the best choice for running your Web surveys. While your own box has the advantage of full control, it also has some drawbacks. This doesn't mean you have to go with an Application Service Provider (ASP) survey vendor for your projects. Many Web survey software vendors also provide "self-service" hosting for their software users.

In a recent workshop, a participant asked how to deal with his Zip code data. Every time he did a survey, he was manually grouping the codes into regions for analysis. If you're in a similar situation, here's a better approach.

First, you need to be able to merge two pieces of data: your survey responses and the Zip code information. This means you'll need to add some extra fields to your questionnaire to handle the city/state/CBSA information. In a Web form, you can use hidden fields to stash the information. On a paper form you can add them to your survey software or database after you print the questionnaire.

One of the strengths of Web, CATI and CAPI surveys is their adaptability. We can create a questionnaire which tailors itself in obvious and hidden ways to a respondent's answers. While in a sense the respondent is "driving" this process, they're doing so after a researcher carefully lays out the cones, sets up hay bales on dangerous curves, and straps the respondent into their go-cart with a safety harness and helmet.

I recently completed a survey where they forgot some of the safety precautions. It was an interesting experience, weaving around the debris from prior respondents while simultaneously dropping cones for my own course.

While we always like to study best practices, sometimes it's the failures which are most illuminating—in this case an unusual password design. The plan was hatched by a client's client before we came in on the rush project, so I can only report on the results and infer motivations.

Just as spammers have made e-mail invitations a perilous exercise, pop-up ads have made Web-based survey invitations challenging. Internet Explorer and Firefox install with pop-up blocking on by default, and people aren't exactly rushing to turn it off. So when you have a Web survey linked from your site, what's the best way to draw in respondents?

Need a Hand?

A little help can add a lot of polish—or just save hours and headaches:

(206) 466-2982 Download VCard LinkedIn Profile
info@querygroup.com

Thanks again for the excellent training sessions. You were able to keep it interesting and worth every penny. You have such a thorough understanding of the software. ~~sigh~~ to be that wise!

Susan L. Despot
California University of Pennsylvania