Kieran Hi! I’m Kieran. I’m a black lab, a tech geek, and an educator. I’ve been teaching regular people about computers since Lassie was a pup.

I’ll lead you through the CoreDogs lessons.

Two other dogs are learning along with you. CC…


...and Renata.


So it will be the four of us. Plus anyone else you want to bring along. It helps if you have a study buddy or two.

The first book – Foundations – is short. It covers three things.

That’s our goal: to make good sites. But if we don’t know what a good site is, it will be hard to make one.

We’ll talk about how computers connect on the Internet, and how Web sites use those connections.

eMe is a Web site about you. It will have whatever content and formatting you want. It will have its own domain, like

CoreDogs will help you learn how to make a great eMe site. Send a link to employers, relatives, friends,... anyone you want to impress with your mad Web skillz.

The menu in the right-hand column shows how everything is organized. Each CoreDogs book has chapters. The first chapter in this book is “Good Web sites.”

Books and chapters

Each chapter has lessons in it.

Chapters and lessons

To go to the first chapter, use the Lessons menu, click the forward link…

The forward link is down there

... or use the table of contents below.

Good Web sites

This chapter is about the most important question in CoreDogs:

What makes a Web site good?

This lesson’s goals

By the end of this lesson, you should know:

In CoreDogs, “people” includes humans as well as us dogs.

My answer

Here’s what I think. That means me, Kieran, the dog writing this.

A good site helps people meet their goals. It helps the people who use the site, the people who own it, and the people who build it.

Three stakeholders

Notice the three different types of people: users, owners, and builders.

Each one is a “stakeholder.” That is, each has an interest in the site being good. Each one has goals. A good Web site helps them all meet their goals. The more it helps, the better the site is.

People who use a site have goals like buying an MP3 player, or learning about core Web tech. A good Web site helps users do these things quickly and easily.

People who own Web sites have goals, like telling customers where a business is located, or earning customer trust. A good Web site helps site owners meet these goals.

Webers – people who build Web sites – have goals, too. Like making a site easy to change. A good Web site helps Webers meet their goals.


OK, there are users, owners, and builders. And they all have goals. But they won’t all want the same things. What happens when their goals conflict?


Good question!

The short answer is that users are in charge on the Web. Owners have to make a site that is worth using.

We’ll talk more about this later.

A bad page

Sometimes it’s easy to tell when a site has problems. Check this out.

Bad page

Figure 1. Bad page

The page is cluttered. The text is hard to read. The colors are ugly. There are spelling mistakes. Yuck!

But site goodness isn’t just about look. It comes down to what people want to do with the site. Suppose someone wants to find out how to get to a store. But the store’s Web site doesn’t have a map, and the address is hard to find. The site has a problem, no matter how good it looks.

An exercise

Here’s a page.

How good is this?

Figure 2. Google

Is it any good?

You can’t judge a Web page without knowing what the page is for.

Google’s home page is for one thing: searching. Here’s what people do (more or less) when they search:

  1. Think of a search term.
  2. Type it into the search box.
  3. Press the Search button.

Here are some ways the page helps:

Cursor on page load

Figure 3. Cursor on page load


Figure 4. Autosuggest

If I’m looking for CoreDogs, I don’t have to type the whole word.

The Google page is plain, but quite good, because it helps people search quickly. For searching, the behavior of the page (e.g., autosuggest) is more important than the look.


But what about the look of the page? Isn’t that important at all?


The page is plain, and that helps users search.

But remember, there’s more than one stakeholder. How could a page’s look affect other stakeholders?


I don’t know… Oh, wait. The look sends a message about the site and the company behind it.



Site owners want to tell users things, like what the owner does, or what benefits the site offers. The look of a page is part of the page’s message.

Check out this page fragment, with the text pixelated out:

Figure 5. A design

You know the site is aimed at kids, just from the colors and drawings. The page is telling you something, just through the look.

Here is what really looks like:

Figure 6.

The site’s designers have done a good job matching the look of the site to its owner’s goals.

A page’s look can send unintentional messages as well. Remember this one?

Bad page

Figure 1 (again). Bad page

If you saw this on the Web, what would you think about the person who created it? Hmmm…..


Where to now?

This entire chapter of the Foundations book is about what makes a Web site good. We’ll look at it from three points of view:

For each stakeholder, we’ll talk about:

We’ll look at two cases:

We’ll also start working on eMe, the Web site you’ll make for yourself.

Site users

Where are we?

A good Web site helps three groups: users, owners, and builders. This lesson and the next are about users.

What makes a Web site good for users? Remember that “good” means “helping people with their goals.”

We need to understand:

  • The goals users have.
  • The actions they take to reach their goals.
  • How Web sites support those actions.

Let’s talk about how this works on CarlysSchool.Com.

This lesson’s goals


  • There are common questions users are trying to answer when they visit a Web site.
  • Information architecture is working out what information should be on a site, and how it should be grouped into pages and sections.
  • People browse through a site to find information. When users click from page to page, they are often following the “scent of information.”
  • Browsing is easier when there are menus, scannable pages, readable pages, predictable pages, and “You are here” signs.
  • People also use a site’s search function to find information.



Carly’s School is a human obedience school in Rochester, Michigan, USA. Carly offers beginner to advanced courses. Beginner courses focus on the basics, like teaching your human to let you inside when you bark. Humans learn tricks in advanced courses. Like the Dance of the Tangled Leash.


Carly’s School has just one location, in downtown Rochester. Customers are local, most from within a few miles.

Users’ goals

What do people want to do with Carly’s site? Let’s break users into two types, depending on why they visit CarlysSchool.Com.

The first group are the DIYers (DIY = do it yourself). They don’t want Carly to do the training. DIYers want to train their humans themselves.

The second group are the potential customers. They are people who live near Carly’s School, and are looking for a class for their humans.

Exercise: Different types of users

Imagine you’re a DIYer. What would make Carly’s site good for you?

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

Carly decides not to help the DIYers on CarlysSchool.Com. This is a business decision on her part. She decides the site should only help potential customers.

The potential customers have one main task: to decide whether to sign up for a class. They’ll use CarlysSchool.Com to get the information they need to make that decision.

What information do they want? Carly talks to potential customers all the time. Their most common questions are:

  • What obedience schools are in the area?
  • What courses does Carly’s School offer?
  • What benefits do the courses offer?
  • What do the courses cost?
  • Where are the courses taught? When are they offered?
  • Is my human ready for a course?
  • Can I talk to someone about the courses? Who?
  • How long has Carly’s School been in business?
  • Does Carly know what she’s doing?
  • How do I sign up?

Carly decides that CarlysSchool.Com should help users answer all of these questions, except for the first one. She doesn’t want to advertise the competition.


So users want an answer to the first question, but Carly doesn’t want to answer it.


Right. Each question she won’t answer reduces the value of the site to the users. But that’s Carly’s call.

Carly also has decided not to do any online course registration, at least not yet. Maybe in the future. To register for a course, people need to call the store, or visit in person.

So, these are users’ goals. How do they meet their goals?

Users’ actions

Users get answers:

  • With a search engine.
  • By looking through CarlysSchool.Com.

There are other ways customers get information, like word-of-mouth, and traditional print advertising. But let’s focus on Web things.

Someone might do a Google search, like this:

Google search

Figure 1. Google search

The closer Carly’s School is to the top of the rankings, the better. Getting a site to the top is called search engine optimization (SEO).

Suppose someone does the search in Figure 1, and clicks on the link to CarlysSchool.Com. The user has now left Googleland, and is on Carly’s site, seeing the Web pages that Carly owns. The user can find information in two ways:

  • Browsing
  • Searching – not in Google, but in Carly’s site

Browsing CarlysSchool.Com

Browsing means looking around the site, clicking from page to page. Webers used to think that people would not browse a site, or at least not much. They had rules like, “No information should be more than three clicks from the home page.”

But research found that people will browse. They’ll click, click, click – if they’re following the “scent of information.”

It’s like a dog following a rabbit. If the scent trail is strong, the dog will follow it. S/he won’t get distracted, even if the trail crosses other trails. But if the scent isn’t clear – if the dog isn’t sure which way to go next – the dog might get distracted by something else.

Scent trail

Figure 2. Scent trail

It’s the same with a site. Users visit page after page. If they think they’re getting closer to the information they want, they’ll keep going. But if they’re not sure what to do next to get closer to the information, they might give up, and go to another site.

So a good Web site is browsable. It lays down information trails users can follow. We’ll talk about how to make a site browsable in a moment.

Searching CarlysSchool.Com

When most people hit a site, they start browsing. But some start searching. I’m not talking about Google, but about the site’s own search function. For example, CoreDogs has a search box on every page:

Search box on a site

Figure 3. Search box on a site

This is an internal search engine. Google is an external search engine.

How CarlysSchool.Com can help users

Where are we?

  • People have questions, like what Carly’s School charges for courses.
  • They use search engines to get to CarlysSchool.Com.
  • When they get there, they browse and search within the site.

Let’s talk about how CarlysSchool.Com can help users find information.

Information architecture

Information architecture is about how information is arranged on a site. This means:

  • Putting the right information on the site.
  • Grouping it into pages.
  • Grouping pages into sections of the site.

Let’s take the first one. Carly has listed the questions that customers have. Answers to those questions should be on the site.

It’s important to get this right. The whole reason Carly wants a Web site is for customers to get their questions answered. If they like what they see, they might give Carly some business.

Information is grouped together on pages. But it can be grouped in different ways. For example, say there are three courses. Carly wants to answer the following questions about each course:

  • What does the course teach humans to do?
  • How will this benefit the humans’ dog?
  • What does the course cost?
  • What is the course schedule?

You could make a page for each course, answering all these questions.

Similar pages are often grouped into sections of a site. Carly’s site might have a section called “Courses.” The individual course pages would be in that section. There would be a front page for the section, giving links to the individual courses.

Here’s how the section could be organized:

Information architecture

Figure 4. Information architecture

The “course section” is not a physical thing. It’s just a set of pages that are presented to the user as if they belong together.

To summarize, information architecture is about what information is on the site, and how it is grouped into sections and pages.

Supporting browsing

“Supporting” means “making it easy.” We want to help users find information by browsing through the site’s architecture. We need to give them the scent of information, so they know where to click next to get closer to the answer they want.

So how can we make browsing easier?

Menus help people quickly learn what is on a site, and jump to relevant pages.

CoreDogs has a menu of tabs at the top of every page:


Figure 5. Tabs

Each tab corresponds to a section of the site.

The tree menu on the right of each page shows the structure of the lesson’s section:

Tree menu

Figure 6. Tree menu

The current page is highlighted.

Carly might put a menu at the left of each page. It would have buttons for the major pages and sections of the site. Here’s a simple menu:

Vertical nav bar

Figure 7. Vertical nav bar

This is often called a vertical navigation bar, or nav bar for short. You’ll learn to make nav bars later.

Scannable pages

A page is scannable if you can quickly run your eye over it, and pick out important information.

Headings make pages scannable. Scroll up and down this page, and the section headings will stand out. They use different font sizes and colors from the rest of the text.

Make sure it’s clear which heading goes with which text. Compare these two page fragments.

Poor grouping

Good grouping

Figure 8. Grouping

The eye uses whitespace to decide what headings belong with what text. That’s easier in the second fragment.

Another way to make text scannable is to use emphasis. Like the word “emphasis” in this paragraph. The word stands out as you scan the text.

To summarize, making pages scannable helps users browse them quickly.

Readable pages

Readability is very important. Users can’t find information they can’t read!

There are two aspects to this: the look of text, and the writing.

Look is about font face, color, size, etc. This is bad:

The look of text

Figure 9. The look of text

The colors make the text hard to look at.

Writing matters as well. Obviously there should be no spelling errors. But there are other guidelines, too.

  • Use lists. Like this one.
  • Use simple words.
  • Use short sentences and paragraphs.
  • Use active voice.
  • Be informal, where appropriate.

Grammar is important. But I’ll drop rules that reduce readability. For example, I’ll end sentences with prepositions.

We’ll talk more about text later.

Predictable pages

Help users browse Web sites by making pages predictable. This helps people direct their attention to the right place.

  • Consistent layout. For example, every CoreDogs page has a menu on the right.
  • Consistent fonts and colors. For example, all major headings should be the same size and color.
  • Make links look like links. Use underlining, and color:

A link

Figure 10. A link

When a link points to a page outside the current site, CoreDogs adds an icon, like this:

An external link

Figure 11. An external link

“You are here” signs

Use signals to helps users know where they are in the site. CoreDogs uses menu highlighting and breadcrumbs.

Tabs are on the top of each CoreDogs page. Each section of the site has a tab:


Figure 5 (again). Tabs

One of the tabs in Figure 5 is highlighted. That’s the section of the site the current page is in.

The tree menu on the right highlights the current lesson:

Tree menu

Figure 6 (again). Tree menu

