PPV Specs

Image sizes

1200×630 Featured image. This takes up a reasonable amount of space on a phone screen, and creates a nice grid for archive pages.

Process to Build a Website (per The Web Style Guide)

I created this document on 1/19/2022.

I resumed using it on 12/31/2023.

I’m with you. It’s painful to hire a web designer. You know they’ll have to spend many expensive, paid hours to achieve your goals. The truth is, you’ll be paying them hundreds, maybe thousands of dollars to extract what they need from you to do their job. Is that what you had in mind? Pay more to work more?

If you want a website but you are not a programmer, I have great news. The bulk of the work is not programming. YOU are already capable of 90% of the process. In fact, YOU are responsible for that 90%. Once you do your part, you can easily get a programmer to code and publish it for a couple hundred dollars. After that, you will have easy access to tweak it yourself forevermore.

What follows is my abbreviated take of the entire process detailed by Patrick Lynch and Sarah Horton in the first chapter of their online book, The Web Style Guide. That guide is aimed at large organizations and large websites. I boiled it down here to what my small-town readers are likely to need.

“As you consider the development process outlined below, note that the construction of the pages that make up the web site is one of the last things that takes place in a well-designed project” (Lynch, et. al). 

The DIY Road

If you are like me, you’ll have to get your hands dirty before paying someone else to do it. I knew my website construction process would be a learning-on-the-job job. I knew it would entail much trial and error and do-overs. I did not know it would take over a year! I wish I had kept copies of the iterations. I wish I knew HOW to keep copies of the iterations. 

My family and friends wondered what was taking so long. I had no answer for them. Check that… I had TOO MANY answers for them. A thousand partial articles and a thousand obstacles. They glazed over before I reached the third of either of those. 

The Site Development Team

The Web Style Guide assumes a whole staff is working on this website. While that’s not us, us is still going to have to cover those same functions. Now, me, it’s just me and many hats. There’s no point in me paying someone to follow my wandering imagination. But you, are you working with a group? Can you recruit help? Do you know a pro you would be happy to support? Write in the names of the first person that comes to mid for each role. If nothing else, you can call them with questions.

Role	Responsibilities	Name
Sponsor	The person to please. The client. The manager. The one who approves the plan, budget, and schedule, and provides the necessary resources.
Manager	Keeps the team focused on the objectives, monitors the schedule and budget, funnels communication, and maintains all documentation.
Usability lead	Conducts research, interviews, field studies, and user testing in order to provide a target persona for the development team. Ensures end-user satisfaction.
Information architect	Draws wireframes to organize content to make the most sense in the least time and space. Chooses categorization schemes, consistent site terminology, and search options. Writes explanations for user interactions.
Art director	Brainstorms the site’s look and feel, and implements it through typography, color palette, page layout, and graphics.
Technology lead	Finds host and framework to publish, determines programming language, manages database, network, and content management system if need be.
Coder	Converts wireframes into html. Creates page templates and CSS stylesheets. Converts data for CMS if need be.
Editor	Sets the editorial tone. Determines style guidelines. Collects, organizes, and delivers text. Creates and updates content. SEO. Assumes leadership after launch.

Do you see how small the programming task is compared to the entire project? Trust me. They’ll be happy to make a quick buck with a cut-and-dry assignment.

Initial Planning

My initial planning got overshadowed by my zeal for learning the tech ropes. As I took Rino’s class on XD design, I thought the ENTIRE time that the design I was building would automatically be a web page. I had a great time adding Elementor features, such as a landfill counter, a flying paper airplane, and a message in a bottle. 

Boy did I get slammed when I discovered that my design was nothing more than a nice set of pictures. There was no web page at all in it. Furthermore, my design elements did not always work when imported to a web page. Even my chosen font was not available. I LOVE Rino’s teachings, but my ignorance was outrageous. Every time I had the chance to sell my services, my site was still not ready for exactly that purpose.

Unfortunately, web projects are often approached as a “technology problem,” and projects can get colored from the beginning by enthusiasms for particular web techniques.

Although the people who will visit and use your site will determine whether your project is a success, ironically, those users are the people least likely to be present and involved when your site is designed and built. 

I was able to recruit a few test subjects. Ellan successfully paid via my WPForms invoice. Benjamin was not impressed with the airplane. Vanlice could not figure out the Woocommerce checkout form on her phone. Ericka ordered and paid via Woocommerce, but then the site broke. Michelle Simonds avoided answering me about site checks, which sent me on a project to create a site-check checklist. Anita got a security warning. All of this helped me tackle the more pressing issues than playful site gimmicks.

Involve real users, listen and respond to what they say, test your designs with a spectrum of users of different ages, abilities, and interests, and be prepared to change and evolve your cherished ideas in response to user feedback, and your project will be a success.

Thoroughly understand and communicate your top three goals

I didn’t know what my goals were. I wanted to teach, both adults and youth. I wanted to sell my services. I wanted to show my peers and ex-peers what I’m made of–that I have intelligence, class, and skills. I wanted to debunk my own myth that I am unhirable, undesirable, all talk and no action, a crying leach.

The first step in designing any web site is to define your goals. Without a clearly stated mission and objectives, the project will drift, bog down, or continue past an appropriate endpoint.

I think I am ready to declare my goals now:

PaperlessPonteVedra	AnthologyOfaResurrection	VoiceOfBelleza	AmyJoHoward.com
Write lessons	Honor God	Promote communication	Store my random writings
Sell services	Blend stories	Ad revenue	Declare my overall brand
Declare my tech branding	Sell the book	Resolve community problems	Write random articles
Ad revenue			Point to my other projects

WSG says I need a goals statement. I could write this for SPVV and PPV as a way to benefit directly, and also practice for selling my services.

A short statement identifying two or three goals should be the foundation of your web site design… include specific strategies around which the web site will be designed, how long the site design, construction, and evaluation periods will be, and specific quantitative and qualitative measures of how the site’s success will be evaluated.

Write your goals statement here:

PaperlessPonteVedra.com

AnthologyOfaResurrection

PPV.com will generate ad revenue from my articles and from community involvement. I will also sell local products on the site. To promote community involvement, I must maximize security and usability. The theme is a pursuit of nature through digital freedom. All designs must remind the user of local nature. The site’s success is measured by the ratio of revenue to maintenance hours netting more than my Amazon paycheck.

Anthology will present the story of Chelsea’s death and resurrection through the eyes of multiple people to propose that God weaves our worlds together to achieve multiple goals simultaneously. The site will provide portals for contributors and filters for readers.

