Kevin Wright’s blog

Your development server and your production server may be one and the same, and you may have been developing the site ‘blind’ by using a dummy home page, or not attaching the domain name; however, you may be using an offline development server instead, with the intent of posting it on the production server for public use when the site is finally done. Why would you choose to do so? Following are some scenarios where it would make sense:
1. You have a large, complex website that needs to be built and tested truly offline, not in any way connected to the Web.
2. You already have a website in operation, and you are building new features for it. Obviously, you do not want to build and debug new features on a site that is in active use.
3. You have hired outside developers to build the site. They are working on their own server, with the intent of moving the site to your server when completed.
These three cases, combined with the various kinds of websites and technology in use, can generate many different situations. Regarding going live or adding new features, and the procedures for doing so, far too many situations exist to examine each one; however, let’s consider some common situations:
* A large, database-driven e-commerce site going live for the first time and being developed out -of-house: In this situation, the site is being developed on a development server (the outside developer’s server). Therefore, it needs to be moved over to the production server and tested before the site can go live. A good approach would be to use password protection until final testing and debugging on the production server is completed.
* A new Java-based game is being added to a Web page on an already live, internally hosted website: In this situation, the Java game can be placed on a copy of the target page on the live server. The file for the page with the game on it should be renamed and placed on the server in the same directory, so any path or linking information remains valid to the current home page. The page with the game on it can be tested and debugged in place on the live server, without affecting the current page that users are accessing. Once the game page is debugged and final, you can simply revert to the home page file name, overwriting the current page, and the new Java-game home page will be live.
* You have an existing website and are switching over to a new ISP: In this case, the domain name/IP address connection is the only real issue. To handle it, start by copying the old site over to the new server, without touching the existing live website. Next, get the IP number of your new site established and test the new site using the new IP number instead of the domain name. When the new site is ready to your satisfaction, ask your ISP to have the domain name switched over to point at the new IP number.
Many development projects involve a transition to a new server. If this is the case, it makes sense to communicate this information with technical personnel who will be maintaining the server, giving them as much lead time as possible. An outside hosting service deals with multiple customers with all kinds of projects going on. In vendor relations, it is a courtesy and often a necessity to give an early heads-up to an outside hosting service. You do not want to be the customer who says, ‘You’ll have the files by 5 p.m., and, by the way, the site needs to go live tomorrow.’ Even if your service can scramble at your behest, you will have lost goodwill.
The irony is that in an in-house hosting scenario, the technology staff may be much less responsive to your needs. No matter what the internal accounting setup is, it tends not to frame you as a ‘paying customer’ in the same way a vendor-client relationship does. A fact of organizational life is that projects are often prioritized by the status of the requester rather than by business objectives. In short, the project manager is called on again to use interpersonal skills and political acumen in this transition to a new server. You absolutely have to be on top of some technology issues here; but don’t kid yourself, it takes people to make it work.
Internal technology personnel hold the keys to the kingdom. No matter what their position in the company hierarchy, they hold power over what goes on the machine. They also tend to be territorial about it. Communication as early as possible is important to gain their buy-in on the project. The technical specification is a key document for this communication. If you’ve kept the document current during the development, it will give technology staff a good idea of the technical requirements and the issues involved in making the site work.

Functionality testing refers to the testing of programmatic features and is most appropriate for sites of higher complexity that contain features such as database access, dynamic page generation, and Java applets, namely features that require actual programming (rather than HTML page building).

Unit Testing

