UNIT ##1

History of Web, Growth of the Web, the Past decate

Before the World Wide Web the Internet really only provided screens full of
text (and usually only in one font and font size). So although it was pretty
good for exchanging information, and indeed for accessing information such
as the Catalogue of the US Library of Congress, it was visually very boring.
Probably the World Wide Web saved the net. Not only did it change its
appearance, it made it possible for pictures and sound to be displayed and
exchanged.
The web had some important predecessors, perhaps the most significant of
these being Ted Nelson's Xanadu project, which worked on the concept of
Hypertext - where you could click on a word and it would take you somewhere
else. Ted Nelson envisaged with Xanadu a huge library of all the worlds'
information. In order to click on hyperlinks, as they were called, Douglas
Engelbart invented the mouse, which was to later become a very important
part of personal computers. So the idea of clicking on a word or a picture to
take you somewhere else was a basic foundation of the web.

Another important building block was the URL or Uniform Resource Locator.
This allowed you a further option to find your way around by naming a site.
Every site on the worldwide web has a unique URL (such as
www.nethistory.info).

The other feature was Hypertext Markup Language (html), the language that
allowed pages to display different fonts and sizes, pictures, colours etc.
Before HTML, there was no such standard, and the "GUIs we talked about
before only belonged to different computers or different computer software.

They could not be Networked .It was Tim Berners Lee who brought this all
together and created the World Wide Web. The first trials of the World Wide
Web were at the CERN laboratories (one of Europe's largest research
laboratories) in Switzerland in December 1990. By 1991 browser and web
server software was available, and by 1992 a few preliminary sites existed in
places like University of Illinois, where Mark Andreesen became involved. By
the end of 1992, there were about26sites.
The first browser which became popularly available to take advantage of this
was Mosaic, in 1993. Mosaic was as slow as a wet week, and really didn't
handle downloading pictures well at all - so the early world wide web
experience with Mosaic, and with domestic modems that operated at one
sixths of current modem speeds at best, were pretty lousy and really didn't
give much indication of the potential of this medium.
On April 30, 1993 CERN's directors made a statement that was a true
milestone in Internet history. On this day, they declared that WWW technology
would be freely usable by anyone, with no fees being payable to CERN. This
decision - much in line with the decisions of the earlier Internet pioneers to
make their products freely available - was a visionary and important one.
The browser really did begin to change everything. By the end of 1994 there
were a million browser copies in use - rapid growth indeed!!
In the same year Marc Andreesen founded Netscape Corporation, and the
World Wide Web Consortium, which administers development of Word Wide
Web standards, was formed by Tim Berners Lee.
Then we really started to see growth. Every year from 1994 to 2000, the
Internet saw massive growth, the like of which had not been seen with any
preceding technology. The Internet era had begun.
The first search engines began to appear in the mid 1990s, and it didn't take
long for Google to come on the scene, and establish a dominant market
position.
In the early days, the web was mainly used for displaying information. On line
shopping, and on line purchase of goods, came a little bit later. The first large
commercial site was Amazon, a company which in its initial days concentrated
solely on book markets. The Amazon concept was developed in 1994, a year
in which some people claim the world wide web grew by an astonishing 2300
percent! Amazon saw that on line shopping was the way of the future, and
chose the book market as a field where much could be achieved.
By 1998 there were 750,000 commercial sites on the World Wide Web, and
we were beginning to see how the Internet would bring about significant
changes to existing industries. In travel for instance, we were able to compare
different airlines and hotels and get the cheapest fares and accommodation -
something pretty difficult for individuals to do before the world wide web.
Hotels began offering last minute rates through specially constructed
websites, thus furthering the power of the web as a sales medium.
And things went even further - in some fields of travel, individuals would
outline where they wanted to travel to and from, and travel companies would
then bid for
the business. All these developments rapidly changed the way traditional
markets worked. In some industries, the world would never be the same
again.

The is the sequence of events documenting the growth of the www :

DATE EVENT
March 1989 The w3 project is first proposed by
Timothy Berners-Lee at CERN
November 1990 The prototype is developed on next by the
CERN team
March 1991 The www is release to a limited to a
limited number of groups
January 1993 More than 50 HTTP server exits
February 1993 NCSA (National center for
supercomputing Application) release it’s
first version of Marc-Andressen’s Mosiac
for X.
September 1993 NCSA releases a working version of
Mosiac for all common platform.
October 1993 More than 500 Knaun HTTP server are
known.
April 1994 Mosiac Communications Corporation is
founded by Jim Claric and Marc-
Andreseen
October 1994 The w3 consortium is created to establish
international standard for client and server
protocols. More than 10000 known HTTP
server are exists.
Auguest 1995 Netscape Files for initial publish offering
of file millions shares of common stock.

The www provides a standard set of protocols for presenting and retrieving
information. It allows users to jump automatically one database to another via
‘hyperlinks’ without having to know where the information is located.
There are so many protocols which we are using in www in which some of them are
as follows.
FTP :- File transfer Protocol
HTTP :- Hyper Text Transfer Protocol
TCP :- Transmission Control Protocol
IP :- Internet Protocol
ICMP :- Internet Control Message Protocol
NNTP :- Network news Transfer Protocol
PPP :- Point to Pont Protocol
SNMP :- Simple Network Management Protocol
SLIP :- Serial Line Internet Protocol
UDP :- User Data gram Protocol
URL :- Uniform Resource Locator

Past of web: In the early 90’s a group at CERN (European Particle Physics
laboratory) in Geneva, Switzerland, developed the World Wide Web. Before
this the first communication tool to benefit the people in their work was e-mail.
Originally e-mail only provided for the sending of raw text between
corresspondants. In 1991 a system known as MIME (Multipurpose Internet
Mail Extension) was introduced to allow e-mail user to make attachment of
additional documents to an-e-mail. These additional documents were not read
and displayed by the e-mail program directly instead they are included as the
separate files along with the text message. Upon receiving a message with
MIME based document, the recipients could detach the document and display
it with a program that understand the format of the attached document.

Web Application
From Wikipedia, the free encyclopedia

Jump to: navigation, search