Know your audience

Pick a few people to represent your audience. Keep them in mind while designing so that your ideas and choices cater to them. The expense of options will narrow quickly when you consider your audience’s knowledge, background, interests, and needs. A well-designed system should accommodate a range of skills and interests, but not lose focus and purpose.

Write five audience members here:

PaperlessPonteVedra.com	AnthologyOfaResurrection
Bill and Anita SmithCarol NelsonBarbara NailerAndy KittsPat ChristensenSuzanne ScheunkeBarbara Jenness	Chelsea HowardKerri WilsonJosh HowardTrevor JahaBryan SchwarzMatt & Tam SchwarzLucy McGill

Web analytics as a planning tool

Web browsers leave footprints. As soon as people start visiting your website, look at the traffic reports. These are available in the server logs on your web host, but you’ll get much better reports if you install Google Analytics on your site. It’s free and invaluable. You will see what people are looking for, what they click on, your most popular pages, what site sent them to yours, what search terms brought them in, what kind of network connection they use, what size their computer screen is, and which operating system and web browser they use.

If you don’t have a site yet, do some Google searches on topics you will be publishing. Google’s search results page will show you what your audience will face when they try to search the same things. Put yourself in their shoes. How will they phrase and re-phrase their search term? Will they add their city name? What search terms bring up your competition? Right at the top of each entry, Google shows how many searchers per month are going to those sites. Put yourself in the lineup by matching your site verbiage to the search trends.

Write five search terms relevant to your site here, then see how much traffic is going to your closest competition.

Search term	Competition	Traffic/month
Ponte Vedra Beach

Design critiques

Whether you are working with a group or with your own split decisions, multiple visions will diverge and clash at some point. Bring the visions closer together by analyzing real-life examples. 

Have each team member bring a list of several favorite sites to the critique, and ask them to introduce these sites and comment on the successful elements of each design.

Keep a record of these examples and the decisions you made from them. For now, find one website you would like to emulate and write three do’s and don’ts that come to mind.

URL:
Do’s	Don’ts

Content inventory

If you are planning to make a website, you probably already have content in mind for it. Is that content already written somewhere? Are there pictures? Be the Information Architect for a moment. Write the major categories of information your site will contain. Then list the content you already have. Then list the additional content you need. Include both written and graphic elements.

Category	Content have	Content need

Once you know where you are short on content you can concentrate on those deficits and avoid wasting time on areas with existing resources that are ready to use. 

A List of Reminders

Place yourself in the background

It’s not about me.

Start and end with the users’ interests in mind. If your site doesn’t provide useful things to the audience, nothing else matters. Design your web site with universal usability principles.

Work from a suitable design

It’s extremely difficult to force a creative idea into a concrete plan. But it’s even more difficult to untangle a web of half-implemented ideas. I know. That’s the tangled web I’m living in right now.

Know what you’re doing, why you’re doing it, and for whom you’re doing it before anyone touches HTML or Photoshop.

Do not overwrite

Not many people love to read anymore, especially from a computer screen. But everybody loves the victory of successfully reading a short and valuable piece of information. Shorten, shorten, shorten.

A concise, high-quality site is much better than a big contraption full of broken links. Produce the minimum necessary to achieve an excellent result.

Prefer the standard to the offbeat

I learned from Benjamin. He was excited about my professional site until the silly plane flew by. People are not surfing the web for entertainment. It’s not a video game. They are surfing to learn something quickly and easily – something they are searching, or something that finds them. Quick learning. Elementor might not be my friend.

Web conventions are your friends. Always favor the tried and true, and save your creativity for the hard stuff: interesting content and features.

Be clear

What does this mean? 

Craft your page titles and content carefully, and make sure that the page title is consistent with your major headings.

Do the visuals last

I started with the visuals first. I wanted Ponte Vedra Beach. I wanted my paperless office. I wanted my filing cabinet running from the hurricane. I don’t understand it, but somehow I got lost for a year.

Early visual design discussions can ruin any chance of a rational planning process.

Revise and rewrite

If I ever make a website for someone else, I absolutely cannot afford a rebuild. Revisions need to be free and maximized during planning so they don’t creep in during development.

Development iteration—where you tear down and revise things late in the process—can ruin quality control, budgets, and schedules.

Be consistent

Creativity can be annoying and confusing to your audience. This is why flat design is back. Make sure your visitors feel in control of their experience.

Consistency is the golden rule of interface design. Be consistent with the general conventions of the web, of your home institution if you have one, and within your site.

Do not affect a breezy manner

Benjamin strikes again. I still don’t understand it. I loved J.K. Rowling’s gimmicky site. But I guess I’m not writing for Harry Potter fans.

Avoid gimmicky technology fads… Never use pointless Flash animations to “make the site more interesting.” To make your site more interesting, add substantive content or features.

Degrade gracefully

The larger a website gets, the more snags it gets. It’s unavoidable. Even if you meticulously comb through every link from every browser with every device and make sure every piece works correctly, you still can’t control the bugs that come in from the integrated software and external services. Be hospitable to the people who accidentally bump into your snags.

Provide a carefully designed “404” error page with helpful search and links if the user hits a broken link on your site.

Do not explain too much

Again, people don’t like to read a lot of nonfiction, especially on a computer screen. Serve them good stuff quick and easy.

Be concise, and be generous with headers, subheads, and lists, so the user can scan your content easily.

Make sure the user knows who is speaking

The internet is full of faceless, voiceless, anonymous, supposedly credible information. “I read it on the internet” is a valid validation for many people. But do they go back to that source? Do they even know where they saw it? Do you want them to remember you and feel like they belong on your site?

Good communication is always a person-to-person transaction. Use the active voice at all times, so the user knows who is speaking. Make it easy to find your mailing address and other contact information.

Types of Websites and Documents

Static versus dynamic web pages

Static web pages

Static web pages don’t change content or layout with every request to the web server. They change only when a web author manually updates them with a text editor or web editing tool like Adobe Dreamweaver. The vast majority of web sites use static pages, and the technique is highly cost-effective for publishing web information that doesn’t change substantially over months or even years. Many web content management systems also use static publishing to deliver web content. In the cms the pages are created and modified in a dynamic database-driven web-editing interface but are then written out to the web server (“published”) as ordinary static pages. Static pages are simple, secure, less prone to technology errors and breakdown, and easily visible by search engines.

Dynamic web pages

