What technologies drive web surveys?

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.


HTML (HyperText Markup Language)

HTML includes the text you read, as well as information on how the page is structured. Pages are organized into sections such as the header, body, or sidebar, and the HTML also indicates if something is a title, paragraph, list, table, image, or link.

The radio buttons, checkboxes, pull-down lists, and Submit buttons in a form are part of this core language. The browser also performs some standard behaviors, such as pressing Tab or Enter while you're within a form.

CSS (Cascading Style Sheets)

In olden days (12 years ago), formatting instructions such as fonts, colors, and backgrounds were intermixed with the HTML. Over time, this information was pulled out, so the styling of a paragraph is a layer on top of the text itself. This makes it easy to re-style an entire site when your logo color changes, or if you decide you want the sidebar on the left instead of right. It also allows for more dramatic effects, such as creating mobile-friendly or print-friendly versions of pages. While CSS allows for more control over layouts these days, most designers still allow some flexibility to support individual settings such as large fonts.

Client-Side Scripts

JavaScript is the most common form of client-side scripting, meaning the script is downloaded to your local device, and runs there. When it comes to forms, there's a wide range of functions you can add via JavaScript, from automatically formatting your phone number to activating a secondary question when you mark the first. Apart from the interactivity, what's great about client-side scripting is it responds instantly as you type or click.

There are just two catches. First, since the script runs locally, it may encounter a browser with scripting blocked, or an old version which doesn't properly understand your functions. Second, every bell and whistle is more development time, and even if you have survey software which adds common functions with a click, more features usually mean higher end tools.


Common plugins include Flash, Silverlight, Acrobat, and Java. These allow developers to create a very controlled user experience—assuming the user has the plugin installed. For the vast majority of surveys, I recommend sticking with conventional HTML forms, for the broadest respondent reach. If someone is pitching you a form which requires a plugin, be sure you ask what functions it provides that they can't do in other ways, and decide if the portion of your population who cannot run the application is an acceptable loss.


A cookie is a small bit of data which a script (server-side or client-side) saves to your local system. Cookies can be used to remember respondents, for resuming an abandoned session or preventing a second submit. However, they're not infallable—they can be blocked, deleted, and only apply to a specific device+user+browser combination so someone can answer multiple times simply by switching from Internet Explorer to Firefox, or desktop to tablet. Cookies are also a problem in shared computer environments.

Server-Side Scripts

PHP, ASP, Perl, and Python are common server-side scripting languages. These execute on the server itself, which means you know exactly how they will work every time. Server-side scripts should be the core of any survey processing for functions such as data validation and skips, because they don't depend on what the user is running. So why do we use client-side scripting at all? Because in order for a server-side script to act, the user needs to click a Submit or Next button, or load a page, so the server can receive a request, process it, and then send the result back to the user.


Many survey applications will be based on, or connected to, a databse. In shared hosting environments, MySQL is very common, while in corporate networks the database may be Microsoft SQL Server. The database server is an important choice for IT professionals, but unlikely to impact your range of survey functions, because there is range of APIs (application programming interfaces) which let the common databases and programming languages connect.

Web Server

The lowest level is the web server itself, such as Microsoft IIS, or Apache on most shared hosts. Just like Windows vs. Apple, this may impact the survey applications you can install on your site. There are also occasional functions, such as restricting a folder to certain IP addresses (see more), which can be set via the server configuration.

Want more web jargon? Read on with Programming Philosophies.

Need a Hand?

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

(206) 399-2344 Download VCard LinkedIn Profile

I rely on Query Group for prompt, accurate turnaround of my reporting projects. Being able to call on Ann lets me take on projects when my full time staff is already busy.

Ron Morris
Feedback Systems