Robert Johnson's weblog

BENEFITS OF TEAM WEB DEVELOPMENT

Mon, 25 Feb 2008 07:20:38 -0500

Better Communication

To make appropriate decisions quickly during the development process, you need to keep a tremendous amount of detail in mind so you can evaluate the ripple effects of various decisions. For example, how will adding a particular feature affect other features? Site navigation? Data preparation? Testing? Will incorporating a nifty new JavaScript function require users to have the newest version of the browser? To make intelligent decisions, you need to know a lot about the project in general and the design specifically. The team needs well-rounded representation of the various disciplines (e.g., programming, testing, design) and free and open communication.
If you try to produce a website with the functional area approach, people down the line need a huge amount of information about the work to be performed, and that information must move along with the work. In fact, the complexity of the required information will slow down the project. So many handoffs open up many opportunities for miscommunication and mistakes.
A website development project does move from an analysis phase through the design phase, prototyping, various production versions, testing, and is finally posted and goes live. This apparent step-by-step process may tempt you to set up an assembly line approach and move the project along in linear fashion. In reality, however, these phases cannot be so cleanly separated. They are often interrelated, and they may need to be repeated in part or in full as new information or ideas emerge.
The product design greatly affects the programming and even the testing procedures. A software tester involved in the project from the beginning can start writing test specifications early, based on the design specification. Otherwise, the test specifications need to be written after the program has been coded, which is much more time-consuming. Likewise, a programmer who is involved early in the design phase can warn about proposed features that might be difficult to implement or inconvenience users, and then offer more viable alternatives. Involving the programmer early also gives him or her a head start on technical design and implementation, perhaps even before the design is finalized, which can save a tremendous amount of time. You should involve as many team members as possible from the beginning of the project.

Concurrent Tasks

The large number of concurrent tasks that can and must be performed to develop a website in a reasonable time frame also points to the team approach. Website development is more akin to synchronized swimming than the 400-meter freestyle relay. During the development process, all team members are working simultaneously on various aspects of the project and need to be in constant communication. If they are working on the project full time, it greatly facilitates this communication and team integration.

Commitment among Team Members

The success of a website is usually a function of inventiveness. A successful website offers distinctive content or somehow creates a more powerful or positive user experience than do other websites. Because most sites try to be different, they are, by definition, attempting something new. Invention is at the heart of the process, and invention is characterized by continuous problem solving, which takes time and dedicated people. People become dedicated to a project only if they feel ownership of it and a responsibility for its success, which usually happens when it is their full-time job, more or less-not just because they have been assigned to the project as part of an assembly line workflow. A full-time website development team will take ownership of the site and become committed to its success. They will vi ew it as a direct manifestation of their efforts.
Programmers who are part of an assembly line process rarely become dedicated or committed to a given program. They may never have seen it before and will probably never see it again; however, as part of a development team, programmers are involved in a product through its development cycle and can actually become emotionally attached to it. They often work extra hours voluntarily to maintain high-quality standards and, more important, because the other members of the team are counting on them.
Not a manipulative or gratuitous ‘warm, fuzzy’ approach, team-based Web development is simply a pragmatic and effective way to achieve one of the essential elements of success-the bonding among development staff. People depend on each other for mutual success and feel compelled to support each other in the effort. The team can take on a wide variety of tasks, and team members can apply their individual strengths and cover for each others’ weaknesses. In this way, a team begins to identify with the successful completion of a project, and the team identity depends on such a success.

Designing and Prototyping

Mon, 25 Feb 2008 07:20:23 -0500