Dynamic web pages can adapt their content or appearance depending on the user’s interactions, changes in data supplied by an application, or as an evolution over time, as on a news web site. 

Dynamic web pages offer enormous flexibility, but the process of delivering a uniquely assembled mix of content with every page request requires a rapid, high-end web server, and even the most capable server can bog down under many requests for dynamic web pages in a short time. Unless they are carefully optimized, dynamic web content delivery systems are often much less visible to search engines than static pages. 

Web content management

Enterprise web content management systems

Content management systems (CMS) are pre-built templates that behave as data-entry forms. The CMS stores data from the form in a database that is protected from amature access.

Most large corporate, enterprise, and university sites are now managed with a cms in a decentralized editorial environment where hundreds of individual authors, content approvers, editors, and media contributors create most of the content for the enterprise’s sites.

Blogs

The most popular use of CMS is for blogs, which makes up most of the internet content.

Blog software such as Blogger, Roller, or WordPress allows nontechnical users to combine text, graphics, and digital media files easily into interactive web pages.

Amateurs can create web pages, add pictures and text, invite others to add comments, and send update notices to subscribers. I intend to use WordPress as a collaboration tool on a multi-authored book.

A blog-based site may be all you need to get up and running quickly with a set of friendly, nontechnical editing tools and (usually) such built-in features as calendars, automated category and navigation controls, and automatic rss feeds. 

Wikis

Although I will use a blog as a collaboration tool, Wiki’s are the original collaboration tool. Teachers use them in their classrooms to allow students to contribute and interact through a computer. In a wiki, users can add and change the actual content. This is how Wikipedia started out as pseudo-information and quickly grew to a worldwide, peer-reviewed encyclopedia.

Wiki’s are a wonderful hub for interactive group projects.

RSS

Do you like to skim headlines in newspapers and magazines? Do you like to get those in your email from certain websites? Do you like being able to click on one and go directly to the article? This is RSS. Really Simple Syndication. Fun title, eh? Not only is it really simple to receive and respond to, it’s also really simple to send out. You set up an RSS file on your website, and your RSS software automatically syndicates new headlines and snippets to your subscribers.

Most blog software can generate rss feeds to notify users of updated content, and there are many special-purpose rss feed authoring programs on the market. 

The Evolution of Web Tools

As Joe Public, we tend to think of websites as online brochures. They display information. The sheer volume of these websites seems endless. However, the World Wide Web is far more expansive than that. The “Web” also contains websites that are not offered to Joe Public. Large organizations have their own private websites for their own members and employees. It’s the same as our old big-company mainframes, except prettier and father-reaching. These private websites are still connected to the World Wide Web so that those users can access them across the globe rather than across the hall.

Because the members of those organizations are working together on most of their documentation, organization websites have been morphing into collaboration portals. Yes, they still contain web pages for internal as well as public display of information. However, they are increasingly dominated by data sharing tools. In fact, many organizations have opened their internal web system to collaboration with their vendors and customers. 

A standalone website has become a genre all to itself.

Two companies in particular foresaw the benefit of web-based collaboration: Google and Microsoft. They each built systems that are easily accessed and incorporated into existing websites. Because they both offer welcome pages and dashboards, they can easily replace a conventional website altogether for organizations who don’t need to show up in Google searches.

The probable evolution of web publishing is away from such html authoring tools…  and toward full-featured software platforms that not only enable easy content publishing on the web but deliver attractive, ready-to-use collaborative tools and document sharing for web development teams. 

Google Docs

In 2006, Google pulled a fast one on Microsoft. Google released their free word processor, Google Docs. Better yet, they released it in a shared, collaborative format, just like Microsoft’s expensive, 5-year-old SharePoint.

Google Docs is both a word processor and a layman’s term for the Google suite of office productivity tools. It is a godsend for travelers. And by travel, I mean going to your doctor’s appointment and sitting in traffic. I have no problem getting stuck in rush hour or sitting in a waiting room. In fact, I cherish it because I get plenty of work done on my phone. I tweak my budget in a Google spreadsheet. I write and edit my articles in Google docs. Google even lets me dictate my articles into my phone, which is the way to go in a traffic jam. My daughter and I use a Google doc to plan my son’s birthdays. 

When I taught Chemistry, I had my students document their science fair projects on a Google Site (website) that they shared with me and anyone else they chose. I was able to see their progress in real time, rather than wait for a 48” backboard to show up in the classroom.

When I worked at Goodwill, most of the paperwork process took place in a Google doc. Every day at 3:00, I counted our supply inventory, opened the Google spreadsheet, and typed in our supply numbers. I could see the rows where the other stores had already entered their numbers, and the stores who were running even later than me on the chore. Sometimes I even saw someone else’s numbers pop in right while I was entering mine.

I created Google forms for my Goodwill store on my own computer, on my own time. When I went to work without my computer, those forms were available to me on the Goodwill office computer.

Google integrates their various online tools seamlessly. I created a Google spreadsheet to input daily staff production numbers. Then I created a Google doc that served as a template for employee performance appraisals. The document looked just like a formal business document you would make in Microsoft Word. However, it pulled the employee name, employment dates, production numbers, and supervisor comments from separate production and personnel spreadsheets. 

I created all that from home because my manager didn’t find it worth company time for me to be on the computer at work. That was fine, because it was all available to me as soon as I wanted to pull reports and performance appraisals while at work. 

Of course, Google’s generous provision of free computer tools comes with two trade-offs. I tend to forget the first one: you must have an internet connection to share these creations. In most cases, you need an internet connection just to get to those tools, unless you can download an offline version. I don’t know how I’d ever survive without an internet connection.

The other tradeoff is Google’s achilles heel, which is still the same concern that has undermined the internet since its inception. No one, not even Google or Microsoft, can stay ahead of the brilliant rats who love to challenge the Do Not Enter sign.

The shared documents reside on Google’s servers and are automatically saved and backed up within the Google server system… Although Google Docs offers a remarkable range of web-based content services, the overall security and privacy of Google’s applications and services remain in question, particularly for sensitive enterprise documents, financial information, and other private content. 

Microsoft SharePoint

As with all innovations, Google learned most of their tricks from a predecessor. Microsoft released its collaboration tool SharePoint in 2001. Only well-funded organizations spent the money to use it. And even then, not many employees understood it enough to realize its value. SharePoint was just the place to store files you wanted someone else to find. In fact, it even took discipline to do that, since most people were already comfortable emailing files. 

