Chapter 10
In This Chapter
How HTML, CSS, and JavaScript work together
Using CSS for text styling
Using CSS for positioning text and graphics
Designing web pages with WordPress
Using JavaScript in web pages
Web development has advanced hugely since its initial heyday in the late 1990s. At the time, there was a huge gold rush to stake out space in the online world — and in the minds of web users — for new business ideas. Pets.com, the Mining Company (now About.com), Facebook, oDesk (for freelancers), and AltaVista (once a famous search engine) were all big names, and all of them but Facebook are now defunct or rebranded or merged into some other company.
Now, you can spend an entire career in web development without ever actually starting a new website. A lot of the major players in the online world are already in place, so extending, expanding, improving, and updating existing sites can consume all the efforts of large web teams.
This can be misleading because it’s hard to fully understand the reasons that people do what they do on the web if you’ve never gone through the birth and successful launch of a website — from initial idea, through prototyping and development, to launch and getting more and more users — yourself.
Most web developers regularly work on new features, and new parts of a site, but it’s not the same thing as taking on (and downing) the whole enchilada.
Many web developers also work on weblike things, rather than true websites: intranet sites, where the audience is internal; apps, many of which are very weblike (or are even mobile device alternatives for the website that people use on computers — and on mobile devices too); and software that has a weblike, or an actual web interface.
In fact, one of the major reasons for creating and maintaining your own portfolio site, as described in Chapter 16, is just to have the excitement and insight that come from actually bringing your own ideas to life online within a fully developed, and truly new, website.
In this chapter, we describe the web development life cycle, from start to finish. Use the description here to recognize where your projects are in the overall life cycle, and to get a better idea of just what you really need to do to help make them succeed.
How does a website get started?
A website gets started to accomplish some goal, or set of goals. Being clear about what you want a website (or any web development project) to accomplish is vital to succeeding, or being able to know whether you’re succeeding.
Like other projects that organizations — and individual people — undertake, people often fail to think rigorously about why they create a website. This lack of rigor often causes problems, or even failure, for the entire life of the site.
To gain true clarity when starting a website, or other web development project, ask yourself a radical question: What’s going to be different because I did this project?
That is, forget about the project itself. What are the important things that will change? Create a list, and then stack-rank it: Put the most important goals first.
Here’s an example of goals for a website project, a stack-ranked list of the things that will change if someone starts a website giving news about solar energy projects — and it’s at least somewhat successful:
Note that this is not a list of what the website will accomplish. Also notice that it has no details about the website itself.
Instead, it’s a list of what you’re trying to accomplish by creating the website. The website details will be determined by whether they help accomplish the goals.
You should create a list like this for every website project and keep referring to it constantly throughout the project. The clarity you develop as a result will save you endless amounts of time, money, and hassle.
This process usually has some very valuable side effects, including
Figure 10-1 shows some useful website advice from the U.S. Government’s Small Business Administration. Note that “figuring out what you want to do and defining your niche” is right at the top of the list.
You’ll often hear references to the “look and feel” or the “functionality” of a website. What are these capabilities, and how do they fit together? We describe these pieces here, to help you better understand how you can play your part.
The number one cause for website projects getting delayed or even canceled, in our experience, is dissatisfaction from senior executives about the “look and feel” of a website. It’s worth understanding this better so that you focus on it at the beginning of a project, when it can still be fixed, rather than suffering over it at the end of a project, when it’s too late.
Even when executives see mock-ups early, as they usually do, the look changes in many ways as implementation proceeds. Also, an executive getting asked to approve the launch of a website is facing a much bigger decision than just green-lighting a project at the beginning. They can, and do, hold the nearly final result to a much higher standard.
The look and feel of a website is somewhat ineffable — “incapable of being expressed in words,” according to Merriam-Webster dictionary — but we’re going to try anyway.
The look of a website is produced by a number of elements: the colors used, singly and in combination; the layout of major elements of each web page like the header, left and right rails, and footer; the amount of white space; the fonts used and how they work (or don’t work) together; and all the other visual elements combined.
Many website demonstrations for senior executives are actually over in a fraction of a second, even if they actually go on for hours. That’s because the senior executive doesn’t like the look of the website at very first glance. They may or may not know this themselves, and they may or may not tell you directly that it’s a problem. But the project, in its current incarnation, is probably doomed if senior executives don’t like the look.
This is a huge problem because the look of the site actually ends up determining, and being determined by, a myriad of things about how the site looks and works. There are some combinations of text and graphics, for instance, that just won’t fit well on a page together if the central content column is narrow. Articles that seem too long when a large font size and a narrow central column is used may look just fine with a smaller font size or a wider central column.
The person in charge of the website project is usually responsible for the look. That’s why graphic designers are so often in charge of these projects, even if other skill areas might seem more important — and why designers who can code well enough to implement their own ideas, or competently lead others in implementing them, are so valuable.
Other team members also have a lot of input into the look of a site, both in the initial design process up front and in the many “small” implementation decisions that end up determining how the planned-for look really appears on the actual site. This tends to make the look better — but also results in widespread disappointment, even shock, if senior executives question or even reject it late in the game.
There are three major things you can do to prevent senior executives from killing your projects, or forcing a painful major revamp, late in the game:
Every time you take one of these steps, you make it more likely that the website will have a look that executives like, and you also build trust in your own judgment, openness to criticism, and willingness to adjust. All these factors make it more likely that you’ll be able to get your project over the finish line without being ordered to start over — and that you’ll be able to recover quickly if you are.
To understand how the goals of a website can be implemented in its look, consider the websites shown in Figure 10-2, the U.S. Department of Defense (or “the Pentagon,” which was once called the Department of War); Figure 10-3, the U.S. State Department (as close as the U.S. has to a “Department of Peace”); and Figure 10-4, the U.S. Department of Agriculture (which could be called the “Department of Food”).
Each website uses an image clearly relating to its mission. And each has aspects that somewhat fit the public image of the department involved — the Pentagon’s is dense and seemingly factual; the State Department’s is more open and inviting; the Agriculture Department’s is somewhere in-between.
Consider writing down some ideas about how changes to the web design and content for each government department could better reflect its mission and role.
The “feel” part of the “look and feel” of a website has a couple of different meanings:
These different meanings of “feel” explain a few things:
Whereas the “look” part of a website is the responsibility of the project head, who usually has a graphic design background, the interactive parts of the “feel” of a website can be the responsibility of several different people. This can include usability people; front-end programmers; interaction designers; and graphic designers.
Bringing the pieces together, a well-run organization will usually have standards for the look and feel of all its websites, external and internally focused. The standards might be applied loosely for low-use, short-term, and internal websites — which are often cobbled together from existing pieces anyway — but applied more strictly for large, highly visible projects and more novel ones.
Figure 10-5 shows the look and feel standards for the U.S. Environmental Protection Agency (EPA). These standards are such a focus for the EPA that they have a name, One EPA Web. Notice the strong wording used — “complying” and “requirement” for using the standard.