Website development is an iterative process. Imagine yourself in a valley, gazing at the majestic peak of a nearby mountain that represents the successful completion of your website project. The distance might be only one mile as the crow flies. You may envision yourself steadily marching in workmanlike fashion right up to the top; however, once you start, you find that this is impossible, the angle is too steep, and no trails take such a route. Instead, the only way to the top is a winding trail 10 miles long that has many switchbacks. Although the trail steadily rises in elevation, sometimes you actually walk downhill. Eventually, however, you reach the top, but it takes longer than you thought.
So goes website development. If you could build the site exactly perfectly the first time, without any rework or modifications, it might only be a month-long project, but such a path does not exist. Multiple options, decisions, meetings, compromises, prototyping and reworking, changes in methods and production, testing and debugging, and more all intervene. The path you must take is not a straight line, but it is the only route. You need six months to reach the top, much longer than the one-month journey it appeared to be.
Advance planning is crucial; however, you should realize that you will need to make many decisions about how to reach the mountaintop when you’re on the trail. Sitting in the valley cannot lend the perspective you will need to make those decisions. You should resist the temptation to overplan. No amount of planning will build the website for you. Do not attempt to outline every contingency. Rather, consider the plan to always be a work in progress. Be steadfast about your desired outcomes, but fluid in how you achieve them. Keep your plan at your side. Let it guide you, but modify it when it’s sensible to do so.
In website development, you and your team have before you many options. You will discuss, debate, and decide upon each one. At a certain point, you will pause again and consider options on another decision. As you progress in building the site, you will make increasingly detailed and functional revisions to the plan. While a pattern of second-guessing yourself is never advisable, you may want to reconsider a direction when it leads to significant obstacles. You minimize the cost of backtracking by quickly developing prototypes to test your decisions. Such practice is what makes website development an iterative process. The process continues with design and prototyping, which is addressed in this chapter, onto the topics of subsequent chapters, including production, or ‘buildout,’ testing, and finally going live. Web development is a continuous process. Although the processes described here are somewhat sequential, they should not be viewed as discrete steps. Parts of the process happen simultaneously.
As an iterative process, website development is circular in parts, with built-in feedback loops designed to lead you to previous steps for revising and refining. The process goes something as follows:
1. You create a design.
2. Through inspection, reviewing, and testing, you identify gaps or problems.
3. You may throw out the design and start over, or make revisions.
4.The cycle repeats.
By way of these switchbacks, you move up the mountainside. It is a fact of Web development that this is the only way to get a final and acceptable result. If you ignore this fact and try to develop a site in one shot with no revisions, you will probably spend your budget in a first cycle that leaves you dissatisfied and without the resources for the revisions you desire.
This chapter describes the following three phases of design development:
1. Menu-tree diagram
2. Skeleton framework
3. Home page and motif

DEVELOPING THE CONCEPT

Mon, 25 Feb 2008 07:20:03 -0500

Specialists on both the technology and creative end will work simultaneously on the project. The project manager must coordinate the efforts. In the early planning stages, the project manager has identified strategic objectives for the site with key stakeholders. In order to answer the basic three questions outlined previously, the project manager has gathered information from others around the organization, including team members for the project. Moving beyond the 90-second executive briefing, the project manager will probably want to bring together the team to further develop the concept.
The project document developed in Chapter 3 makes a good starting point for bringing people together. As explained later, suggested documents for both functional design and technological design include a brief and a specification, which is more refined. You will also prepare a creative brief for designers and writers. They will not be able to dig into their work until some functional and technological questions have been answered. For instance, graphic designers may brainstorm and identify graphics for a site, but they cannot design a navigation bar until the navigational structure is in place. Bring the team together and present your 90-second answers to the three basic questions. Share written documentation that is available, such as briefs. Then brainstorm, discuss, and debate. Strive for consensus and make decisions, even if these decisions are subject to change.
Your challenge here is to be as open-minded as possible. Your client may have delivered a navigational structure for the site with the initial request for proposal or project description document. Perhaps you have drawn up your own plan. At no other stage in development will changes be more doable than now. Do your best to shed preconceptions and allow for the perspective and insight of others.
Phase 1: Menu-Tree Diagram
When developing the concept and working with the initial layout of the site, you will probably want to create a menu-tree diagram or schematic. A menu-tree diagram is basically a page-by -page layout of the site, with the top-level menu (the home page) at the top of the page, divided into submenus, each of which is broken down into its component pages. Consider the following menu-tree diagram for the fictional company Campus Posters, Inc.

As a bird’s-eye view of the various sections and subsections, the menu-tree diagram clearly shows the relative sizes and relationships among the different sections. It reveals the complexity of the site, its richness, and its potential pitfalls.
The menu-tree diagram is a useful visual aid for a brainstorming or concept development meeting. The diagram helps everybody visualize the site and presents talking points for design and structure. You may want to use self-adhesive notes on posterboard, so ‘pages’ can easily be moved around. Some developers cover whole walls with index cards, pushpins, and thread.
The menu-tree diagram shows pages, links, and some description of content. As your site plans develop, you can fill in specific details on content types, such as images, video, and copy. The menu-tree diagram helps the team members understand what is on the page. Designers will see both the big picture and all the elements that must be fit onto individual pages. If there are too many pages, this issue can be raised and addressed during concept development. Later on in production, it can help people track the content assets.
Design teams use a variety of software products to create diagrams. Adobe Illustrator or Microsoft Visio work well. You can also use Microsoft Word. The menu-tree diagram can also be created in outline format if you feel more comfortable. An outline consists of the same information as the schematic. Shortcomings of this approach are that it is more difficult to show linking and that it is not as effective in illustrating site structure as a visual diagram.

Functional Design

Mon, 25 Feb 2008 07:19:33 -0500