It took a long time for employees to discover the pain caused by multiple copies of a document floating around in different hands. Have you ever tried to figure out if you have the most recent copy of a document that has been revised? Have you ever revised a copy only to find out that it wasn’t the most recent version?

Over time–my gut tells me it was a good ten years–average employees began understanding the value of sharing a single copy of a document. They also gradually explored SharePoint’s other features. For companies fully partaking, SharePoint is no longer that shared folder–it is an entire virtual office within a customized website.

SharePoint can be used to host sophisticated web sites… which provide shared workspaces, documents… wikis, blogs, rss… process workflows, to-do lists, group announcements, email-based alerts, and discussion boards. 

Microsoft is still the wise grandfather to Google. SharePoint had a focus on security from the get-go because it was designed for business environments. 

User access to SharePoint collaborative sites is usually handled through Microsoft Active Directory Services and thus offers a secure environment for corporate, medical, or other collaborations involving sensitive private data.

Leveraging web-based services

Google and Microsoft are merely the flagships in a sea of free and cheap ways to publish content on the internet. For nothing more than potential unwanted exposure, you can freely publish your thoughts on social media, your videos on YouTube, your podcast on iTunes. You can network the global family photo album in Flickr or Picasa. You can collect votes and feedback with SurveyMonkey. 

Your only real challenge with these popular tools is deciding which ones pose the least security risk at any given moment. But that risk is quickly overshadowed by the lure of free publicity.

Many companies have recognized that high-traffic web portals like YouTube and FaceBook aren’t just great communications tools for individuals but are also influential mass communications media and have begun to establish a managed corporate online presence and regular press releases within these highly public sites.

The Site Development Process

If you’ve read this far, your gears are surely cranking on the possibilities for your website. But before building your site, before building your site PLAN, you need to think through the tough questions. I found this phase too painful and dove in without it. As a result, I produced content for every possibility. I ended up with a confusing conglomerate of a home page, not to mention the rest of the site. 

I wasted over a year of iterations, and hundreds of dollars of hosting and design subscriptions, just trying to sort out what I needed on the fly. I lost all credibility with my loving support system. In a way, I didn’t mind because it was the only way I could see to truly learn the trenches of my new career. However, this would be highway robbery to proceed unprepared on someone else’s watch or wallet.

Developing a large web site is a process that may have far-reaching budgetary, personnel, and public relations consequences for an organization, both during the development of the site and long after its deployment. 

Too many web sites begin life as ad hoc efforts, created by small interest groups working in isolation from their peers elsewhere in the organization and without fully considering the site’s goals within the context of the organization’s overall mission. 

The result of poorly planned, hasty development efforts often is an “orphan site,” starved of resources and attention.

Think before you act, and make sure you have the organizational backing, budget, and personnel resources you’ll need to make the project a success (fig. 1.8).

Site definition and planning

Web teams within corporations or other large enterprises can often count on substantial in-house technology support when creating web sites. If you are on your own as an individual or small business, you may need to contract with various technology and design vendors to assemble everything you’ll need to create a substantial content site or small e-commerce site.

You will have to come up with answers to many questions along the way. Here is a checklist to capture them as they become apparent. Fill in what you can. If you have to guess, go ahead and do so. However, highlight your guesses in yellow to make sure you confirm or correct them later. If something does not apply for your project, nullify it with a row of hyphens.

Site Production Checklist
Goals (results)
Objectives (purpose)
Static or CMS?
Budget
Resources have
Resources need
Content scope
Interactive functions
Tech support for visitors
Tech support for inhouse
Information sources
Audience (real people, if you know some)
Network required
Security required
Email address(es)
Chat rooms
Discussion boards
Database needed?
User logins needed?
Questionnaires
Videos/audio
Web host
Disk space required
Site traffic limitation
SEO search terms

Appoint the Editor

Are you your own website editor? Who will fill that role? Will you be adding content over time?

I was once commissioned by an entrepreneur to write some historical articles for a new tourism website he was developing. Nine articles later, he hired me to write and edit business content for the site. Then he offered me a deal to make the site profitable by selling ads on it. Then I was given authority to direct the design staff on anything that would improve the sales effort. Then I learned that we had zero SEO in place, and was given authority to implement analytics and SEO. All this discovery and development burned through the entire budget for the site.

All along, I was still the go-to for all written content, and I was the spokesperson for all historical community involvement. All along, I still had no job title. What should my business card say? Nobody knew. Nobody cared. Everyone else had other projects going on. Nobody was 100% focused on the new site except me.

I proposed and received the title Managing Editor so that our viewers and clients would understand my role better. Although we increased traffic and sales dramatically, the staff was regularly diverted to other projects before my customers’ needs were met. The new site was not able to support my salary requirements. I sadly said goodbye. The whole adventure came back to me a decade later when I read this in the Web Style Guide:

Every successful new web site makes a transition from a development project to an ongoing editorial process that keeps the site alive and fresh over time. You’ll need a project manager to get your new site launched, but you’ll also need to hand the site over to a process manager (read: “editor”) after the site is launched. A site that is “everyone’s responsibility” can quickly become an orphan. For current content and consistent editorial, graphic design, and management policies you’ll need one person to act as the editor of the overall web site. 

Yes, that was me, for about 18 expensive months. Will you need an ongoing editor? If so, here is their job description:

Other editors coordinate and edit the work of many contributors who work directly on the site pages, aided by a maintenance plan that specifies who is responsible for the content of each section of the site. When multiple people contribute to site maintenance, the site editor may choose to edit pages after they are created and posted to avoid becoming a bottleneck in the communications process. However, high-profile public pages or pages that contain important information should be vetted by the editor before posting. 

A site editor will also typically bear the primary responsibility for keeping the site content as visible as possible in local enterprise or general Internet search engines. Broken links and scrambled content organization schemes can harm your search engine rankings and make your content harder for users to locate. The site editor is also the logical person to handle the collection and analysis of web site analytics and to produce periodic reports on the usage of the site.

In addition to ensuring editorial quality, a site editor must also make certain that the content of the site reflects the policies of the enterprise, is consistent with local appropriate use policies, and does not contain material that violates copyright laws. Many people who post pictures, cartoons, audiovisual files, or written material copied from other sites on their own sites do not understand copyrights and the legal risks in using copyrighted materials inappropriately. A site editor is often an institution’s first line of defense against an expensive lawsuit over the misuse of protected material.

Information architecture