In software engineering, a web application—sometimes called a webapp and much
less frequently a web application—is an application that's accessed with a web
browser over a network such as the Internet or an intranet. Web applications are
popular due to the ubiquity of the browser as a client, sometimes called a thin client.
The ability to update and maintain web applications without distributing and installing
software on potentially thousands of client computers is a key reason for their
popularity. Web applications are used to implement webmail, online retail sales,
online auctions, wikis, discussion boards, weblogs, MMORPGs, and many other
functions.
Contents

[hide]
 1 History
 2 Interface
 3 Technical considerations
 4 Structure
 5 Application
 6 Business use
 7 Writing web applications
 8 See also
 9 External links
o 9.1 Links from main article

o 9.2 Other links

History

In earlier types of client-server computing, each application had its own client
program which served as its user interface and had to be separately installed on each
user's personal computer. An upgrade to the server part of the application would
typically require an upgrade to the clients installed on each user workstation, adding
to the support cost and decreasing productivity.

In contrast, web applications dynamically generate a series of web pages in a standard

format supported by common browsers such as HTML/XHTML. Client-side scripting
in a standard language such as JavaScript is commonly included to add dynamic
elements to the user interface. Generally, each individual web page is delivered to the
client as a static document, but the sequence of pages can provide an interactive
experience, as user input is returned through web form elements embedded in the
page markup. During the session, the web browser interprets and displays the pages,
and acts as the universal client for any web application.

Interface

The web interface places very few limits on client functionality. Through Java,
application-specific methods such as drawing on the screen, playing audio, and access
to the keyboard and mouse are all possible. General purpose techniques such as drag
and drop are also supported by Java, though this may be simpler with current
Javascript libraries[1]. Web developers often use client-side scripting to add
functionality, especially to create an interactive experience that does not require page
reloading (which many users find disruptive). Recently, technologies have been
developed to coordinate client-side scripting with server-side technologies such as
PHP. Ajax, a web development technique using a combination of technologies, is one
example.

Technical considerations

A significant advantage of building web applications to support standard browser

features is that they should perform as specified regardless of the operating system or
OS version installed on a given client. Rather than creating clients for Windows, Mac
OS X, GNU/Linux, and other operating systems, the application can be written once
and deployed almost anywhere. However, inconsistent implementations of the
HTML, CSS, DOM and other browser specifications can cause problems in web
application development and support. Additionally, the ability of users to customize
many of the display settings of their browser (such as selecting different font sizes,
colors, and typefaces, or disabling scripting support) can interfere with consistent
implementation of a web application.

Another (less common) approach is to use Macromedia Flash or Java applets to

provide some or all of the user interface. Since most web browsers include support for
these technologies (usually through plug-ins), Flash- or Java-based applications can
be implemented with much of the same ease of deployment. Because they allow the
programmer greater control over the interface, they bypass many browser-
configuration issues, although incompabilities between Java or Flash implementations
on the client can introduce different complications. Because of their architectural
similarities to traditional client-server applications, with a somewhat "thick" client,
there is some dispute over whether to call systems of this sort "web applications"; an
alternative term is "Rich Internet Application".

Structure
Though many variations are possible, a web application is commonly structured as a
three-tiered application. In its most common form, a web browser is the first tier, an
engine using some dynamic web content technology (e.g., CGI, PHP, Java Servlets or
Active Server Pages) is the middle tier, and a database is the third tier. The web
browser sends requests to the middle tier, which services them by making queries and
updates against the database and generating a user interface.

Application

Web interfaces have increasingly been used for applications that have previously been
thought of as traditional, single-user applications. For example, Microsoft HTML
Help replaced Windows Help as the primary help system in Microsoft Windows. Like
their networked brethren, such applications generate web pages as their user interface
and send them (sometimes via an embedded HTTP server) to a local web browser
component, which then renders the pages for the user and returns user input to the
application. Web applications powered by embedded web servers have also become
commonplace as the user interfaces for configuring network components such as
servers, switches, routers, and gateways.

Business use

An emerging strategy for application software companies is to provide web access to

software previously distributed as local applications. Depending on the type of
application, it may require the development of an entirely different browser-based
interface, or merely adapting an existing application to use different presentation
technology. These programs allow the user to pay a monthly or yearly fee for use of a
software application without having to install it on a local hard drive. A company
which follows this strategy is known as an application service provider (ASP), and
ASPs are currently receiving much attention in the software industry.
Web deveplepment strategies:

1 WEB PROJECTS
The web project began as one of the 19 original technology innovation challenge
grants awarded by the U.S department of education of 1995 to establish processes to
improve student learning through the use of multimedia and telecommunications.

The web project became a non profit organization in 2000, devoting to continuing the
innovative ideas begun with the original federal grant. We are currently focusing on
community -based projects and making links to American history and civic
engagement.
Basically it’s not software development and it’s not print production – it’s the web, a
whole new medium. You have learned doing software development or advertising
production. In fact you will see methodologies that I’ve borrowed from this field
throughout this book. But the Web is different; development times are much faster
and the teams change on a project-by-project basis. You might be working with
marketers and strategists as the web becomes the advertising space of future.

WEB PROJECT CHARACTERISTICS

Web Projects Software Projects Advertising Projects Traditional Projects

Project manager are Different Similar Different

Not always client
Managers

Development schedules Can be similar; Similar, though manage- Similar

Are dramatically called “death able since there is no
Short. March” projects technical component

New, often beta, tech- Different N/A N/A

nologies are used, often
Without technical
Support.

Scope change occur Similar, though not Different Similar

During the implement- without dramatic
ation phase change in cost and
time

A pricing model for web Similar Different Different

Projects does not exist.

Standards for Web Different Different Similar

Production do not exist
Team roles are less Different Different Different
Specialized.

Clients are often unwell- Different Different Differemt

Ing to bear the costs of
Web development, especially
During the planning phase.

The project manager’s Different Similar Different

Responsibilities are very
Broad

