What You’ll Learn in This Lesson:
A very brief history of the World Wide Web
What is meant by the term web page and why this term doesn’t always reflect all the content involved
How content gets from your personal computer to someone else’s web browser
How to select a web hosting provider
How different web browsers and device types can affect your content
How to transfer files to your web server by using FTP
Where files should be placed on a web server
How to distribute web content without a web server
How to use other publishing methods, such as blogs
Tips for testing the appearance and functionality of web content
For example, a file containing HTML and CSS is useless without a web browser to view it, and no one besides yourself will see your content unless a web server is involved. Web servers make your content available to others, who, in turn, use their web browsers and other devices to navigate to an address and wait for the server to send information to them. You will be intimately involved in this publishing process because you must create files and then put them on a server to make them available in the first place, and you must ensure that your content will appear to the end user as you intended, whether the user has a screen the size of a watch face or a billboard.
Once upon a time, back when there weren’t any footprints on the Moon, some farsighted folks decided to see whether they could connect several major computer networks. We’ll spare you the names and stories (there are plenty of both), but the eventual result was the “mother of all networks,” which we now call the Internet.
Until 1990, accessing information through the Internet was a rather technical affair. It was so hard, in fact, that even Ph.D.-holding physicists were often frustrated when trying to swap data. One such physicist, the now-famous (and knighted) Sir Tim Berners-Lee, cooked up a way to easily cross-reference text on the Internet through hypertext links.
This wasn’t a new idea, but his simple Hypertext Markup Language (HTML) managed to thrive while more ambitious hypertext projects floundered. Hypertext originally meant text stored in electronic form with cross-reference links between pages. It is now a broader term that refers to just about any object (text, images, files, and so on) that can be linked to other objects. Hypertext Markup Language is a language for describing how text, graphics, and files containing other information are organized and linked.
By 1993, only 100 or so computers throughout the world were equipped to serve up HTML pages. Those interlinked pages were dubbed the World Wide Web (WWW), and several web browser programs had been written to enable people to view web pages. Because of the growing popularity of the Web, a few programmers soon wrote web browsers that could view graphical images along with text. From that point forward, the continued development of web browser software and the standardization of HTML has led us to the world we live in today, one in which more than a billion websites serve billions of text and multimedia files.
For more information on the history of the World Wide Web, see the Wikipedia article on this topic: http://en.wikipedia.org/wiki/History_of_the_Web.
These few paragraphs provide a very brief history of what has been a remarkable period. Today’s college students have never known a time in which the World Wide Web didn’t exist, and the idea of always-on information and ubiquitous computing will shape all aspects of our lives moving forward. Instead of seeing web content creation and management as a set of skills possessed by only a few technically oriented folks (okay, call them geeks, if you will), by the end of these lessons, you will see that these are skills that anyone can master, regardless of inherent geekiness.
You might have noticed the use of the term web content rather than web pages; that was intentional. Although we talk of “visiting a web page,” what we really mean is something like “looking at all the text and the images at one address on our computer.” The text that we read and the images that we see are rendered by our web browsers, which are given certain instructions found in individual files.
Those files contain text that is marked up with, or surrounded by, HTML codes that tell the browser the structure of the text—as a heading, as a paragraph, as a quotation, and so on. Some HTML markup tells the browser to display an image or video file rather than plain text, which brings us back to this point: Different types of content are sent to your web browser, so simply saying web page doesn’t begin to cover it. Here we use the term web content instead, to cover the full range of text, image, audio, video, and other media found online.
Other files contain CSS that tells the browser how a page should look—bold text, with a blue border, red color, and so on. CSS defines how the browser should display the content structure that is defined in the HTML.
Several processes occur, in many different locations, to eventually produce web content that you can see. These processes occur very quickly—on the order of milliseconds—and occur behind the scenes. In other words, although we might think all we are doing is opening a web browser, typing in a web address, and instantaneously seeing the content we requested, technology in the background is working hard on our behalf. Figure 1.1 shows the basic interaction between a browser and a server.
However, the process involves several steps—and potentially several trips between the browser and the server—before you see the entire content of the site you requested.
Suppose you want to do a Google search, so you dutifully type www.google.com in the address bar or select the Google bookmark from your bookmarks list. Almost immediately, your browser shows you something like what’s shown in Figure 1.2.
Figure 1.2 shows a website that contains text plus one image (the Google logo). A simple version of the processes that occurred to retrieve that text and image from a web server and display it on your screen follows:
Your web browser sends a request for the
index.html file located at the http://www.google.com address. The
index.html file does not have to be part of the address that you type in the address bar; you’ll learn more about the
index.html file further along in this lesson.
After receiving the request for a specific file, the web server process looks in its directory contents for the specific file, opens it, and sends the content of that file back to your web browser.
The web browser receives the content of the
index.html file, which is text marked up with HTML codes, and renders the content based on these HTML codes. While rendering the content, the browser happens upon the HTML code for the Google logo, which you can see in Figure 1.2. The HTML code looks something like this:
<img alt="Google" src="/images/srpr/logo4w.png"
> tag provides attributes that tell the browser the file source location (
src), alternate text (
alt), width (
width), and height (
height) necessary to display the logo. (You’ll learn more about attributes throughout later lessons.)
The browser looks at the
src attribute in the
<img> tag to find the source location. In this case, the image
logo4w.png can be found in the
images directory at the same web address (www.google.com) from which the browser retrieved the HTML file.
The browser requests the file at the web address http://www.google.com/images/srpr/logo4w.png.
The web server interprets that request, finds the file, and sends the contents of that file to the web browser that requested it.
The web browser displays the image on your monitor.
As you can see in the description of the web content delivery process, web browsers do more than simply act as picture frames through which you can view content. Browsers assemble the web content components and arrange those parts according to the HTML commands in the file.
It is possible to view web content locally—that is, on your own hard drive—without the need for a web server. The process of content retrieval and display is the same as the process listed in the previous steps, in that a browser looks for and interprets the codes and content of an HTML file. However, the trip is shorter: The browser looks for files on your own computer’s hard drive rather than on a remote machine. A web server would be needed to interpret any server-based programming language embedded in the files, but that is beyond the scope of these lessons. In fact, you could work through all the lessons without having a web server to call your own, but then nobody but you could view your masterpieces.
Despite my just telling you that you can work through all these lessons without having a web server, having a web server is the recommended method for continuing. Don’t worry; obtaining a hosting provider is usually a quick, painless, and relatively inexpensive process. In fact, you can get your own domain name and a year of web hosting for just slightly more than the cost of the lessons you are reading now.
If you type web hosting provider in your search engine of choice, you will get millions of hits and an endless list of sponsored search results (also known as ads). Even if you are looking at a managed list of hosting providers, it can be overwhelming—especially if all you are looking for is a place to host a simple website for yourself or your company or organization.
You’ll want to narrow your search when looking for a provider and choose one that best meets your needs. Some selection criteria for a web hosting provider follow:
Reliability/server “uptime”—If you have an online presence, you want to make sure people can actually get there consistently.
Customer service—Look for multiple methods for contacting customer service (phone, email, chat), as well as online documentation for common issues.
Server space—Does the hosting package include enough server space to hold all the multimedia files (images, audio, video) you plan to include in your website (if any)?
Bandwidth—Does the hosting package include enough bandwidth that all the people visiting your site and downloading files can do so without your having to pay extra?
Domain name purchase and management—Does the package include a custom domain name, or must you purchase and maintain your domain name separately from your hosting account?
Price—Do not overpay for hosting. You will see a wide range of prices offered and should immediately wonder, “What’s the difference?” Often the difference has little to do with the quality of the service and everything to do with company overhead and what the company thinks it can get away with charging people. A good rule of thumb is that if you are paying more than $75 per year for a basic hosting package and domain name, you are probably paying too much.
Here are three reliable web hosting providers whose basic packages contain plenty of server space and bandwidth (as well as domain names and extra benefits) at a relatively low cost:
The authors have used all these providers (and then some) over the years and have no problem recommending any of them. Julie predominantly uses DailyRazor as a web hosting provider, especially for advanced development environments, while Jennifer tends to use Bluehost.
A Small Orange (www.asmallorange.com)—The Tiny and Small shared hosting packages are perfect starting places for a new web content publisher.
DailyRazor (www.dailyrazor.com)—Its website hosting package is full featured and reliable.
Bluehost (www.bluehost.com)—The Basic shared hosting package is suitable for many personal and small business websites.
If you don’t go with any of these web hosting providers, you can at least use their basic package descriptions as a guideline as you shop around.
One feature of a good hosting provider is that it provides a “control panel” for you to manage aspects of your account. Figure 1.3 shows the control panel for a hosting account at DailyRazor. Many web hosting providers offer this particular control panel software (called cPanel) or another control panel that is similar in design—with clearly labeled icons leading to tasks you can perform to configure and manage your account.
You might never need to use your control panel, but having it available to you simplifies the installation of databases and other software, the viewing of web statistics, and the addition of email addresses (among many other features). If you can follow instructions, you can manage your own web server—no special training required.
Now that we’ve just discussed the process of web content delivery and the acquisition of a web server, it might seem a little strange to step back and talk about testing your websites with multiple web browsers and devices. However, before you go off and learn all about creating websites with HTML and CSS, do so with this very important statement in mind: Every visitor to your website will potentially use hardware and software configurations that are different from your own, including their device types (desktop, laptop, tablet, phone), operating systems (Windows, Mac, Android, iOS), screen resolutions, browser types, browser window sizes, and connection speeds. Remember that you cannot control any aspect of what your visitors use when they view your site. So just as you’re setting up your web hosting environment and getting ready to work, think about downloading several web browsers so that you have a local test suite of tools available to you. Let us explain why this is important.
Although all web browsers process and handle information in the same general way, some specific differences among them result in things not always looking the same in different browsers. Even users of the same version of the same web browser can alter how a page appears by choosing different display options and/or changing the size of their viewing windows. All the major web browsers allow users to override the background colors and fonts the web page author specifies with those of their own choosing. Screen resolution, window size, and optional toolbars can also change how much of a page someone sees when it first appears on their screens. You can ensure only that you write standards-compliant HTML and CSS.
In Part IV, “Responsive Web Design,” you’ll learn about the concept of responsive web design, in which the design of a site shifts and changes automatically depending on the user’s behavior and viewing environment (screen size, device, and so on).
Do not, under any circumstances, spend hours on end designing something that looks perfect only on your own computer—unless you are willing to be disappointed when you look at it on your friend’s computer, on the computer in the coffee shop down the street, or on your iPhone.
You should always test your websites with as many of these web browsers as possible:
Apple Safari (https://www.apple.com/safari/) for Mac
Google Chrome (https://www.google.com/chrome/) for Mac, Windows, and Linux/UNIX
Mozilla Firefox (https://www.mozilla.com/firefox/) for Mac, Windows, and Linux/UNIX
Microsoft Edge (https://www.microsoft.com/edge/) for Windows
Opera (https://www.opera.com) for Mac, Windows, and Linux/UNIX
Now that you have a development environment set up, or at least some idea of the type you’d like to set up in the future, let’s move on to creating a test file.
Before you actually create a file, take a look at Listing 1.1. This listing represents a simple piece of web content—a few lines of HTML that print
"Hello World! Welcome to My Web Server." in large bold letters on two lines centered within the browser window. You’ll learn more about the HTML and CSS used within this file as you read future lessons.
<title> Hello World! </title>
<h1 style="text-align: center;"> Hello World! <br>
Welcome to My Web Server.</h1>
To make use of this content, open a text editor of your choice, such as Notepad (on Windows) or TextEdit (on a Mac). Do not use WordPad, Microsoft Word, or other full-featured word processing software because those programs create different sorts of files from the plain-text files we use for web content.
Most web designers don’t use Notepad or TextEdit for writing web pages. Instead, they use editors designed specifically for the purpose. These editors give you more features to make it easy to write and design web pages. The following are some of the most popular editors:
Coda (https://panic.com/coda/)—A text editor for Mac made specifically for editing web pages.
HTML-Kit (https://www.htmlkit.com)—A popular text editor for Windows. The older versions are free.
Komodo Edit (https://www.activestate.com/komodo-edit)—A free, open-source version of the popular Komodo IDE. It runs on Windows, Mac, and Linux.
Notepad++ (https://notepad-plus-plus.org)—A free, open-source editor for Windows.
Sublime Text (https://sublimetext.com)—A popular editor for all platforms that also has a healthy ecosystem of free plug-ins.
Once you’ve decided on the editor you want to use, type the content that you see in Listing 1.1 and then save the file, using
sample.html as the filename. The
.html extension tells the web server that your file is written in HTML. When the file contents are sent to the web browser that requests it, the browser will also know that it is HTML and will render it appropriately.
Now that you have a sample HTML file to use—and hopefully somewhere to put it, such as a web hosting account—let’s get to publishing your web content.
As you’ve learned so far, you have to put your web content on a web server to make it accessible to others. This process typically occurs by using File Transfer Protocol (FTP). To use FTP, you need an FTP client—a program used to transfer files from your computer to a web server.
FTP clients require three pieces of information to connect to your web server; this information will have been sent to you by your hosting provider after you set up your account:
The hostname, or address, to which you will connect
Your account username
Your account password
When you have this information, you are ready to use an FTP client to transfer content to your web server.
All FTP clients generally use the same type of interface. Figure 1.4 shows an example of FireFTP, which is an FTP client used with the Firefox web browser. The directory listing of the local machine (your computer) appears on the left of the screen, and the directory listing of the remote machine (the web server) appears on the right. Typically, you see right arrow and left arrow buttons, as shown in Figure 1.4. The right arrow sends selected files from your computer to your web server; the left arrow sends files from the web server to your computer. Many FTP clients also enable you to simply select files and then drag and drop them to the target machines.
Many web editing programs include a built-in FTP client. If you are planning on using a web editing program, find out if it does before you download (or purchase) another FTP client.
Many FTP clients are freely available to you, but you can also transfer files via the web-based File Manager tool that is likely part of your web server’s control panel. However, that method of file transfer typically introduces more steps into the process and isn’t nearly as streamlined (or simple) as the process of installing an FTP client on your own machine.
Here are some popular free FTP clients:
Classic FTP (https://www.nchsoftware.com/classic/) for Mac and Windows
Cyberduck (https://cyberduck.io) for Mac
FileZilla (https://filezilla-project.org) for all platforms
Transmit (https://panic.com/transmit) for Mac
When you have selected an FTP client and installed it on your computer, you are ready to upload and download files from your web server. In the next section, you’ll see how this process works, using the sample file from Listing 1.1.
The following steps show how to use Transmit to connect to your web server and transfer a file. However, all FTP clients use similar interfaces, so if you understand the following steps, you should be able to use any FTP client.
Remember that you first need the hostname, the account username, and the account password. When you have them, follow these steps:
Start the Transmit program and click the FTP tab. You are prompted to fill out information for the site to which you want to connect, as shown in Figure 1.5.
Fill in each of the items shown in Figure 1.5, as described here:
The Server is the FTP address of the web server to which you need to send your web pages. Your hosting provider will have given you this address. It probably is yourdomain.com, but check the information you received when you signed up for service.
Complete the User Name field and the Password field using the information your hosting provider gave you.
Leave the Initial Path field blank for now. You learn more about this later in the lesson.
Leave the Port field set to
21 and choose
FTP unless your hosting provider specified to use SSL or TLS/SSL.
When you’re finished with the settings, click Connect to go to the FTP server. You can click the plus icon if you want to add this server to your favorites.
You now see a countdown timer in the lower right, indicating that Transmit is attempting to connect to the web server. Upon successful connection, you see an interface like the one in Figure 1.6, showing the contents of the local directory on the left and the contents of your web server on the right.
You are now almost ready to transfer files to your web server. All that remains is to change directories to what is called the document root of your web server. The document root of your web server is the directory that is designated as the top-level directory for your web content—the starting point of the directory structure, which you’ll learn more about later in this lesson. Often, this directory is named
www has been created as an alias for
htdocs. You do not have to create this directory; your hosting provider will have created it for you.
Double-click the document root directory name to open it. The display shown on the right of the FTP client interface changes to show the contents of this directory. (It will probably be empty at this point, unless your web hosting provider has put placeholder files in that directory on your behalf.)
The goal is to transfer the
sample.html file you created earlier from your computer to the web server, so find the file in the directory listing on the left of the FTP client interface (navigate if you have to).
Click the file and drag it to the right side of the window to send the file to the web server. (Alternatively, you can double-click the file to transfer it.) When the file transfer completes, the right side of the client interface refreshes to show you that the file has made it to its destination.
Go to the File menu and choose Disconnect to close the connection and then exit the Transmit program.
These steps are conceptually similar to the steps you take anytime you want to send files to your web server via FTP. You can also use your FTP client to create subdirectories on the remote web server. To create a subdirectory using Transmit, right-click in the directory you want the folder to be in and choose New Folder. Different FTP clients have different interface options for achieving the same goal.
An important aspect of maintaining web content is determining how you will organize that content—not only for the user to find but also for you to maintain on your server. Putting files in directories helps you manage those files.
How you name and organize directories on your web server and whether you develop rules for file maintenance are completely up to you. Maintaining a well-organized server makes your management of its content more efficient in the long run.
As you browse the Web, you might have noticed that URLs change as you navigate through websites. For instance, if you’re looking at a company’s website and you click on graphical navigation leading to the company’s products or services, the URL probably changes from
In the preceding section, we used the term document root without really explaining what that is all about. The document root of a web server is essentially the trailing slash in the full URL. For instance, if your domain is yourdomain.com and your URL is http://www.yourdomain.com/, the document root is the directory represented by the trailing slash (/). The document root is the starting point of the directory structure you create on your web server; it is the place where the web server begins looking for files requested by the web browser.
If you put the
sample.html file in your document root as previously directed, you will be able to access it via a web browser at the following URL:
If you entered this URL into your web browser, you would see the rendered
sample.html file, as shown in Figure 1.7.
However, if you created a new directory within the document root and put the
sample.html file in that directory, the file would be accessed at this URL:
If you put the
sample.html file in the directory you originally saw upon connecting to your server—that is, if you did not change directories and place the file in the document root—the
sample.html file would not be accessible from your web server at any URL. The file would still be on the machine that you know as your web server, but because the file is not in the document root—where the server software knows to start looking for files—it will never be accessible to anyone via a web browser.
The bottom line? Always navigate to the document root of your web server before you start transferring files. And if your FTP client allows, change the default starting directory to your document root, just to be extra careful.
This is especially true with graphics and other multimedia files. A common directory on web servers is called
images, where, as you can imagine, all the image assets are placed for retrieval. Other popular directories include
css for style sheet files (if you are using more than one) and
Whether it’s a ZIP file containing your art portfolio or an Excel spreadsheet with sales numbers, it’s often useful to publish files on the Internet that aren’t simply web pages. To make available on the Web a file that isn’t an HTML file, just upload the file to your website as if it were an HTML file, following the instructions earlier in this lesson for uploading. After the file is uploaded to the web server, you can create a link to it (as you’ll learn in Lesson 7, “Using External and Internal Links”). In other words, your web server can serve much more than HTML.
Here’s a sample of the HTML code that you will learn more about later in these lessons. The following code would be used for a file named
artfolio.zip, located in the
downloads directory of your website, and with link text that reads
Download my art portfolio!:
<a href="/downloads/artfolio.zip">Download my art portfolio!</a>
When you think of an index, you probably think of the section in the back of a book that tells where to look for various keywords and topics. The index file in a web server directory can serve a similar purpose—if you design it that way. In fact, that’s where the name originates.
index.html file (or just index file, as it’s usually referred to) is the name you give to the page you want people to see as the default file when they navigate to a specific directory in your website.
Another function of the index page is that users who visit a directory on your site that has an index page but who do not specify that page will still land on the main page for that section of your site—or for the site itself.
For instance, you can type either of the following URLs and land on Apple’s iPhone informational page:
If there were no
index.html page in the
iphone directory, the results would depend on the configuration of the web server. If the server is configured to disallow directory browsing, the user would see a “Directory Listing Denied” message when attempting to access the URL without a specified page name. However, if the server is configured to allow directory browsing, the user would see a list of the files in that directory.
Your hosting provider will already have determined these server configuration options. If your hosting provider enables you to modify server settings via a control panel, you can change these settings so that your server responds to requests based on your own requirements.
Not only is the index file used in subdirectories, but it’s used in the top-level directory (or document root) of your website as well. The first page of your website—or home page or main page, or however you like to refer to the web content you want users to see when they first visit your domain—should be named
index.html and placed in the document root of your web server. This ensures that when users type http://www.yourdomain.com/ into their web browsers, the server responds with the content you intended them to see (instead of “Directory Listing Denied” or some other unintended consequence).
Publishing HTML and multimedia files online is obviously the primary reason to learn HTML and create web content. However, there are also situations in which other forms of publishing may be useful? For example, you might want to distribute CD-ROMs, DVD-ROMs, or USB drives at a trade show with marketing materials designed as web content—that is, hyperlinked text viewable through a web browser but without a web server involved. You might also want to include HTML-based instructional manuals on removable media for students at a training seminar. These are just two examples of how HTML pages can be used in publishing scenarios that don’t involve the Internet.
This process is called creating local sites; even though no web server is involved, these bundles of hypertext content are still called sites. The local term comes into play because your files are accessed locally and not remotely (via a web server).
Let’s assume that you need to create a local site that you want to distribute on a USB drive. Even the cheapest USB drives hold so much data these days—and basic hypertext files are quite small—that you can distribute an entire site and a fully functioning web browser all on one little drive.
Distributing a web browser isn’t required when you are creating and distributing a local site, although it’s a nice touch. You can reasonably assume that users have their own web browsers and will open the
index.html file in a directory to start browsing the hyperlinked content. However, if you want to distribute a web browser on the USB drive, go to https://portableapps.com/ and look for Portable Firefox or Portable Chrome.
You can think of the directory structure of your USB drive just as you would the directory structure of your web server. The top level of the USB drive directory structure can be your document root. Or if you are distributing a web browser along with the content, you might have two directories—for example, one named
browser and one named
content. In that case, the
content directory would be your document root. Within the document root, you could have additional subfolders in which you place content and other multimedia assets.
It’s as important to maintain good organization with a local site as it is with a remote website so that you avoid broken links in your HTML files. You’ll learn more about the specifics of linking files in Lesson 7.
You might have a blog hosted by a third party, such as WordPress, Tumblr, or Blogger, and thus have already published content without having a dedicated web server or even knowing any HTML. These services offer visual editors in addition to source editors, meaning that you can type your words and add presentational formatting such as bold, italics, or font colors without knowing the HTML for these actions. The content becomes actual HTML when you click the Publish button in these editors.
However, with the knowledge you will acquire from these lessons, your blogging will be enhanced because you will be able to use the source editor for your blog post content and blog templates, and this will afford you more control over the look and feel of that content. These actions occur differently from the process you learned for creating an HTML file and uploading it via FTP to your own dedicated web server, but we would be remiss if we did not note that blogging is, in fact, a form of web publishing.
Whenever you transfer files to your web server or place them on removable media for local browsing, you should test every page thoroughly. The following list helps you ensure that your web content behaves the way you expect. Note that some of the terms might be unfamiliar to you at this point, but come back to this list as you progress through these lessons and create larger projects:
Before you transfer your files, test them locally on your machine to ensure that the links work and the content reflects the visual design you intended. After you transfer the pages to a web server or removable device, test them all again.
Perform these tests with as many browsers and devices as you can—Chrome, Firefox, Microsoft Edge, Opera, and Safari is a good list—and on both Mac and Windows platforms, as well as mobile devices like phones and tablets. If possible, check at low resolution (800 × 600) and high resolution (1920 × 1080).
Turn off auto image loading in your web browser before you start testing so that you can see what each page looks like without the graphics. Check your alt text and then turn image loading back on to load the graphics and carefully review the page again.
Use your browser’s font size settings to look at each page in various font sizes to ensure that your layout doesn’t fall to pieces if users override your font specifications with their own.
Wait for each page to completely finish loading and then scroll all the way down to make sure all images appear where they should.
Time how long it takes each page to load. Use a tool like Google Page Speed (https://developers.google.com/speed/) to make sure it isn’t too slow. Slow pages annoy users and can get your site penalized by search engines.
If your pages pass all those tests, you can rest easy: Your site is ready for public viewing.
You learned the criteria to consider when determining whether a web hosting provider fits your needs. After you have selected a web hosting provider, you can begin to transfer files to your web server by using an FTP client, which you also learned how to do. You also learned a bit about web server directory structures and file management, as well as the very important purpose of the
index.html file in a given web server directory. In addition, you learned that you can distribute web content on removable media, and you learned how to go about structuring the files and directories to achieve the goal of viewing content without using a remote web server.
Finally, you learned the importance of testing your work in multiple browsers after you’ve placed it on a web server. Writing valid, standards-compliant HTML and CSS helps ensure that your site looks reasonably similar for all visitors, but you still shouldn’t design without receiving input from potential users outside your development team; it is especially important to get input from others when you are a design team of one!
Q. I’ve looked at the HTML source of some web pages on the Internet, and it looks frighteningly difficult to learn. Do I have to think like a computer programmer to learn this stuff?
A. Although complex HTML pages can indeed look daunting, learning HTML is much easier than learning actual software programming languages (such as C++ or Java). HTML is a markup language rather than a programming language; you mark up text so that the browser can render the text a certain way. It requires a completely different set of thought processes than developing a computer program. You really don’t need any experience or skill as a computer programmer to be a web content author.
Q. Running all the tests you recommend would take longer than creating my pages! Can’t I get away with less testing?
A. If your pages aren’t intended to make money or provide an important service, it’s probably not a big deal if they look funny to some users or produce errors once in a while. In that case, just test each page with a couple different browsers and call it a day. However, if you need to project a professional image, there is no substitute for rigorous testing.
Q. Seriously, who cares how I organize my web content?
A. Believe it or not, the organization of your web content does matter to search engines and potential visitors to your site. But overall, having an organized web server directory structure helps you keep track of content that you are likely to update frequently. For instance, if you have a dedicated directory for images or multimedia, you know exactly where to look for a file you want to update—no need to hunt through directories containing other content.
The Workshop contains quiz questions and exercises to help you solidify your understanding of the material covered.
1. How many files would you need to store on a web server to produce a single web page with some text and two images on it?
2. How many requests to the server would a browser make to display a web page with some text and two images on it?
3. What are some of the features to look for in a web hosting provider?
4. How many browsers should you use to test your web pages?
5. What type of editor should you use to create web pages?
6. What three pieces of information do you need in order to connect to your web server via FTP?
7. What is the document root?
8. Is it possible to publish web pages to a USB drive?
9. What is the purpose of the
10. Does your website have to include a directory structure?
Just a reminder for those of you reading these words in the print or e-book edition of this book: If you go to www.informit.com/register and register this book (using ISBN 9780672338083), you can receive free access to an online Web Edition that not only contains the complete text of this book, but also features an interactive version of this quiz.
1. You would need three: one for the web page itself, which includes the text and the HTML markup, and one for each of the two images.
2. There would be three requests to the server: one for the HTML itself and one for each of the two images.
3. Look for reliability, customer service, web space and bandwidth, domain name service, site-management extras, and price.
4. You should test your website in as many browsers and on as many devices as possible.
5. You should use a text editor such as Notepad or TextEdit. You can also use an editor specifically for writing HTML, such as Komodo Edit or Coda.
6. You need the hostname, your account username, and your account password.
7. The document root is the top-level directory on a web server—the trailing slash after the domain name.
8. Yes. This is called publishing content locally.
index.html file is typically the default file for a directory in a web server. It enables users to access http://www.yourdomain.com/somedirectory/ without using a trailing filename and still end up in the appropriate place.
10. No. Using a directory structure for file organization is completely up to you, although using one is highly recommended because it simplifies content maintenance.
Get your web hosting in order: Are you going to move through the lessons by viewing files locally on your own computer, or are you going to use a web hosting provider? Note that most web hosting providers will have you up and running the same day you purchase your hosting plan. Name three possible hosting providers.
If you are using an external hosting provider, then use your FTP client to create a subdirectory within the document root of your website. Paste the contents of the
sample.html file into another file named
index.html, change the text between the
</title> tags to something new, and change the text between the
</h1> tags to something new. Save the file and upload it to the new subdirectory. Use your web browser to navigate to the new directory on your web server and ensure that the content in the
index.html file appears. Then, using your FTP client, delete the
index.html file from the remote subdirectory. Return to that URL with your web browser, reload the page, and see how the server responds without the
index.html file in place. Name two FTP clients.
Using the same set of files created in the preceding exercise, place these files on a removable media device—a CD-ROM or a USB drive, for example. Use your browser to navigate this local version of your sample website and think about the instructions you would have to distribute with this removable media so that others could use it.