The functional design is a definition of what the website will enable users to do. What are you building? Answering this question is the starting point for any design work. You need to clearly determine what the website will do before you can plan how to accomplish it, what the site will look like, or what it will cost. The functional brief answers that question. Execution is not described in the functional brief. How a site will execute a particular function is a matter of technical design.
We were recently approached to build a website for a small floral business. The owner said he realized that he needed a ‘home page.’ His first question was, ‘How much will it cost?’
‘What do you want it to do?’ we replied. ‘Let people get in touch with you? Take orders? Show products online? Search for delivery locations and rates?’
‘Yes,’ he said, ‘all that stuff.’
‘It could cost a quarter of a million dollars.’
‘I thought I could get a home page for a thousand dollars,’ he said.
Clearly, the functional design was the starting point for this project. In the end, we built him a nice little site for $2,500 that serves his real needs. He’s even planning to get an e-mail account.
The functional specification is a continuation of the brief, delving into greater details, such as specific features, content topics, and user interactivity. The functional specifications also describe the organization of content and the site’s navigational structure.
Examples of items in the functional design documents for Campus Posters, Inc. might include the following:
* The Campus Poster website will allow customers to search the database of approximately 1,000 posters stocked at the downtown store and thousands more that the store can special order from suppliers.
* Search will be on artist or source of poster, a short description of the poster, and broad
categories such as music, sports, nature, and fine arts.
* Users will be able to browse categories for in-stock items.
* Search results will indicate whether the item is stocked or special order.
* Thumbnail photos will show up with search results, and a larger image will appear on the product listing page.
* A section of the site will be dedicated to special promotions and new releases.
* An e-commerce module will allow users to purchase posters online.

Technical Design

Mon, 25 Feb 2008 07:18:31 -0500

Ideally, you will have involved some members of the technical team in development of your concept. By participating in the process, they will have had the opportunity to raise any concerns about implementing the site’s functions as described. In the technical design process, programmers, software engineers, database administrators, or other technical personnel decide how to implement technologies that will realize the goals of the functional design.
The technical brief starts with the technologies you can anticipate on the client side (that is, on your users’ computers). The sorts of questions you should be asking include the following:
1. What kind of computers and browser software will they be using?
2. What browser software and versions are common?
3. Will they be using dial-up access or a high-bandwidth connection?
4. Do they use plug-ins and are they able to install them?
Server logs or specialized software can collect some of this information. Other data you might extrapolate from market research or contact with your own customers.
For example, one of our clients is a major airline, with an intranet for which they specify a common browser, screen resolution, and plug-ins for all computers in the company. This situation simplifies development because the browser is a known quantity. We can therefore incorporate a wide range of functionality on the client side because we know exactly what resources the user has. Other sites are made for viewing over the World Wide Web, where users might have virtually any type and version of browser, and little to no ability to install plug-ins themselves. A website developed for such a site should be kept simple and flexible in its design.
The technical team should look at the functional specification from a strategic point of view. For example, depending on the complexity of the site and the business objectives, a sensible strategy may be to plan for some enhancements after the launch. Regardless, the nature of websites is that they require updating. What distinguishes a Web project from media like print publishing or video production is that there is virtually no end to the product development cycle. The time to consider maintenance issues for the site is early on, in the technical planning phase, not after the site is launched. For instance, when planning a database-driven site, you may want to develop ‘administrator’ tools that will make it easier for nontechnical people to import new content into the database.
The technical specification speaks to the techies and engineers developing the site and documents their planning. The first decision is what platform and server software to use for the site. The development of the site from prototype on out should take place on a Web server with the same operating system and server software as the final live site. The server should be accessible to members of the development team but not to the general public. This server is referred to as the development environment. The server that hosts the live site is called the production environment.
The technological specification addresses what technologies to use for delivering the functional requirements, such as Java, Perl, Active Server Pages, Cold Fusion, or digital certificates, and how they will work. For example, in a database-driven site, the technical team may decide that since the site will be hosted on a Windows 2000 server, the appropriate database technology to use is Microsoft SQL-Server with Active Server Pages. To implement this technology, they will need to design the database(s) and query functions appropriately. Depending on the complexity of the technology and the various software applications involved, the technical team may need to get up to speed on the application programming interfaces (APIs) necessary to integrate functions. They may plan some feasibility testing to determine if desired features are doable within the budget and available technology.
To continue with the example of Campus Posters, Inc., the technical specification might include such items as the following:
* A large portion of the customer base, on-campus students, will be accessing the site
using smaller monitors from laptops or iMacs in the library or student center.
* The host server will run on a Windows 2000 platform.
* The Web server will be Microsoft IIS.
* The database will be Microsoft SQL-Server.
* The e-commerce module will be Microsoft 2000 Commerce server.
* Credit card verification will be done online.

Technical specifications are likely to change during the development process. More details would be added to specify how it is all supposed to work. As a project manager, you should encourage the development of detailed technical specifications throughout the process. If the project suffers a change of personnel in midstream, your new engineers will benefit greatly from a current and detailed technical specification.