1. Project managers are not always client managers: On a Web project you
might not be the person responsible for managing the client’s expectations.
This is especially true if you work in an agency where you have an account
manager.
2. Development schedules are dramatically short: Most Web projects are
“death- march” projects – projects with seemingly impossible development
schedules. The reason is that the Web is a relatively new development
phenomenon, so people on both sides (client and developer) underestimate the
time and resources needed to complete a Web project.
3. New, often beta, technologies are used, often without technical support:
In the first commerce site I worked on , our commerce vendor had to work
along with us to write patches for software bugs we unearthed while building
the site. Now software packages are used while they are in beta, usually
because they are available and because they offer “new” and “cool” features
that client and Web developer alike want to use.
4. Scope changes occur during the implementation phase: This is something
that occurs on most Web projects and often in software project, but this does
not tend to happen in advertising because it is very expensive to change a print
at once it’s gone to press. However, clients and web project
Managers need to understand that scope changes during implementation phase
are very expensive and must be tracked and managed.

5. A pricing model for Web projects does not exist : In the advertising world,
costs are fairly modularized and budgets tend to be somewhat easy to create ,
once the campaign has gone through the creative phase. However, it’s very
difficult to cost out Web project. There aren’t ranges for “e-commerce site” or
“a series of advertising interstitials”; however, this is what clients tend to
want.

6. Standards for Web production do not exist : In the advertising

,manufacturing and software development worlds, there are standards to follow
that ensure quality. Standards, or best practices, can help Web company gain
efficiency and therefore realize some profitability. This makes getting the Web
project off the ground a difficult task.
7. Team roles are less specialized : On a Web project, a server side
developer may also be an HTML programmer, and a producer may also be an
information architect. Roles are less specialized, often because a Web project
might call for someone who can create content in Flash, Real Audio, and HTML.
There is not always enough work to have specialists in each category.
 8. Clients are often unwilling to bear the costs of Web development,
especially during the planning phase : In my experience, getting the
client to buy into our planning and design and
a specification phase is hard. Clients want to see creative concepts as soon as
possible and do not want to hear that a production budget is an impossible thing to
give them until after they have signed off on a design and specification document.

9. The project manager’s responsibilities are very broad : On a Web project,

a project manager or producer might be responsible for anything from developing the
schedule and budget tomanaging assets to acquiring talent and negotiating contracts.
Depending on the kind of Web site, the project manager’s or producer’s role will be
broad.

WRITING A WEB PROJECT:

Producing a Web project really depends on the individual and the team. A person with
no technical skill can produce a Web project. If that person has experience as a project
manager, understand the Web and how sites are built. Although some project
managers could lead a Web project without ever being on a production or
development team, these people are rare. There is a list of skills that is requiring in
project managers:-

 Software or film project management experience.

 Rigorous understanding of scheduling, budgeting and resource allocation.
 Superior written and verbal communication skills.
 Ability to lead effective meetings.
 Detail oriented
 Pragmatic
 Good sense of humor
 Ability to stay calm during disasters
 Development or production experience in Web, multimedia, software or film.

IDENTIFICATION OF OBJECTS:

Objectives are results. They are –

 Specific
 Measurable
 Attainable
 Realistic
 Time-limited

Of these five characteristics of objectives, the measurable and attainable

characteristics are the hardest to determine. If an objective of Web site is to increase
brand awareness, how do you measure that? Two questions help you monitor progress
of objectives:

1. What is the desired outcome?

2. How will you know when you achieve it? Answering this last question for
all your project objectives, especially no quantifiable ones like our
 example, is very important. This answer will help you establish criteria for
objectives that cannot be quantified.

WHO SETS THE OBJECTIVES?

Clear objectives are probably the most important factor in the success of a Web
project. Objectives help your creative team to design the best graphics for the site,
they help the programmers understand how the web site might grow, and they tell the
writers what tone or information is critical to the site.
Who decides your site’s objectives or goals depends on many things, but generally the
person or persons who fund the project are the people, called stakeholders, who,
directly or indirectly, set the objectives of the project. In the early days of Web
Development, when small software consulting companies were the primary providers
of Web sites, this was definitely true. Now, however, the Web team has evolved to
incorporate strategic marketers who may not be the primary stakeholder develop the
Web site’s objectives.

WEB SITE OBJECTIVES

What are some common Web site objectives? As the web evolves from a
communications tool to an integrated business system, the objectives for having a
Web site continue to evolve. I’ve worked on Web sites with the following objectives:
sell products, ship goods, replenish inventory, increase brand awareness, improve
corporate communications, and improve brand perception.

TARGETED USERS

The kinds of content that you will create for the Web site will be determined by the
users whom you want to visit the site. Though the makes common and business sense,
often Web designers and developers over- look the degree of research that is required
to identify users accurately. Clients often want to use site traffic as a measure of a
Web site’s success. However, site traffic is misleading. The only way to truly measure
a site’s success is to determine whether your objectives have been met. If your
objective was to increase your Web sales through a new and improved ordering
process, then you would look at sales figures before and after your new ordering
process was implemented. If you did not increase orders, yet your site traffic
increased, you would attribute the increased traffic not to the simplified ordering
process but to a good advertising campaign, a particular search engine, or pure luck.
How do you go about learning what your targeted users want to see on your Web site?
What will make them purchase your product or use your service? The only real way is
to ask them, I discuss ways to reach your targeted audience.

MARKET RESEARCH
If you have worked for an advertising or public relations firm, you know how
important market research is to the success of your campaign. Market research is
equally important if you are going to create a web site that sells products, services, or
ideas. If you are looking for any kind of the return on your investment (ROI) from
your Web site, then it is critical that you understand exactly who your audience is and
what it wants, so that you can provide it.

Many firms provide this kind of service to companies. If you are a Web designer
working as a freelance consultant, you should think about developing partnerships
with research companies that specialize in the new media so that you can provide this
service to your clients. If you are building a Web site for your company, build market
research into your budget if your company does not have a marketing department. If it
does not have a marketing department, then make sure the personnel understand how
your audience interacts with the Web.

FOCUS GROUPS

If you can’t afford the services of a market research company, then consider
conducting a focus group. A focus group is a group of people who represent your
target user or audience. Focus groups are used to get feed back on proposed ideas for
your Web site or to understand how your target audience thinks. When I was putting
together a Web presentation for a group of two hundred high school girls, I thought I
understand what they wanted to know. After all, I was once a high school girl. I put
together all my ideas and perceptions, and then I conducted a focus group. I couldn’t
have been more wrong about what they were looking for on the Web. Believing that
you understand the target audience without any supporting data won’t work most of
the time. If you are going to be spending money on a Web effort, then spend some
money up front and do the right level of research.

