Writing
Student Papers for the Web
A Beginner's Guide
By
Ross F. Collins, Ph.D.
Associate Professor of Communication,
North Dakota State University, Fargo
Table of Contents
I. Getting out of Line:
An introduction to student web-based projects.
II. Tiny ships in a vast sea: Non-linear thinking.
III. Web sites and apple trees: Planning your pages.
IV. Cut a plank of HTML: Learn simple coding from scratch.
V. Picking up the apples: Putting it all together.
I. GETTING OUT OF LINE
WELCOME TO THE WORLD of Web-based writing. We're pleased you have decided to
join in, but feel obligated to fairly warn you: you are about to enter a creative
world perhaps unlike anything you have likely encountered before in your assignments.
Beyond is a vast sea of information. You must navigate through this new medium,
and eventually, add a cup of your own material to it. You have no guide. You
do have maps and charts. You do have your own skills: ability to read, to write,
to find information. You'll need them, and more: ability to execute simple designs
and computer code. And you'll need to develop understanding, ability to navigate
through a new way to gather and present knowledge. It is an exciting, yet demanding
world.
And in return? Perhaps nothing less than your ticket to a place in a future
of human knowledge unlike the world has ever seen before. The plane is already
pulling back from the gate. Do you want to join now, or risk being left behind?
Why the Web is different
To understand the real potential of the Web as a learning tool, we have to think
a little about how we usually acquire formal knowledge. Books and class lectures
are designed to present information sequentially, in an order selected by the
presenter. You sit in a media class, and I tell you what I think you need to
know, beginning with point A and on to point Z. There's no way to fast-forward
a lecture, even if you've already heard points F and G in another class. As
well, there's no way to pause on point Q, say, for more information to satisfy
a little extra confusion or curiosity you may have there. Television and radio
are similar, offering a sequential presentation of material. Sure, you can record
and play presentations again, but sequence is basically the same.
Similarly, book authors present materials in a sequence controlled by the numbered
pages. While some modern publishers have tried to offer non-linear "points
of entry," so you can jump into the book at any point, still you have no
immediate resources beyond the text itself, presented pretty much in a linear
way from intro to conclusion. What's exciting about the multimedia environment,
and in particular the World Wide Web is its non-sequential presentation of information.
Pretend you've just moved to a new city, and know absolutely nothing about it.
You begin by taking a walk, looking at the buildings around you, hearing the
traffic and the voices, reading the signs.... You consult a map, greet some
neighbors, take a tour, find the essential conveniences.... And using all your
senses in many ways you gather information about your new home, taking from
here and there, choosing from possibilities as your needs and interests take
you.
This, cognitive psychologists contend, is our innate learning style: visual,
active, wide-ranging, quick and non-linear.(1) If we translate that real world
into the world of multimedia, we might build a learning opportunity like this:
• Able to run on a computer.
• Able to call up text, illustrations, ideally movement and sound, that
is, multiple media to appeal to several senses at once.
• Able to allow user interaction, choices on how material appears, and
when.
This means, for instance, that television, while including sound, pictures and
text, is not multimedia, because it's not interactive. A sound and light show
might be a feast for the senses, but because it's not presented by computer,
it's not multimedia. Multimedia offers a learning experience more fun, and more
effective, because like walking in town, you become an actual participant instead
of a passive listener. (2)
How the World Wide Web fits into multimedia
The web is just one of many protocols by which computers can communicate, and
it's not even the first one. Some decades ago, in an era dominated by mainframe
supercomputers, a few researchers thought out a new, revolutionary idea. Why
not link many small computers to share computing capabilities and together meet
or surpass the power of one giant?
One famous episode of television's "Star
Trek: the Next Generation" required the good starship "Enterprise" to battle a most formidable foe: the Borg. The immense Borg battleship actually
was a force of combined computer-like beings, each one linked to cooperate in
a force of irresistible power. Defeat came only by planting a computer error
into the system.
Whether or not our own immense Borg of the internet could be defeated by similar
means is perhaps futurist fiction, but the fact is that today anyone connected
to the network can tap into an incredibly powerful network of information. Geography,
time mean nothing: a database held in Japan is as close to our screen as a web
site at North Dakota State University. Only traffic or our own slower modems
add seconds, perhaps, but not days or weeks to our search.
How we transmit this material depends on the protocol we use, and on the importance
of preparing our computer to send and receive information. A program on our
machine, called the client machine, may connect to any computer offering material
of interest to the internet, called the server machine, by way of a number.
Computers like numbers; we like words. So we address our request in "domain
names" such as:
http://ndsu.nodak.edu
A program called the Internet Domain Name System translates those words into
Internet Protocol (IP) numbers to find the address of that server, such as
134.129.134.10
The address we humans can read is called a Uniform Resource Locator (URL).
The server can transmit information by many means. Some of the older and most
familiar are FTP (File Transfer Protocol) and, of course, electronic mail. One
thing is missing here, however: the multimedia of pictures, sounds, and interactive
pages.
The World Wide Web was actually invented by Tim
Berners-Lee in the CERN labs in Switzerland as a way to transmit research
information around the world by computer. Multimedia was not really the concern:
what was needed was some sort of standardized way to transmit information to
discrete computers built on all sorts of different formats. The solution was
called Hyper Text Markup Language (HTML),
part of a larger language called Standard Generalized Markup Language (SGML).
Picture yourself as an editor, preparing copy for a printer. You want some words
boldface, some as headlines, some as italic, space to insert a photo, and so
on. To indicate this, you use shorthand terminology such as bf, ital, 24pt,
slug, etc.
HTML shorthand tells a computer generally how a document ought to look. Using
standardized commands that can be read by a web browser (Netscape and Internet Explorer are most common), a server tells a computer how to draw the document. But it
doesn't actually render it for our us-that's up to our own machines. It's as
if I told you how to draw a picture, but didn't touch the pen myself. Common
commands in HTML language are called tags; you're tagging text with suggestions
to a receiving computer on how a document should appear.
Along with this, HTML coding can tell your computer to do other things-such
as how look for other files containing pictures and sounds, and how to display
them. It can also offer opportunities to easily call up more information from
other sources, that is, links to other servers. Your computer and web browser
software dutifully render the results by reading the HTML.
So why, when you call up a pretty colored computer file we've nicknamed "home
page," do you not see a clog of ugly coding? Ah, but you do--it's only
masked by the browser's response to the commands. One HTML expert compared it
to the old horror movies where the seductive beauty rips off a mask to reveal
a hideously misshapen face. Like the monster, the web wears a mask, a pretty
picture over an ugly truth. To rip off the mask from a Netscape-rendered home
page, for instance, merely choose View and Page Source from the pull-down menus.
(Choose Source from the Internet Explorer View menu.) Horrors. What gibberish
behind such a pretty web site.
You'll be learning to write simple gibberish in this guide, at least the simple
amount you need to produce a Web-based term paper or article. But writing using
Web concepts won't be like producing a stunning web page. We're sticking to
basic functions offered by the web, and if you want to reach farther and farther
into the technology, you can find all sorts of tutorials in the bookstores or
actually on the web. You also can select a web-writing program such as Dreamweaver,
or even a word-processing program, to do it for you. You can learn to add splashy
graphics and handy forms using Javascript or Flash. But here we begin by learning
to crawl: despite all these great tools, a web author still needs to understand
good old serviceable HTML, the language that started it all. We'll do a bit
of that below.
Notes
1. Sueann Ambron and Kristina Hooper, eds., Learning with Interactive Multimedia. Redmond, WA: Microsoft Press, 1990, 194.
2. William Gates, "The Promise of Multimedia." The American School Board Journal 180:3 (1993), 35; William E. Halal and Jay Liebowitz, "Telelearning: the Multimedia Revolution in Education." The Futurist 28:6 (1994), 22.
II.
TINY SHIPS IN A VAST SEA
THE FIVE LITTLE WOODEN SHIPS, wrought on medieval building techniques but resting
on a Renaissance ideal, sailed from Sanluca de Barrameda in the fall of 1519.
Navigator Ferdinand Magellan
reached South America, rounded the stormy cape now named in his honor, and came
about to face--infinity. A vast, placid sea of unimaginable size, breathtaking,
daunting, a shining sheet reaching beyond the horizon. Two whole months' of
sail took the starving and exhausted sailors to their first sign of land, Guam.
The world was indeed bigger than any medieval mind had believed.
Today the physical world seems so much smaller, yet when we sail out after knowledge
using the internet as our sea, the vastness is an exhausting mental challenge.
An on-line web workshop(1) once reported a computer data firm's research showing
that in 1985, the number of documents in the world was doubling every five years.
By 1989, the amount was doubling every three years. In 1991 they doubled every
year, and in 1994, they were estimated to double in nine months. Pages on the
web may be doubling even faster-I can't keep up. I don't think anyone can. Google the doughty search engine tries: in September 2002 it reported its ability to
search 2,469,940,685 web pages. What must it be today?
Everyone who has jumped into the web for a ride knows how quickly the hours
can tick by as screen after screen of colorful text and links pass our tired
eyes. We call up one page, then click an intriguing link to another page, then
to another, and yet another colorful scene, a mesmerizing parade of text and
images we call net surfing. It's informational inundation like trying to drink
from a mug under Niagara Falls. And at day's end? Little to show for our glutted
mind.
This is the challenge of the dawn of a Web-based age of information, the vast
sea of knowledge through which we must navigate. Metaphors of seas and waterfalls,
or highways and surfers, seem to be the only way we can explain the terrifying
excitement of this ocean at our keystroke, yet perhaps it gives us some feeling
of what students are up against. It is ironic that on the one hand we welcome
the non-linear aspect of multimedia education, and yet on the other hand, we
can let it drive us to stupor. Let's try yet another metaphor. Back to our walk
in a new city. Let us suppose that the new city was Cairo.
A first walk in this ancient crossroads of civilizations is a sensorial assault:
flying taxis, roaring streetcars, aggressive shopkeepers, the swirling colors
and dust of multitudes crammed through narrow streets. After the first shock
one may be tempted to retreat back gasping into the hotel. But slowly we learn
to find our way through.
Turn off the computer
We said that the non-linear aspect of multimedia learning appeals to our natural
tendency to pick up information interactively, using all our senses. It seems
that to organize your multimedia-harvested research for your own writing or
Web page design, however, requires some means of controlling the itching clicking
finger. Otherwise, you can too easily ricochet off your main topic and onto
interesting, but ultimately irrelevant, tangents.
A first step is to turn off the computer. (Um.... After printing this guide, perhaps.) Why? Because you need to pull together a plan. Think about your topic,
about ways you can refine your research, to ask specific questions. Similar
to looking up very general questions on a library's computer card catalog, inputing
very general terms to a Web search engine will pull you off on a chase far from
the information you need. Because Web pages offer so many distractions, some
of them helpful, some of them not, you need to hold onto a clear focus of your
topic question as you dive in. Write a paragraph to help you focus, if necessary,
and to help you settle on a research question. It may still be somewhat vague
at this point, but the more specific you can be, the easier you will be able
to control the glut.
All right, now turn on the computer. Navigate first to what is an old and familiar Web search aid, Yahoo:
www.yahoo.com.
Yahoo offers to search by topic, somewhat like a library card catalog. It's
called a database searcher, because someone has gathered the sites for you to
look through.
On the other hand, some searchers launch a search on request for Web pages which
contain that topic, whether or not they're part of an index. Try everyone's favorite,
www.google.com. Or my favorite, www.dogpile.com.
As you find pages and links, scan for information germane to your topic. Follow
links as you think they may have a bearing: part of research is serendipity,
and the Web makes it so much easier than following written footnotes.
You'll probably want to copy material you may find useful. Avoid copying too
much, as it becomes as dreary looking back through it as it might looking through
page after page of photocopied articles from the library. In fact, some find
it's better to open a word processing program and take on-line notes, toggling
between the word processor and the Web page. In fact, I use the medieval method
of scratchings on parchment, I mean ballpoint on notebook, to keep track of
notes. You can always call up the pages again, if necessary. Keep track of URLs
in your notes, or in your Web Journal (see below).
A knotty problem students face using the web is the quality of information.
While the credibility of sources is certainly worth careful consideration in
traditional library research, information there usually has been screened and
edited by a publisher. You can put confidence in material offered by a publisher
known for high standards, whether it be a scholarly journal or nationally-respected
organization.
A web page can be thrown up by anyone, anywhere, often without any editing filters
at all, and because companies are in such a rush right now trying to build a "web presence," the quality of their material might be lower than
in published sources. Generally you can use anyone's web material to help point
you in the right direction, to help spark your ideas, but you can only use web
material from legitimate and well-known sources in your final paper. Anything
less, and you run the risk of producing an argument you can't easily defend
by resting on information from an expert.
However, the WebPaper concept asks you to look at footnotes differently. Instead
of footnotes, you provide links. We'll talk about the mechanics of that below.
Note
1. Thomas P. Copley and Barbara L.Copley, "Make the Link" workshop, Tutorial Number 5/1, by e-mail, 1995.
III.
WEB SITES AND APPLE TREES
WE'VE TALKED ABOUT how people learn non-sequentially, gathering information
from several senses, somewhat at random, like a kid kiting apples from a tree.
I like the apple tree metaphor because it helps me to plan the concept of web-based
writing. Some students begin a standard writing project by preparing an outline
of points they wish to cover, and write based on this rather formal checklist.
Others just start writing and see where their words lead them, checking for
accuracy and comprehensiveness during the editing and polishing process.
Producing student web-based writing, what I like to call the "WebPaper," borrows from both these concepts: on the one hand, you need structure, but on
the other, you need room to explore. Here's where the metaphor of the apple
tree comes in. If you draw a tree trunk at the bottom of a large piece of paper,
you can picture it as a sturdy support for all the branches and fruit above.
Going out from the tree are branches of various sizes, some holding many apples,
some holding only one. The branches may stray into other branches, and from
there into yet other twigs, but eventually they all can be traced back to the
main trunk.
You already see where I'm heading here, right? The trunk is your main topic,
or your home page. This page forms the base from which a reader can navigate
around the tree, around various sub-topics under your main topic, while never
losing sight of the basic structure at the bottom. This gives your reader the
opportunity to explore and catch apples of information somewhat at random, but
still attached to a trunk for support when necessary.
Let's take an example. If you call up, appropriately, the "Minne-apple's"
home page www.minneapolis.org, you'll find a delightful display of opportunities
to explore the city through its web site. Click on the index bar or fuzzy disk
to find more specific information. From there, you again often have the opportunity
to click on another index for further information. Or you can go back to the
original home page, the "trunk," by choosing "back" from
the menu bar, or the Minneapolis logo at the top. Other choices bring you information
on the city weather, advertisers and promotions. Or search for information from
the search box.
So you can go to various branches of the tree to bring home the apples that
look most interesting. But it's always clear how to get back to the original
trunk, where you can begin again for more choices.
Try to think of your WebPaper like this "Minne-apple" home page. You
want to give your reader a variety of starting options, a variety of links,
but still a good solid idea of where he or she has been and how to get back
there. So try to place sub-topics on your pencil sketch as places readers can
go by clicking from your main page. From these you can branch off more sub-topics
as seems logical. Some sub-topics may also be linked to other topics, as you
see connections. Write those possible links down also. (Note: URLs are case-sensitive,
so be sure to copy exactly.) Leave plenty of space so that you can fill in more
links to other URLs, more of your own material, photos, etc.
This offers a first step to help you find your way as you do research, so that
you yourself can think in a non-linear way about your topic presentation. That's
pretty different from the way we've been taught to write, each topic handled
as part of a sequential whole from beginning to end. Providing this new kind
of logical but non-sequential guide is called information mapping.(1) We try
to begin by offering information viewers can relate to, perhaps arranged in
a familiar way, leaving openings for the new discoveries, and occasional side
trips. If you've ever done a storyboard for a video advertisement, the concept
is a little bit the same.
Clustering the apples
As you add possible links on the tree, it's sometimes helpful to work fairly
quickly, without great deliberation. This "clustering" style (2) helps free your right brain creative energy to new possibilities you
may not have thought of. Don't worry about making it messy--you can always cross
out or copy the tree over again. It's just for your own use. But there will
come a point of closure, when you instinctively feel you've gone far enough
with the sketch and now are ready to gather more information to fill in the
hollow of ideas you've set up.
At this point most term paper research students will have to begin by relying
on that old-fashioned, linear-based library. The time may come when every journal,
every magazine, every book, every newspaper article will appear on a web server
somewhere. It's not here yet, and in fact some of your information probably
will still have to start from the dusty stacks. So begin your WebPaper by perusing
library sources, gathering as many notes and information as you believe necessary
for a strong information base. As you take notes, try to think of key concepts
as possible links, items to add to your tree and to serve as a key word for
a web search. Look for illustrations, too. While it is NOT legal to actually
publish someone else's copyrighted art as a web page without permission, it
is okay to use it as part of your WebPaper submitted as a class assignment.
If you want to actually launch your WebPaper on a server, however, you'll have
to either remove these photo links, get permission, or find copyright-free downloadable
illustrations on line.
Notes
1. Ronald D. McFarland, "Ten Design Points for the Human Interface to Instructional Media." Technical Horizons in Education Journal 22.7 (1995), 67.
2. For more on clustering as a creative, non-sequential tool for writing inspiration, see Gabriele Lusser Rico, Writing the Natural Way. Los Angeles: J.P. Tarcher Inc., 1983.
IV.
CUT A PLANK OF HTML
BASIC HTML IS A PIECE OF CAKE, which is why everyone and her brother seems to
have a web site nowadays, and why you can choose from a bevy of software, some
of it free, to make pages for you. As this WebPaper or web design class is designed to help you
learn the concepts of web-based, non-linear communication, however, we're going to present HTML in its pristine
form. That is, actual coding.
I like to build things out of wood. To build a project, though, often I need
some simple homemade tools to help me get square joints, straight cuts, and
so on. The things I build to help me make other things more easily are called
jigs. Tacking together a jig not only gives me a useful item, but it also helps
me improve my woodworking skills on practice jobs where mistakes aren't so critical.
As a first project, I'm offering you the opportunity to build a jig to help
you navigate the web. This jig is designed to offer a solution to a frustrating
student problem: keeping track of URLs. As you become more accustomed to web-based
learning, you find yourself collecting site addresses you'd like to remember.
A well-done page, a useful database, a cool site you stumbled upon in the process
of clicking links might well be worth re-visiting. If you can remember where
it is, that is. Now, some people can memorize long lists of URLs for just that
reason. (Well, I assume some people can, though I've never met anyone like that.)
For those of us who can't, Netscape and other web browsers offer a "bookmarks" or "favorites" function to collect URLs. But if you're used to using different machines as
available in public clusters, the bookmarks won't travel with you. In any case,
bookmarks don't give you great flexibility to catalogue your personalize your
URLs by date or subject, and add your own comments concerning their contents.
Wouldn't it be nice to have a personal address book of URLs you can carry and
click on any computer? Well, why not build your own genuine URLJig? (Patent
Not Pending.)
To begin, remember that HTML is merely vanilla-flavored word processed text,
that is, word processing saved as an ASCII or "Text Only." You can
use any word processing program; BBEdit is popular with professionals. But you also can compose
HTML in most work processing programs, and save as "Text Only."
Okay, we all know you can also save a Word file as a web page, or compose the
page in Dreamweaver, or Adobe InDesign, or WebWhatEver,
BUT: we're here to learn basics of web-site production. Do you want to
become a savvy web-slinger, or do you want to keep limping on crutches someone
else threw together for you? What happens when your web page won't render the
way you want? You strip away that pretty mask we talked about above and--now
what? A bunch of computer-like code. Fear not, you'll need no crutch. You learned
beginner's HTML right here, right now, right?
Your own really simple URLJig
On BBEdit or a word processing program, open a new document, and type or copy
and paste the following:
<html>
<head>
<title>My Web Link Directory</title>
</head>
<body>
<h4>Regional Interest</h4>
<ul>
<li><a href="http://www.ndsu.edu/communication"> NDSU
Communication Department.</a>Everything I need to know about NDSU comm.,
and a few bad jokes.
<p>
<li><a href="http://ndsuspectrum.com">NDSU Spectrum on
line.</a> The <em>Spectrum</em> in a handy form to read when
I'm away on important business trips....</p>
<p>
<li><a href="http://www.minneapolis.org/">
Minneapolis web site.</a> Lists coming events, restaurants, maps, etc.
Nice inviting site for America's coldest major metropolis.</p>
</ul>
</body>
</html>
This is an excerpt from my own URLJig, that is, my web journal. After writing
the above, save to a your disk in a separate text-only file, called
myjournal.htm. (Note you have to have save it with an htm or html file extension.) All
quotes and apostrophes must be straight ("rabbit-ear") style; curly-cue
(typographer's) quotes we use in published material are not recognized as html
code.
Now call up Netscape, Explorer, Mozilla or another browser and choose Open File from the File pull-down
menu. Note that Open Location looks for an URL on a remote server, while Open
File looks for one on your own machine. Choose your own disk,
and open the file you just saved. You should see it displayed as a simple web
page the journal information you entered. Ta-dah! You'll just created a web
page. Try clicking on one of the links. And you
thought computer coding was hard?(1)
Your task is to collect together your own web journal and organize it as you
wish: by topic, by date found, by title. Include comments. Save to a floppy,
and carry with you from machine to machine. It's better than any bookmark function,
and it's as personal as you want it to be. Note that a web page does not have
to be launched on the internet to work. You can build a web page saved to a
disk and send it by mail, or hand it to a professor as, say, a WebPaper.
Dissecting the jig
This coding is about as simple as it gets, but if you understand it, you've
gone a long way to understanding the whole web-page building process. Let's
dissect:
<html>
Tells the web browser you're using Hyper Text Markup Language. Your page will
render without this header, but it's considered good web form to include it
anyway. The < and > brackets must be used for all tags in html. You may
code in capital (HTML) or lower case letters, as the browser is not case sensitive.(2)
HTML tags used to be typed upper case to help them stand out from text, for
easy de-bugging (that is, fixing your screw-ups). Now, however, the World
Wide Web Consortium (http://www.w3.org) recommends XHTML,
which asks for lower case tag pairs and attributes. The new guidelines are designed
to avoid nonstandard markup to make pages more accessible.
<head></head>
Material here directs formatting for the entire site. JavaScript goes here,
but that's beyond this beginning lesson.
<title></title>
What you want your browser's title bar to read. You don't absolutely have to
have this, but it looks sort of amateurish to have your URL displayed in the
title bar.
<body></body>
The rest of the document.
<h4> </h4>
This is a heading style, "H." You may choose from H1, the biggest,
through H6. The slash / indicates that you want that particular tag command
to end now. You can also rely on the browser text size selected by the user,
by choosing <+1>, <+2> etc., or <-1>, <-2> etc., to
indicate bigger and smaller type.
Note that pairs of bracketed tags, the second with the slash, are called tag
pairs, and if you forget one of the two the command may not render or, as in
the case of headings, everything is big.
<ul> </ul>
This sets up an "unordered list," that is, indented, bulleted items.
Each new bulleted item must be preceded by the <li> (list) tag.
<a href="http://www.ndsu.edu/communication">
This is the link reference, the key command to linking your page with other
sites or files. The "A HREF" command stands for Anchor Hyper-REFerence,
telling the web browser to look for the URL surrounded by quote marks following.
Note that the URL in quotes does not actually render (show up on the page),
but any words you write after it and before the closing tag (</a>) will
be underlined and highlighted as a link on the page. When you find a URL you
want to keep, in Netscape or Explorer you can simply drag over it in the Location window, of course, choose
Copy, move to your journal in the word processing program, and Paste.
Note that if your URL won't render, it means you either didn't include any description
inside the anchor tag pair or, a common coding bug, you didn't close the quotes.
<p> </p>
New paragraph, adds a slug
of space between a copy block. When using the <h> heading tag pairs, space
will automatically be added after. Note that some early web site builders (like
me c. 1995) simply skipped the </p> closing tag. While that usually works,
XHTML guidelines indicate closing all tag pairs to assure proper browser operation.
<em> </em>
This points out a key concept of a web page--while you are in effect telling
a machine how to draw the page, you aren't drawing it yourself. Let's say you
want something to stand out in text. That's basically a "strong" rendering
in text, so if you say that with the tag pair, a web browser will interpret
your intent to make that text stand out. Exactly how it interprets your intent
is up to the browser, as it is with <em> </em> for italics. It's
true some browsers do indeed support <ital> or <bold> tag pairs,
but in writing HTML it's usually better to remember the concept of offering
only a guide to the page, and letting the browser choose how to interpret it.
Print designers used to the precise control they have over display of text and
graphics in a layout program such as Adobe InDesign are at first frustrated
that they have to surrender some control over how the page will look in a web
browser. But HTML is designed to run on many computers, with many web display
programs, so the end product inevitably must reflect the user's tastes and possible disabilities. A web
browser may also control display of colors, photos, centering, fonts, etc. This
is not a good job for control freaks.
Here are a few other basic text formatting tags:
<br> Break, start a new line, no space between. No closing tag necessary.
<ol> </ol> Ordered (numbered) list.
<u></u> Underline.
<hr> Horizontal Rule.
<center></center> Centers elements on a page.
Adding images and color
Try backing up to my own, deceptively simple, web site home page:
http://www.ndsu/communication/collins
Choose View and Page Source (or Source) to see the code behind the page. (Note
that this command gives you the opportunity to see how anyone's home page is
constructed. If you see something you like, learn how to do it by copying its
source code.) Somewhere near the top, following a bunch of JavaScript blah-blah, you'll see some
code including:
<body bgcolor=#FFFFFF text=#000000 alink=#3399CC link=##0000CC vlink=#FF0000>
The first series of numbers tells the browser to choose a background color;
the second, to choose a text color; the third to choose an active link color; the fourth,
to choose an inactive link color, the fifth, a color for visited links. Colors are ordered by the Red Green Blue (RGB) additive
color system used in computer monitors and televisions. The first two numbers
indicate red; the second two, green; the third two, blue. FF means full color,
00, black. Numbers can be set from 0 to 255. Nerds call this the hexidecimal
system. I tend to agree with critics who say links should be in standard blue, and visited links in standard red, but it seems like if you choose another color scheme, as long as the link is still obvious, it shouldn't be a problem nowadays. Not many of us are still new to web site navigation.
Try this experiment: call up the source code of your web journal, and write:
<body bgcolor=FFFF00>
Save (you always have to save your changes, or a browser won't render them),
and open your journal as a web page. Wowza! Quick, from high school art class:
red and green make....
You can guess and see with the hexidecimal system, or you can let someone else do it for you at: http://www.w3schools.com/html/html_colors.asp. (Note: this site also is one of many on the net offering a fine tutorial in HTML, part of an extensive resource for webmasters.)
After table specifications (we cover that later in web design class) you'll spot this code snippet:
<img src="rossc.jpg" width="425" height="87"
alt="Ross F. Collins Readings & Resources">
This important bit tells the web browser to look for an image, the source of
which is the file name in quotations. Its size is specified in pixels. The "alt" command makes sense of an image for text-only browsers or disabled
people who use text readers to surf the net. It's becoming more and more important
for people designing education-based web pages to offer handicapped accessible
sites. For more information, refer
again to the incredibly rich World Wide Web Consortium site: http://www.w3.org/TR/WDCAG.
Note the "&" is code for the special character meaning "ampersand."
Best practice is to scan all the illustrations you need
and place them as necessary in their own separate folder (subdirectory) within your web site folder. (Yeh, I know I didn't do this on my own site. But I compare it to Notre Dame Cathedral, that is, built over many years and many styles.) It's important to place all your web site material in its own folder. When you specify a file-based image using
the img src= code, the web browser will search for it in your home-page folder.
The width and height tags size
your illustration (in pixels), and the align tag sets your image on the page.
Keep your images small (chopped down using Photoshop) and they'll render more quickly. Impatient web readers
(and who isn't?) will dump your home page if it takes too long to transmit.
Lots of big pictures slow it down. As for cutlines, HTML itself has
no below-photo captioning capability, so you need to include the descriptions
in the text or in the scanned image.
Most web browsers can read these illustration file formats:
This short guide should be enough to create a simple web-based paper
that taps the non-linear power of the web. Of course, it's just the beginning.
Getting fancy-schmancy is beyond the scope of this class. If you want to learn
more, go to the bookstore, or check out the handy North Dakota State University web development pages: http://www.ndsu.edu/wwwdev/web_team/home.shtml.
Notes
1.Well, real programmers don't really consider HTML to be "code." What, it didn't render? Checklist: a) saved as text only, without formatting? Even if it's formatted as standard courier or times, it won't work. b) Quotation marks all straight ("), not curly? All brackets opened (<) AND closed (>)? SINGLE spaces and slashes (/) copied exactly as shown? HTM suffix? Still doesn't work? Ask the egghead: www/ndsu/edu/communication/collins/egghead.htm.
2. Web page URLs, however, are case-sensitive, remember.
ARMED WITH A LITTLE GENERAL
web background, some authoring tools, some research ideas, and that practice
jig, you're ready to begin your WebPaper. Assuming you have your apple tree
guide in front of you, it's time to write your paper, apple by apple.
Generally you'll begin with an introduction, part of your home page, explaining
your subject and research question to your reader. Try to keep this and other
segments fairly short, about 200-300 words maximum--web-style multimedia emphasizes
information doled out in small bites. If you do have a larger chapter to write,
it's best to break it into several segments, using subheadings and links from
one segment to the next.
Include a table of contents, offering links to other topics on the tree. Include
in your contents a link to your bibliography, and somewhere on the page a link
to your e-mail address, in case someone wants to respond. An e-mail link can
be set up using the attribute <mailto:" "> and your e-mail address
(no spaces after the colon), all within the quote marks of the tag pair.
Save your home page introduction as a separate file, and begin a new file for
each section. Link each of these files on your home page. To link use the anchor
(<a>) tag pair with the file name of your text. Note that the anchor tag
pair can be used not only on text, but on icons or images--just bracket around
any element to make it "hot." While browsers
do include a "back" button that calls back the old pages, it's helpful
if you set up a number of links reaching out on the tree to give readers an
opportunity to link back to the beginning. Some web designers use a "home" link.
As you write your text, it's helpful to think of links, putting together words
and ideas and other web sites or your own separate files with more information.
For instance, you write:
Clearly the influence of John Stuart Mill's harm principle can be encountered in a contemporary illustration from the controversial animated television program "South Park."
The underlined links offer two opportunities for readers to find more information
on each of those topics, either from another home page, or from your own additional
material. You should have at least one link in every ten lines or so. Links may
also serve a footnotes for information you find on the web and incorporate into
your text. To footnote information not found on the web, use social science style
(notes in the text). You MUST footnote your material in academic style document
requiring standard documentation for your statements.
Links can also be set up as separate paragraphs within the text, with short descriptions
on what the link will bring to the reader, such as
For a debate on the power of animated television among pre-school age children, consult the National Association of Broadcasters.
Of course, illustrations are also part of multimedia, and you need to add images whenever you can. As this is a class project, it's okay to scan images from texts, or download them from the net. In real life, though, copyright laws mean you won't be able to actually "publish" that web page on line. Otherwise, check out the free downloadable images through Yahoo or other illustration directories or, best choice, take your own photos and scan them. Tables and graphs can either be treated as images or placed on web pages using more advanced HTML coding.
For more information:
North Dakota State University web design pages: http://www.ndsu.edu/wwwdev/web_team
W3Schools: http://www.w3schools.com
Web design group: http://www.htmlhelp.com/.
Pages that suck: http://www.webpagesthatsuck.com/.
Copyright 2004 by Ross F. Collins, <www.ndsu.edu/communication/collins>
