If you have your own website, or are thinking about building one, you may have a lot of different idea about what kind of content you want to publish, and also what level of user interactivity you need. Maybe you want to build a straight-forward content site (like this one, for example), which most provides text, images, and video. Or perhaps you want a more app-like experience, with lots of interaction. This article covers some of the things you need to know in order to build an interactive, dynamic website.
The world wide web was originally designed as a way to share and link documents. Text was considered central, images secondary, video more or less unheard of. Interactivity — the kind found in desktop applications — was simply never considered.
This, of course, is no longer the case. Web sites have become graphics heavy, video reigns supreme, and many people use web-based applications — email, document editors, games, social media — as much or more than “traditional” desktop applications.
But it is important to know (at least a little) about how the web was originally designed, because it helps explain why things are the way they are now — and helps you understand how to build interactivity into your own site.
First we’ll cover a little of the history of web interactivity. This is important to know because sometimes you will hear or read suggestions to use a particular method or technology. If you’ve never heard of it, it might sound new and great. But if you know that it went out of fashion ten years ago, you can avoid it. (You might be surprised at how many people are still out there, using and advocating for decades-old technology.)
Then, we’ll look at some of the newer, up-to-date technology for adding interactivity to your website. Finally, we’ll explore some of the actual tools you can use for implementation.
Contents
Web History — Static Pages and Early Interactivity
As mentioned above, the world wide web was originally a web of documents — primarily text files, with some (but not many) images.
The primary protocols (communication methods) for connecting your computer’s web browser to a web site were built around this idea of documents:
- your browser sends a request (the URL) to the server
- the server sends back to the browser the page that that was requested
- everything stops until the next request
This procedure — which is still mostly how the web works — does not lend itself to highly dynamic, desktop-style applications.
First generation dynamic website technology
Because of this static “document-orientation,” the first wave of interactive technologies all felt like they were “tacked on” somehow, like they were smashed onto the web.
Common Gateway Interface (CGI)
If you have any familiarity with PHP or other server-side scripting, you already sort of understand how CGI works. If not, it isn’t hard to understand.
Common Gateway Interface (or CGI) was a way to make websites dynamic on the server. It worked like this:
- on the server, there is a directory identified as the CGI directory (usually labeled
cgi-bin - in the CGI directory is a bunch of mini computer programs, or pieces of programs, called “scripts”
- when a request was made for a URL corresponding to one of the CGI scripts (
http://example.com/cgi-bin/hello-world.bin), the script would be run - whatever the effect of running the script might be would happen (usually reading and writing to a database)
- the output from the script would be sent back to the browser as if it were a regular document
CGI scripts could be written in a handful of languages. C and Perl were both very common.
This provided a way to build dynamic websites — websites that would respond to the user in one way or another, or that had the potential to be different for every viewer. Since the document that was returned to the browser was generated on the fly by the script, the document viewed by each visitor could be personalized, updated, or unique in any number of ways. Additionally, many individual scripts could be written all together to form a large application, such a Content Management System.
CGI has largely been replaced by PHP and other modern web scripting languages and tools, but the basic idea underlying it hasn’t gone away.
Java
Java is one of the worlds most popular programming languages and applications platforms. Java is, literally, everywhere. It is commonly used in devices, kiosks, stand-alone equipment, and desktop environments.
Part of the reason for its popularity is that is highly portable. That means that it works on a large number of systems, and it is easy to move a Java app from one system to another.
Because of that portability, it seemed like a natural fit for building client side applications for the web.
A client side application is an app that runs in your web browser (the client) rather than on the server. CGI was a server side technology — it worked on the server and sent back static pages. Java, and other client side technologies, ran locally. This provided a way to build more app-like interactions, including games and other highly-interactive experiences.
The problem with Java is that it isn’t exactly “native” to the web, or to web browsers. This led to several shortcomings:
- You needed a special plugin on your browser to run the Java app.
- The contents of the Java app were not searchable by search engines.
- When you ran a Java app, you were basically running a full-fledged computer program in your browser. This made it susceptible to viruses and other forms of attack.
Flash
Flash was an attempt to build an application platform similar to Java, but more native to the web. It became very popular, especially for games — in fact, it is still used for games. But it has fallen out of fashion for most other uses.
Flash had most of the same problems as Java — the need for a plugin, the lack of search-engine support, and the general security hazard.
Flash and Java and Web Protocols
Both Flash and Java (and a few other competing technologies) were built like bolt-ons to the way the web was designed to work. Basically, instead of returning a document or image file, the server would return the files needed to run a Flash or Java application. If you had the right plugins, they would just work — but if they didn’t, your browser couldn’t make heads or tails of them.
Web Interactivity Today
The last decade or so has seen a focus on web standards — designing and building sites and applications for the web that conform to agreed-upon conventions and philosophies. Along with that focus has come a number of technologies for better handling client-side scripting. At the same time, better server-side tools have emerged, and the two have side of the coin have become more tightly integrated.
HTML 5
HTML — Hypertext Markup Language — is the language of web sites. Originally conceived as a simply a way to prepare and present text documents for the web, it has expanded a great deal.
The latest version of HTML — HTML 5 — includes provisions for embedded media and dynamic, interactive content.
CSS
CSS — Cascading Stylesheets — is the language used for defining how HTML documents should look when displayed in the browser. A CSS file might specify the color of the page background, the font, or the size of various images.
As the language has developed, it has gotten a lot more complex and sophisticated. In addition to document styling, it provides a number of tools for handling interaction. For example, CSS can be used to animate web page elements and move them around the screen, resize them, or otherwise manipulate them.
JavaScript
JavaScript (which has no real connection to the Java language mentioned earlier) is a (mostly) client-side scripting language that allows you to write scripts (computer programs) which run inside the web browser.
Web browsers have had JavaScript capabilities for a long time. But early on, JS was just used for low-level interaction and cheap tricks. The language has evolved into a full-fledged programing language, and can now be used to build fully-featured applications.
JS applications are native to the web browser environment, and are are tightly integrated with HTML documents. These features overcome the limitations on other client-side application platforms.
Server-side scripting
A number of server-side languages have developed and evolved since the bad old days of CGI. Some of them are web-specific. Others are more generalized, but have web-facing components.
- PHP
- Python
- Ruby
- Perl
- JavaScript (via Node.js)
AJAX
AJAX isn’t really a technology as much as it is an idea — a pattern for designing web applications.
AJAX stands for “Asynchronous JavaScript and XML.” It works like this:
- You have a website open on your browser, with a JavaScript application running on the page
- Without reloading the page (that is, asynchronously) the JS app sends a request to the server
- The server sends back data, rather than a full document. The data was originally usually XML (hence the name AJAX), but today it is more likely to be JSON.
- The JS app parses the data and updates the currently displayed page, without the page every reloading.
It is said to be “asynchronous” because new content can be loaded into a page at a different time than the page is loaded into the browser.
AJAX-style interaction drives many of the web applications you probably use all the time — Facebook, Twitter, GMail.
How to use these great new tools
It’s one thing to know about all these different tools, but how do you actually implement them into your own website? There are several sets of tools that can help.
Content Management Systems
A Content Management System, or CMS, is a web application that allows you to easily manage a content-driven website. It usually includes:
- an admin application for adding and editing content
- a database for storing content
- a templating system for displaying content to visitors
- a plugin system for adding functionality and new featues
The larger, more popular CMSes have huge collections of plugins to choose from, many of which provide rich, interactive experiences for users.
The most popular CMSes are:
Frameworks
If you can learn code a little, application development frameworks provide a way to jumpstart the building process for a unique, interactive web application. They provide a “skeleton” app, which you flesh out by adding the specific features and defining data organization.
Frameworks are language specific.
- PHP
- Ruby
- Perl
- Pyton
- Javascript
Front End Frameworks and Libraries
Front-end frameworks and libraries help you make use of in-browser technologies to create interactive web applications. They all use some combination of HTML, CSS, and JS.
- Design and Interaction
- Application Features
- Templating
Summary
The web has come a long way in the last decade. Many of the tools for interactive web development that were current just a few years ago have become obsolete, while other things which were considered low-powered “toys” have evolved into full-fledged, serious tools.
Today using CMS plugins, or applications development tools, you can build a highly interactive website that will keep your users engaged.