UNDERSTANDING INTRANET AUDIENCE

If you are developing an intranet site, you have access to your audience; but you will
find that each department or group within your audience has specific needs and
desires that are related to their job functions. With such varying needs, it’s easier to
focus your first planning effort for your intranet on the areas that affect every
department or group.
The best strategy for understanding your intranet audience is to take the time to meet
with each group or a representative of each group.

WEB TEAM :

Web team began with Webmasters, people who did everything from coding the page
to maintaining the Web server. As the popularity of the Web increased, companies
began to recognize the need for a more formal, dedicated Web team. Service
companies like advertising agencies, software development companies, and start-up
interactive shops began to put together Web Team. Each company has its own team
model; but at the core were a project manager, a graphic designer, and an HTML
programmer.

The web team is evolving because business leaders are beginning to understand that
the Web is transforming the way business is done. Leaders are realizing the need to
bring this medium into the overall, long term business plan and treat it as they would
any other significant component of their business.

Be it on the service side or the client side, the new web team has a strong strategic
component, strong content management and production processes, and an IT
component that can handle doing business on-line.

ROLES AND RESPONSIBILITIES

Core (C), Extended (E), and Special (S) Team Members

No matter what kind of web site you are producing, there are some core
responsibilities roles. For other kinds of sites, generally larger and more complex
sites, there are extended team members. Extended team members are people whose
skills might not always be necessary or who might have cross-functional roles.
Special team people are brought in to do work that is not part of your core or extended
team but may become so. For example, in an interactive agency, there are team
members who are specialists in audio engineering, security or database architecture.
However, the special members of this web team might be core or extended members
of yours, depending on what kinds of sites your company tends to produce.

PRODUCT MANAGER/PRODUCER(C) : The project manager/producer is

responsible for scoping the work, developing the project plan, scheduling, allocating
resources, budgeting, and managing the team. In the absence of an account manager,
the project manager or producer handles client management.

ACCOUNT MANAGER (E) : Part of the extended team, the account manager is
generally present in agencies or companies who follow the agency model. Generally,
this means that the company is responsible for a client’s entire on-line business plan,
which may consist of several projects. Usually
these kinds of engagement are time based, and a web company is held on retainer.
The account manager generally interacts with the client, the project manager, and the
creative lead.

TECHNICAL LEAD (C): A technical lead overseas the project from a technical
point of view. The technical lead assists the project manager in ensuring that the
technical strategy is sound, manages the programmers , and chooses specialized team
members such as security experts and other systems integrators.

PROGRAMMER (E): A programmer develops applications for the Web project. The
skills a programmer needs, depending on the kind of programming he is doing, could
be any of the following : an understanding of object oriented programming, Java,
JavaScript, Lingo, Visual basic, VBScript, SQL, C/C++.
NETWORK ENGINEER(E) : A network engineer is responsible for setting up and
configuring a Web server. He is also responsible for registering domain names and
sometimes responsible for setting up e-mail servers as well.

SECURITY EXPERT (S) : A security is someone who provides security strategy for
Web sites. This person understands the processes involved in making financial
transactions on-line and can advise on products and strategies from the security
perspective.

WEB PRODUCTION SPECIALIST (C): A Web production specialist is the person

who integrates the site using HTML or JavaScript, and is generally the hub of site.
The Web production specialist communicates with all members of the Web team and
reports status to the producer.

CREATIVE LEAD (C): The creative lead determines the creative concept for the
site and is responsible for the site’s design. The creative lead may not design the site
herself, but acts as art director for the site.

DESIGNERS (C): Designers create the look and feel of the site. The main tool of
choice for this work is Adobe Photoshop. Web designers should have a good
understanding of design principles, including information design and interaction
design. The designers are managed directly by the creative lead. In reality, a designer
is often also the creative lead.

INFORMATION ARCHITECT (E): An information architect would be responsible

for site architecture, navigation, search and data retrieval, and interaction design. As
well the information architect would be responsible for key messages to users
regarding errors, service, technical needs of the site, and privacy messages.

COPYWRITER (E) : It would be great to have a dedicated copywriter on a project,

but often copywriting is a luxury. The information architect might also double as a
copywriter. Often, the client supplies copy and the information architect or designer
makes it Web-readable.

PRODUCTION ARTIST (c): A production artist transforms the artwork that the
designer creates into Web-ready art. The production artist obtains Photoshop files
from the designers and cuts up the files into individual graphics, and then optimizes
the graphics into Web file formats.

QUALITY ASSURANCE LEAD (C): This person makes sure that the product you
deliver meets the criteria specified in the scope document and functional specification.

TESTER (E) : A tester tests the Web project based on the test plan that the QA lead
writes. On small teams, the tester might be the QA lead.

AUDIO ENGINEER (S) : An audio engineer designs sounds for Web sites. These
sounds could range from music to sounds that happen when the user does something.
The audio engineer usually interacts with the creative and technical leads.
VIDEO ENGINEER (S) : The video engineer creates video images and delivers
them in digital format to the creative lead or the Web production specialist.

3-D MODELER (S) : A 3-d modeler creates artwork that is in 3-d and usually works
with the creative lead.

WEB CAST SPECIALIST (S): A Web cast specialist is usually a third – party
vendor who specializes in Web casts.

MEDIA BUYER (S) : A media buyer is usually part of the client’s advertising
agency. If your project is an advertising campaign, the producer will interact with the
media planner to obtain specifications on the media buy so that the Web team can
create advertisements based on the sizes in the buy.

STRATEGIC PLANNER (S) : A strategic planner is the person who delivers the
consumer insight to the team. This person generally conducts market research on the
client’s audience and delivers a brief to help the creative team understand the mind of
the target audience.
 The Appropriate core team members will manage specialized team members
Account Manager

Project Manager/Producer
Cross Communication

Creative Lead Technical Lead Information Architect Production Lead Quality Ass. Lead