It’s time to don your architect hat. That’s right. Grab a pencil and a stack of printer paper. What information will be on your site? Car pictures? Articles? Address? About Us? A contact form? 

This is that proverbial paper basketball game. Write page titles at the top of blank pieces of paper to represent your site pages. Draw boxes on the page for various chunks of information. These are called wireframes. If it can’t fit on one page, break it into multiple pages. Your viewers don’t want to read long pages. 

If multiple pages cover the same topic, list them as links on some central page. Just keep drawing boxes to hold your information in a logical arrangement. Ball up the discards and toss them in the wastebasket. Too many options lying around will make you tired and grouchy.

Site design

Prototypes

When you have a decent enough layout in wireframes, you can make a prototype in Google Sites.

Site prototypes are useful for two reasons. First, they are the best way to test site navigation and develop the user interface. The prototypes should incorporate enough pages to assess accurately what it’s like to move from menus to content pages. 

When your ideas have run out, send the link to your support group for feedback. Invite them to save a separate copy and modify it with their ideas. Try all kinds of alternatives. You never know when the magic combination will hit.

Second, creating a prototype allows the graphic designers to develop relations between how the site looks and how the navigation interface supports the information design. 

Don’t forget to preview the site in mobile and tablet mode.

By now, I’m sure you’ve thought of pictures you want on your site. If you don’t already have them, Google something similar to use in your prototype. When you are sure of what you want, see if you can create the scene and photograph it yourself. If not, there are many free and paid photo banks on the internet. Don’t just settle for Google. It’s worth $10 or $20 for the picture that speaks the perfect thousand words.

Research, writing, organizing, assembling, and editing the site’s text content is also performed at this stage. Any programming, database design and data entry, and search engine design should be well under way by now. The goal is to produce all the content components and functional programming and have them ready for the final production stage: the construction of the actual web site pages.

Typical products or deliverables at the end of this stage include:

Content components, detailed organization and assembly

Text, edited and proofread

Graphic design specifications for all page types

Finished interface graphics for page templates

Header and footer graphics, logos, buttons, backgrounds

Detailed page comps or finished examples of key pages

Site graphic standards manual for large, complex sites

Interface design and master page grid templates completed

Finished html template pages

Illustrations

Photography

Functional and logic components

JavaScript scripts, Java applets designed

Database tables and programming, interaction prototypes completed

Search engine designed and tested

Templates

Whether you develop your site on your own or hire a professional web developer, you should develop page templates for your new web site. It’s much easier to add new pages when you can start from a page that already contains basic navigation and site graphics. If you have a team working on page development, you will want to share templates, along with standards on how to handle page text and content graphics. Popular web site development software such as Adobe Dreamweaver offer powerful templates and standard reusable libraries of site graphics and html that make it easy to create new pages and maintain consistency in your site.

Accessibility

In most large enterprises, providing universal access to web pages is long-established institutional policy, and in many instances it is required by state or federal regulations. It is critical, therefore, that you validate your designs and page templates and the content of your site throughout the development process to ensure that your pages are accessible to all users. Use the guidelines and techniques developed and maintained by the Web Accessibility Initiative (wai) as a measure against which to test the accessibility of your pages.

Sidebar: Web Accessibility

Making sure that web sites are accessible and usable by people with disabilities is the focus of web accessibility. The key efforts in this area arise out of the World Wide Web Consortium (W3C) in the form of the Web Accessibility Initiative. WAI efforts are focused on developing tools and best practices that promote the development of universally accessible web sites. Most validation tools use the WAI guidelines as the standard against which to measure sites.

The following links may be helpful in learning what makes a site accessible, how to promote accessibility within an organization, what’s required for accessible designs, and how to evaluate designs for accessibility:

Web Accessibility Initiative

Developing a Web Accessibility Business Case for Your Organization

Web Content Accessibility Guidelines

Evaluating Web Sites for Accessibility

Site construction

Only at this mature stage of the project are the bulk of the site’s web pages constructed and filled out with content. By waiting until you have a detailed site architecture, mature content components, fully tested wireframes and prototypes, and a polished page design specification you will minimize the content churning, redundant development efforts, and wasted energy that inevitably result from rushing to create pages too soon. Of course, you will always learn new things about your overall design as the prototype matures into the full-blown web site. Be prepared to refine your designs as you and your users navigate through the growing web site and discover both weak spots and opportunities to improve navigation or content.

Once the site has been constructed, with all pages completed and all database and programming components linked, it is ready for user testing. Testing should be done primarily by people outside your site development team who are willing to supply informed criticism and report programming bugs, note typographic errors, and critique the overall design and effectiveness of the site. Fresh users will inevitably notice things that you and your development team have overlooked. Only after the site has been thoroughly tested and refined should you begin to publicize the url of the site to a larger audience.

Typical products or deliverables at the end of this stage should include:

Finished html for all web pages, all page content in place

Finished navigation link structure

All programming in place and linked to pages, ready for user testing

All database components in place and linked to site pages

All graphic design, illustration, and photography in place

Final proofreading of all site content

Detailed testing of database and programming functionality

Testing and verification of database reporting features

Testing of site user support procedures, answering email, etc.

Archives of all site content components, html code, programming code, and any other site development materials

Maintainable code

Most businesses or departments in larger enterprises will contract with a web development group to create the initial site design and to build all the pages in the first version of the web site. They then assume responsibility for the site, doing some or all of the daily maintenance and updating content as needed to keep the site current.

Often not until the practicalities of site maintenance arise do customers realize the importance of understanding the details of how the web developer generated the html and other code that makes up the web site. Although all html and css markup is much the same to web browsing software, how the html and css is formatted and what web authoring tool the developer used can make a huge difference in how the code looks to a human reader.

Consider the two code examples below:

Example 1

<table summary=”HR Committee Schedule, FY 2008”>

<tr>

<th>Meeting Dates 2008</th>

<th>Agenda Item Submission Deadline</th>

</tr>

<tr>

<td>Monday, Oct 6, 2008</td>

<td>Friday, Oct 3, 2008</td>

</tr>

</table>

Example 2

<table summary=”HR Committee Schedule, FY 2008″> <tr> <th>Meeting Dates 2008</th> <th>Agenda Item Submission Deadline</th> </tr> <tr> <td>Monday, Oct 6, 2008</td> <td>Friday, Oct 3, 2008</td> </tr> </table>

