- Featured Columnists
- Table of Contents
- Web Basics
- Publishing on the Web: Putting Files on the Server
- Web Design Process and Workflow
- Project Management
- Mark My WWWord: HTML and XHTML
- Standards Compliance
- Meta Tags and Search
- Enhancing Web Page Interaction
- Web Graphics
- Web Page Optimization
- Overview of Servers
- Server Programming Basics
- Careers in Web Design
- Intellectual Property for Web Designers
Last updated Mar 1, 2004.
By Molly Holzschlag
Server-side interactivity is when either the majority or all of the interactive ability of the Web page is controlled by some technology on the Web server itself, either using technology inherent to the server itself, or using an application technology and additional programming languages and even database technology to provide the interactivity that you as a designer are after.
One of the earliest, most stable, and easiest ways of tapping into interactivity on the server comes in the form of server-side includes, known as SSIs. These includes are simple bits of syntax that are added to a document to perform different bits of interactive functions such as:
Automatically add the correct date to the page. While in and of itself this is not interactive, having the correct date on a Web page is an important part of user experiencegiving a sense that the Web site is up-to-date and relevant.
Enable the inclusion of external files. This very powerful feature enables Web designers to take portions of a given page, such as a header or footer, and place them in an external file. Then, every page on the site can use the include syntax to pull in the separate footer. This allows for the included portions of the page to be very quickly edited site-wide.
Automatically add a "Recently Updated" feature to the page. Again, not in and of itself interactive, but certainly informative and important to the site visitor looking for the timeliness and relevance of your content.
Most Web servers have SSIs available, and the syntax is usually the same from server to server. Here's an SSI sample. This sample would sit in the main HTML page and pulls in the external file, in this case a footer section.
<!--#include file="includes/footer.html" -->
Then, after the server delivers the file to a user's Web browser, this file is automatically included by the server, which inserts the code held in the file directly into the file. The file is then sent to the user. If the user views the resulting source within the browser, he or she won't see the include syntax. Rather, the code will be displayed because it was added to on the server-side.
SSIs are very popular because they really help Web designers improve workflow. Using them, you could not only add good information, but create a variety of interactive features, such as polls, slip them into the include file, and update them regularly without having to update 10s or 100s of files. The user gets up-to-date information and interaction, and the time-in on your end is minimal.
The one difficulty with SSIs is that many ISPs do not enable the option on. So, you may or may not be able to tap into the power of SSIs on your given server.
SSIs can also be written in application languages such as PHP and .NET, but the code tends to be more detailed because it's not relying on the server's basic intelligence; instead, it relies on the more complicated intelligence within application languages.
Another means of getting interactivity into pages is to use application languages. It's interesting and necessary to point out that most of what can be accomplished by browser-based techniques can also be accomplished using application languages. What's more, each application language usually has some means of dealing with a given type of interactive option.
The real challenge here has more to do with determining certain critical issues pertaining to the type of interactivity you're looking to add to your site.
Some of the issues that have to be addressed are the following:
What kind of Web server are you using?
Which technologies on that server are made available to you?
What is the complexity level of your interactive needs? Will you require database technology?
What kind of scope will your interactive element(s) require? In other words, are you providing a small feature for a few people (poll on a Web page) or a complex feature for thousands (portal site management).
If this seems like a list of tall orders, you're right. That's because the majority of time wasted, frustration for you and your clients, and an inability to achieve a given goal all usually come about from improper planning. In the case of application languages, which can provide any of the interactive features you require, the questions have more to do with setting up a system than achieving the interactivity. Whether you use ASP on an IIS server to create your interactive game or use Perl/CGI on an Apache server to create the game, you'll get the results you're after.
The critical thing to remember about server-based interactivity is that it is considered to be more stable, more interoperable, and more browser-compatible than browser-based techniques. This is because all the processing is done on the server side, with the browser interpreting only the results, not the scripting itself.