Functionality testing should start at the source, namely by the programmers who write the code. When programmers test their own code, module by module, it is referred to as unit testing. Each programmer tests his or her own modules thoroughly and does not start a new module before testing and fixing the previous one. The programmer tests not simply by running the code a few times to see if it works, but rather by feeding the code common, uncommon, and even unexpected inputs to make sure it handles them correctly and does not malfunction. This technique is the most cost-effective and efficient testing method and is a way of promoting ‘quality at the source.’ Programmers who are willing and able to thoroughly test their own code module by module, after each is written, generally find defects faster than other testers and are able to fix them in the shortest time. Unit testing stops problems before they can crop up in other modules, and it prevents other testers from having to spend time finding, isolating, and documenting these defects, then retesting for them later (regression testing) to make sure they were fixed.
Requiring programmers to thoroughly test their own code can be difficult to enforce, however, for several reasons. First, most programmers like to write code, not test it. Some see testing as monotonous work that is not part of their job. Second, programmers are often under extreme pressure to produce usable code as fast as possible. Therefore, the emphasis is often on quantity rather than quality. If programmers are on a tight schedule, there is little chance they will want to spend ‘extra’ time thoroughly testing their own code instead of logging the completion of that module and starting work on a new feature.
You should do your best to encourage programmers to take the time to test their own code thoroughly and fix defects they find before turning it over. One motivation is to let it be known that you will be monitoring the quality of the modules during testing.

Integration Testing

When the various modules are combined and the features are all running together, it is said to be integrated, and testing of the full program is called integration testing. Although all of the modules may seem to work perfectly in isolation, they often exhibit defects when combined as a system. Reasons include unexpected inputs and outputs between modules, incompatible variables, and just about anything else that can go wrong. Professional software testers are experienced in finding such flaws, and integration testing is usually performed in force by nonprogrammers. By not knowing how the site is constructed, they are more likely to operate the software in a way programmers had not anticipated, and so uncover errors programmers would not uncover.
Website features should be tested in an ongoing manner, while still in development. Testing the site this way allows the project manager to realistically monitor the site’s progress, by building testing time right into implementation. For example, if QA testing does not start until after the whole site is supposedly ‘finished,’ you would have no idea how many defects are actually lurking out there in the code and how long it will take to fix them. In addition, there is a good chance the defects will be repeated in various forms throughout the site. If the site is tested as it is being built, however, defects-especially those in the software architecture-can be caught earlier and will be easier to fix, and will cause fewer follow-on defects, lending a gauge of actual progress to date.

Regression Testing

The most thorough method of testing is not only to test for defects fixed from the previous versions, but also to retest for defects fixed in earlier versions. This process of repeatedly retesting for defects to see if any old ones have reappeared is called regression testing. Good record-keeping of what version of the software exhibited the defect is essential to regression testing. For example, if a particular defect was found in a database query on Monday, and fixed on Tuesday, it is wise to continue testing for it in subsequent days and even weeks to follow. At first glance, this process may seem excessive; however, regression testing can uncover serious problems and safeguard against them. Defects that were apparently fixed may recur for various reasons. An old copy of a particular file may have been used by mistake to build a later file, or a new or different programmer may attempt to optimize code and reintroduce an old error.
Another reason to perform regression testing is that in the process of fixing old defects, new defects may be introduced. It is entirely possible for a programmer to inadvertently introduce one new defect for every 20 fixed. Regression testing allows a much better chance of discovering these potentially serious defects.

Compatibility Testing

Testing the site on the various kinds of user hardware and software configurations is called compatibility testing. If the site has programs that run on the user’s browser (client-side programs), such as Java applets, JavaScript, or various plug-ins, it should go through compatibility testing. With the various versions of Java and JavaScript that have been released, it is possible that features that work fine on one machine may stall or malfunction on another. Problems reveal themselves in such situations that might never be discovered otherwise.