Which example do you find easier to understand? These code examples are exactly equivalent to a web browser, but most people would find Example 1 significantly easier to read and understand. If you contract with a developer to build your site, it is important to understand how the developer writes code, what state the code will be in when the site is delivered, and whether the software used by the developer is compatible with what you will be using to maintain the site after delivery. Some web development software produces html code that is nearly impossible for a human to read without significant (and expensive) reformatting. Other programs (such as Adobe Dreamweaver) produce html code that is easy for web programmers to read, which can make a huge difference if you decide to change web developers or if you decide to edit html directly when maintaining your site.

If you hire someone to create your web site or components of your site, such as database or dynamic elements, be sure to ask what tools they will use to write the html and any other code. Ask to see examples of code written for other clients. Have your technology lead examine the code to be sure the developer inserts explanatory comments and dividers for legibility in the code. Be sure to find out whether there will be problems or conflicts if you use your favorite tools to edit the code the developer produces. Make sure the developer understands what editing tools you prefer to use and develops the code for maximum compatibility with your maintenance tools.

HTML and CSS code validation

Also ask for representative sites the developer has created, and choose pages to test for code validity, using the free online tools available from the w3c (see below). Many perfectly functional pages will fail w3c validity tests either for relatively minor code mistakes or for complex links to database or application urls that use problematic characters like ampersands (&). Ignore minor failures in the code validation, since they are unlikely to cause major functional problems. But if representative pages come back from testing with long lists of html code problems and css mistakes, beware of that developer’s work, and thoroughly discuss and put in writing your expectations around code validation as part of any contract.

html and css code validation tools from the w3c:

html validation: validator.w3.org

css validation: jigsaw.w3.org/css-validator

Today’s web pages are much more complex than pages in the past, and many new mobile and other devices can now display web pages. Search visibility is crucial to successful web sites, and web accessibility is a legal requirement with a growing set of case law behind it. Using carefully validated html and css code is one of your best strategies for getting maximum flexibility and value from your web development dollars. Be extremely wary of a web developer who tells you, “Validation isn’t important.”

Site marketing

Your web site should be an integral part of all marketing campaigns and corporate communications programs, and the url for your site should appear on every piece of correspondence and marketing collateral your organization generates.

If your web site is aimed primarily at local audiences you must look beyond getting listed in standard web indexes, such as Yahoo! and Google, and publicize your url where local residents or businesses will encounter it. Local libraries, newspapers, and schools are often the key to publicizing a new web site within a specific locale.

You may also find opportunities to cross-promote your site with affiliated businesses, professional organizations, broadcast or print media, visitor or local information agencies, real estate and relocation services, Internet access providers, and local city or town directory sites. Your organization could also feature local nonprofit charitable or school events on your web site. The cost in server space is usually trivial, and highly publicized local events featuring a web page hosted within your site will boost local awareness of your web presence. Site sponsorship might also interest local broadcast media as an interesting story angle.

Your home page url should appear in all:

Print advertisements

Radio and television advertisements

Lobby kiosks in high-traffic areas of your enterprise or in local libraries, schools, or other suitable venues

Direct mail campaigns

Business cards

Stationery

Bills and statements

Product manuals and product packaging

Response cards and warrantee cards

Publications and promotional materials

Press releases

Posters and billboards

Tracking, evaluation, and maintenance

Your web server software can record an abundance of information about visitors to your site. Even the simplest site logs track how many people (unique visitors) saw your site over a given time, how many pages were requested for viewing, and many other variables. By analyzing the server logs for your web site you can develop quantitative data on the success of your site. The logs will tell you which pages were the most popular and what brands and versions of web browser people used to view your site. Server logs can also give you information on the geographic location of your site users. Detailed logs are the key to quantifying the success of a web site. Your webmaster should archive all site logs for long-term analysis and should be prepared to add or change the information categories being logged as your needs and interests change.

A number of popular software packages are designed to produce easily readable site traffic reports, complete with data graphics and charts to aid in data analysis. As a service to customers, site hosting companies often offer reports from popular site analysis programs like Google Analytics for no additional charge. Before contracting with an Internet service provider for site hosting services, always ask about site analysis services. If your isp (Internet service provider) or corporate web site does not offer a good site traffic analysis package, ask whether the webmaster can give you access to a monthly server log of your account. Basic versions of traffic analysis programs like WebTrends are inexpensive and you can run them on a personal computer if you can gain access to the raw web server log from your isp or corporate webmaster (fig. 1.9).

A screen capture from Google Analytics, showing the various tabular data and graphic chart data displays of web site metrics.

Figure 1.9 — Web statistics are much more than just raw measures of traffic. They can tell you what content people looked at, where your visitors are coming from, and provide a rich set of technical information on what technology your typical readers are using. From Google Analytics.

Maintaining the site

Don’t abandon your site once the production “goes live” and the launch parties are over. The aesthetic and functional aspects of a large web site need constant attention and grooming, particularly if a group of individuals shares responsibility for updating content. Your site editor will need to be responsible for coordinating and vetting the new content stream, maintaining the graphic and editorial standards, and ensuring that the programming and linkages of all pages remain intact and functional. Links on the web are perishable, and you’ll need to check periodically that links to pages outside your immediate site are still working. Don’t let your site go stale by starving it of resources just as you begin to develop an audience—if you disappoint them by not following through, it will be doubly difficult to attract your audience back to the site.

Backups and site archives

The site editor should be sure that the web site is regularly backed up onto a secure and reliable storage medium to ensure that a catastrophic hardware failure in your web server does not wipe out your web site. Most web servers maintained by it professionals or commercial web service providers are backed up at least once a day. If you don’t know what your backup schedule is, ask your webmaster or web hosting provider. Human error is the most common reason you may need quick access to a backup copy of your web site. Unfortunately, it’s easy to overwrite an old file (or a whole directory of files) accidentally over a newer version on the web server, to delete something important in error, or to wipe out someone else’s work by mistake when updating a web site. A recent backup (ideally no more than twenty-four hours old) can often be a lifesaver.

If your site is successful, it will quickly become an important record of your enterprise’s work, your accomplishments, and a valuable record of the “state of things” as the site evolves over time (fig. 1.10). Unfortunately, too little attention is paid to this aspect of web sites, and we are collectively losing huge pieces of our hig because no one thinks about preserving permanent records of a web site. Unless your web site is prohibitively large, your web site editor should arrange to collect and store the files of the site periodically or contract with your web service provider to set aside a backup version at regular intervals as a long-term archive. We take for granted the “paper trail” of history left by conventional business and work practices. Without a plan for preserving our digital works, our collective history may vanish without a trace.

