Blue Link Webs produces small and medium Web sites for business. We're experts at database-driven Web sites using LAMP (Linux, Apache, MySQL, and PHP) and AJAX (Asynchronous JavaScript and XML).

Project Methodology

We believe in planning. Of the ten steps listed here, five are planning and preparatory steps. We've found that time spent up front in planning is more than repaid through the reduction of rework near the end of a project. We're happier because no one likes rework, even if they're being paid by the hour. More important, the client is happier because there are no surprises, either in cost or in the delivered product.

Here is what some other experts say about planning:

One of the most common mistakes new Web designers make is plunging into developing a site without thinking through all their goals, priorities, budget, and design opportunities. ... Do yourself a favor and save yourself some grief by planning ahead.
          –Warner and Gardner, Dreamweaver MX 2004 for Dummies

Because planning and a methodical approach are so crucial to success in Web development as in any information technology project, we've developed a ten-step process that delivers successful Web sites on time, on spec, and within budget. Laid out in a list, our methodology looks like this:

  • Statement of purpose
  • Storyboards
  • Functional requirements
  • Page designs and prototypes
  • Page templates and style sheets
  • Content development
  • Design, programming and coding
  • Integration and documentation
  • Testing
  • Project turnover.

This list might make you think that a project could take a very long time. That doesn't have to be the case because a lot of overlap is possible. The first step, statement of purpose, stands alone. After that, storyboards, functional requirements, and page designs can overlap. The client is primarily responsible for content development, and can proceed as soon as the storyboards begin to take shape. At the same time, Blue Link Webs will be collaborating with the client on page design and developing prototypes. Programming and coding can start when the functional requirements are complete. Integration brings content, design and programming together, and so occurs late in the process. Each function is unit tested as the functions are developed, so in the project testing phase, what is being tested is how the functions work together. Alpha testing by Blue Link Webs is followed by beta testing by the client and possibly by outside testers. Project turnover involves moving everything to the client's server if it's not there already, a final round of integrity tests on the client's server, and formal acknowledgement that the project is complete.

Statement of purpose: For any project, big or small, we like to start with a statement of what success looks like. The statement of purpose tells what a successful project will have accomplished. It will almost never be more than a page long. Here, for example, is the statement of purpose for the Blue Links Webs Web site:

The Blue Link Webs site is a showcase that lets our expertise shine through and exemplifies our philosophy. Visitors can tell by looking that the site was designed and executed by experts, and will want their own Web presence to reflect the same kind of expertise.
The Blue Link Webs site has enough information about our virtual organization, our philosophy, our approach to our projects, and our cost structure that a visitor can make a reasonable assessment of whether we would be a good fit for a planned project without needing additional information.
Finally, Blue Link Webs will use our Web site to share the knowledge we've developed over more than eleven years of working with the medium. We will write up our more interesting and useful techniques and publish them on our Web site, along with an invitation to use them under a minimally-restrictive license. We've learned a lot from others over the years, and we will pay back by sharing what we've learned.

That's it. Just three paragraphs and six sentences make a yardstick against which to measure our own Web site. Although there's work for us to do in sharing our knowledge and techniques, we think the site you're reading accomplishes what we set out to do.

Writing a similar statement of your own purpose will give you the same kind of yardstick against which to measure not only the final product, but also your progress from the very start. It will keep you and the development team focused on your goals.

Storyboards: The storyboards describe the story your Web site will tell. You have a story in your mind, and the storyboard puts it in physical form so that others can help you implement it. The easy way to develop a storyboard is with Post-It notes and poster paper. Write each main idea on a Post-It. Arrange the notes on the poster paper so that the ideas flow left to right and top to bottom. When you are satisfied with the arrangement, use a pen or marker to connect them with arrows. The notes represent individual Web pages, and the arrows represent the navigation. We'll turn your storyboard into an electronic document that can change and evolve as your Web application develops.

As you write the Post-Its, also note the graphics, illustrations, photographs, or other multimedia "objects" that you believe this page will have. Keep a separate tally of those objects by writing on a master list each time you write on a Post-It. When you're done with the storyboard, you'll also have a list of other elements to develop.

When you're done, number the pages. If there are a lot, use outline numbering, like this: 1, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 2.2.1, and so on. otherwise, just number them.

Functional requirements: The functional requirements describe the things that visitors to your site will be able to do. For a small and static site like this one, the only functional requirement is for navigation. For database-driven sites that are our specialty, the functional requirements may be much more complex. We'll work with you to develop a set of functional requirements that describe what you want your Web application to do. The functional requirements describe the "what," not the "how" of a Web application, and are written in language that uses little or no technical jargon or special terminology.

The functional requirement phase is where security is addressed. The Web hosting provider is responsible for physical, network, and operating system security. Application security is our responsibility, and we take it seriously. We will work with you to consider the C-I-A of information security: confidentiality, integrity, and availability, and to develop specifications that strike an appropriate balance between usability and security.

Page designs and prototypes: The page designs establish the look and feel of the site. The design includes layout, typography styles, colors, and graphical features like logos, ornaments, and photographs. The first stages of page design can literally happen on the back of an envelope. Extremely rough sketches are enough to get us started. Some designers call these sketches "wireframes." That sounds impressive, but it's still just a sketch.