Breadcrumbs show the path to the current page:


Figure 12. Breadcrumbs

Let’s summarize.

  • A good site helps people reach their goals.
  • Users of CarlysSchool.Com have questions, like what classes are offered.
  • Users browse and search Web sites for answers.
  • You can support browsing by making sites scannable, readable, and predictable, and adding “You are here” signs.

Let’s talk about searching.

Supporting searching

CarlysSchool.Com should have a search box, like the one on CoreDogs:

Search box on a site

Figure 3 (again). Search box on a site

The user types something in…


Figure 13. Searching

... and gets some search results:

Search results

Figure 14. Search results

The results show each page where the search term “breadcrumbs” was found. The page you’re looking at now is listed.

Searching can get complicated. For example, suppose I type “programming” into the CoreDogs search box:

A search

Figure 15. A search

Here’s one of the results:

A search result

Figure 16. A search result

But wait a minute. The word “programming” isn’t in the result. In fact, it’s nowhere on the Writing a JS program page. So why is it in the search results?

The CoreDogs search engine can handle stems. “Program” is the stem of the word “programming,” so CoreDogs returns pages with “program” in it. The Writing a JS program page contains the word “program.”

One reason for Google’s success is that it handles stems, misspellings, synonyms, abbreviations, and other things. For example, if you search for “cascading style sheet,” Google will return pages that have the abbreviation “CSS,” even if they don’t have the term “cascading style sheet” at all. This happens so naturally that you usually don’t even notice how smart Google search is.

And of course, autocomplete gives some interesting facts:

Google autocomplete for

Figure 17. Google autocomplete for “dogs are”


  • There are common questions users are trying to answer when they visit a Web site.
  • Information architecture is about working out what information should be on a site, and how it should be grouped into pages and sections.
  • When users click from page to page, they are often following the scent of information.
  • People also use a site’s search function.
  • Browsing is easier when there are menus, scannable pages, readable pages, predictable pages, and “You are here” signs.

What now?

Let’s look at how people use WanderingDog.Com, an ecommerce site.

WanderingDog users

Where are we?

We’ve seen how CarlysSchool.Com helps users learn about the human obedience school. Let’s see how an ecommerce site could help users buy stuff.

This lesson’s goals

Learn that:

  • Users have two goals at the WanderingDog.Com ecommerce site: choosing a product, and buying a product.
  • Choice strategies include (1) choosing a product that others recommend, (2) choosing based on one major product attribute, or (3) choosing after a detailed analysis of many products.
  • WanderingDog.Com uses product category pages to support all three strategies.
  • WanderingDog.Com has a horizontal nav bar listing all the product category pages.


Jesse runs the online store WanderingDog.Com. There’s Jesse on the right. Hello, Jesse!

WanderingDog sells portable electronics for dogs, like MP3 players and paw-held games. It only does business on the Web. There is no physical WanderingDog store.

In this part of the chapter, we’re talking about what makes a site good for users. So let’s talk about that for WanderingDog.Com.

Users’ goals

Users have two goals when they go to WanderingDog.Com.

  • Choosing a product to buy.
  • Buying a product.

Users’ goals change over time. Suppose a user visits WanderingDog.Com three times. On the user’s first two visits, s/he learns about MP3 players, deciding which one to buy. The user’s goal on these visits is “choosing a product.” S/he then makes a choice. The goal on the third visit is “buying a product.”

To keep things simple, let’s just talk about the first goal: choosing a product.

Users’ actions

Jesse looks at research on how people choose stuff to buy. This is what he learns:

  1. Some people choose the product that trusted people recommend. “Trusted people” could be friends, experts, or just other people in general (that is, buying the product that most other people buy).
  2. Some people focus on just one product attribute, like price, or coolness. They start by looking at, say, the cheapest product. If that does what they want, they stop looking. If it doesn’t do what they want, they look at the next cheapest one. And so on. They stop when they find a product that is satisfactory.
  3. Some people spend more time. They learn about the product category, like MP3 players. They think about their needs. They look at several, or maybe many, products, and make a careful choice.

Jesse designs WanderingDog.Com to support all three of these actions.

How WanderingDog.Com can help

Product categories home pages

Jesse gives each product category – MP3 players, games, etc. – its own section of the site, with its own front page. The category front pages will support the three ways of buying a product.

Here’s Jesse’s drawing of a category front page. His pawwriting is bad, but you should be able to get the idea:

Category home page

Figure 1. Category front page

This page supports all three ways of choosing a product.

  • Recommendations. You can see what other people think (“The People’s Choice”). You can read what the experts like best by clicking on “The Reviewer’s Choice.”
  • Single important attribute. You can see which product Jesse thinks is the coolest, and which is the best value. Notice that Jesse changed “cheapest” to “best value,” to use more positive words.
  • Complete analysis. If you want to get into the details of all of the products, you can use the grid at the bottom. Click on the column titles to sort the data by name, price, whatever.

See how Jesse is working systematically to make a good site. He thought about user goals, and the actions they take to reach them. Then he designed something that would help.

Finding the right category home page

How to make it easy for people to find the right category front page? Jesse decided to make a menu at the top of each page:

Nav bar

Figure 2. Nav bar

There’s a button for each section of the site. This is common; it’s the way CoreDogs works, for example.

This type of menu is also called a horizontal navigation bar, or nav bar for short. You’ll learn how to make nav bars later.


  • Users have two goals at the WanderingDog.Com ecommerce site: choosing a product, and buying a product.
  • Choice strategies include (1) choosing a product that others recommend, (2) choosing based on one major product attribute, or (3) choosing after a detailed analysis of many products.
  • WanderingDog.Com uses product category pages to support all three strategies.
  • WanderingDog.Com has a horizontal nav bar listing all the product category pages.

What now?

A good Web site helps users meet their goals. We’ve seen how that works with two sites.

Now let’s talk about what site owners want.

Site owners

Where are we?

This chapter is about what makes a Web site good. A good site helps users, owners, and builders reach their goals.

We’ve talked about users. Now let’s see how sites help owners. We’ll look at the same two sites: CarlysSchool.Com, and WanderingDog.Com.

This lesson’s goals


  • The owners are the people who pay for the Web site.
  • Sites for private companies should make money, either directly (e.g., by selling through the site), or indirectly (e.g., by generating leads).
  • Users are in charge on the Web.
  • A value proposition tells customers why they should buy a company’s product or service.
  • Branding creates an identity, and reminds people of the value proposition.

Money and not money

The owners are the people who pay for the Web site. They have things they want the site to do for them. Let’s call these things the “business goals” of the site.

The two example sites in this chapter – CarlysSchool.Com, and WanderingDog.Com – belong to money-making (we hope!) businesses. So an obvious business goal is: sites should make money.

But commercial sites often have other goals as well. People who run small companies care about how they make a living. Many business owners would make more money if they worked for a company, but they choose not to.

Let’s talk about money and non-money goals.

Making money

Businesses make money by selling stuff to customers. No news there.

A Web site can be part of the selling process. But the role it play varies.

Generating leads

Let’s look at Carly’s School. Recall that it sells obedience courses. Carly’s School trains humans to obey their dogs.

Here’s how the buying process might work for a customer.

A Carly's School customer

Figure 1. A Carly’s School customer

Here are the parts that the Web site helps with.

What CarlysSchool.Com helps with

Figure 2. What CarlysSchool.Com helps with

CarlysSchool.Com doesn’t actually complete the sale. Instead, the Web site generates leads. Leads are potential customers. The Web site helps bring them into the business, where the sale can be completed.

Direct sales

WanderingDog is different. It sells directly from the Web site.

Here’s a sample sales process.

A WanderingDog customer

Figure 3. A WanderingDog customer

Here are the parts of the process that WanderingDog.Com helps with.

What WanderingDog.Com helps with

Figure 4. What WanderingDog.Com helps with

This Web site handles more of the sales process.

The value proposition

Users are just a click away from thousands of sites. If owners want to attract customers, their sites have to offer clear value propositions.

A value proposition tells customers why they should buy a company’s product or service.

For example:

Carly’s School trains humans to obey their dogs.

This is a promise that Carly’s School makes.

For Carly’s School to succeed, it needs to:

  • Have a value proposition people want.
  • Let people know what the value proposition is.
  • Deliver on it.

WanderingDog.Com says:

WanderingDog.Com helps you find the portable dog electronics you want.

This value proposition says you get the electronics, yes, but there’s more to it. There’s the “you want” at the end. WanderingDog.Com helps customers make good choices.

WanderingDog.Com is vulnerable to competition. There are hundreds of sites that sell portable electronics. They’re all just a click away. WanderingDog has to deliver on its promise.

That’s why Jesse spent time learning how people choose products. He couldn’t deliver on the promise otherwise.

Communicating the value proposition

Marketers talk about “branding.” The most important things branding does are:

  • Create an identity for something, like a product or a site.
  • Remind people of the value proposition.

CoreDogs is typical of a branded site. Look at the page header:

CoreDogs header

Figure 5. CoreDogs header

The name of the site is there. Just put a .com on the end of it, and you have the site’s URL.

There’s a logo. It ties in to the dog theme. Notice how simple it is. Easy to reproduce. The logo is used in other places, like CoreDogs’ Facebook page.

The value proposition is right there as well.

The CoreDogs color scheme is white, brown, and black. Dog colors. The header uses the scheme.

If you look closely, you can see some dog paw prints.

All of this builds a set of mental associations with the name “CoreDogs.”

If you build a site for yourself, a business, or a non-profit, keep branding in mind. Try to create an identity for the site, and link it to the value proposition.


You learned that:

  • The owners are the people who pay for the Web site.
  • Sites for private companies should make money, either directly (e.g., by selling through the site), or indirectly (e.g., by generating leads).
  • Users are in charge on the Web.
  • A value proposition tell customers why they should buy a company’s product or service.
  • Branding creates an identity, and reminds people of the value proposition.

What now?

We’ve talked about two typical commercial sites. But what about your site?

Your eMe

Where are we?

We’ve talked about two commercial sites. What about your site?

Why you should have a site

You should have a Web site, with your own domain, like, or

It will be yours to control. Want to show off your killer Magic the Gathering deck? Go ahead. Want to show photos of fun places you’ve been? No problem. Want to list the best dog parks around? OK. It’s your site, so you get to decide.

Use your site to show the Web skills you’ve mastered. In CoreDogs, you’ll learn how to show pictures, format text, make slide shows, quizzes, and other things. Impress your friends, or just make something for the challenge.

You can use your site to support something you care about. A local sports team, dog rights, Scottish independence. You could explain why the issue is important, and what your opinion is. Include photos, YouTube videos, and links to other sites.

Show your poetry, or artwork. Photos of you winning Best in Show. CoreDogs will explain how.

What do you want your site to be about?

What are you into? Acid techno? TMNT? Shoes? Basketball?

Exercise: What are you into?

List at least ten things you like. For me, that would be:

  • Buffy the Vampire Slayer and Angel
  • Zombie literature
  • First-person shooters – Borderlands rules!
  • Learning about tech
  • Drupal
  • Sick jokes
  • Mango juice!
  • Coffee
  • Fail blog
  • Sarah McLachlan

Enter the ten (or more) things here.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

Pick two or three of the things you’re into. For each one, list some stuff you would put on your site. For example, for Buffy the Vampire Slayer, I might have stuff on:

  • Willow (sigh)
  • The musical episode in season 6 – the best television ever!!
  • Faith, the bad slayer. 5×5, B.
  • Glory, the bad god. Sometimes.
  • The preacher in season 7. The scariest evil doer of all time.
  • Why Dawn is so annoying. Really. She is irritating beyond belief. Such a meat puppet. So is Connor, in Angel. Blech.

Exercise: Stuff about the things

Pick two of the ten things you wrote down earlier. List stuff you would say about those things.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

Now you’ve got some ideas for your site.


Looking for a job? A Web site will help. Employers can get to know you. They can also see your mad Web skillz.

If you do try this, check out the article Personal brands: An introduction.

What now?

Web sites cost money. Let’s talk about that.

Site cost

Where are we?

This chapter is about what makes a Web site good. A good site serves owners. We’ve talked about how a site can increase sales. But owners want to control costs as well. Let’s talk about that.

This lesson’s goals


  • A business that has a Web site must pay to (1) create a site, (2) run the Web server and its infrastructure, and (3) keep the site’s content up-to-date.
  • Web servers for most small business sites cost from about $20 to $200 per month to run.
  • A content management system (CMS) can reduce the cost of updating a Web site, by (1) reducing the cost of creating the site, and (2) letting less skilled people update the site.

Types of cost

The value proposition and branding are about sales. They’re about getting people to come to the site and do business.

But profit is sales minus cost. If the site is too expensive to run, the business won’t make a profit. Owners want sites that are cheap to run.

Creating the site is obviously a major expense. But it’s not the only one. Once a site is up and running, there are two main types of costs:

  • Technology operation, particularly the Web server.
  • Keeping the site up-to-date.