A four-part diagram comparing the gradual evolution and growth over time of old buildings (show as building diagrams) and old web sites (show as site diagrams).

Figure 1.10 — Much as older buildings grow through additions and adaptation over time, sites grow and change in response to changing needs and ideas. (Adapted from Stewart Brand’s How Buildings Learn.)

Developing a Project Charter

Developing a Project Charter

The project charter is the planning team’s concise statement of core goals, values, and intent in order to provide the ultimate policy direction for everything that comes next. Designing a substantial web site is costly and time-consuming. When you’re up to your neck in the daily challenges of building the site, it can be easy to forget why you are doing what you are doing and to lose sight of your original priorities, not knowing whether the decisions you are making firmly support the overall objectives. A well-written project charter is a powerful daily tool for judging the effectiveness of a development effort. It becomes a compass to keep the team firmly pointed at the goals established when you started the journey. A good project charter becomes a daily reference point for settling disputes, avoiding “scope creep,” judging the potential utility of new ideas as they arise, measuring progress, and keeping the development team focused on the end-result.

At minimum, a project charter should define the content scope, budget, schedule, and technical aspects of the web site. The best project charters are short and to the point, often outlines or bulleted lists of the major design or technical features planned. The finished project charter should contain the goals statement from the planning phase, as well as the structural details of the site.

Goals and strategies

What is the mission of your organization?

How will creating this web site support your mission?

What are the two or three most important goals for the site?

Who is the primary audience for the web site?

What do you want the audience to think or do after having visited your site?

What web-related strategies will you use to achieve those goals?

How will you measure the success of your site?

How will you adequately maintain the finished site?

Production issues

What is the budget for the site?

What is the production schedule for the site, including intermediate milestones and dates?

Who are the people or vendors on the development team and what are their responsibilities?

How many pages will the site contain? What is the maximum acceptable count under this budget and schedule?

What special technical or functional requirements are needed?

Who will be responsible for the ongoing support once the site is launched?

These are big questions, and the broad conceptual issues are too often dismissed as committees push toward starting the “real work” of designing and building a web site. However, if you cannot confidently answer all of these questions, then no amount of design or production effort will guarantee a useful result.

Avoiding scope creep

The project charter defines the scope of your project: what you need to do, the budget, and the development schedule. Scope creep is the most prevalent cause of web project failures. In badly planned projects, scope creep is the gradual but inexorable process by which previously unplanned features are added, content and features are padded to mollify each stakeholder group, major changes in content or site structure during site construction are made, and more content or interactive functionality than you originally agreed to create is stuffed in. No single overcommitment is fatal, but the slow, steady accumulation of additions and changes is often enough to blow budgets, ruin schedules, and bury what might have been an elegant original plan under megabytes of muddle.

One excellent way to keep a tight rein on the overall scope of the site content is to specify a maximum page count in the project charter. Although a page count is hardly infallible as a guide (after all, web pages can be arbitrarily long), it serves as a constant reminder to everyone involved of the project’s intended scope. If the page count goes up, make it a rule to revisit the budget implications automatically—the cold realities of budgets and schedules will often cool the enthusiasm to stuff in “just one more page.” A good way to keep a lid on scope creep is to treat the page count as a “zero sum game.” If someone wants to add pages, it’s up to them to nominate other pages to remove or to obtain a corresponding increase in the budget and schedule to account for the increased work involved.

Changes and refinements can be a good thing, as long as everyone is realistic about the impact of potential changes on the budget and schedule of a project. Any substantial change to the planned content, design, or technical aspects of a site must be tightly coupled with a revision of the budget and schedule of the project. People are often reluctant to discuss budgets or deadlines frankly and will often agree to substantial changes or additions to a development plan rather than face an awkward conversation with a client or fellow team member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes rationally.

The firm integration of schedule, budget, and scope is the only way to keep a web project from becoming unhinged from the real constraints of time, money, and the ultimate quality of the result. A little bravery and honesty up front can save you much grief later. Make the plan carefully, and then stick to it.

Shaping the final project charter

The project charter is the document that formally authorizes a project to begin. In projects bid out to external contractors this information is generally contained within a request for proposal (rfp) document, but a project charter should exist for every web project, even small in-house web sites.

Statement of work or deliverables

The project charter should begin with a concise narrative description of the content, features, and services that the new site will provide. For in-house projects the project sponsor usually supplies this statement of overall intent for the site. For projects offered to outside design firms the statement of work forms the core of the rfps offered to potential contract bidders.

Business needs the site will support

This section answers the “why” of your project. It should be a short description of the sales, marketing, communications, or other business goals that will be accomplished by creating the new web site, along with a rationale and general metrics for determining the success and return on investment (roi) for the proposed web site. Think of it as a written version of your “elevator speech” to senior managers who must approve the project: your most concise, to-the-point rendition of your top three reasons why the new or redesigned web site should exist. This section should end with a short strategic statement that places the site project within the context of the sponsoring organization’s missions and existing web presence.

Satisficing in design

The economist Herbert Simon coined the term “to satifice” by combining “satisfy” and “suffice.” Satisficing is consciously choosing not to find one perfect design solution and instead aiming at a balanced approach that roughly satisfies (“satisfices”) all major design requirements. Complex or lengthy design iteration is expensive and necessarily involves the combinations of many unknown factors with no clear promise of a single optimum design solution. Although satisficing may sound like settling for mediocrity, satisfice strategies have produced some of the most successful designs of the past century.

The Douglas DC-3 was not the best competitor in any single performance class: all its competitors could best it in some category of speed, engine power, range, and carrying capacity. Yet the DC-3 was such a successful satisfice of all design factors that today, more than seventy-five years after it was designed, more than thirteen hundred DC-3 airframes are in daily use.

Don’t allow contention over single points of your site design to paralyze the design process or to plunge your team into endless rounds of “Would it be better if . . . ?” All projects are in some measure satisfices, because there’s no practical way to know if there is a single best solution to every problem for every user. Don’t let the perfect become the enemy of the very good.

Drawing of the side view of a Douglas DC-3 airplane.

Success metrics

Most web site projects have measurable goals: to increase traffic, boost sales, improve client relations, reduce support emails, and so on. Many of these measures rely on preexisting data to enable before-and-after comparisons of the site’s success. Before you begin a site development project, determine how you will measure the impact of your efforts, and include details of success metrics in your project charter. It is important to establish success metrics before you begin because you may need to be proactive about collecting “before” data before launching the site.

