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
paulsworld.net.
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.”

Each chapter has lessons in it.

To go to the first chapter, use the Lessons menu, click the forward link…
... or use the table of contents below.
This chapter is about the most important question in CoreDogs:
What makes a Web site good?
By the end of this lesson, you should know:
In CoreDogs, “people” includes humans as well as us dogs.
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.
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.
Sometimes it’s easy to tell when a site has problems. Check this out.

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.
Here’s a page.
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:
Here are some ways the page helps:

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.
Right!
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 Funbrain.com really looks like:

Figure 6. Funbrain.com
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?

Figure 1 (again). Bad page
If you saw this on the Web, what would you think about the person who created it? Hmmm…..
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.
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:
Let’s talk about how this works on CarlysSchool.Com.
Learn:

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.
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.
Imagine you’re a DIYer. What would make Carly’s site good for you?
(Log in to enter your solution to this exercise.)
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:
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 get answers:
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:

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 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.

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.
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:

Figure 3. Search box on a site
This is an internal search engine. Google is an external search engine.
Where are we?
Let’s talk about how CarlysSchool.Com can help users find information.
Information architecture is about how information is arranged on a site. This means:
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:
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:

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” 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 lessons section:

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:

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.
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.


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.
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:

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.
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.
Help users browse Web sites by making pages predictable. This helps people direct their attention to the right place.

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

Figure 11. An external link
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 8 is highlighted. That’s the section of the site the current page is in.
The tree menu on the right highlights the current lesson:

Figure 6 (again). Tree menu
Breadcrumbs show the path to the current page:

Figure 12. Breadcrumbs
Let’s summarize.
Let’s talk about searching.
CarlysSchool.Com should have a search box, like the one on CoreDogs:

Figure 3 (again). Search box on a site
The user types something in…

Figure 13. Searching
... and gets some 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:

Figure 15. A search
Here’s one of the results:

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:

Figure 17. Google autocomplete for “dogs are”
Let’s look at how people use WanderingDog.Com, an ecommerce site.
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.
Learn that:

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 have two goals when they go to WanderingDog.Com.
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.
Jesse looks at research on how people choose stuff to buy. This is what he learns:
Jesse designs WanderingDog.Com to support all three of these actions.
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:

Figure 1. Category front page
This page supports all three ways of choosing a product.
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.
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:

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.
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.
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.
Learn:
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 – CarlysSchools.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.
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.
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.

Figure 1. A Carly’s School customer
Here are the parts that the Web site helps with.

Figure 2. What CarlysSchool.Com helps with
Carly’sSchool.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.
WanderingDog is different. It sells directly from the Web site.
Here’s a sample sales process.

Figure 3. A WanderingDog customer
Here are the parts of the process that WanderingDog.Com helps with.

Figure 4. What WanderingDog.Com helps with
This Web site handles more of the sales process.
Users are just a click away from thousands of sites. If owners want to attract customer, 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:
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.
Marketers talk about “branding.” The most important things branding does are:
CoreDogs is typical of a branded site. Look at the page 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:
We’ve talked about two typical commercial sites. But what about your site?
We’ve talked about two commercial sites. What about your site?
You should have a Web site, with your own domain, like dalmationpower.net, or caseybrandenburg.com.
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 are you into? Acid techno? TMNT? Shoes? Basketball?
List at least ten things you like. For me, that would be:
Enter the ten (or more) things here.
(Log in to enter your solution to this exercise.)
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:
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.)
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 to try this, check out the article Personal brands: An introduction.
Web sites cost money. Let’s talk about that.
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.
Learn:
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:
Of the two, the second is usually more expensive.
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.
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.
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?
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.
Let’s talk about three things:
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:
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:
Working together helps owners and builders move in the right direction. Productivity is about how quickly they travel.
Builders try to:
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:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Dogs</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js">
<script>
</head>
<body>
<h1>Dogs</h1>
<p>Dogs are the best.</p>
</body>
</html>
Figure 2. Your code
You try it, but it doesn’t work.
You left something out. Line 8 should have been…
</script>
... instead of…
<script>
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++:

Figure 3. Code in Notepad++
Here’s what it looks like in Netbeans:

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

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:

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:

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.
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.
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:

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:
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.
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.
This book – Foundations – has three more chapters.
Onward!
Everything that happens on the Web involves at least two computers: a client and a 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.
Web tech is messy. Learn a way of thinking that makes it easier to understand.
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.
Here’s Alison.

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

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 know 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:

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.
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.
Let’s talk about the lowest layer.
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.
By the end of this lesson, you should:
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.
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:

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.
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: 123.21.22.11, 211.22.92.91, and 88.120.233.9.
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.
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:

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

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.)
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 219.32.228.181 today!” Ack!
Instead, we have the domain name system (DNS). When you register a domain name, maybe renata.org, you associate the domain name with an IP address. So your ad can read: “Free download! Go to renata.org today!” Much better.
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:
ping coredogs.com
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 microsoft.com, for example, ignores pings.
Find the IP addresses of some of your favorite Web sites. (I like masalatime.com and failblog.org.)
(Log in to enter your solution to this exercise.)
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 |
|---|---|
| sitepoint.com | 69.20.16.232 |
| whitehouse.gov | 96.16.226.135 |
| ... | ... |
When you type a domain name like sitepoint.com 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.
Think up a strange domain name, like deathpoodles.com. Go to http://www.networksolutions.com/whois/index.jsp and type it in. The one who comes up with the strangest name wins.
You can find some strange stuff. (There is a strangestuff.com.)
(Log in to enter your solution to this exercise.)
You know all you need to know about the BoNL. Let’s talk about the services layer.
We talked about the bucket o’ numbers layer. Now let’s move on the services layer.

Figure 1. This lesson’s topic
By the end of this lesson, you should:
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.
Jake wants to send an email to Jules. Jake’s email address is jake@evildoom.com. Jules’ is jules@dogbowl.com.
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.

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 “evildoom.com” part of “jake@evildoom.com”). Instead, Jake’s email client asks another computer to send the email. This computer is the email server for evildoom.com. It offers email service to everyone with an EvilDoom account.

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:

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 mail.evildoom.com
Server: 250 Hello evildoom.com
Client: rcpt to: jules (at) dogbowl.com
Server: 250 Ok
Client: DATA
Server: 354 End data with .
Client: Subject: Study group meeting
Client: D00d,
Client:
Client: I'm buying the coffee tonight.
Client:
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 http://www.freesoft.org/CIE/RFC/821/index.htm.
When Microsoft’s programmers created Microsoft Mail (the client program Jake is using), they read RFC 821, so they’d know how their progra 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;
You can see that the client software has two main 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.
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.

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.
Client:
GET superdogs.html HTTP/1.1
Host: www.evildoom.com
Server:
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.
In this lesson, you learned:
A Web browser gets data from a Web server, and sends it to the display layers. That’s coming up next.
We’re working through the layers of the Internet. We just talked about the services layer. On to the display layers.
Figure 1. Where we are
By the end of this lesson, you should:
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’s 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 …
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?
Yes.
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:
<h1>Ducks</h1> <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:

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.
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.
(Log in to enter your solution to this exercise.)
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:
<h1>Ducks</h1> <p>Ducks are <em>great</em>!</p>
Figure 2 (again). Some HTML
It looked like this in a browser:
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:
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.
Onward!
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:
When someone looks at a Web page, s/he sees a display on a computer screen.

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?
To the user, a Web site is a bunch of pages. Here’s a site with two simple pages.

Figure 2. A Web site
You can try it.
The site has two pages. Each page has two things:
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:
Here’s how it works.

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.
<p> I am a pig. I know a <a href="cow.html">cow</a>. </p>
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.

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.
Where are we?
So, these files on the server. How do they get created?
A Weber (someone who makes Web pages) decides on a page’s:
Often the Weber makes a rough drawing:

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.
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…
<p> I am a pig. I know a <a href="cow.html">cow</a>. </p>
Figure 4 (again). Code that the browser rendered
... that a browser will render like this:

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.
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.
Browsers ask servers for files. How do browsers know which files to ask for? They use URLs.
This lesson is about URLs. You’ll learn:
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:
http://www.blm.gov/wo/st/en/bpd.html
The URL has several parts. You’ll learn how the pieces work in the next lesson.
To get a URL into your browser, you usually either:
Try both for the URL above. Copy the link and paste it into your browser’s address field:

Figure 1. Address bar
Now for the second method. You can click here to visit the URL.
That URL again is http://www.blm.gov/wo/st/en/bpd.html. 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
So:
Here’s the cow page again.

Figure 3. Cow page
You can try the page.
The URL of the page is http://coredogs.com/content_media/lessons/corecore/simple-web-pages/animals/cow.html.
There are three things on the page:
Here’s some code from cow.html. The browser renders it to make the three things.
<p> <img src="bessie.jpg" alt="Bessie"> </p> <p> I am a cow. I know a <a href="pig.html">pig</a>. </p>
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, http://coredogs.com/content_media/lessons/corecore/simple-web-pages/animals/bessie.jpg.
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.htmlbessie.jpgcow.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:
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:
The display is like this:

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 http://coredogs.com/content_media/lessons/corecore/simple-web-pages/animals/pig.html. pig.html in <a href="pig.html">pig</a> is shorthand for that full URL.
You can see that URLs are important things. Let’s learn a little about what a Web server does when it gets a URL.
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?
By the end of this lesson, you should know:
Suppose that a browser shows this.

Figure 1. Link rendered in a browser
It comes from this HTML.
<a href="http://doomdogs.com/products/ball.html">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: http://doomdogs.com/products/ball.html. That’s where the browser will go if the link is clicked.
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 http://doomdogs.com/products/ball.html. The first part – http – is the service-layer communication protocol to use. The second part – doomdogs.com – is the domain name of the server. So that’s where the message is sent: to the server at doomdogs.com.
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.
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.

Figure 2. Directory tree
The Windows file path to the file renata.jpg is:
C:\dogs\mydogs\renata.jpg
This means:
Start at the root of the
C:drive.
Then go down into thedogsdirectory.
Then go down into themydogsdirectory.
There you will find the filerenata.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:

Figure 3. Windows file path
Other operating systems have different rules for file paths. A path on a Unix machine might look like this:
/dogs/mydogs/renata.jpg
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:
C:\awah\ajer\kyam.txt
and
C:\awah\ajer\Kyam.txt
refer to the same file. But in Unix:
/awah/ajer/kyam.txt
and
/awah/ajer/Kyam.txt
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.
OK. So we have URLs. They’re Web addresses for files. Like:
http://doomdogs.com/products/ball.html
And we have file paths, like:
C:\dogs\mydogs\renata.jpg
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.
Here’s Jake, looking at a Web page on doomdogs.com.

Figure 1 (again). Link rendered in a browser
Why is Jake’s browser showing him a link? Because of this HTML:
<a href="http://doomdogs.com/products/ball.html">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 http://doomdogs.com/products/ball.html.
Let’s look at what happens when Jake clicks.

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="http://doomdogs.com/products/ball.html">Bouncing ball</a>
So the browser knows it should show the page http://doomdogs.com/products/ball.html.
The browser creates an HTTP message to doomdogs.com: GET /products/ball.html (2). The Internet sends the message to the Web server.
The server at doomdogs.com 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.

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.

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 doomdogs.com 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.

Figure 7. Computing the file path
Now Apache knows where to get the file the browser asked for.
Here’s the process again.

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 http://thing.com/what.html, thing.com 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 http://www.google.com/search.html. I type http://www.google.com. 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 http://doomdogs.com/ maps to http://doomdogs.com/index.html.
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:
Let’s put some of this knowledge into action. Time to buy a Web hosting account, and get real!
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.
By the end of this lesson, you should:
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 blakenshot.com, and give yourself a cool email address, like rover@blakenshot.com. You could give email addresses to your family and friends. Your brother could be billy@blakenshot.com. You get to decide. Oh, the power! The power!
You forgot something.
What’s that?
Having your own site is so freakin’ cool!
You need to do three things to get your own Web site:
blakenshot.com. You get an account on a Web server that has the IP address 123.234.123.234. You tie the two together. So when someone types blakenshot.com into a browser, that gets translated into 123.234.123.234.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 yourname.com, don’t despair. Try yourname.org, yourname.net, and yourname.info. You’ll come up with something.
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.)
You get a bunch o’ stuff, but here are the main things:
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.
There are lots of hosting plans, but they fall into a few main types.
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.
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 sees 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:
OK, now that you put it that way. I guess I can skip a small vanilla latté now and then.
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).
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.
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:
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:
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.
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:
Most important of all, you bought your own hosting account, and your own domain name.
You did, right?
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.
You bought a hosting account. Now it’s time to add a home page.
By the end of this lesson, you should:
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:
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:

Figure 1. Email from hosting company
(1) is the domain, like doomdogs.com. 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.
You first home page will just be plain HTML, with some CSS to add a little color. You’ll follow these steps:
OK, let’s get started. I’ll being doing everything with Windows. The steps are the same for another OS, but you’ll a different editor and FTP client.
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 file 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:
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 name 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 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.

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:

Figure 4. Hi from the browser
Now let’s change that to real HTML.
In Notepad++, delete “Hi!” Then copy the code below into your file.
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<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;
}
</style>
</head>
<body>
<h1>Welcome</h1>
<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="http://coredogs.com/">CoreDogs</a>.</p>
</body>
</html>
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 6. Toolbar
Then choose the copy icon.

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.
W00f!
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).

Figure 8. HTTP client and server
FTP is similar. There’s an FTP client running on your computer, that interacts with an FTP 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.

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.

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).
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.

Figure 12. FTP login
Type the address of your host in (1). For Hostgator, that usually just you domain name. For other hosts, it might be ftp. and your domain name, like ftp.mysite.com.
Type your user name 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.)

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:

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 doomdogs.com might be /sites/dd/. If you want to make a Web page available on the Internet as http://doomdogs.com/firefly.html, 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.

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.
Type your domain name into your browser, like http://a.com. You should see your home page. In fact, everyone can now look at your home page.
Major w00f, with w00f sprinkles!
Let’s do one more thing before we endth 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 http://doomdogs.com/cpanel. 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.

Figure 15. Email control panel
Click the icon “Email accounts.” You’ll see a form to 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.
You 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 evilplatypus.com, your email users can check their accounts at http://evilplatypus.com/webmail. They will need to use their fully qualified email addresses to log in, that is, “bill@evilplatypus.com” and not just “bill.”
Again, this is for Hostgator. Other companies do things differently.
In this lesson, you:
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.
This chapter is about interactive pages. We’ll start off with programs that run in Web browsers.
By the end of this lesson, you should know:
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:

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.");
return;
}
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 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.
JavaScript is used for lots of things, but the three main ones are:
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.

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.
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.
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 Wb 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.

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.
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.
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.
You’ve seen how browsers run JavaScript programs. But servers run programs as well. Let’s talk about that next.
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.
By the end of this lesson, you will:

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.
<p> SquirelScan 3000 <strong>$49.95</strong> </p> <p> Bob's Bark 'n Bag Mark II <strong>$54.95</strong> </p> <p> Tree Ratter Xtreme <strong>$29.95</strong> </p>
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:
<p> Name <strong>Price</strong> </p>
Figure 3. HTML template for product list
Apply the template to every product, and you get the HTML for the product list.
How does the HTML in Figure 2 get created? One way is to do it by hand. Suppose Jesse 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.
squirrel-scanners.html.<p> Name <strong>Price</strong> </p>
Figure 3 (again). HTML template for product list
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:
<p> SquirelScan 3000 <strong>$49.95</strong> </p> <p> Bob's Bark 'n Bag Mark II <strong>$54.95</strong> </p> <p> Tree Ratter Xtreme <strong>$29.95</strong> </p>
Figure 2 (again). HTML for product list
Jesse uploads squirrel-scanners.html to his Web server. Customers can see it at http://wanderingdog.com/squirrel-scanners.html.
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 | |
| 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 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.
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.

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.
squirrel-scanners.html.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>
name
<strong>price</strong>
</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:
<p> SquirelScan 3000 <strong>$49.95</strong> </p> <p> Bob's Bark 'n Bag Mark II <strong>$54.95</strong> </p> <p> Tree Ratter Xtreme <strong>$29.95</strong> </p>
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!
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.

Figure 8. Showing the product list
Customers like Sarah and Paula go to the page http://wanderingdog.com/squirrel-scanners.php. 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.
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:

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

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:
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!