Animator Security Focus Group HTML Testers

Specialist Coders

Sound
Production
Engineer Database
Artists
Architect
Video
Java Script &
Developer Programmers
Client-side
 ASP-C
3-D Development
 Java/C++
Designer  Lingo
Core Team
Networking
Designer
Specialist Unix Line of Management

or NT Specialized Team
Copywriter
ASSESSMENT OF WEB TEAM:

IDENTIFYING NECESSARY SKILLS : When putting together Your team, make

sure that the following skills are covered :

 Project management skills: The ability to see and communicate the big picture
to the team and your client and make sure the site gets built according to
specification, on time, and on budget. This infers that you have strong
executive support for your project if you are a project manager for a
corporative Web site for your own company.
 Information design/architecture skills: The ability to design a usable and
useful user interface that includes how the user will interact with the interface
and navigate the site.
 Graphic design skills: The ability to transform the information design into a
visual design.
 Graphic production skills: The ability to create Web graphics that are fast
loading and that look great on all browsers.
 Content development skills: The ability to develop both written and
interactive content for Web sites. This includes copy, video, audio, and
anything that is not part of the user interface.
 Programming skills: The ability to create Web pages using HTML, JavaScript
and other client/server scripting languages.
 Technical/network infrastructure skills: The ability to understand the
requirement for serving a Web site on the internet and to recommend the best
strategy based on the client’s or stakeholders needs.

BUILDING A TEAM : Finding the right people is a difficult task, but an even more
challenging task is matching team members both to the task and to each other. If you
are managing multiple Web projects, then you have probably faced the dilemma of
choosing the right combination of people for a particular project.
You might find yourself having to choose between similar people to do a certain task.
To make a good choice, it’s important to think about several thing :

 Is there a critical deadline for a task? If so, choose the person with the better
track record for meeting deadlines. This will reduce the risk of missing the
deadline.
 What risks do I take if I put this person on this task? If you know that one
person is more prone to mistakes, then you can assign him or her tasks with
lower risk.
 How does this person interact with the rest of the team? If either person has a
history of not getting along with one of your team members, then you decide
whether to take the risk of having to manage interpersonal problems as well as
project-oriented issues.

TEAM DYNAMICS : THE UNIQUE ISSUES

Virtual Management
There will ultimately be occasions where your Web teams will be in different
locations, working simultaneously on a Web project. If you find yourself managing
resourses at different locations, be prepared to travel a lot. Here are some reminders to
help you manage and support your team.

Set Clear Guidelines

When members of a team are scattered in various locations, nothing becomes more
important than a clear understanding of what every one’s roles are, including who
does what , when , and how. It’s critical to provide team members with information
about the other team members, what there roles and deliverables are, and how they
will deliver their piece of the project. A clear scope document and a description of the
process, or methods, for executing the project is an absolute must. A production guide
is also critical if more than one person is going to be producing HTML pages,
graphics, and multimedia elements.

Set Up a Review Site

A very important tool for the virtual team is the review Web site. This is a Web site
that lists everything about the project, from contact names and addresses to the scope
document, schedule, and schematics of the site. As well, it has a link to the staging
site, which is where your team will work collaboratively on the site.
You manage the review site; or if you are fortunate enough to have a production
assistant or and associate producer, you can delegate this task. It should be updated
regularly with changes, news, and the latest additions to the site-in-progress.

Working with the client’s Resources :

The most important thing to do as a project manager is to be open to using these

resources. Never refuse to use them. Doing so would only cast you in a negative light
to your client. The right thing to do is to find a job for them. If they are IT people or
employees who have learned Web production, then pair them with people from your
team and give them low-risk tasks to do. If they prove themselves to be component,
then you have just earned another resource, and you can use your own team resource
on another project. Above all, give them the respect they deserve. You will benefit
from their approval of you in the long run.

Outsourcing or Working with Vendors :

Every now and then you will need to work with an outside resource on a project.
Either you will need to hire a specific resource, such as a coder or designer, or you
might need to form a partnership with a vendor to provide services to your client that
your Web team does not provide, such as networking infrastructure, production, or
strategic planning.
Many companies are forming strategic partnerships. For example, TBWA Chiat - Day
use Red Sky Interactive as their interactive agency for one of their client, Absolut
Vodka.

Sorting Apples and Oranges

Finally, remember that all members of your team don’t work the same way. Your
responsibility is to develop an environment of communication and production systems
that help your team to do best job possible. To do this, you need to understand how
the different members are use to working.

How Programmers Work

They are used to getting a requirements document, designing the specification and
then coding. They do not respond well to having to write documentation, but they
know they have to. Some programmers will not speak up and will differ to the loudest
voice. Others would not. Be sure to listen carefully to programmers concerns. Always
ask them questions about potential Red flag and risks.

How Designers Work

Designers are professional because they are ultimately responsible for how the site
looks, they are very visible often their sense of value is at risk. Wanting to be perfect
can cause your project to go over time and budget, so its important to develop a
method for making sure your design team can do the best effort in the sort amount the
time. A clear idea of marketing goals and key consumer insight can be invaluable in
helping a designer get the concept right on the first try. Given a designer a production
to do photo research is also a good idea. This way the designer does not spend too
much time getting art work and can focus on sketching and design.

How Writers Work

Writers need to know how the audience is and what the projects objectives is or they
will the writing in a vacuum. Your creativity should contain what the writer needs to
develop copy that is appropriate for the audience. Some writer need to write at home.
Be flexible.

How You Work

Finally how are you used to working? It’s your job to motivate, support and derive
this team to your ultimate goal: to deliver a project on time and on budget. You must
know yourself and your shortcomings so that you can identify then and not let then
sabotage your project. Are you impatient? Do you tend to compare members of your
team to yourself? Are you to lenient? Take a good look at yourself, accept yourself,
and keep the projects goals in the front of your mind. Remember not to sweat the
small stuff. Give perks to your team when they need them, and take a few for
yourself.

PLANNING AND PROCESS DEVELOPMENT

