The Active Web
short glossary and links

Alan Dix
email: alan@hiraeth.com

download onCue now - it's free!

This is a short glossary and links list to supplement my articles on the Active Web:

Alan Dix (1998).
The Active Web - part I. Interfaces, 38 pp. 18-21. Summer 1998.
The Active Web - part II. Interfaces, 39. Autumn 1998 (to appear).
http://www.hcibook.com/alan/papers/ActiveWeb/

See also:

Contents


CGI - Common Gateway Interface

The standard way to include programs (usually called CGI scripts), including processing of HTML forms. CGI is transaction-oriented as a request is passed to the server which then responds with a web page. For rapid interaction a client-end program is required in JavaScript, VBScript or Java. Alternatively you can use one of the downloadable plug-ins like Shockwave.

Do note that there are small differences between the way servers pass values to the CGI scripts and also in the way you tell the server what is a valid script.

Be very careful too when you write CGI scripts as it is easy to open up security holes in your web server!

Perl

The language used in many CGI scripts because of its powerful string handling capabilities. It has a syntax derived partly from C and partly from UNIX shell and the Awk report language. Not really for the programming novice, although it is possible to get many standard scripts from web resource sites and even tweak them slightly.

Java

Well you can't have missed Java! Originally developed by Sun for embedded applications (programs in your hi-fi and washing machine), but known by most for its use in applets and in general Internet hype.

The only portable way to include interactive graphics, but requires real programming.

Actually applets are not that well integrated into the web. Most simply sit in a portion of the web page doing their own thing in blissful ignorance of the rest of the page. It is possible to communicate between web page form elements and applets, but this is rarely seen.

JavaScript

Introduced by Netscape to allow interactivity at the client-end. Perhaps the simplest way to get into interactive web pages as the code is simply included within tags in the web page and small amounts of JavaScript can be added to add small amounts of extra functionality.

JavaScript is also the power behind Dynamic HTML.

WARNING - JavaScript tends to be buggy in many web browsers and also varies slightly between browsers. In particular, there are differences between Microsoft's JScript and Netscape's JavaScript. However, help is on the way ... there is a new ECMA standard for the language called ECMAScript. New versions of browsers should support this and thus become compatible ... for a while ...

VBScript

VBScript is a subset of VBasic which is understood by Internet Explorer. I is not understood by non-Microsoft browsers and so JavaScript (depite its problems!) is a better bet for general Internet pages. However, it would be suitable for Intranet applications where you can be sure of that IE will be used as the browser.

Dynamic HTML

This allows pages to be laid out DTP style, but also to change that layout and content interactively using JavaScript, JScript or VBScript.

Actually Dynamic HTML is a combination of JavaScript and the 'Document Object Model' (DOM - that is, how the browser represents a web page to JavaScript) and Cascading Style Sheets (CSS - which say how elements such as headings should appear). Unfortunately, the DOM was different in Netscape4 and IE4, so DHTML pages have to be written for one or the other, or be very carefully written to work with both. Happily, there is a standard for DOM and CSS which should be used in future browsers.

W3C - World Wide Web Consortium

The official World Wide Web specifications!

Real Audio & Video

The de facto standard for sending streaming audio and video over the Internet. It achieves acceptable performance by heavy compression (especially of video) and also using large buffers to reduce the effects of jitter and frane loss.

CU-SeeMe

Live desktop video conferencing over the Internet developed by Cornell University. Unlike real-audio & vieo, CU-SeeMe must transmit video and audio in real-time and cannot be buffered more than a fraction of a second. The consequence is that frames may be lost or arrive late. This is acceptable for video, simply meaning that the picture occasionally breaks up or freezes temporarily. For audio it is more significant as parts of the conversation may be lost. Because of this, CU-SeeMe allows both audio and text-based communication. Many CU-SeeMe users use live video, but text for actual communication.


http://www.hcibook.com/alan/papers/ActiveWeb/aw-links.html
Alan Dix 31/7/98