Of the two, the second is usually more expensive.

Technology costs

Every site needs a Web server, a computer that sends data to browsers. The server needs to be in an air-conditioned room, plugged in to a power outlet, and connected to the Internet. It needs to be kept secure. The data needs to be backed up regularly, so it can be restored if something goes wrong.

All of this costs money. But not much, at least for a typical small business. Very few companies run their own servers. Instead, they pay other companies to run the servers for them.

Hosting companies run Web servers, and sell space on them. CarlysSchool.Com could spend as little as $10 per month on its Web server. You’ll learn more about this later.

WanderingDog.Com might need more power. But, unless the site became very popular, it would not cost more than $200 per month. That’s a lot cheaper than a physical store!

There can be other technology costs as well. For example, Carly might buy a PC for her store, so she or someone else can update the site from there.

Keeping the site up-to-date

Someone has to keep the site up-to-date. This labor cost is often the most expensive part of running a site.

CarlysSchool.Com might not change very much over time. Add new courses, change the starting dates of the next courses, change prices. Maybe a few changes per month.

WanderingDog.Com would change a lot. New products would come out. Older products would be retired. There would be new expert reviews all the time. The site would change every day.


  • A business that has a Web site must pay to (1) create a site, (2) run the Web server and its infrastructure, and (3) keep the site’s content up-to-date.
  • Web servers for most small business sites cost from about $10 to $200 per month to run.
  • A content management system (CMS) can reduce the cost of updating a Web site, by (1) reducing the cost of creating the site, and (2) letting less skilled people update the site.

What now?

This chapter is about what makes a Web site good. We’ve talked about users and owners. What about the people who build the site? What makes a site good for them?

Site builders

Where are we?

A good Web site serves users, owners, and builders. We’ve talked about the first two. Now let’s see what people who make Web sites want.

This lesson’s goals

Let’s talk about three things:

  • Satisfying users and owners.
  • Productivity.
  • Pride in craftsmanship.

Satisfying users and owners

At the beginning of a project, owners and builders sit down together. Here are three different ways the conversation might go:

Conversation 1. The conversation is about the business, who its customers are, what customers want, how the business makes money.

Conversation 2. Owners list tech they want, like lots of Flash, and animation, and movies, and sound, and pop up ads. Some Webers, particularly inexperienced ones, will enthusiastically agree, and start working.

Conversation 3. Owners say, “You’re the experts. Build a good site. Let us know when you’re done.” The Webers guess about business goals and customer needs.

Conversation 1 is a good start. It keeps everyone focused on business goals and user needs. The owners have a good chance of ending up with a site that serves business and user goals.

Conversations 2 and 3…, well, it’s not going to be pretty. The owners will get a site that people don’t want to use, and that doesn’t serve the business. The owners will be angry with the Webers, the Webers will be angry at the owners, and both will be angry at the users.

Experienced Webers know that a successful project is as much about the business as the tech. Wise owners know this, too.

One of the worst things Webers can do is to get some initial input from owners, go away and build a complete site, and then present it to owners. It’s unlikely that owners will like what they see.

Why? Because business and user needs aren’t all known when the project begins. Some goals are known at the beginning, but others are uncovered as the project goes along.

Owners and builders should meet every week or so, and review the work so far. Over time, they’ll get a better idea of the final goals of the site.

Goal changes can be frustrating. Webers could have spent hours creating something, only to be told, “Oh, now that I’ve seen it, I guess we don’t want that after all.” This is normal. It’s simply the way things work in the real world.

At some point, owners and builders will need to throw away some of their work. It takes courage to say, “OK, we were wrong about that goal. Let’s change it.”

But what’s better:

  • Keep going down a path you know is wrong?
  • Change direction, and work towards a site that might actually succeed?

To make a good site, start with wise owners and Webers, who accept joint responsibility for the project.


Suppose you’re starting a journey. The time it takes depends on:

  • Whether you go in the right direction.
  • How quickly you travel.

Working together helps owners and builders move in the right direction. Productivity is about how quickly they travel.

Builders try to:

  • Use the right tools.
  • Reuse their work.


Builders need tools to write programs, edit images, and do other things. We won’t talk about them all right now. That comes later.

I’ll just give you one example here. Suppose you want to make a page like this:


Figure 1. Output

You open an editor, a program that lets you type and save text. Editors are like word processors, but without all the formatting and stuff. Just plain text.

You type this:

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <script type="text/javascript"
    <p>Dogs are the best.</p>

Figure 2. Your code

You try it, but it doesn’t work.

You left something out. Line 8 should have been…


... instead of…


That one missing character – a / – makes all the difference.


You’re kidding. That one thing?


Yes. That one character.


That’s stupid!


Computers are really stupid. They have no common sense at all.

Unless you program them to detect errors like that, they won’t.


Hmm. That might make me crazy. Trying to find mistakes like that.


Get ready to be frustrated.

You have to be patient when doing computer work. Patient with the computer, and patient with yourself.

I make mistakes like the missing character all the time. I’ve learned how to keep going.

But all is not lost. Read on.

Remember, you use an editor to type in your code. There are many editors you can use to write pages. Two I talk about later are Notepad++ and Netbeans.

Suppose you use Notepad++. Here’s what the page with the error looks like when typed into Notepad++:

Code in Notepad++

Figure 3. Code in Notepad++

Here’s what it looks like in Netbeans:

Code in Netbeans

Figure 4. Code in Netbeans

Netbeans shows you that something is wrong. Put the mouse cursor over the error, and see this:

Error message

Figure 5. Error message

Netbeans can analyze your code. It can show you errors it finds. It doesn’t always know exactly what is wrong, but it tells you that something is.

Netbeans takes longer to learn than Notepad++. But most Webers prefer tools like Netbeans. Tools that show errors make you more productive.

Of course, Netbeans will only show some errors. But some is better than none.

So the right tools make builders more productive.


Reuse is another way to be productive. The idea is to create something once, then use it again and again.

Templates are great examples of reuse. Most Web sites have a standard look for their pages. For example, most CoreDogs pages look something like this:

CoreDogs template

Figure 6. CoreDogs template

I wrote the code for the template once. It gets reused again and again. So the effort I spent on the template pays off again and again. At the time I’m writing this, I’ve reused the template more than 900 times.

W00f! A productivity win.

Templates also make the site easier to change. Suppose I wanted to change the CoreDogs logo to this:

New logo

Figure 7. New logo

I just change the code in the template, and every page in CoreDogs would change.


Webers love to show off their best stuff. Just like carpenters, writers, artists, and engineers. It feels good when someone says, “That’s good work.”

There’s a danger, though. A Weber can make a page too complicated, just to show off his/her skills. This can increase the cost of a site, and even make it harder to use. Webers should remember that they’re creating something for owners and users, not for themselves.


  • Owners and builders need to work together to make a Web site good.
  • Goals change during a Web site project.
  • Owners need to constantly review what builders make.
  • Using the right tools makes builders more productive.

What now?

A good Web site serves users, owners, and builders. We’ve looked at things that are important to all three.

Let’s summarize, and then move on to the next chapter.

What "good" means

What’s good?

So what makes a Web site “good?” Here’s what I think.

A good site helps people meet their goals. It helps the people who use it, the people who own it, and the people who build it.

Sometimes you can tell a Web page is bad, just by looking at it. Here’s an example:

Bad page

Figure 1. Bad page

But “goodness” isn’t just a matter of look. You need to think about what a site is for before you can decide whether it’s good.

Look at Google:

What do you think of this?

Figure 2. Google

This is so plain. Nothing fancy at all.

Is it good? I would argue that, yes, it’s good. Because it helps you search.

Learning about goodness

What does this view of goodness mean for you, as you learn about the Web’s core?

It might lead to you think about things that are not “tech” at all.

For example, a page has to be readable to be useful. Figure 1 shows that part of readability is about fonts and colors.

But readability is also about the writing. No spelling errors. Short sentences. Simple words. All of these things affect how easy text is to read.

Good writing isn’t about tech. But it affects site goodness. So, CoreDogs talks about writing for the Web.

The rest of this book

This book – Foundations – has three more chapters.

  • Clients and servers. How Web browsers and Web servers work together.
  • Basic Web sites. How simple sites work.
  • Interactive sites. How Web pages change based on what users do.


Clients and servers

Everything that happens on the Web involves at least two computers: a client and a server.

Web client and server

Figure 1. Web client and server

The client is the Web browser on your computer. The server is the place where Web pages come from.

This chapter tells you what you need to know about clients and servers.

Thinking in layers

This lesson’s goals

Web tech is messy. Learn a way of thinking that makes it easier to understand.

The problem

Web tech is complex. Lots of pieces, all connected together.

Don’t try to understand it all at once. You’ll just get confused. Everyone does.

You need a way to break the Web up into chunks. Then you can understand each chunk by itself.

Just as there are different ways to slice cheese (drool!), there are different ways to slice up the Web. This lesson shows one way to slice up the Web to make it easier to understand.

Alison and the light layers

Here’s Alison.


Here’s Alison dancing to the light of her favorite lamp.

Alison dancing

Alison doesn’t pay much attention to the lamp. If she needs light, she turns it on. If not, she leaves it off.

Alison knows how the lamp works. She knows about bulbs, electricity, switches, and stuff. But normally she doesn’t think about all that detail. Too dark? Turn the lamp on. That’s all she needs to do.

Only when the lamp doesn’t work does Alison need to think more. Suppose she paws the switch and nothing happens. She remembers what she knows about lamps, and first checks to make sure the lamp is plugged in. It is. OK, how about the bulb? Aha! It’s burned out. Get a new one, put it in, turn on, and dance, baby, dance!

Alison thinks about the lamp in layers. She normally thinks at the on/off layer:

Lamp layers

The on-off layer is simple. The lamp is on, or it’s off. That’s it. Thinking at this layer doesn’t take much time, or much learning. And it’s useful. When Alison has the goal “get light,” the on-off layer is all she needs to think about.

But if the lamp doesn’t work, then Alison thinks about the lower layer. Bulbs, plugs, and stuff. Things she can usually ignore.

We think in layers all the time. Cars, stereos, even our bodies. Life is easier when you can ignore details. Our brains would get clogged if we had to keep all of the details in mind all of the time. So we normally think at the higher layers, ignoring the details that make those layers work.

Web layers

The Web is like that, too. It’s best to ignore the details most of the time. But if you want to create and maintain Web sites, you need to understand what’s going on under the hood. Just a little bit.

We’ll talk about the Web in three layers:


The top layer actually shows the pages. That’s the layer most people work in most of the time.

The middle layer is about how computers send information to each other. The bottom layer is all the geeky electronics and stuff.


Is there really a layer called “bucket o’ numbers?”


The layers are just ways of thinking about what is going on. I made up this three-layer stack for CoreDogs.

Other writers use different stacks, depending on how detailed they want to get. Talk to a geek, and you might hear about seven layers. But CoreDogs covers only the most important stuff. Three layers is enough for that.


The Web is complex. Lots of pieces.

It’s easier to think about it in layers. When you think about one layer, you can ignore the others.

The Web has three layers: display, service, and bucket o’ numbers.

What now?

Let’s talk about the lowest layer.

The bucket o' numbers layer

Where are we?

On the previous page, you learned that thinking in layers is important. Otherwise, your brain might get overloaded.

This page explains what you need to know about the bottom layer: the bucket o’ numbers layer.

This lesson’s goals

By the end of this lesson, you should:

  • Know what TCP/IP is.
  • Know what an IP address is.
  • Be able to find the IP address of your computer.
  • Be able to find the find the IP address of a Web site.
  • Know what DNS is and why it is used.
  • Be able to find the owner of a domain name.

Ouch! That’s a lot of acronyms. My brain is already switching off.


I hear you. Some books throw lots of complicated stuff at you all at once. Your brain gets into the habit of giving up.

Tell your brain to try again. CoreDogs is slow and gentle. Your brain has a chance here.

It’s all in the numbers

The bucket o’ numbers layer sends numbers from one computer to another. It doesn’t care what the numbers are. Email? Photo? Bank balance? Web page? It doesn’t care. It’s all just numbers. The higher layers (the services and display layers) figure out what the numbers mean.


It can’t be just numbers. Web pages have letters, A, B, C, and the rest. Where do all the letters come from? And photos. They aren’t numbers.


Good question! Actually, it is all numbers. That’s all computers ever deal in.

Computers use numbers to represent letters and symbols. Each one is given a code. For example, “A” is 65, “B” is 66, “*” (an asterisk – geeks call it a “splat”) is 42, etc.

To send the word “Renata,” a computer could send the numbers: 82 101 110 97 116 97.

Photos are made of numbers as well. The numbers represent colors for dots on the screen.

At the bucket o’ numbers layer, everything is just numbers.

The Internet links millions of computers together. Millions and millions and millions!

