Programming Philosophies

Keeping a low profile

We've all visited websites where the scripting does the browser equivalent of a musical theatre number, with pop-ups, auto-scrolling, beeps, and more. Unobtrusive JavaScript is the idea that scripts are a quiet helper, there to provide support when needed, but for the most part unnoticed as the user goes through your survey. Think of it as the perfect dining experience, where your glass is always filled and the next course arrives just when you want it, without the server ever interrupting your conversation.

Staying with conventions

In the early days of the Web, browsers would add support for their own special functions, some of which eventually made it into the core HTML specification, while others never caught on so pages wouldn't work consistently in different browsers. Web standards is the idea that we all benefit from using the same set of language specifications, including having browsers interpret them consistently.

While you probably won't be involved in the nitty-gritty of your code, standards are still a good thing to keep in mind. Every time you add an animated scroll bar to a page, or swap out standard checkboxes for extra large ones, you're overriding built-in functions. As tempting as it is to go with the fancy/cool "upgrade," remember you're trying to get respondents to answer a form, not provide them entertainment. And while the standard form controls might seem a little boring, they're also ones the respondents know exactly how to deal with, and which will work reliably in every circumstance.

Tailoring to the user's environment

My phone will display the same web pages as my laptop, but shrinking and panning isn't an ideal experience. Responsive web design is the idea that websites should smoothly accommodate a range of devices. Naturally, this is much simpler to say than to do.

If you have a very simple single column page, you could simply set it to 100% of the browser width, but while that would be readable on a phone, it would actually be difficult on a desktop because the line lengths would be far too long (45-75 characters per line is a common target). In the case of a site like this, it gets trickier because in small displays the sidebar needs to go away, with its content either dropped completely or rearranged in a way which works better. Even within the main body column, we start having to deal with scaling images, or perhaps briefer content.

Surveys have their own particular challenges, especially in longer forms with extensive grids, such as employee satisfaction or industry salary surveys. In order to fit your grid on a phone screen, you may need to change from text labels to a 1-5, swap in pull-down lists, rearrange from a grid with radio buttons to the side to a series of questions with the scale below, etc. In addition, when text fields are used, a large portion of the screen is covered by the keyboard. And despite my general dislike of one page per question syndrome, I'm willing to revisit it for tiny screens.

With pages like this site, designers often use CSS media queries to say "If the screen is >x pixels, do y." (These are generally referred to as breakpoints.) That action may be resizing, rearranging, or hiding sections, but it's all acting on a single source page. (This is also used for print-friendly pages.) At other times, designers will create two essentially independent sites, tailored for specific devices, with a switcher script that sends respondents to one site or the other. I've used designated sites for mobile projects because tailoring forms generally takes more than a little styling, but just be sure you think through its impact on pause/resume, one time use passwords, and such.

If a mobile edition of your survey is important to your research, I recommend starting with that as the target, and then making cosmetic adjustments for larger displays. It's easier to begin with the most constrained situation, than to cut down a survey you've already refined for more flexible environments.

Failing gracefully

The user has JavaScript disabled or cookies blocked. What now?

You could tell the user what they need to "fix." Most of us have seen notices about installing a plugin or enabling some browser feature to proceed, and many of us have responded with "Bye!" If your scripts will block a non-compliant browser, keep in mind that a respondent has to be (a) willing, and (b) able to remedy the problem—and there are no small requests when we're all scrambling for respondents.

Instead, most sites are designed to proceed even without full support, via either graceful degradation or progressive enhancement. These are the same concept approached from two directions.

With graceful degradation, you design your ideal experience for the "typical" user. Then you go through the scripts, playing what-if in case of older browsers or restrictive environments.

With progressive enhancement, you design for the bare bones, and then consider what icing you could add for people who happen to have the latest and greatest installed.

Whichever way you tackle it, this usually involves an overlap of server-side and client-side scripting. So even if there's no instant JavaScript check on their e-mail address format, it's still OK because you've backed it up with a PHP or ASP function as soon as they click Next/Submit.