There's no substitute for seeing the real thing on the screen, and once we understand your design idea, we'll produce a prototype of each kind of page in the site. There won't be many. Even a large site may have only half-a-dozen different page designs. (The Blue Link Webs site has three, and two of them are used only in our Web Development Notes and supporting pages.)

When the client is satisfied with the prototypes, each is documented. The documentation will become part of the site's style guide. The style guide is what helps you keep a consistent look and feel as the Web site grows and changes. You'll use it when you make changes yourself, and if you hire a different Web developer for a later part of your site's development, you'll give them a copy.

Content development: Content development depends upon the storyboard, and so it can start as soon as you're satisfied with the storyboard. There are four kinds of content, not all of which will apply to every site:

  • Text
  • Graphics and illustrations
  • Photographs
  • Sound, animations, video, and other multimedia
  • Data

You'll develop the text yourself. Use whatever word processing program you're most comfortable with. Name your file according to the number on your storyboard, and indicate which graphical items appear with the text. (The Microsoft Word comment feature works well for this.) You don't have to try to include the graphics in the document itself; we'll do that.

It is not unusual for content development to trigger changes in the storyboard. You write something and you get an idea for something else. Good! Changes are easy at this point. The storyboard is sticky notes on poster paper. Just change them!

Even a simple site will have a surprising number of graphic objects. We'll take care of the "behind-the-scenes" objects like rounded corners for boxes. We can help with graphic arts development, or use your logos and illustrations.

Page templates and style sheets: When page design prototypes are accepted, the designs will be turned into Dreamweaver templates and style sheets. A template is much more than the empty skeleton of a Web page. It is a tool that can be used to create pages quickly and with the assurance that they follow the template exactly, and even to make small corrections to the structure of pages after they've been built. The template represents the structure of a particular page design. For each category of template, we'll also create a style sheet. Style sheets are computer code that describe the presentation of a Web page. By centralizing information about the structure and presentation of each page design, we guarantee that all pages of a particular design will have the same look and feel, and we make future changes much easier.

Program design and coding: For sites that use server-side programming, database technology, or AJAX functionality, the necessary programs were identified in the functional requirements. In this phase, the programs are designed, coded, and tested.

Integration and documentation: The site directory structure is finalized and navigation elements are completed. The directory structure will closely follow the project storyboard, so storyboard changes become more complex after this point. A computer file containing HTML and other code is built for every page in the storyboard; the site will be navigable on the test server at this point, although some pages will be skeletons. Content items and program are integrated into the HTML. The directory structure and navigation are documented, documentation developed in earlier phases it collected, and any necessary help pages are built. A test plan is written to describe how conformance with the specifications will be measured. Program code is integrated into the HTML pages. For most sites, the integration and documentation phase will be the longest (and most exciting!) phase in the development of your Web site.

Testing and remediation: Following the integration and documentation phase, the whole project works. You can navigate around the pages and perform the functions described in the functional requirements. Navigation, functionality, and "fit and finish" are tested according to a test plan, first by us, then by you, and in some cases, by outside testers. If any elements fail to meet the specifications developed for the project, remediation brings the test site into conformance with the specifications. The specifications are the driving force behind testing; differences between the code and the specifications are collected into a punch list, and the developers correct each item in the punch list to conform to the specifications. Changes to the functional requirements, storyboard, or site content are not part of testing and remediation, and return the project to earlier steps in the process.

A word about changes: In the integration and testing phases, Web projects become real to clients, who may develop dozens of good ideas that could really improve the project. Building a Web site is like building a house; the flow of ideas doesn't stop when construction has started. But, like building a house, a change that's easy in the blueprint stage may be difficult and expensive after the walls are up. To keep everyone in sync, once each part of the specification is in final form, we will want to document requested changes in the form of change orders.

Project turnover: For new sites, we may have the luxury of building the site on the client's server or Web hosting account. In that case, "project turnover" might consist of a celebration lunch. However, if we were replacing or modifying an existing Web site, we will have had to do the work someplace else. For simple sites, we can use our own hosting accounts; for more complex sites, we will want an account that duplicates the production environment as closely as possible. In either case, the new Web site has to be transported into the production environment. We will develop a cutover plan that describes how the existing site will be backed up and the new site put in its place. Part of the cutover plan will be re-execution of the test plan on the production site to verify that everything functions as intended. A deliverable checklist will assure you that you've gotten all the ancillary material, like documentation, page templates, and source files for graphics.

Happily ever after: By the time of project turnover, the client has contractual control of the domain name and hosting arrangements. If there are database functions, we will have provided database update programs so that the client can make any necessary changes. We will have helped set up a copy of Macromedia Contribute so that the client can make changes to the content without help. We will have delivered all the necessary documentation and source files, along with licenses for anything that is not a work made for hire. In short, at project turnover, the client will be in complete control of the site and all its contents. We hope that will be the beginning of a long relationship in which you do the easy and comfortable things, and we do those things you'd rather not tackle. But, in keeping with that part of our philosophy that says, "It's the client's site," we promise to leave you in a position where you get to decide.