Here’s what the Internet looks like:

Lots of simple links

Figure 1. Lots of simple links

The computers are connected by simple links. Each link connects only two computers. Computers in the network are often called nodes.

When you connect your home computer to the Internet (over cable, telephone, or whatever), you connect to an Internet gateway. This is a computer that passes data back and forth between the Internet and individual computers. In Figure 1, node A is a gateway computer.

All computers on the Internet talk to each other using a protocol called TCP/IP. The details don’t matter. We don’t even care what TCP/IP stands for.


I hear the word “protocol” a lot. What does it mean?


A protocol is a set of rules for communicating. For example, suppose the telephone rings. What do you do?


I pick it and say “Hello.”


Right. You could say “My brain is made of meat” instead of “Hello.” Why don’t you?


When I say “Hello,” the caller knows what to do. “Hello” means “I’m ready to listen.” If I talked about brains, the caller wouldn’t know what to do. Maybe hang up and call the cops.


The “hello” thing is a protocol for people. A rule for communicating.

It’s the same with computers. TCP/IP is a set of rules for one computer sending numbers to another. A TCP/IP message has data about which computer is sending the numbers, which computer the numbers are being sent to, the numbers themselves, and other stuff.

There’s software in your Windows PC, Mac, Linux machine, or whatever, that knows how to talk TCP/IP. They all have to talk TCP/IP, if they want to use the Internet.

IP addresses

Computers on the Internet need to know how to identify each other, so each machine can send numbers to the right destination computer. Each computer has an IP address. It’s four sets of digits with periods (.) in between. For example:,, and

Every computer on the Internet has to have an IP address. There are tricks for using one IP address for several computers. But, in the end, each machine has an IP address.

Exercise: Find your computer's IP address

You can find out the IP address of your computer. On a Windows PC, bring up the Run dialog. The easiest way is to hold down the Windows key and press R. The Windows key looks like this:

Windows key

Type cmd and press Enter. You’ll see a command line window. Mine looks like this:

Command line window

Type ipconfig and press Enter. You’ll get a bunch o’ output. The IP address will be labeled something like IPv4. Type it in the solution section below.

If you have a different type of computer, use Google to find out how to get your computer’s IP address. Explain how in the exercise discussion.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

Domain names

IP addresses are used for all Internet traffic, including the Web. But numbers are hard for people to remember. Imagine an ad that says: “Free download! Go to today!” Ack!

Instead, we have the domain name system (DNS). When you register a domain name, maybe, you associate the domain name with an IP address. So your ad can read: “Free download! Go to today!” Much better.

Exercise: Find a Web site's IP address

You can find the IP addresses of Web sites. There are several ways to do it. One way is to use the ping command.

Go to your computer’s command line. (On a Windows machine, hold down the Windows key and press R, type cmd and press Enter.) Type ping and then a domain, like:


Your computer will ping the computer associated with the domain name. A “ping” is an “are you there?” message, used to tell if a server is running. As a side effect, ping will tell you the IP address of the server.

Some servers won’t respond to pings. The server that answers to, for example, ignores pings.