The project manager must monitor the content development process closely. Programmers and graphic artists will be able to complete much of their work using dummy data. Sooner or later, however, the content must arrive. Missing or late content, especially with accountability on the client end, is a leading cause of deadline slippage. It’s important to stay on top of the content situation. Content encompasses multiple media-written text, graphics, photos, audio, or video. The files may be stand-alone for HTML calls into a static Web page, or they may be records in a backend database.
Often, the content needs work on the developer’s end. You can control the amount of work by writing detailed specs for content in production guidelines; however, it might be advantageous to the schedule for members of the development team to take on some of the content development responsibility. For instance, suppose the marketing design staff of the client is modifying print graphics for use on the website, but they lack experience with Web graphics. It would be more efficient for your experienced Web artists to assume this task. In fact, they might end up redoing the client’s work anyway, which leaves you with the worst of both worlds. Of course, preparing the graphics files is a commitment of time and resources. If this responsibility is beyond the scope of the agreement, then additional compensation is appropriate.
Not only does the content need to come in according to schedule, but it must also be satisfactory in quality. It probably will not be possible for you to check every piece of content personally, and in fact, you may not feel qualified to judge it. You should, however, establish a system that ensures that somebody is responsible. The Web is full of copy that, by all appearances, has never been edited. Companies take great care in editing and proofreading brochures or press releases, yet when it comes to publishing on the Web, quality control seems to relax or be nonexistent. The nature of Web pages is that editorial changes are easy to implement after publication, whereas with print pieces you get only one shot. Nonetheless, it’s best to resist the temptation to ‘worry about that later.’ Print and graphical content should be checked against the specifications you’ve communicated and for a general quality review.
Content development for a website project is accomplished in one of two ways:
1. offline content development
2. online content development
 
Offline Content Development

In offline content development, as the name would indicate, you build pages offline, on a workstation rather than on a Web server. You would generally use this method in building a basic site of static pages. In this process, you build pages or content files and, when complete, they are uploaded (copied) to the server. This procedure is generally the case for regular HTML pages or fully prepared database files. Master templates or style sheets for the design can make offline development much more efficient. Nonetheless, the technique is not very scalable to websites that contain many pages.

Online Content Development

As a site grows, the viability of updating and adding pages manually diminishes, until it becomes less and less feasible. As an extreme example, imagine building all of the pages for a site like Weather.com, which gives up-to-the-minute weather maps and forecasts for cities nationwide. Maintaining a site like Weather.com, or Amazon.com with so many individual product pages, is possible only because the content is drawn from a database.
Each page is created ‘on-the-fly’ by the server in response to your request. When, for example, you request the weather report for Chicago, your computer sends the request in the form of a command to the Weather.com server. The server then follows three steps:
1. Finds the generic ‘weather report’ page (an ‘empty’ template page without data).
2. Looks up the data for that location and places it in the proper spots on the template page.
3. Sends you that newly created page.
So, through automation, creating such a rich site is a piece of cake. Well, almost. Data must still be created and placed in the database.
The Web development team can access the backend database online and maintain it from any Web-connected browser. E-commerce sites commonly use an online content development process. Company personnel must continually update information, adding new products, deleting old ones, and changing prices, or posting new promotions. Those closest to these marketing and product decisions are probably not database experts; however, user-friendly interfaces simplify the process. Using standard browser software, authorized staff can access Web pages set up to edit records in the database through text-based form fields, pulldown lists, and dialog boxes. With appropriate security and authentication processes in place, staff or contractors can maintain the site from any location connected to the Internet.
Online content development is a powerful tool. With some upfront investment, you gain tremendous scalability with database-driven websites, which is truly a strategic asset in today’s Web marketplace.

For a website, a prototype is a first attempt to express or demonstrate the functional design through one of the other design phases. Following are a few examples of prototypes:
* The navigational prototype is usually a layout of the navigational structure of the site, also called the site skeleton or framework. Without implementing actual features, this prototype shows only the overall navigation structure. It uses plain links and blank pages,
or pages with sample data.
* The technical prototype is a raw demonstration of the features required by functional
design. It may be a programmatic interface to a database, which shows how you can
search a particular database by various parameters.
* The visual prototype could take the form of a simple graphic file (not even a real HTML
page) showing an ‘artist concept’ of the home page. This is often called a ‘treatment’ or
graphic approach.
What all of these prototypes have in common is that they provide the first ’support beams’ for the website, a starting point from which the design can proceed. As the various prototypes are refined and accepted, they are combined to build a first version of the website, which may also be called a prototype. Design proceeds in modular fashion where possible. If you must discard your work, which is expected, it’s best if you can do so in removable chunks.

