Lesson 1

Any communication can be separated into the message (the content of the communication) and the medium (plural of media, including such items as a newspaper, a compact disc, word of mouth, or a Web site). In the previous module, you were introduced to the message elements of a website, the first three layers of the Web Interaction Model:

1. Signs and Metaphors, where the user interprets the message of a Web site;
2. Information Architecture, the architecture that structures the navigation through the message; and
3. Software, applications that enable the design and support the storage of files necessary to the site.

This module discusses the Web Interaction Model as a framework for understanding the two remaining layers of the model:

1. Networks and Internet and,
2. Physical Hardware.

These layers are the media over which the message is sent and the physical components required to send and store the message and associated data. You will also learn about some of the protocols by which networks communicate, as well as how businesses are using the Internet to leverage the power of Web-based applications.

The Web Interaction Mode aligns with concepts from web design and user experience theory, but it is not a universally standardized framework with a fixed set of layers like, say, the OSI model for networking. However, based on this distinction between message (content) and medium (the means of delivery), we can evaluate whether the three layers 1) Signs and Metaphors, 2) Information Architecture, and 3) Software could map to this idea and represent a reasonable breakdown of web interaction.

1. Signs and Metaphors: This layer focuses on how users interpret the message of a website through visual cues, symbols, and design elements (e.g., a shopping cart icon for purchases). It’s about the content as perceived by the user—how the message is communicated through interface design. This aligns well with the "message" aspect, as it deals with meaning and interpretation.
2. Information Architecture: This refers to the structure and organization of the content, enabling navigation and access to the message. It’s less about the message itself and more about how the medium facilitates interaction with it—think menus, sitemaps, or page hierarchies. It bridges the message and the medium by shaping how content is delivered and explored.
3. Software: This layer includes the applications and systems (e.g., servers, databases, coding frameworks) that power the website, store files, and make the experience possible. This is squarely the medium—the technical backbone that supports the delivery of the message but doesn’t define its content.

These three elements cover key aspects of web interaction: 1) user interpretation (message), 2) content organization (message-medium bridge), and 3) technical delivery (medium). However, some models might include additional layers, like User Experience (holistic interaction) or Hardware (physical infrastructure), or they might frame these differently (e.g., combining Signs and Metaphors with Information Architecture under a "Design" layer).
They are a solid conceptual fit for analyzing web communication, though not necessarily the only or first three layers in every possible model.

By the end of this module, you will be able to:

1. Explain the setup and purpose of the Internet, intranet, and extranet.
2. Explain TCP, IP, HTTP, and FTP protocols
3. Explain how Web resources are transmitted across the Internet
4. Describe components of the hardware layer
5. Use the Web Interaction Model to explain how resources are requested and received via the Web
6. Explain how the Web-based business applications are supported by the Web Interaction Model

In the next lesson, you will learn the distinctions between the Internet, intranets, and extranets.

A Web interaction starts with a client program establishing a network connection to some server. At the low level this is done via sockets with the TCP/IP protocol. Perl does support socket programming directly (see below), and the module Net contains functions to allow a program to follow TCP/IP (as well as many others Internet protocols, such as FTP, DNS, and SMTP). On top of sockets and TCP/IP for basic data transfer, the HTTP protocol dictates the structure and content of messages exchanged between client and server. Rather than deal with all these technologies individually, the LWP::UserAgent module allows the programmer to manage all client-side activities through a single interface. A simple client script would look like this:
Perl LWP::UserAgent module

use LWP::UserAgent; # imports other
modules too
$client = new LWP::UserAgent();
$acmeReps = new URI::URL('www.cplusoop.com/
reports/index.html');
$outHead = new HTTP::Headers(User-Agent=>'MyBot v2.0', 
Accept=>'text/html');
$outMsg = new HTTP::Request(GET, $acmeReps, $outHead);
$inMSg = $client->request($outMsg);
$inMsg->is_success ? {print $inMsg->
content;} : {print $inMsg->message;}

The network connections and message formatting to HTTP protocol requirements is handled transparently by the LWP functions. Here, the client causes a request like this to be sent to the Web server at www.cplusoop.com:

GET/reports/index.html HTTP/1.0
User-Agent: MyBot v2.0
Accept: text/html

If the requested file is not there, the response from the server will be an error message. If it is there, the response will contain the HTML file for the bot to process in some fashion.