If you are going to invest in a Web site, the money you spend in the planning stage is
the best money spend. It’s the only way to ensure that your Web project will
accomplish what it must in order to achieve your business goal. However, clients does
not always want to pay of planning. Sometimes the client will have certain aspect of
the Web site planned long before your are hired to build the project. It’s up to you to
decide at that point if that particular project is right for you and your team.

Some companies are fortunate enough to have and entire department devoted to
strategic planning. This group determines the best use of the Web for the client, based
on the client’s business objectives. It’s a label of planning that is new for the Web
industry, specially because some Web developers can create a Web site in a week.

EARLY PLANNING

Getting to know your audience :

If you do not now your audience, you will not be able to build a successful Web site,
because you would not understand what the Web site must contain in order to meet
your client’s goal. There are many ways to know your audience and route your task to
a definite path so that to achieve desire goal. The way we can understand both Internet
audience and Intranet audiences.

Interviewing :

A thoughtful and well planned interview with your clients and department
representatives and team members is the best way to fully understand what kind of
experience you will need to create in order for your Web site to be successful. You
will most likely be able to conduct such an interview if you are creating and Intranet.
Before you set-up the interviews, you need to do some hard thinking about what you
need to learn. Here a some points to consider:

1. You are trying to find out what your user need in order to meet the objectives
set by the shareholder. Make your questions bold but still related to the
objective. If you ask some narrow question, you will get a narrow answer like
Yes and No which wouldn’t tell you much.
2. Be open to ideas about Web site features, but remember that each feature has a
cost associated with it.
3. Bring a tape recorder and if possible an assistant to take notes. You should
focus on listening carefully.

Focus Groups and Market Research :

If you are creating an Internet site, chances are you would not have access to your
targeted audience. Focus groups and market research services can help you
understand your target audience.

Gathering end user requirements :

Focus groups can help you understand the mind set of your target audience, but you
also have to ask the client how the site is supposed to function for the user. Do your
users need to download software? Do You want them to sign in? Do they need to get
to data quickly? Do they need a certain browser? These are things your focus group
would not tell you. End user requirements are important parameter that you must
follow in order for your site to be usable to the people who visit it.

There are some consisment requirements that you need to address for all kinds of Web
site. These requirements have to do with user connection speed, browsers and browser
version.

Other requirements have to do with the kind of site you are building. Depending of
the objectives of the site, you will need to ask “what is the experience supported to be
for the user?” Are the users going to need to get information from the Web site? Will
they be finding important data? Do they need to interact with a game? These kinds of
end user requirements are specific to the Web site, so they will be different for each
kind of site you create. When you have gone through the process of gathering the end
user requirements, you will need to list them all in your functional specification.

Defining Development stages and Strategies :

It’s very important for u, your client and your team to understand what the stages of
development will be. It is very easy to miscommunicate when everyone is saying
words like “strategy” and “design phase” and “production guide”. These terms may
mean different thing to different people. Therefore, one of the first thing for you do to
with your client and your team is to meet and define exactly what your phases of
development will be and specify the deliverables that will result from each phase. The
four- stage development process works the best for my team, but it may not be
realistic for you.

Phase I: Strategy

During this phase, either a strategic planner, account executive, or project manager
and/or the client is determining the objective for the site based on dedicated research
effort. The culmination or deliverable of this phase is the creative brief, which clearly
outlines the objectives, requirements, and key insights of the target audience. The
creative brief provides a foundation for every team member’s work.

Phase II: Design

During this phase, the creative and technical teams are doing a parallel design of the
site. The creative team is designing the user interface and interactions, and the
technical team is designing the back-end and applications that will be used on the site.
The culmination of this phase is the functional and/or technical specification, site
architecture, schematics, and designs of the site.

Phase III: production

During this phase, we are building the site. Any major changes in functionality and
features have to be monitored closely. If the client requests a change at this point, a
change order is issued. The culmination of this phase is, of course, the site, which will
go into Phase IV. A production guide is also created during this phase.
Phase IV: Testing

During this phase we are testing the site and getting ready to publish it on the live, or
production, Web server. Our QA manager develops a test plan based on the scope
document and functional specification and tests against this plan. Bugs are reported
and fixed. The site is ready to go live at the end of this phase.

IDENTIFYING THE DEVELOPMENT PHASES

At the end of the strategic planning phase, you might find a discrepancy between what
your client wants and what it is possible to deliver in the required time. When this
occurs, meet with your client to present your position and offer alternatives that you
can develop within the required time.
If not handled correctly, this can be very critical and project-ending discussion. You
Need to be able to frame to your client what you can deliver and why it is the
appropriate way to proceed. You need to convince your client that this is the best
choice for her, and you need to believe it yourself in order to convince her.
The objective of this conversation is to agree on phases for development. For
example, if your client wants a storefront like Amazon.com, but needs it in a month,
you will need to be able to negotiate a first step for that eventual goal.

Writing the Creative Brief

The creative brief is the document that defines the objective of the project, along with
a description of the audience and the key insight into their mind-set. It is the
foundation of the site and should be what the web team uses to ground and focus them
as they design and build the site. The creative brief should contain the following
section headings:

 The project: The section describes the project.

 The objectives: This section describes the project’s goals.
 The Target Audience: This section describes the target audience and gives
demographic
information about it, including targeted browser,
platform, and
connectivity.
 Personality : This section describes site’s desired personality and
tone.
 Current Mind-set : This section describes audience’s mind set.
 Key Target Audience insight: This section gives an insight into the mind of
this Web site’s
consumer – often one of the most important
factors in
developing a concept that will reach the
target audience.

Brainstorming :
Wit the creative brief in hand, you can conduct a brainstorming session with the entire
team to discuss the features the site must have in order to meet the objectives. From
this discussion, you can write the creative document and the functional specification
of the site. If you haven’t written the scope document yet, this is when you should
begin to focus in earnest on the exact scope of the project. If you have written the
scope document as part of your business proposal, then after the brainstorming
session and preliminary creative planning phase you would write a functional
specification, which explores what the functionality of the site will be. This document
is the best written after your team develops the site architecture and schematics.

Creating the Review Site