Project scope and description

Here you detail the “what” of the proposed site. In as much detail as possible for each stage of the project, describe the web site to be created. Early in the planning process this statement will have to be general and should concentrate on the core “must-have” features, content, and purposes of the site. Avoid specifying the use of specific technologies (such as, “We’re using Ajax for everything”) that really should be determined after the web site team has made a thorough assessment. The project scope description should be a living document early in the planning stages of the project but should become a fixed specification before hard budget numbers or schedule deadlines are assigned to the project. Ironically, it is often useful (and sometimes easier) to make a careful statement of what your project is not. This form of “is/is not” scope statement is particularly useful where your new site may have aspects that are similar to existing organizational sites or where your project sponsors may not immediately grasp your intent in creating the web site.

Roles and responsibilities

Your charter should name the major sponsors, the project, design, technical, and editorial team members, and any other strategic stakeholders within the enterprise. There is no single correct way to structure a web site development effort, but everyone involved should be clear at the start about who is responsible for each aspect of the site development. This is an opportunity to make the point that the project requires an ongoing commitment, beyond the site launch. It is also another opportunity to clarify for sponsors and stakeholders that they have responsibilities and deadlines too, and that the team will be dependent on everyone’s contributions. You should also outline a proposed project governance and approvals process, so everyone involved is clear about how each major project milestone will be communicated and formally approved by the sponsors or major stakeholders (fig. 1.11).

Large, two-page diagram of a very detailed Gantt chart for a complex web design project, showing the relative level of effort for each team discipline over the life of the project.

Figure 1.11 (Click for a PDF version) — A more detailed look at a typical web site development project. Note that although many people and disciplines may contribute to building a site, not everyone is busy at the same time. Project management is essential to bring the right resources to bear when they are needed.

Project budget

Your project budget should account for all of the expense categories outlined in Site Definition and Planning, above. Make your best calculations on your people, hardware, software, content, and technology development expenses, and then add a hefty contingency budget. Web projects always grow, often by as much as 10 percent or more, even in tightly managed projects. It happens to everyone, and it will happen to you, too. Plan for it rationally, or deal with the pain later.

Project risk assessment

Every good project plan should outline the risks of failure in major components of the project. Although your whole project is unlikely to melt down, take a hard look at the various make-or-break components of the plan and think about “Plan B” alternatives. For example, what happens if your content development and site design work out well, but your programmers don’t meet expectations on interactive features? Will the site be viable? What happens to the project team if your designers and technologists do everything right but the client fails to produce the site content on time? What financial, schedule, quality-assurance, or other contingencies could be written into the contract and project charter to mitigate those risks?

Common risk points in web projects

Schedule, budget, and scope of work: Let these drift and you’re doomed.

Quality assurance: qa becomes a problem when other schedules run long but the launch date doesn’t change and qa testing is squeezed into the last few days before the site goes live.

Content development: This is the most commonly underestimated factor in web publishing—ask any editor.

Application development: Web projects rarely fail because an application does not function properly. Instead they fail because the intended audience hates to use it or doesn’t find its features useful.

Security audits and managing security risk

Databases and applications that deal with e-commerce, or sensitive personal, financial, or health-related information should be scrupulously maintained and periodically audited for data security threats. Even a minor security leak or unchecked programming error could allow a hacker to access your database records, cause malicious damage, or take over your server to support email spamming or other illegal Internet schemes. The data security environment changes daily, and what was perfectly secure six months ago might be hopelessly vulnerable today if your servers, databases, and applications are not under active management and maintenance. Any web-based application or web database must operate with a plan for periodic security audits, as well as the normal timely application and web server patching and maintenance that you’d expect in any well-management data center or commercial web hosting service.

Ongoing technical support for hosting, databases, applications

Nontechnical managers are often unpleasantly surprised by the expenses of hosting and maintaining web sites that require substantial database or programming support. Although basic hosting of “static” web sites is an inexpensive commodity, web sites that depend on databases and the complex interactive features of web applications must usually be hosted on two or more tightly interrelated servers for security and technical reasons. The multiple servers must be maintained and updated, regularly backed up to prevent data loss, and housed in a secure networked data center environment for maximum reliability and “up time.” Make sure that your technical team lead has accounted for these ongoing system maintenance costs as well as the initial development and start-up costs.

Editorial maintenance

Your brand-new web site starts aging the day you launch it into the world. If you don’t maintain the site, technical changes, content changes, and the inevitable entropic “link rot” will degrade your site over time. Even a simple site with relatively stable content will deteriorate over time without basic maintenance, and business environment changes that affect your content will certainly happen. Plan for it, make sure you can clearly identify who is responsible for which content on the site, and make ongoing maintenance part of the original site planning.

General Advice About Running Web Projects

General Advice About Running Web Projects

Ready, fire, aim

The prospect of creating a new or revised web site is exciting, and many teams will find it irresistible to jump in and start “sketching” or prototyping site designs long before anyone on the team knows:

What your goals and strategies are

Who exactly you’re designing the site for and what those users want

What essential content structures, navigation, and interactive features are needed

Don’t let the process get hijacked by eager beavers who “just want to make some pages.” Decide the big strategic things first, and make pages only when you have all the important answers in place to guide the rest of the design process intelligently.

Stay away from visual design until everything else is planned

The fastest way to run a web project off the rails is to start your planning process by discussing the home page visuals or what the overall graphic design of the site should look like. Pour the foundation and build the walls before you let anyone fuss about the color of the drapes. The visual form of your site should flow from careful and informed decisions about site structure, navigation, content and interactivity requirements, and overall business goals. Detailed visual design should always come last in site planning: premature graphic design decisions will confound you at every turn.

Small is good

Often the easiest way to “manage” a site project is by adding content or features to avoid contention on the team, particularly if you look only at the initial programming or design costs. Large web sites are expensive to maintain, and it’s easy to bite off more than you can chew. Every new page, link, or application feature requires a long-term maintenance commitment. Stay small if you can, and stay focused. A small, high-quality site is infinitely better than a giant contraption with old content and broken links. The Kiva site is a model of simple, straightforward design and functionality—staying small while accomplishing enormous good (fig. 1.12).

Screen capture of an internal page on the Kiva site.

Figure 1.12 Elegant sites are never more complex than they need to be. www.kiva.org

Plan the work, then work the plan

The oldest joke in project management is, “Good, fast, or cheap? Pick any two.” If you are developing anything more than a small web site, make sure you have an experienced web project manager.