Find the IP addresses of some of your favorite Web sites. (I like and

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

How does your computer know what IP address matches what domain? By asking a domain name system (DNS) server. A DNS server is a computer with a table in its memory (or on disk), like this:

Domain name IP address
... ...

When you type a domain name like into a browser, your computer sends the DNS server the domain name, and gets back the IP address. Your computer uses the IP address to send the actual message.

When you register a domain name and associate it with an IP address, the new name and IP address spread across the Internet. That is, the DNS servers tell each other that there is a new table entry.

You can find out who registered a domain name using a whois service. Try this exercise.

Exercise: Play the Weird Domain Game

Think up a strange domain name, like Go to and type it in. The one who comes up with the strangest name wins.

You can find some strange stuff. (There is a

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?


  • Computers on the Internet use TCP/IP.
  • Computers have IP addresses to identify them on the Internet.
  • You know how to find the IP address of your computer.
  • You know how to find the IP address of a Web server.
  • DNS servers associate domain names with IP addresses.
  • You know how to find the owner of a domain name.

What now?

You know all you need to know about the BoNL. Let’s talk about the services layer.

The services layer

Where are we?

We talked about the bucket o’ numbers layer. Now let’s move on the services layer.

This lesson's topic

Figure 1. This lesson’s topic

This lesson’s goals

By the end of this lesson, you should:

  • Know that a service is something one computer does for another.
  • Know how the email protocol SMTP works.
  • Know how the Web protocol HTTP works.

A “service” is something that one computer does for another. Like sending email, fetching Web pages, saving data to a database, whatever. Email is one of the easiest services to understand, so let’s start with that.

Sending email

Jake wants to send an email to Jules. Jake’s email address is Jules’ is

Jake starts up his email client. Jake uses Windows Mail. Windows Mail runs on his own PC in his kennel. Jake types in a message. When he’s ready, he clicks the Send button.

Email client

Figure 2. An email client

The term “client” has more than one meaning. Sometimes, “client” means the physical computer Jake is using. Sometimes, “client” means the email software running on the computer (Windows Mail). You have to figure out from the context what is meant.

Jake’s PC can’t send email by itself. It doesn’t have a domain name (the “” part of “”). Instead, Jake’s email client asks another computer to send the email. This computer is the email server for It offers email service to everyone with an EvilDoom account.

Client and server

Figure 3. Client and server

Just like the word “client,” the word “server” has more than one meaning. Sometimes, it means a physical computer. Sometimes, it means some software running on that computer, that offers services.

There’s lots of different email server software. qmail, Microsoft Exchange, and others.

When Jake sets up Windows Mail (his email client software), he has to tell it which server to talk to:

Identifying a server

Figure 4. Identifying a server

Now the client will know where to send messages.

OK, so Jake has finished typing his message, and clicks the Send button. Windows Mail on Jake’s PC starts a conversation with the email server. It’s like a conversation between dogs. One computer says something, the other replies, the other replies to that, and so on.

The conversation between email client and server goes something like this:

Client: HELO
Server: 250 Hello
Client: rcpt to: jules (at)
Server: 250 Ok
Client: DATA
Server: 354 End data with .
Client: Subject: Study group meeting
Client: D00d,
Client: I'm buying the coffee tonight.
Client: Jake
Client: .
Server: 250 Ok Mail queued for delivery
Client: QUIT
Server: 221 Bye

The conversation follows some rules, such as using HELO to start, and ending the message with a period (.) on a line by itself. The set of rules are called the simple mail transfer protocol (SMTP).

Jonathan Postel created the SMTP protocol. He wrote down the rules in a document called RFC 821. It’s great reading if you have trouble sleeping. You can see it at

When Microsoft’s programmers created Microsoft Mail (the client program Jake is using), they read RFC 821, so they’d know how their program should talk to servers. They put in an instruction something like this:

print "HELO " & computer_name;

Now suppose that EvilDoom is running the qmail server. The dude who wrote qmail, Dan Bernstein, read RFC 821. So he knew what clients would send to his server software, and what responses they would expect. He wrote code something like this:

get Command;
if ( Command == 'HELO' ) call StartMessage;

The two functions of a client

You can see that the client software has two main functions.

Client functions

Figure 5. Client functions

First, it has to support the user’s tasks. For email, that means (1) letting the user type in messages to send, and (2) showing messages from other people.

Second, the client has to be able to talk to a server. They have to share the same protocol (set of communication rules), otherwise they won’t be able to interact.

Standards rock!

The only reason that the Microsoft Mail client can talk to the qmail server is that they both use SMTP. That is, they both follow the rules in RFC 821 that Jonathan Postel wrote.

RFC 821 is a public document. Anyone can see it. Some software companies use private protocols. They won’t tell anyone how they work.

Who creates standards? All sorts of people, but some groups are more important than others. SMTP is supported by the Internet Engineering Task Force, an open community that reviews and adopts standards.

That’s enough email for now. Let’s move on to the Web.


HTTP stands for the hypertext transfer protocol. It’s a standard, just like SMTP. However, it’s designed to support sending data on the Web, not sending email.

Service-layer protocols are like that. They support specific types of communication. There are hundreds of protocols, for instant messaging, mapping, gaming, and lots of other things. But to a Weber, only a few are important.

HTTP is maintained by the World Wide Web Consortium, another nonprofit standards group. The W3C is the most important standards group for the Web.

The setup is the same as before, with a client and a server. But this time, the client is a Web browser, and the server is a Web server.

Web client and server

Figure 6. Web client and server

There are many Web browsers, including Firefox, Google Chrome, Safari, Opera, and Internet Explorer. We’ll use Firefox in our lessons, because it has nice features for Webers.

There are many Web servers as well. The most widely used is the Apache Web server. It runs on just about every computer there is.

HTTP is the set of rules that browsers and servers use to communicate. Browsers follow the rules when they talk to Web servers. Web servers follow the rules when they respond to Web clients.

Suppose Jake clicks on this link on a page:


Figure 7. Superdogs

Here’s the conversation between the browser and the server.

GET superdogs.html HTTP/1.1

HTTP/1.1 200 OK
Last-Modified: Mon, 25 Dec 2006 22:22:22 GMT
Content-Type: text/html
(Web page content)

The HTTP standard document says that clients should use GET to fetch content. Servers should use the code 200 to say that everything is OK. There’s lots more to HTTP, but you get the idea. HTTP is a set of rules that browsers and servers use to talk to each other.

Going deeper

  • HTTP headers. A short CoreDogs article on HTTP response headers.


In this lesson, you learned:

  • That a service is something one computer does for another.
  • How the email protocol SMTP works.
  • How the Web protocol HTTP works.

What now?

A Web browser gets data from a Web server, and sends it to the display layers. That’s coming up next.

The display layers

Where are we?

We’re working through the layers of the Internet. We just talked about the services layer. On to the display layers.

Where we are

Figure 1. Where we are

This lesson’s goals

By the end of this lesson, you should:

  • Know what HTML is.
  • Be able to look at the HTML behind a page.
  • Know that CSS and JavaScript are important.

The display layers

The display layers take data from HTTP and other protocols, and show it to the user.

There’s different display software for different data. There are programs to show maps, different programs to show movies, different programs to play sound, etc.

We’ll only talk about Web pages. The most important display technology is …

The hypertext markup language (HTML)

An HTML file is plain text. No pictures, sound, or anything like that. Just text.


But, but, ...


You want to say, “It can’t be just text, there are photos and things.” Right?




The photos are stored in separate files. Each one is downloaded separately from the HTML file. We’ll see that later.

HTML is a language for describing what a Web page looks like. It contains the content of a page (the actual text), and some of the formatting.

HTML files usually have an extension .html, or sometimes .htm (you should always use .html). So a file named duck.html contains HTML.

An HTML file doesn’t contain the actual image of the Web page, that is, a picture with the right fonts and things. Instead, an HTML file has instructions that tell the browser how to display a page.

Suppose an HTML file has this in it:

<p>Ducks are <em>great</em>!</p>

Figure 2. Some HTML

The <?> things are called tags. The browser interprets the tags, choosing fonts, colors, spacing and such, before rendering a screen for the user. “Rendering” means “showing” in geekese.

Here’s what the tags above might produce:

Rendered HTML

Figure 3. Rendered HTML

You can try it in your own browser.

This doesn’t look much like the HTML in Figure 2. The fonts are different, for example. But remember, HTML is a set of instructions for how to show things. <h1> means to show a header. <p> means to show a paragraph. <em> means to emphasize.

It’s up to the browser to decide exactly how to show a header, a paragraph, and so on. In Figure 3, the browser showed big, bold text for <h1>, and smaller text for <p>. It used italics to emphasize content.

Inspecting a page’s HTML

You can tell your browser to show you the HTML behind the page. In Firefox, press Ctrl-U, or right-click on the page and select View Page Source. Other browsers do it differently, but right-clicking will usually get you there.

Look at the source of this page, the one you’re looking at right now. You’ll see lots and lots and lots of HTML. Don’t be discouraged. The pages you create in the book CoreDogs will be much shorter.

Exercise: Finding the headings

Look at the HTML for this page. Find the <h1> tags. Match them up to what you see in the browser. What text is inside the <h1> tags? Type it below.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

Styling HTML

Most Web pages have other things besides HTML. Take the page you’re looking at now. There are images, like the dog logo at the top of the page. But the image is not stored in the HTML. It’s in its own file, that your browser downloads separately.

There are also style sheets. If you look at this page’s HTML, you’ll see lines like:

<link type="text/css" ... href=".../style.css">

The file style.css has rules that tell your browser how to display HTML on this page.

Let’s go back to the duck code. Remember that we had this:

<p>Ducks are <em>great</em>!</p>

Figure 2 (again). Some HTML

It looked like this in a browser:

Rendered HTML

Figure 3 (again). Rendered HTML

Suppose we wanted the heading to be green. We could add a style rule like this:

h1 {
    color: green;

You can try it.

The HTML doesn’t change, but the way it looks does change.

The language for specifying style rules is called CSS, for cascading style sheets.


A Web page has content, formatting, and one other thing: behavior.

People interact with Web pages. The most familiar user behavior is clicking on a link. But people can do other things on Web pages. Fill in forms, expand menus, watch movies, ...

Here’s an example. Suppose you wanted to show the user a joke, but the joke would depend on the user’s age. Users under 10 years old would get a booger joke. Others would get a more “mature” joke. In the field below, type in your age and click the button.


Try typing various things into the age field. Note that it handles errors, like negative ages.

HTML and style sheets can’t handle button clicks by themselves. You need to add a program to the page, a set of instructions to tell the browser what to do when the user clicks the Show Joke button.

The programming language you write these programs in is called JavaScript. It’s harder to learn than HTML or CSS. But don’t worry. We’ll only look at a little piece of it.


In this lesson, you learned:

  • What HTML is.
  • How to look at the HTML behind a page.
  • That CSS and JavaScript are important.

What now?

This chapter explained the three layers of the Internet. You just saw how simple HTML and CSS work.

In the next chapter, you’ll see how an entire Web site works.


Basic Web sites

You’ve read about what makes a Web site good. You know how clients and servers exchange data.

Now let’s see how a simple Web site works. You’ll:

Where Web pages come from

This lesson’s goals

When someone looks at a Web page, s/he sees a display on a computer screen.

A Web page

Figure 1. A Web page

There are photos and drawings, text, different colors, boxes to type in, buttons, and other things.

But what makes all that? What actually puts the text on the screen, in the right fonts and the right colors?

The user experience

To the user, a Web site is a bunch of pages. Here’s a site with two simple pages.

A Web site

Figure 2. A Web site

You can try it.

The site has two pages. Each page has two things:

  • Information it displays, like photos and text.
  • Behavior, like clicking a link to go to another page.

The user’s experience of the site is made up of both information and behavior.

The Web browser creates this experience for the user. Browsers like Firefox, Chrome, Safari, Opera, and Internet Explorer. It’s the browser that draws the text, shows the photos, and executes the behaviors.

Firefox is CoreDogs’ official browser.

But how does the browser know what information to show, and what behavior to execute? Here’s how:

  • The browser gets files from a Web server. (Recall that a Web server is a computer on the Internet that waits for browsers to ask for files, and then sends them.)
  • The files contain instructions on what displays to make.

Here’s how it works.

Fetch a page

Figure 3. Getting a Web page

Say the user is looking at cow.html (see Figure 1). S/he clicks on the link to pig.html (1 in Figure 3). The browser executes a behavior, that is, show the Web page pig.html.


How does the browser know to show pig.html and not some other page?


Because of this code in cow.html:

<a href="pig.html">pig</a>

This makes the browser show the word “pig” and underline it. When the user clicks on “pig,” the browser loads pig.html.

You’ll learn more about this later.

The browser asks the server for some files (2 in Figure 3). The server reads the files from its disk drive, and sends them back to the browser (3 in Figure 3).

In step 4, the Web browser renders the files, creating the display the user sees.


Here’s part of the file pig.html. It’s a file that the browser got from the server.

  I am a pig. I know a <a href="cow.html">cow</a>.

Figure 4. What the server sent

It’s some instructions on what to show on the user’s computer screen.

The browser follows those instructions. It creates a display like this.

From the pig screen

Figure 5. From the pig screen

When a browser renders a page, it follows some instructions and creates a display for the user.

Different types of files contain different types of instructions. The data in Figure 4 are in the file pig.html. They’re instructions in the HTML language.

The data that make the photo of the pig are in a different file. The name of that file is eunice.jpg. eunice.jpg is a bunch o’ numbers, just like every file. The numbers follow the JPEG standard, created by the Joint Photographic Experts Group.

The Weber’s job

Where are we?

  • The browser gets files from a Web server. The files contain instructions on how to make displays.
  • When a browser renders these files, it follows the instructions in the files to make a display.

So, these files on the server. How do they get created?

A Weber (someone who makes Web pages) decides on a page’s:

  • Content – the text and images.
  • Formatting – what the content looks like (colors, fonts, etc.).
  • Behavior – e.g., what happens when a user clicks on a link.

Often the Weber makes a rough drawing:

Page sketch

Figure 6. Page sketch

Then the Weber creates files that will make the browser render a page like that.

The Weber types in some of the files, like the HTML in pig.html (see Figure 4). Typity typity, type, type, type, type.

For photos, the Weber won’t type in color codes. S/he will get a photo from somewhere, and maybe change it a little. I got the pig photo from the US Department of Agriculture.

Finally, the Weber uploads all of the files to the Web server, where Web browsers can get to them.

What you will learn

The second book in CoreDogs – ClientCore – will help you learn how to create a Web experience for the user.

You’ll learn how to make the files that the browser will render the way you want. You’ll learn how to write code like this…

  I am a pig. I know a <a href="cow.html">cow</a>.

Figure 4 (again). Code that the browser rendered

... that a browser will render like this:

From the pig screen

Figure 5 (again). From the pig screen

And you’ll learn how to put the files on a Web server.

You’ll need a Web server to put your files on. Soon, you’ll learn how to get your own server space.


  • Web pages have content, format, and behavior.
  • The Web browser creates the user’s experience of a Web page.
  • The browser grabs files from a Web server.
  • The browser renders the files it gets from the server, that is, it follows instructions in the files to create displays.
  • The Weber creates the files that the server sends.

What now?

URLs are key to how Web browsers and servers work together. The next two lessons are about URLs. Let’s start by talking about what URLs are.

What URLs are

Where are we?

Browsers ask servers for files. How do browsers know which files to ask for? They use URLs.

This lesson’s goals

This lesson is about URLs. You’ll learn:

  • What a URL is.
  • How browsers work out how to render data they get from a URL.
  • That clickable links on Web pages have URLs embedded in them.

URLs are addresses

Every file on the Web has a URL (uniform resource locator). Whether it’s an HTML file, a photo file, whatever, it has a URL.

A file’s URL is its unique address on the Web. Just as a cell phone has a unique telephone number, a file has a unique URL.

It’s a little more complex in some cases, but let’s ignore those cases for now.

Here’s an example of a URL:

The URL has several parts. You’ll learn how the pieces work in the next lesson.

How URLs get into browsers

To get a URL into your browser, you usually either:

  • Put the URL into a browser’s address field.
  • Click on a link to the page.

Try both for the URL above. Copy the link and paste it into your browser’s address field:

Address bar

Figure 1. Address bar

Now for the second method. You can click here to visit the URL.


That URL again is It’s a URL for a page, not a photo or some other thing.

How do I know it’s a URL for a page?

The part of the file name after the last period (.) is the file’s extension. It tells the browser what type of data is in the file. Then the browser can decide how to render the file.

Every browser has a table like this:

Extension Render as...
html Web page
jpg Image
png Image
... ...

Figure 2. File extensions and types


  • Every file on the Web has a unique URL.
  • The file’s extension tells the browser what type of file it is.

The cow page

Here’s the cow page again.

Cow page

Figure 3. Cow page

You can try the page.

The URL of the page is

There are three things on the page:

  • Some text, like “I am a cow.”
  • An image.
  • A link to the pig page.

Here’s some code from cow.html. The browser renders it to make the three things.

  <img src="bessie.jpg" alt="Bessie">
  I am a cow. I know a <a href="pig.html">pig</a>.

Figure 4. Code from cow.html

Don’t worry about the details. We’ll cover them later. Just a couple of things to note for now.

First, the text “I am a cow” is in the file. You can see it in line 5.

But the cow photo is not in cow.html. So how did the photo get into the page? Look at line 2:

<img src="bessie.jpg" alt="Bessie">

The photo is in a separate file, called bessie.jpg.

The photo file has its own URL. bessie.jpg is shorthand for the full URL,

Copy and paste the URL into a browser. You’ll see the photo by itself, without the rest of the page.

So when you tell your browser to go to cow.html, your browser asks the server for two files:

  • cow.html
  • bessie.jpg

cow.html has instructions on how to draw the text and the link to the pig page. The instructions follow the HTML standard. bessie.jpg has data on how to make the photo. The data follow the JPEG standard.

OK, so there are three things that make the cow screen:

  • Some text.
  • An image.
  • A link to a pig page.

Let’s talk about the link.

This code makes a link:

<a href="pig.html">pig</a>

When the browser renders this, it does two things:

  • It shows something on the display.
  • It gets ready to execute a behavior.

The display is like this:

The pig link display

Figure 5. The pig link display

The browser draws the word “pig” in blue, and underlines it. That’s the display part.

The behavior? When the user clicks on the link, the browser asks the server for a new file. The link gives the URL of that file. The URL is usually for a Web page (ending in .html), but it could be for any type of file.

The full URL of the file is pig.html in <a href="pig.html">pig</a> is shorthand for that full URL.


  • Every file on the Web has a URL. A file’s URL is its address on the Web.
  • The file’s extension tells the browser what type of data is in the file.
  • Photos are stored in separate files from HTML pages.
  • Links contain URLs.

What now?

You can see that URLs are important things. Let’s learn a little about what a Web server does when it gets a URL.

How URLs work

Where are we?

You learned that a URL is the address of a file. Could be a page, could be a photo, could be something else.

Let’s dig a little deeper. What do servers do when they get a URL request from a browser?

This lesson’s goals

By the end of this lesson, you should know:

  • When a browser asks for the contents of a URL, it usually gets back the contents of a file on a server.
  • How a URL is mapped to a server file.

Suppose that a browser shows this.

Link rendered in a browser

Figure 1. Link rendered in a browser

It comes from this HTML.

<a href="">Bouncing ball</a>

There are two parts to the link. First, there’s the text shown to the user. That’s “Bouncing ball.” Second, there’s a URL: That’s where the browser will go if the link is clicked.

GETting a page

A user clicks the “Bouncing ball” link. What does the browser do?

First, it creates an HTTP GET request. We looked at HTTP earlier, in the lesson on the services layer. The request looks something like this:

GET /products/ball.html HTTP/1.1

The message is sent to a server. Which server? The one given in the URL.

The URL of the desired page is The first part – http – is the service-layer communication protocol to use. The second part – – is the domain name of the server. So that’s where the message is sent: to the server at

The rest of the URL (/products/ball.html) tells the server what data to return to the browser. That part of the URL matches a file on the server. A server might have 50,000 files that it can send to a browser. /products/ball.html is the particular file it should send.

URL paths and file paths

Let’s look at this more closely.

As you know, the files on the computer you’re using right now – PC, Mac, whatever – are organized into a directory tree. Windows calls directories “folders,” but they’re the same thing. Webers usually talk about directories rather than folders.

Here’s part of the tree on my Windows hard drive.

Directory tree

Figure 2. Directory tree

The Windows file path to the file renata.jpg is:


This means:

Start at the root of the C: drive.
Then go down into the dogs directory.
Then go down into the mydogs directory.
There you will find the file renata.jpg.

I can use this path in Windows programs. For instance, I could type the path into the Open File box of a Windows editor:

Windows file path

Figure 3. Windows file path

Other operating systems have different rules for file paths. A path on a Unix machine might look like this:


Unix (and Linux and similar things) don’t have drive letters, like C: or D:. And they use a / rather than a \ to separate subdirectory names.

Another difference is that Windows file names are not case sensitive, while Unix file names are case sensitive. So, in Windows:




refer to the same file. But in Unix:




refer to different files.

Beginners often forget this. Suppose you create a site on a Windows PC. You type the file name DepressedDoom.html in some places, and depresseddoom.html in others. It works fine on your computer, because Windows thinks that DepressedDoom.html and depresseddoom.html are the same file.

You upload the site to a Unix server (most Web servers run Unix of some sort), and the site breaks. Unix thinks that DepressedDoom.html and depresseddoom.html are different files.

Here’s the rule we follow throughout CoreDogs:

Always use lowercase for file names.

Mapping URL paths and file paths

OK. So we have URLs. They’re Web addresses for files. Like:

And we have file paths, like:


They look similar, don’t they? They both have slashes, things that look like directory names, file names, and extensions.

There’s a reason they look similar: they are different versions of the same thing!

A URL is really a file path, with some networkish stuff added.

On simple sites. Some advanced tech is different. Let’s ignore it for now.

How can a URL and a file path both refer to the same thing? By taking a directory on a Web server, and making it the root of a Web site.

An example

Here’s Jake, looking at a Web page on

Jake finds a ball

Figure 1 (again). Link rendered in a browser

Why is Jake’s browser showing him a link? Because of this HTML:

<a href="">Bouncing ball</a>

This link says to show the text “Bouncing ball.” If Jake clicks on it, his Web browser will jump to the page

Let’s look at what happens when Jake clicks.

Serving a file

Figure 4. Serving a file

Jake clicks on the link (1 in Figure 4). The browser looks at the code that created the link. The code is:

<a href="">Bouncing ball</a>

So the browser knows it should show the page

The browser creates an HTTP message to GET /products/ball.html (2). The Internet sends the message to the Web server.

The server at is a computer, with a hard disk spinning away. It runs the Unix operating system.

If you looked on the server’s disk drive, you would see a file with the path /sites/dd/products/ball.html.

Server files

Figure 5. Server files

This is the file with information on the bouncing ball.

Somehow, we want the Web server to use the URL the browser sent, to fetch the right file from its disk drive. It needs to convert the URL into a file path, then use the file path to read the file.

Translate URL into file path

Figure 6. Translate URL into file path

Suppose the server is running the Apache Web server software (it’s the most popular in the world). Apache has a configuration file, created by the DoomDog’s Web master. The file tells Apache how to run.

One of the settings in the file is DocumentRoot. The setting tells Apache where on the computer’s disk drive the files for the Web site are stored.

The Web master put all the data for the Web site in the directory /sites/dd. Then s/he set DocumentRoot to /sites/dd, so that Apache would know where to get the files.

The server takes its DocumentRoot setting (/sites/dd) and appends the URL path (/products/ball.html), giving /sites/dd/products/ball.html.

Computing the file path

Figure 7. Computing the file path

Now Apache knows where to get the file the browser asked for.

Here’s the process again.

Serving a file

Figure 4 (again). Serving a file

We’re at step 3. Apache has translated the URL to a file path on the server computer’s disk drive.

Apache reads the file (4), and sends its contents back to the browser (5). The browser renders the content for Jake (6). Recall that rendering is the process of making a display from code in a file.

Hooray! Jake is happy, and runs around and barks.


So for a URL like, is the server name, and /what.html is a file path?


Yes, that’s a good way to think about it.


But when I want to Google something, I don’t type I type There’s no file path in that URL. What does the Google server do?


Good question!

The server needs to get a file name from the path. If there isn’t a file name there, it adds one. That is, it uses a default file name.

Every server could use a different default, but in practice most use index.html. So, the URL maps to


So when I make a home page, I should call the file index.html? So if someone just types the domain name, they’ll get the home page?


Yes! That’s it! You are one smart puppy.

Servers actually have a list of default names, like index.html, index.php, default.htm, and so on. The server will grab the first file in the list that it finds.

For now, let’s assume it’s always index.html.


In this lesson, you learned:

  • That many Web page requests are actually requests for files.
  • How a URL is mapped to a server file.

What now?

Let’s put some of this knowledge into action. Time to buy a Web hosting account, and get real!

Buy hosting. Now!

Where are we?

You’ve learned how Web browsers and servers interact. Time to start putting your knowledge into practice. But first, you need your own home on the Web.

This lesson’s goals

By the end of this lesson, you should:

  • Know what “buying hosting” means.
  • Know about some different kinds of hosting.
  • Know what features to look for from a shared hosting plan.
  • Be ready to buy hosting.

You need a home on the Web

You need your own Web site. Yes, you do. A place for your own eMe. Really, you need your own Web site. With your own domain name and everything.


I know we talked about this before. I have a Facebook page. Remind me why I need a Web site.


Facebook’s great. But there are a few issues with it.

First, Facebook pages have Facebook’s logos, format, and ads. In other words, Facebook’s branding.

You want your site to be about you, or your company, or whatever you choose to promote. You don’t want people to be distracted by other stuff. Take the page you’re looking at now. It’s all CoreDogs.

With your own site, you have complete control. Choose the fonts, colors, images, you name it.

Second, Facebook limits what you can do. Say you’re an expert on zombies. You can make a site on how to survive the coming Zombie Apocalypse. You can put ads on your site, sell stuff through it, run events (“Come to the Spring Zombie Hunt!”), make some moolah. Dosh, cash, bread, simoleans.

You can do some of that on Facebook. But not everything you want.

Third, when you have your own site, you tell the world that you can do Web work. It’s a valuable skill that not everyone has.

Fourth, having your own site teaches you a lot about the Web. In fact, most of the exercises in the ClientCore and ServerCore books ask you to upload your solutions to your own site. You can’t do that if you don’t have a site!

One last thing. Suppose your name is Rover Blakenshot. You could register, and give yourself a cool email address, like You could give email addresses to your family and friends. Your brother could be You get to decide. Oh, the power! The power!


You forgot something.


What’s that?


Having your own site is so freakin’ cool!

Three things

You need to do three things to get your own Web site:

  • Get a domain name. The first part of the URL of all your Web pages. You and only you have that domain.
  • Get a hosting account on a Web server. This is a computer you put files on, that’s accessible over the Internet. Someone else runs the server for you. Recall that every server has an IP address, like
  • Tie them together. For example, suppose you register the name You get an account on a Web server that has the IP address You tie the two together. So when someone types into a browser, that gets translated into

Most domain names end in .com, .org, .edu, or .gov. These are called “top-level domain names.” There are other options, including .info, .biz, and .name. Wikipedia has a complete list.

Countries have their own top-level domain names. Like .au for Australia, and .uk for the United Kingdom.

Domain names are unique. You must choose one that nobody else is using.

There are two ways to figure out whether a domain name is available. The first way is to type it into your browser, and see if you get anything back. If you do, the domain is taken.

A more reliable way is to look up the domain database. There are Web sites that will do this for you.

A warning: be careful of the lookup service you choose. Some of the them might register the domain while you’re thinking about it. (I think this has happened to me, though it’s hard to be sure.)

One service that’s probably safe is Network Solutions. It will tell you whether a name you’re thinking about is available.

If you can’t get, don’t despair. Try,, and You’ll come up with something.

Exercise: Choose a domain name

Choose a domain name that’s easy for people to associate with you. It could be your name, though if you have a common name, domain names based on it might be taken.

Think of at least three options. Talk it over with your friends. See if they can come up with some good names.

If you have some advice for choosing domain names, please share it.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

What you get when you buy hosting

You get a bunch o’ stuff, but here are the main things:

  • Disk space on a server. This is where you’ll store your Web pages. Each server has an IP address. The hosting company will tell you what it is.
  • Some way to upload files to the server from your computer.
  • The right to associate your domain name with the IP address of your host.

More on what you get in a moment, but these are the basics.

A domain name is a separate purchase, but hosting companies make it easy to register a domain name during account sign up.

Types of hosting

There are lots of hosting plans, but they fall into a few main types.

Free hosting

Some companies will give you free server space, and insert ads in your pages. Avoid this type of hosting.

First, you usually don’t control the ads on your pages. You give your URL to a potential employer, and the first thing s/he sees is a flashing ad for “Hot Bondage Boys! Click NOW!” Think you’ll get that job?

Second, you don’t fully control your pages. The ads interfere, and sometimes even break your pages. The hosting company can change the size and placement of your ads, whenever it likes.

Third, the company doesn’t have much incentive to look after your content. If the disk drive with your site crashes, they might not be in a hurry to restore it from their backups. If they have backups.

Shared hosting

Cheap, and what you’ll use to begin with. With shared hosting, you share a server with other people. So you might have, say, fifty Web sites on the server, along with your own.

This usually works fine. Reputable hosting companies make sure that none of the individual sites uses too much of the server’s processing time.

The hosting company does most of the server management for you. They take care of basic software updates and such. They back up your files, in case something goes wrong. You can just worry about your Web site.

Most shared hosting accounts run on Unix machines. Some run on Windows machines.


I don’t know how to use Unix. So I should get a Windows server?


No! You should get a Unix account.

You interact with servers differently from the way you interact with your PC. For a Windows user, a Windows server is not easier to work with than a Unix server. They’re about the same.

But a Unix server will run more free software than a Windows server. All sorts of goodies, at your fingertips.

And remember that most Web servers run Unix. That means most employers use Unix servers.

Finally, Unix hosting accounts are often cheaper than Windows hosting accounts. Why? Because there are lots of free versions of Unix. Not so for Windows.

Shared hosting runs from about $5 USD to $10 USD per month. We’ll talk about some specific services later. But that’s about what you can expect to pay.


Do I have to spend the money?


You should. You get to create your own eMe, showing the world what you can do. That can get you a better job, at the very least.

You will stand out if employers see that you run your own Web site with your own domain. The proof is right there in front of them.

You’ll also learn more about the Web. You can add “manage Web sites” to your résumé, along with “create Web pages.”

Here are some approximate price comparisons:

  • One month of Web hosting = a meal at McDonalds.
  • One month of Web hosting = a pack of cigarettes.
  • One month of Web hosting = a movie rental.
  • One month of Web hosting = a coffee at Starbucks. No cookie, though.
  • One month of Web hosting = a magazine.

OK, now that you put it that way. I guess I can skip a small vanilla latté now and then.

Dedicated hosting

Web sites that need lots of power run on dedicated servers. That is, the site has its own computer. The hosting company maintains the computer – connects it to the Internet, keeps it running, backs up the data, etc.

The main difference between shared and dedicated is that dedicated hosts can support many more concurrent users without slowing down. “Concurrent” means “using the server at the same time.” Further, since you’re the only site on the computer, no other sites can interfere with yours.

Dedicated hosting starts around $200 USD per month, depending on the options you buy. For example, the more memory on your server, the more it will cost you (but the faster your Web site can run).

Virtual dedicated hosting

This is a hybrid of the two previous options. You share a host, but your account is configured so that it acts like a separate computer. You’re usually guaranteed to get certain performance from your server. Such-and-such processing speed, such-and-so memory, and so on. These services start around $40 USD per month.

If shared hosting is too slow, but dedicated hosting is too expensive, consider virtual dedicated hosting.

Of these options – shared hosting, dedicated hosting, and virtual dedicated hosting – you want to go with shared hosting to start with. It’s cheap, and Cheap is Good.

Choosing a hosting company

Choose a hosting company based on:


Make this low, but not necessarily the lowest. You usually get a discount if you pay yearly.


I’ve been burned by a company that went out of business. I ended up losing a domain name. Not fun.

I also had a site that stopped working because of a hardware failure. It took the hosting company more than a week to fix it. I wasn’t pleased with that company, either.

Choose a hosting company with a good reputation. Particularly for customer service. The company should have support people available around the clock.

One place to read hosting company reviews is ClickFire. They seem to be honest. In fact, Joe Eitel wrote an article Is Clickfire the Only Honest Web Host Review Site?.


Most companies offer more-or-less the same features on their shared accounts. They differ in the limits on their accounts. Look for:

  • Lots of server disk space. At least 200 megabytes (MB).
  • Lots of transfer. This is the amount of data that people can download from your site, without you being charged extra. A few gigabytes (GB) per month is good.
  • Email accounts. Make sure you can have twice as many as you think you’ll ever need.
  • PHP and Perl. Server-side programming languages.
  • Database server. MySQL is the most common. Make sure you get to create at least 10 databases.
  • Multiple sites per account. This means you could run several Web sites on the same account without paying extra. Each site will have its own domain name. Maybe one for you, one for your human, and one for your Webcomic. Look for at least three at no extra cost.

What does CoreDogs use?

CoreDogs runs on Hostgator. Their customer service is good. Security, backup, and other things are also done well.

You can buy a Hostgator account by clicking here:

Buy hosting

If you buy hosting using this link, CoreDogs gets a referral fee.

Either the Hatchling or Baby plans would work. The Hatchling plan is cheaper, but it only gives you one site per account. You will need to upgrade if you want more than one.

At the time I’m writing this, you can get a Hatchling plan for under $5 USD per month. Come on! That’s really cheap! How can you afford not to do this?

You can register a domain name during the buying process. Hostgator will set it up and link it to your account. Choose a domain name before you sign up, with a backup in case the one you want is taken. They’ll send you information on uploading files to your account. More on how to do that in the next lesson.

You don’t have to use Hostgator. An account with any reputable company should work fine. But make sure you check out the hosting company before buying. Really! It’s worth a little research.

What are you waiting for?

Well? What are you waiting for?

Get out your credit card. Or use your PayPal account. Buy a hosting account. Now!

Many, many, many people have their own Web sites. Thousands of regular, non-geek people have their own Web sites.

Now it’s your turn. If so many people can do it, so can you. And you have CoreDogs to help.

It’s the best investment you can make in your Web future.


In this lesson, you learned:

  • You need your own domain name and Web presence.
  • What you get when you “buy hosting.”
  • That there are different kinds of hosting.
  • What features to look for from a shared hosting plan.

Most important of all, you bought your own hosting account, and your own domain name.

You did, right?

What now?

In the next lesson, you’ll create a simple Web page about yourself. It will live on your own computer to start with. But then you’ll upload it to your server. This is the start of your eMe site.

eMe: Your first home page

Where are we?

You bought a hosting account. Now it’s time to add a home page.

This lesson’s goals

By the end of this lesson, you should:

  • Understand the information your hosting company sent you.
  • Be able to copy-and-paste HTML for your home page, and change it (a little) for your needs.
  • Be able to upload the home page to your server.
  • Be able to access your home page with your browser.
  • Be able to set up an email account on your domain.

Understanding your hosting account

When you bought your hosting account, you entered your email address. You got emails from your hosting company, telling you how to use your account. So let’s start doing some stuff.

Er, you did get a hosting account, right? If not, click this:

Buy hosting

If you buy hosting using this link, CoreDogs gets a referral fee.

OK, I’ll stop nagging now.

Here’s part of the email I got when I signed up with Hostgator:

Email from hosting company

Figure 1. Email from hosting company

(1) is the domain, like Remember that the domain name is really an alias to the IP address of your server, shown in (4). As we discussed earlier, DNS servers, also called name servers, help Web browsers make the connection between domain names and IP addresses. It can take a few days for new domain registrations to “propagate,” or reach all of the Internet’s DNS servers. Until that happens, you can still reach your Web site using the IP address directly. That’s what (6) and (7) are all about.

Your primary name servers are shown in (5). You might need this information if you want to move your server to another host.

Have a look at the home page of your Web site. Use your domain name or, if you just set up your account and your DNS entry hasn’t propagated yet, use the link at (7).

What you see isn’t exactly what you want. Let’s fix that.

Making a home page

You first home page will just be plain HTML, with some CSS to add a little color. You’ll follow these steps:

  • Start up a text editor with a blank file.
  • Copy-and-paste some code I’ll give you.
  • Edit it to add your name and some other things.
  • Test the file in a browser.

OK, let’s get started. I’ll be doing everything with Windows. The steps are the same for another OS, but you’ll have a different editor and FTP client.

Starting a text editor

An HTML file is just plain text. You can create it with any editor that lets you create plain text.

Which one to use for this project? You could use Notepad, the editor that comes with Windows. But it’s…, well, not very good. Let’s try something else.

Download and install Notepad++. It’s free, and fairly good. When you really start learning HTML, I recommend you use something more powerful, like Netbeans (get the PHP bundle). But use Notepad++ for now. It’s easier to get started with.

The Notepad++ Web site can be a little confusing. Here’s a direct link to the download page. As I’m writing this, there’s a big green button with Download on it. Download the installer (the program that will install Notepad++), and run it.


Can I just use Microsoft Word?


No! No! A thousand times no!

HTML files are plain text. Word files are not plain text. Word inserts strange characters that can break Web pages.

Some programs do a decent job of converting Word text into plain text. But if you’re starting a Web page from scratch, you’re better off using a plain text editor.

Start by creating a directory for your project on your home computer.

You’ll be doing lots of CoreDogs projects. It’s best to create a separate directory for each one. This keeps all the related files together, and stops them interfering with each other.

On your PC, make a directory inside your home folder (e.g., My documents, or Documents) and call it coredogs. Inside the coredogs directory, create a directory called first-home-page.

Notice the names I suggested. We’re going to follow two rules for directory and file names in CoreDogs:

  • Lowercase
  • Separate parts of names with dashes

Remember that directory and file names on Unix servers are case-sensitive. Unix thinks that Myfiles and myfiles are different directories, and X.html and x.html are different files. Standard practice is to use all lowercase to avoid confusion.

Although you’re probably working on a Windows PC now, eventually you’ll upload everything to your server, which probably runs Unix. It’s best to prepare for that step now, by making directory and file names lowercase. Then you won’t have to go back and change things.

It helps readability to have names like first-home-page rather than firsthomepage. Spaces are allowed in file names (like first home page), but sometimes you have to follow special rules to handle them. It’s easiest to avoid the issue all together, and use dashes instead of spaces.

Many people use underscores (_) instead of dashes (-) in Web work. So why do I recommend dashes in directory and file names? Because Google prefers it. This might make your pages easier for people to find.

Start Notepad++. Type “Hi!” and save your work into the file index.html in your project directory. This isn’t HTML yet, but it will be.


Figure 2. Hi!

index.html is the default file name servers use when a URL doesn’t include one. That makes it the best name for a home page. We talked about this earlier.

Now open the file in a browser. How? The way I normally do it is to double-click the HTML file.

Open the file

Figure 3. Open the file in a browser

My PC uses Firefox as its default Web browser. You should download Firefox and install it. I recommend making Firefox your default browser, though you don’t have to.

Another way to open a file in your browser is to use File | Open in your browser’s menu.

When you’ve loaded the file into your browser, you should see something like this:

Hi from the browser

Figure 4. Hi from the browser

Now let’s change that to real HTML.

Adding the HTML

In Notepad++, delete “Hi!” Then copy the code below into your file.

    "-//W3C//DTD HTML 4.01//EN" 
    <meta http-equiv="Content-Type" 
        content="text/html; charset=utf-8">
    <title>[Full Name]'s Home Page</title>
    <style type="text/css">
      body {
        font-size: 14px;
        font-family: Verdana, sans-serif;
        background-color: #FFFFFA;
      h1 {
        color: #660000;
    <p>I'm [Full Name]. I'm a [student, mother, cook, and dog lover].</p>
    <p>I'm learning to be a Weber. A Weber is someone who gets paid
    to work on Web sites. I'm a beginner, but learning fast.</p>
    <p>There's not much on this page right now. But as I learn more, 
    this site will have some cool stuff on it.</p>
    <p>I'm learning with <a href="">CoreDogs</a>.</p>

Figure 5. Code for your page

To copy the code, put your mouse anywhere on the code, and a toolbar will appear in the upper right:

Figure toolbar

Figure 6. Toolbar

Then choose the copy icon.

Copy code

Figure 7. Copy code

Paste into Notepad++.

You need to make a few changes. Replace the text [Full Name] with your name. Replace the description list ([student, mother, ...]) with whatever applies to you.

You can keep or delete the CoreDogs link. If you want to get rid of it, delete line 27.

Save the file, and look at it in your browser.


Uploading to your server

There are various ways to get files from your computer to your server. The most common is to use FTP. FTP stands for file transfer protocol.

Let’s think back a moment. Recall that when you use the Web, you use the HTTP protocol. You have an HTTP client (a Web browser, usually) that works with an HTTP server (like Apache).

HTTP client and server

Figure 8. HTTP client and server

FTP is similar. There’s an FTP client running on your computer, that interacts with an FTP server.

FTP client and server

Figure 9. FTP client and server

Usually, the FTP server software is on the same computer as the Web server software. So when you use FTP to upload a file to the server computer’s disk, it’s available to your Web server.

FTP and Web server on the same computer

Figure 10. FTP and Web server on the same computer

There are other protocols that do the same job as FTP. The most common are SCP and SFTP. They work more-or-less the same as FTP.

So, here’s how a Weber publishes a page to a site.

Publishing a page

Figure 11. Publishing a page

The Weber creates a file on his/her computer, and uploads it to the server (1). The server stores the file on its disk drive (2).

Later, a user clicks on a URL that maps to the file. The server grabs the file (3), and sends it to the user (4).

Get an FTP client

Time to install an FTP client program. Let’s use WinSCP. It’s good, and free.

Download and run the WinSCP installer program. If it asks you what type of interface to use, select the Commander interface.

Start up WinSCP. You’ll need to establish a connection to your FTP server before you can upload anything. Start a new session, and let’s fill in the connection information.

FTP login

Figure 12. FTP login

Type the address of your host in (1). For Hostgator, that is usually just you domain name. For other hosts, it might be ftp. and your domain name, like

Type your user name and password in (3) and (4). They’re from your welcome email, the one we saw in Figure 1. Here it is again. (The user name and password are items 2 and 3 in this figure.)

Email from hosting company

Figure 1 (again). Email from hosting company

The protocol in (5) should be FTP. Leave the port (2) alone, unless you have instructions otherwise. You can save your connection information at this point, if you want to make it easier to connect later. But don’t do this on a public machine! Only on one that’s physically secure.

Click Login when you’re ready to connect.

You’ll get a split screen:

FTP client

Figure 13. FTP client

Drag files from left to right to upload (from your local computer to your server). Drag from right to left to download (from your server to your local computer). You can drag entire directories, if you want.

Remember the concept of a Web site’s root? That’s the directory on a server’s disk drive that corresponds to the root of a Web site. So the Web root for might be /sites/dd/. If you want to make a Web page available on the Internet as, you would copy it to /sites/dd/firefly.html.

When the FTP client first connects, it usually doesn’t show you your Web root. It shows the files one level above the Web root (or maybe some other location entirely). Hostgator and most other hosting accounts work this way.

FTP root versus Web root

Figure 14. FTP root versus Web root

Now, you want to put your files into the Web root, which is public_html. The www in the figure is a shortcut to public_html, called a “symbolic link” in Unix. They both point to the same place.

Double-click on public_html or www. This will show the contents of that directory in the right-hand pane.

Now, in the left-hand pane, navigate to where you stored the file you created on your computer (index.html).

Then upload the file index.html to your server. Drag from the left and drop on the right.

Look at your home page in your browser

Type your domain name into your browser, like You should see your home page. In fact, everyone can now look at your home page.

Major w00f, with w00f sprinkles!

Set up an email account

Let’s do one more thing before we end the lesson: set up an email account.

This doesn’t involve FTP, so you can close WinSCP. Instead, we’ll use your Web site’s control panel.

The control panel is a Web page that makes it easier to manage your Web site. The URL of your control panel came in the welcome email from your hosting company. It might be something like Go to the URL, and enter your user name and password.

There are about a bazillion buttons on a typical control panel. They’re organized into groups. One of the groups is about email. Here’s a typical one.

Email control panel

Figure 15. Email control panel

Click the icon “Email accounts.” You’ll see a form to add an email account.

Add an email account

Figure 16. Add an email account

You can create email accounts for your friends, family (including humans), even for your Evil Twin.

Your account includes Web mail applications that let users read and send mail. How users do it will depend on your hosting company. For Hostgator, if your domain is, your email users can check their accounts at They will need to use their fully qualified email addresses to log in, that is, “” and not just “bill.”

Again, this is for Hostgator. Other companies do things differently.


In this lesson, you:

  • Learned how to use the information your hosting company sent you.
  • Created your first home page by copy-and-paste.
  • Uploaded your home page to your server.
  • Accessed it through a browser.
  • Saw how to set up an email account.

Interactive sites

Many Web pages are static. Users can’t interact with them, except for clicking on links.

Some Web pages are interactive, like the page you’re reading now. You can expand and collapse items in the menu to the right. You can move the mouse over the tabs at the top of the page, and they jump around a little.

Other CoreDogs pages let you type in solutions to exercises. The solutions are saved. They’ll be there next time you look at the page.

In this chapter, we’ll look at how Webers make pages interactive.

Programs in browsers

Where are we?

This chapter is about interactive pages. We’ll start off with programs that run in Web browsers.

This lesson’s goals

By the end of this lesson, you should know:

  • Some programs run inside browsers.
  • Those programs are downloaded along with pages.
  • Every major browser can run JavaScript programs.
  • Programs are triggered by events.
  • JavaScript is used for interface effects, validating form data, input widgets, and sending data to a server.

Example: How many dogs?

Here’s a program that advises humans how many dogs they should live with. Type a number in the input field, and click the button.

How many dogs live in your house?


The program is something like this:

When the user clicks the Advice button:
  Get the number of dogs the user entered.
  If it isn't a valid number, show an error message.
  If dogs = 0:
    Show: That's too bad. You should get some dogs.
  If dogs = 1:
    Show: That's not enough dogs. Get another one.
  If dogs = 2:
    Show: That's a good number of dogs to have.
  If dogs is more than 2:
    Show: Lucky you, to live with so many dogs!

Figure 1. How many dogs?

The program doesn’t actually look like this. But Figure 1 shows you the logic behind it. Type in different things, and track through the code in Figure 1 to predict how the program will respond.

How does the program get to the browser? The program is inside the page itself. When I was typing the page you’re looking at right now, I typed the program straight into the page.

So when your browser loaded this page, it loaded the program as well.


The program is in a language called JavaScript. Every major browser can run programs written in JavaScript. So it’s the browser itself that runs the code.

Here’s another example. This one is real JavaScript code. It computes the area of a rectangle.

w = prompt("Width of rectangle?");
h = prompt("Height of rectangle?");
a = w * h;
alert("Area: " + a);

Figure 2. Area program

prompt() shows a dialog like this:

Prompt dialog

Figure 3. prompt() dialog

Then it waits for you to type a number. Line 1 stores whatever you type into the variable w. A variable is a piece of computer memory with a name, like w, sales_tax, or age.

Line 2 gets a value for h. Line 3 computes the area; * means multiply. Line 4 shows the result. alert() shows a message on the screen.

Click the button below to run the program.


I typed a negative number into the program, and it didn’t give me an error message. It just gave me a negative area. That doesn’t make sense.


Computers do exactly what you tell them, and nothing more. There’s no code in Figure 2 to check for negative numbers. The program for Figure 1 does check, but only because I typed in JavaScript code to do that.


What would the check for the width be?


It would be something like this:

if (w < 0) {
   alert("Please enter a valid width.");

This would go in after line 1 in Figure 2. The return statement stops the program.

I don’t want to go into more detail right now. I just want you to get the general idea of what JavaScript is.

The code in Figure 2 is tied to an event. An event is something that happens in the browser, like a user pressing a key on the keyboard, or moving the mouse over something. The program in Figure 2 is tied to the click event of the button. So when the user clicks the Click me button, the browser runs the code.

What JavaScript is used for

JavaScript is used for lots of things, but the four main ones are:

  • Interface effects.
  • Validating form data.
  • Input widgets.
  • Sending data to a server.

Interface effects

Move your mouse over the dog.


That’s a simple interface effect.

I started by making two versions of the dog image. Here they are with borders, so you can tell where the edges are.

No w00f W00f

Figure 5. no-w00f.png and w00f.png

The code is like this:

Initialize the image to no-w00f.png.
When the mouse cursor enters the image:
  Switch the image to w00f.png.
When the mouse cursor leaves the image:
  Switch the image to no-w00f.png.

Figure 6. W00fing

“Initialize” in line 1 means “do this at the start.” So the image starts off as the no-w00f.png version.

The “mouse cursor” in line 2 is the mouse pointer thing you move around the screen. It’s usually an arrow. Line 2 is an event: the mouse cursor moves over the image. When that event happens, the browser runs line 3, and switches the image to the w00f.png version. Lines 4 and 5 switch it back when the mouse leaves the image.

This isn’t a useful interface effect, just a simple example. A more useful effect is the book and chapter expand/collapse in the Lessons menu in the right-hand column.

Validating form data

You’ve filled in lots of forms on the Web. Sometimes you get error messages, telling you you’ve forgotten to complete a field, or done something else the page doesn’t like. JavaScript is used for that.

Here’s a simple one. Give it a try.

The code looks roughly like this:

age = (get what the user typed);
if ( age is empty ) {
  alert('Please enter your age.');
else if ( age is not a number ) {
  alert('Please enter a number.');
else if ( age < 0 ) {
  alert('Please enter a positive number.');
else if ( age > 100 ) {
  alert('Please enter your real age.');
else {
  alert('Thank you!');

Figure 7. Validating age

Type different things in the field. You should be able to follow the code, and predict what the program will say.

Input widgets

An input widget is a thing on the screen that lets users enter data. You’ve seen two input widgets already:

A text box:

These are built in to HTML. Browsers already know how to make text boxes and buttons. Just give them the right tags on a Web page. For example, here’s what I typed to make the button:

<button type="button">A button</button>

But there are other input widgets that HTML doesn’t have built in. One is called a spin button. Give this one a try.

How many walks would you like today (0 to 5)?

Click the up and down arrows, and watch what happens.

HTML doesn’t have a spinner widget built in. I created it, with help from JavaScript.

Send data to a server

You can use JavaScript to send data to a server. This technique is often called Ajax. Once the data gets to the server, it can be stored, emailed, or whatever.

Here’s a simple example. When you click the button below,
a counter on the server goes up by one. Try it.

Number:         Wait...

Here’s how it works. When you click the button, your browser sends a message to the CoreDogs server:

Browser to server: Dude! Increase the counter by one.

The server will do it, and send a message back to the browser.

Server to browser: Done, dude! Here’s the counter’s new value: xxxx.

The counter is stored on the server, not the browser. So if you go to another page and then come back to this one, the counter will retain its data. Shut down your browser, start another one, and the counter will have the same value.

OK – turn your computer off, go to bed, dream of chasing rabbits, wake up tomorrow, fly to Bruges in Belgium, find a computer in an Internet cafe that allows dogs, and look at this page – the counter will still have the right value.

Because the data is on the server, you can shut your computer down, dig a hole and bury it, whatever. The data will remain intact.

And the number goes up when anyone clicks a button, not just you. Have a contest with a dog in Australia. See who can click the button more times in three minutes.

See the little blue thing that appeared briefly? It’s called a throbber. It shows that your browser is contacting the server. The throbber goes away when the server replies.

This is not the only way to send data from a browser to a server. Traditional Web forms don’t use JavaScript to send data. Ajax (using JavaScript to send data) is a relatively new and advanced technique.


  • Some programs run inside browsers.
  • Those programs are downloaded along with pages.
  • Every major browser can run JavaScript programs.
  • Programs are triggered by events.
  • JavaScript is used for interface effects, validating form data, input widgets, and sending data to a server.

What now?

You’ve seen how browsers run JavaScript programs. But servers run programs as well. Let’s talk about that next.

Programs on servers

Where are we?

This chapter is on interactive Web sites. We just saw how code running in a browser can interact with the user. But that’s just part of the story. Let’s look at the server side.

This lesson’s goals

By the end of this lesson, you will:

  • See how to manually create a Web page with a product list.
  • See how easy it is to make a mistake.
  • Learn that a Web server can automatically create a product list page from data in a database. This reduces the number of mistakes.

A list of products

Think back to the first chapter of this book, the one about what makes a Web site good. We talked about Jesse and his site, WanderingDog.Com. WanderingDog sells portable electronics for dogs, like MP3 players, and paw-held games.

Here’s part of a page on the site. It lists squirrel scanners people can buy.

SquirelScan 3000 $49.95

Bob's Bark 'n Bag Mark II $54.95

Tree Ratter Xtreme $29.95

Figure 1. Product list

OK, it won’t win any design awards. But it’s simple.

Each product has two pieces of information: name, and price. Each line in the product list has the same format. First the name, then the price in bold.

Here’s the HTML that makes the product list. It’s in a file called squirrel-scanners.html.

  SquirelScan 3000
  Bob's Bark 'n Bag Mark II
  Tree Ratter Xtreme

Figure 2. HTML for product list

The <p> tag makes a paragraph. That’s some content with white space above and below it. The <strong> tag does the bolding.

So every product has a simple HTML template:


Figure 3. HTML template for product list

Apply the template to every product, and you get the HTML for the product list.

Creating the product list

How does the HTML in Figure 2 get created? One way is to do it by hand. Suppose Jesse uses a word processor like OpenOffice Writer or Microsoft Word. He makes a document like this:

Name Price
SquirelScan 3000 $49.95
Bob’s Bark ‘n Bag Mark II $54.95
Tree Ratter Xtreme $29.95

Figure 4. Master product list

Jesse keeps this master product list current at all times.

It’s easy to make the HTML from this. Just a lot of copy-and-paste.

  • Create a new file, called squirrel-scanners.html.
  • Paste a copy of template (Figure 3) at the end of the file. Remember that it looks like this:

Figure 3 (again). HTML template for product list

  • Take the name and price of the first product, and paste them in the copy of the template.
  • Paste another copy of template at the end of the file.
  • Take the name and price of the second product, and paste them in the copy of the template.
  • Paste another copy of template at the end of the file.
  • Take the name and price of the third product, and paste them in the copy of the template.

And so on. Just do the same thing for every product in the master list, and you’ve got the HTML you need. Here it is again:

  SquirelScan 3000
  Bob's Bark 'n Bag Mark II
  Tree Ratter Xtreme

Figure 2 (again). HTML for product list

Jesse uploads squirrel-scanners.html to his Web server. Customers can see it at

Updating product data

Product data changes all the time. New products are added. Old ones are dropped. Prices go up. Or down, when there’s a sale. There could be dozens of changes a week for a small store with a few hundred products. A large store with thousands of products might have to make a hundred changes to the product data every week.

Suppose the price of Bob’s Bark ‘n Bag Mark II goes from $54.95 to $56.95. Jess first goes to his master product list and changes it:

Name Price
SquirelScan 3000 $49.95
Bob’s Bark ‘n Bag Mark II $54.95 $56.95
Tree Ratter Xtreme $29.95

Figure 5. New master product list

Then Jesse can change the HTML in squirrel-scanners.html. If this product’s price appears on more than one page, Jesse has to remember to change it everywhere.

Let’s say there are 15 price changes per week. That means 15 changes to the master product list, and 15 to the squirrel-scanners.html. That’s 30 changes every week.

It would be easy to make a mistake. Take the price change for Bob’s Bark ‘n Bag Mark II. Let’s say that Jesse typed the new price correctly into the master product list, but made a mistake when editing squirrel-scanners.html. Instead of changing $54.95 to $56.95, he accidentally deleted the first 5, making the price on the Web site $6.95.

Suppose there are ten orders before Jesse finds the mistake. He either loses $50 per order, or annoys ten customers. No way to win.

The more products there are, the more chances there are for errors. Not to mention the time it would take to make all the changes.

A better way

Jesse makes two big changes. First, instead of having his master product list in a word processing document, he puts it into a database table.

A database management system (DBMS) is a piece of software that can help with problems like Jesse’s. There are many different DBMS. Jesse uses MySQL, a popular open source DBMS, widely used for Web sites. CoreDogs uses MySQL underneath.

Most DBMS store data in tables. Here’s a MySQL table called products.

products table from database

Figure 6. products table from database

It’s the same data as before, in more-or-less the same format. There are rows, and there are columns. Each row is data for one product. Each column is an attribute, or characteristic, of a product.

Why did Jesse move the data into a database table? Because when the data is in a database, programs can use the data.

So that’s the first thing Jesse does. He moves the data to a database.

The second thing: he writes a program to automatically create the page squirrel-scanners.html.

Remember the steps Jesse went through to make squirrel-scanners.html manually. Here they are again.

  • Create a new file, called squirrel-scanners.html.
  • Paste a copy of the HTML template at the end of the file.
  • Take the name and price of the first product, and paste them in the copy of the template.
  • Paste another copy of template at the end of the file.
  • Take the name and price of the second product, and paste them in the copy of the template.
  • Paste another copy of template at the end of the file.
  • Take the name and price of the third product, and paste them in the copy of the template.

These are repetitive things that a computer can do. Here’s what a program to create squirrel-scanners.html would do.

Connect to the database.
Open the products table.
For each row:
  Get the name from the row.
  Get the price from the row.
  Output: <p>

Figure 7. A program to make the product list HTML

Line 3 starts a loop. Lines 4 to 9 run for each row in the table. They grab product data, populate the template, and output the results. When the program finishes, we have this:

  SquirelScan 3000
  Bob's Bark 'n Bag Mark II
  Tree Ratter Xtreme

Figure 2 (again). HTML for product list

It’s the same as before, but the computer does the work, not Jesse.

The big advantage is that Jesse enters a new price just one time, no matter how many times the price is shown on his site. The computer does the grunt work of transforming the product data into HTML, so there are fewer mistakes.

Big productivity win for Jesse! W00f!

Where does the program run?

So there’s a program that takes data from a database, and outputs HTML. Where does the program run? In a browser?

Typically, programs like this run on the Web server, not in the browser. They aren’t written in JavaScript, but in a language designed for use on servers. PHP is a popular server-side language. In fact, the code that generates CoreDogs pages is in PHP.

Here’s what happens.

Showing the product list

Figure 8. Showing the product list

Customers like Sarah and Paula go to the page The extension isn’t .html anymore, because this isn’t an HTML file. squirrel-scanners.php is a program that generates HTML.

When the Web server gets the request, it notices the .php extension. It runs the program, and sends back the output the program generates.

Remember that squirrel-scanners.php is a program, and it outputs HTML (see Figure 7). So the browser gets HTML. The browser doesn’t know or care that the HTML was generated automatically, rather than typed by a person. It just renders what it gets.

Where the value is

Companies that create value on the Web do a lot of server-side processing. When you send a tweet, a program on a Twitter server stores it in a database. When one of your followers logs in to Twitter, another program reads the database, and shows your tweet.

When you add something to your Facebook wall, a program on a Facebook server stores your new entry in a database. When one of your friends logs in, a different program runs. It extracts your entry from the database, and shows it.

You search for a product on Amazon:

Amazon search

Figure 9. Amazon search

A program runs on an Amazon server. It searches through the database for your search term, and shows matches:

Amazon search results

Figure 10. Amazon search results

Notice that this is like Jesse’s product list, with a product name and a price. Well, a little better, even Jesse would admit that.

So the server side is where it’s at if you want to make money on the Web. CoreDogs’ ServerCore book is all about server-side processing.


You learned:

  • How to manually create a Web page with a product list.
  • How easy it is to make a mistake.
  • A Web server can automatically create a product list page from data in a database. This reduces the number of mistakes.

Moving on

Congrats! You’ve finished the Foundations book. By now, you should have a basic understanding of how the Web works.

Time to dig deeper. Continue to ClientCore, and learn how to create basic Web sites.

Along the way, you’ll make your eMe site really sing. You’ll add photos, slide shows, puzzles, and other things. By the time we’re done, we’ll have something you can be proud of. W00f!