David Siegel talks about the use of the project Web site to keep clients aware of the
progress of the Web site in development. Earlier, I referred to this as the review site.
No matter what you call it, this excellent communication tool functions both as a way
to keep clients apprised of the progress of the project and to keep all team members
up-to-date on all aspects of the site. On a typical review site at Red Sky Interactive,
Web project managers are responsible for coordinating and updating the project site.
The following information is available:

 Roles and responsibilities of the project team.

 Contact information for all team members.
 The project mission.
 The creative brief.
 Site architecture
 Schematics
 All design reviews
 The project schedule
 A link to the staging site.

Creative and content Planning :

Early planning usually culminates with the creative brief. The purpose of this
document is to provide information about the customer or user to the creative team.

Creating the Concept :

Every Web site needs a concept. The concept shapes the way the Web site will look,
its tone, and the other kinds of features it offers. The most important thing about a
concept is that it must be able to extend itself throughout the site, in visual design,
through copywriting, and even with regard to the kinds of technologies that are used
to create the user experience. For people with marketing and advertising backgrounds,
the idea and value of concept is understood. But for the Web project manager who
comes from a software development background, a concept can seem like a foreign
and unnecessary thing. It’s not. The concept, like the creative brief, becomes the
primary focus for the visual execution and writing of the site.

Communicating the Concept :

Once the concept has been thought out, it needs to be communicated to the rest of the
team, specifically, to the design team that will be creating the look and feel of the site.
Usually the creative director is responsible for leading the development of the
concept, and so the creative director can choose the method that help the design team
understand the concept the best. Some companies use storyboards, other use a more
formal written document along with illustrations. It’s important to give the design
team a sense of the concept along with preliminary ideas for imagery and copy. Other
companies write a creative document, which directly addresses the highlights of the
creative brief. Doing this ensures that the creative team is in line with the objectives
that were laid out in the early planning stage, a critical milestone to hit if you want
your site to be successful.

Usability studies :

After the first round of design has been done, getting feedback on how well the user
interface works is critical. Unfortunately, very few Web teams actually do this
because the cost to the client can be prohibitive. To get this kind of feedback, you
need to conduct a usability study by having actual users explore a prototype of the
Web site you are building. Usually, an interface designer will lead the study and will
videotape users as they click through the site. The interface designer will ask them to
find certain areas of information and will then watch how long it takes a user to find
the information. As well, the interface designer will look for patterns among users that
might indicate a usability problem. For example, if the user is trying to find
information about products and continuously clicks on a heading called “About Us”
instead of “Crafty Gadgets” then the interface designer might conclude that it’s
necessary to rename the heading in order for the users to find the information they
want.

Site Architecture and Schematics :

When you are in the process of designing and developing content for a Web site, it’s
important to have a way of keeping all team members in the communications loop
regarding the content of the site. This is especially true for large Web teams with
multiple content providers, such as writers, designers and audio/video creators.
Content development is an iterative process. Your team brainstorms for ideas about
what information belongs on the site and you need a way to show your client or
stakeholder the team’s ideas. Once the client has signed off on what the site will
contain, your team members, from designers to coders, will need to know what
elements go on which page and how the pages link together. Two invaluable tools for
informing everyone are the site architecture and the schematic. Both of these models
will live on your project site, so that the entire team can have access to the
information at all times.

A site architecture gives you an overall view of your entire site’s content, page
schematics show you what elements of content live on each page. The different kinds
of content might include :

 Copy
 Images
 Links
  Video
 Audio
 Shockwave
 Other media files

The value of the schematic is huge. Schematics help the designers understand the
element on each page so that they can appropriately design the pages, and they help
the production staff track the assets needed for each page. The schematics help the
client understand and contribute to the development of the content by providing a
visual representation of the site long before the design is finished.

TECHNICAL PLANNING

Technical planning is the phase in which your technical team investigates the
technical requirements of a project and develops a strategy for building features of the
site such as databases, shockwave movies, transaction systems and scripts of all kinds.
As with all the other phases of development, the technical team must plan for not only
the first rollout of the Web site but also the evolution of the site from a technical
standpoint.

Identifying Technical Infrastructure:

The technical infrastructure is the environment in which your Web site lives. By this I
mean the server environment which includes hardware, software, security, and
connectivity. In addition, your technical team needs to provide both a development
environment for your Web team and a production environment, which is where the
site will live when it goes live.
The purpose of this is to ensure that the live site will work perfectly in the production
environment. By doing this, you eliminate the risk of dealing with unknown problems
that can arise when moving the site over to the production environment.
One of the more important decisions your technical team will make is what platform
and server software your Web site will run on. This decision should be based on the
client’s existing environment, their existing technical resources and their budget.

Network Assessment :

One of the steps your technical team can take in identifying the necessary technical
infrastructure requirements is to use an assessment questionnaire. I’ve included a
sample form on the CD-ROM. Our form is basically for our clients, and it helps us
determine what the existing network infrastructure is. Then the technical team makes
the necessary recommendations to support the targeted features of the site.

Defining Technical Development Requirements :

Your technical team will define the technical development requirement by reading the
objectives document and participating in the creative brain storming. The technical
team should come away with the good idea of the overall functionality of the site.
As a project manager, you can do some risk assessment in this phase by asking your
technical team members some key questions:
  Will they be using technologies they haven’t used before? This is a very
typical scenario since the Web and Web technologies change virtually from
week to week. Risk increases when your technical team uses software or
languages that are new and unexplored.
 How different are the new technologies from those they have used? It’s a
greater risk if they have absolutely no experience in a certain technology.
However, if someone is trying out a new server-side scripting language and
they have done many kinds of server-side scripting, the risk may be less.
 Will they be using code that is already developed or will they need to create
code from scratch? Often, you will find that engineers can use the same code
cover and over again, and sometimes they can’t. The development time will
naturally be slower for code that needs to be written from scratch.
 Will they have access to the production environment, and will they be able to
test on that environment? It’s critical that the technical team be able to test
its code in an environment that mirrors the production environment.

Feasibility and Software Testing :