Phase 2: Skeleton Framework

Phase 1 developed the concept through creation of the menu-tree diagram. From that document, planning work for the functional, technical, and creative efforts ensued. The next step is to prototype the website by developing skeleton Web pages representing the pages on the menu-tree diagram (Figures 8.4 through 8.6). These pages are ‘empty,’ consisting only of the minimal HTML tags and content for the page title and navigation links. It’s best to work without content or graphics at this stage. If, for some reason, you find it useful, dummy content should suffice. In this manner, you can quickly prototype the whole site. As you click your way around the site, design flaws will be readily apparent. In this bare bones environment, nothing can hide the navigational structure. An ideal iterative environment, the skeletal framework takes only a few minutes to build or change. You can test-drive concept and structure and easily experiment with modifications.

Phase 3: Home Page and Motif

With the skeleton framework in place, the graphic artist has enough information to sketch out a visual design approach, or motif, for the site. The work generally begins in a graphics program such as Photoshop. Drawing from the creative brief and samples of the client’s existing images, the artist works up a few alternative designs and approaches for client review. Based on feedback from the client, the artist revises the home page design until client approval is gained. Once approved, the motif can be applied to the rest of the pages in the site, keeping the site style consistent.

Once you know what you are building, and how you are going to build it, you can start designing what it will look like and how the user interacts with the various features on the website. As project manager, you will communicate to the graphic designers and user interface designers who the audience is-their attitudes, expectations, and motivations. Most of all, designers need a clear idea of what action the organization expects users to take on the website.
User interface design and visual design work hand-in-hand to create the user experience but are not the same thing. User interface design is a unique discipline that draws on design theory and cognitive psychology. The user interface design basically describes what the user needs to do to make use of the site and operate the site features.
The information architect, if a team has one, works closely with designers on the user interface design. Regardless of what positions constitute the team, to execute a well-designed user interface, the designer must be intimately familiar with the functional specifications. The user interface defines the way users will get around the site, as well as the specific mechanics of interacting with elements such as buttons, text fields, and the like. Consider a site with five main sections, each containing subsections. The designer must decide whether a static navigation bar on the top of the screen will suffice, or if the site is deep enough to warrant an expandable tree on the left, showing the subsections for each main section.
The user interface design questions around the search feature for Campus Posters, Inc., include the following:
1. How will customers find their way to the search field?
2. What sorts of tips or guidance should be offered?
3. If there are no hits, what will the page look like?
4. How will the customer get back to the search field to try again?
Any labels or instructions on the site are part of the user interface design, as are the messages in dialog boxes.
User interface design is critical to a site’s success. It’s easy to see how this aspect might become the weak link that would make all of the other work on the site fruitless. A rich, robust, full-featured site serves nobody if only the programmer can figure out how to operate it.
The visual design refers to the artwork itself, such as graphics, logos, colors, and fonts. An aesthetic element of the site, the graphics convey a mood or motif. All the elements of artistic aesthetics-color, texture, illustrations, and photographics-can contribute to the ultimate goals of the website. Good graphic design also supports the usability of the site. Consistent, purposeful use of color, shape, layout, and other elements of design can subtly orient users to the site’s structure. The best design is subtle in that it doesn’t call attention to itself, but powerful in that it clearly communicates more than words ever could. Your users may or may not read the text on your site; most users, in fact, don’t. There’s no escaping your visual message, though. At first blush, the graphics are a decorative element; however, they must be called upon to do more. Otherwise, they are merely gratuitous eye candy.
Unfortunately, novices tend to start their website development projects with graphics because that is what they see and notice about other sites. Flashy as the visual design might be, it nevertheless plays a supporting role to function in website development. Creating graphics is extremely time-consuming. Final artwork need not be prepared until other design phases have been completed.