Early in the design and specification phase, your technical team should be doing
feasibility and software testing. A feasibility test is a test that explores a particular
technical strategy to find out what the issues are in pursuing the strategy. For
example, if your creative team wants to use pull-down menus in dynamic HTML,
your technical team might do a feasibility test to see what kinds of obstacles they are
likely to face. The reason for doing feasibility testing to see early in the design phase
what the problems might be in implementing a technical solution.
Software testing is a kind of feasibility test. In software testing, the technical team
tests all software that is to be used on the site, such as e-commerce server software, so
that they can get up to speed with the features and the application programming
interfaces. This should happen during the design phase.

PLANNING FOR MAINTENANCE AND GROWTH:

It’s important to begin a Web project with the end in mind. Who is going to inherit the
site when your team is finished developing it? Will your team need to provide simple
templates or is a content management system necessary to help the client’s Web team
maintain the site? Both your technical and production teams need to think about
maintenance in the beginning of the project when the requirements are being
gathered.
If a content management system needs to be implemented, your technical team should
be the team to evaluate the different kinds of software and make a recommendation
based on the client’s existing technical infrastructure- both hardware and human
resources. It’s important that some one on the client’s team take a part in this
decision.

TECHNICAL SPECIFICATIONS
The technical specification is a document that clearly details how a technical
component will be built. It is different from the functional specification because it
goes into very specific detail from an engineering standpoint. The users of the
technical specification are other engineers who may be brought in to work on the
project, as well as the client’s technical team.
You don’t always need a detailed technical specification, but it’s a good idea to have
one. The best reason to use the technical spec is to anticipate the need to bring an
engineer in midway through the project. Some other very good reason to have such a
document are to demonstrate to your client that you understand its technical
environment and to ensure that once the project is finished it will be easily integrated
into an existing environment. It’s a good way to communicate with your client’s team.

PRODUCTION PLANNING:

Production planning covers two distinct areas: planning for the initial production of
the site and planning for handoff to a client or another production team. Most of the
planning before production, preproduction, is done to ensure that by the time a project
is ready to move into the production phase, the production team is ready and
completely informed about its scope and requirements.

UNDERSTANDING END-USER REQUIREMENTS :

After reading the creative brief, all team members should understand what the project
objectives; we usually have a meeting specifically to discuss these objectives before
gathering the requirements and certainly before going into the design phase. However,
the production team must understand end-user requirements in order to make sure that
the site meets them. These requirements are usually the following :
 Browser – If your target audience is expected to have a certain version of a
browser, the production team will make sure the site looks good on this
browser.
 Platform – If your target audience is expected to own a certain computer
platform(windows or Macintosh), then your production team will make sure
the site is optimized for that platform.
 Connectivity - If your target audience is expected to connect to the site using
a certain speed of modem, then your production team will make sure the site
downloads acceptably over a modem of that speed.
 Plug-in - If your target audience will need a plug-in to view a certain feature,
such as a Quick time movie, then your production team will make sure that
users know this up front and will provide a method for getting the plug-in to
the users.
 Software Setting – If your target audience needs additional software or has
modified the software setting for particular browsers, then your production
team also need to alert the users to action they need take to get the optimal
experience of your site.

PRODUCTION GUIDE:

As I said in the beginning of this section, you are planning not only for the
implementation of the Web site, you might also be planning for handing the project
off to your client’s Web team or to a different Web team that might be responsible for
maintaining and updating the site. I use a production guide to keep track of how the
site was built, and then I hand this guide to my client to serve as documentation of the
site, from how the graphics were created to what the files were named and why. Here
are some important facts to include in your production guide :

 Directory structure - A description of the file structure of the site. Be sure to

include a summary of file locations.
 File names - A description of how files were named. A solid naming
convention is important, especially for large sites. Files should be named in
such a way that you can tell where the file lives and what it contains just by
looking at the file name.
 Coding and scripting notes - If you are using any kind of JavaScript or cgi-
script, then it’s important you describe what the script does and how to make
modifications to it. As well, fully commented code will help the people who
are maintaining the site to quickly see what to update.
 Production art notes - A description of how the images were saved. We
usually tell our clients what setting to save GIFs and JPEGs. These numbers
change, depending on the palette and the end-user requirements.

PRODUCTION INFRASTRUCTURE:

Planning ahead and providing a good production infrastructure for your team is
essential to a smooth production process.

TRACKING CONTENT:

The production infrastructure is not only where the site gets built, but also where all
the content of the site is kept in various stages of completion. The process of moving
and tracking elements of the site such as copy, images, and other media is called asset
tracking. It’s important that someone is in charge of making sure all assets come in
form the people who are supposed to provide them, and then go through a review
phase before they get handed to coders to incorporate into the site. All assets should
have sign-offs before they get incorporated.
The asset- tracking process should be a process that all team members feel
comfortable with and it should evolve out of the best way For people to work
together. At Red sky, we have a folder structure in place and assets move through
their various stages by way of these folders. When assets are ready to be integrated in
to the site, they get moved to the production folder, which contains folders for the
different media types.

DEVELOPMENT SITE :

The development site is the environment in which the site gets built. It’s critical that
this area be ready before the project moves into the production phase. Some of the
specific questions you might ask about the development site include :

 Where is the site? What is the IP address or URL?

 Does the team need a user name and password to access it?
 Do we need to use special software to access it?
  Is there appropriate security on it so that only the Web team can access and
view it?
 Does it mirror the production (or live) Web environment?

When you know the answers to these questions, this information should go either on
the project site or in the production guide, whichever makes the most sense for you
and your team.

PLANNING FOR CHANGE :

No matter how much planning you do, changes will inevitably occur as a result of
client or internal review of the site as it is getting built. While it often doesn’t seem
so, change is good. Let your team know that some degree of change will occur and to
think about that in their planning phases. On the client’s side, handling change can be
sensitive issue. It’s important that you always go back to the original scope document
and the supporting functional specification and make sure that you negotiate
additional fees for changes that occur outside of the features outlined in these
documents. If a client wants a change and the delivery date is not moveable, then you
will need to negotiate to implement the change at a later phase. You might want to
draw up a service agreement with your client that states that your team will implement
the change for an additional cost after the initial site is delivered. Remember, the
reason for writing the scope document and functional specification is so that you and
the client remain clear about the work and costs you’ve agreed upon. Clients need to
know the costs of development, and they need to know when a perceived small
change really is a large change with implicating costs.