BT eTrading Intranet Site

boompikeInternet και Εφαρμογές Web

8 Δεκ 2013 (πριν από 3 χρόνια και 4 μήνες)

74 εμφανίσεις

BT eTrading Intranet Sit
e

Development Documentation

Ben Johnson, British Telecommunications plc 2002

BT eTrading Intranet Site
-

Development Documentation


Page
2

1

Executive Overview

The BT eTrading site


which aims to promote information sharing within the e
-
Commerce
(formerly “EDI”) team, as well as providing an efficient means of communication with
current a
nd potential customers


is driven by a powerful, extensible Content Management
System (CMS) named
Content Delivery XML System

(‘
cdXP
’).

Benefits offered by cdXP over alternative approaches (e.g., MS FrontPage) include:


Central management of appearance and

function of all site content.

→ Easily change the look and feel of the site in one step



Personnel contact information updated automatically at display time using data from
BT TeamConnect Directory

→ Eliminates outdated contact details, the # 1 web main
tenance headache



Maintain site content by visiting a page using a standard web browser and clicking an

Edit
’ link, instead of requiring physical access to server

→ Intuitive, minimal hassle content maintenance

→ Create advanced cross
-
browser content wi
thout web development skills

→ No need for editors to understand the physical web server configuration


This report documents the development of cdXP and the eTrading Intranet site.

BT eTrading Intranet Site
-

Development Documentation


Page
3

2

Contents

1

EXECUTIV
E OVERVIEW

................................
................................
................................
...............................

2

2

CONTENTS

................................
................................
................................
................................
..........................

3

3

INTRODUCTION & SCOPE

................................
................................
................................
............................

4

4

PROJECT BRIEF

................................
................................
................................
................................
................

5

5

PROJECT PLANNING & A
PPROACH

................................
................................
................................
.........

5

6

CUSTOMER REQUIREMENT
S

................................
................................
................................
.....................

6

7

SYSTEM SPEC
IFICATION

................................
................................
................................
..............................

7

7.1

C
ONTENT
D
ELIVERY
B
ACKEND
S
YSTEM
................................
................................
................................
.......

7

7.2

N
AVIGATION
S
TRUCTURE AND
C
ONTENT
O
RGANISATION

................................
................................
...........

7

7.3

O
N
-
SCREEN
L
AYOUT AND
P
AGE
A
PPEARANCE
D
ESIGN

................................
................................
...............

7

8

SYSTEM DESIGN

................................
................................
................................
................................
...............

8

8.1

C
ONTENT
D
ELIVERY
B
ACKEND
S
YS
TEM
................................
................................
................................
.......

8

8.2

N
AVIGATION
S
TRUCTURE AND
C
ONTENT
O
RGANISATION

................................
................................
.........

10

8.3

O
N
-
SCREEN
L
AYOUT AND
P
AGE
A
PPEARANCE
D
ESIGN

................................
................................
.............

10

9

DESIGN IMPLEMENTATIO
N

................................
................................
................................
......................

12

9.1

I
MPLEMENTATION
A
PPROACH

................................
................................
................................
.....................

12

9.2

I
SSUES
E
NCOUNTERED
&

T
HEIR
R
ES
OLUTION

................................
................................
............................

12

10

PROJECT EVALUATION

................................
................................
................................
..........................

14

10.1

I
NTERNAL
&

E
XTERNAL
E
VALUATION

................................
................................
................................
........

14

10.2

M
ETA
-
LEVEL
E
VALUATION

................................
................................
................................
..........................

15

10.3

F
URTHER
W
ORK

................................
................................
................................
................................
...........

15

11

APPENDICES

................................
................................
................................
................................
................

17

11.1

ISE

S
WINDON
I
NTRANET
S
ITE
V
ISITOR
Q
UESTIONNAIRE

................................
................................
...........

17

11.2

U
SER
P
ROFILES
,

T
ASK
S
CENARIOS AND
A
SSOCIATED
R
EQUIREMENTS

................................
.....................

18

11.3

N
-
T
IER
W
EB
C
ONTENT
D
ELIVERY
A
RCHITECTURE

................................
................................
....................

19

11.4

BT

E
T
RADING
S
ITE
A
CTOR
&

U
SE
-
C
ASE
A
NALYSIS

................................
................................
..................

20

11.5

BT

E
T
RADING
S
ITE
O
N
-
SCREEN
I
NTERFA
CE
D
ESIGN

................................
................................
.................

21

11.6

EDI

S
ITE
D
ESIGN
A
RTWORK
-

P
ROJECT
B
RIEFING
&

D
ELIVERABLES

................................
........................

22

11.7

D
ELIVERING THE
BT

E
T
RADING
N
AVIGATION
B
AR VIA CD
XP
................................
................................
...

22

11.8

CD
XP

C
ONTACT
D
ETAILS
L
OOKUP
F
UNCTIONALITY

................................
................................
..................

23

11.9

CD
XPE
DIT
F
ORM
V
IEW

................................
................................
................................
................................

24

11.10

BT

E
T
RADING
H
OME
P
AGE

................................
................................
................................
.....................

25

11.11

P
AGE
E
DIT
P
ROJECT
P
ROPOSAL

................................
................................
................................
...............

26


BT eTrading Intranet Site
-

Development Documentation


Page
4

3

Introduction & Scope

This report documents the development of the eTrading Intranet

site, including the
‘eTrading’ brand and the cdXP Content Management System that powers the site. It is
aimed at developers wishing to understand the reasoning and technologies behind the
system, typically in order to extend cdXP with additional functiona
lity. Thus, it assumes
familiarity with working with the Microsoft IIS server platform and web development
technologies such as HTML, CSS, ASP, XML and XSL.

Users simply wishing to update content or customise the appearance of pages on the
eTrading site sh
ould refer instead to the document “BT eTrading Intranet Site:
Administrator Documentation” which does not require this technical knowledge.
Developers wishing to extend the system should also consult the administrator
documentation in order to understand
the system from a user perspective.

This document is adapted from “
UMIST Industrial Experience Report”, by the
developer
,
so is written in first
-
person and presents an evaluation of the project perspective rather
than just as a historical record of develop
ment progress.

Section
4

(following) presents the original project brief and subsequent sections (
5
-
9
) are
dedicated to the Planning, Requirements, Specification, Design & Implementa
tion
Waterfall Model stages respectively. Finally, Section
10

evaluates the project and Section
11

presents Appendices. It should also be noted that due to the original report dating to
before the eTrading p
roject was wrapped, the evaluation does not cover system/user
testing, although meta
-
level evaluation is conducted, including further work proposals.

BT eTrading Intranet Site
-

Development Documentation


Page
5

4

Project Brief

Although my placement involved a wide variety of projects and responsibilities, my biggest
a
ssignment required me to design, develop and deploy a customer
-
facing Intranet site
dedicated to the EDI Gateway, a task that I worked on throughout my placement. The
project was briefed to me in a manner similar to the following a few weeks after my arriv
al
at British Telecom:

“Design and develop an Intranet site to communicate information relating to the EDI
Gateway amongst staff and customers, as well as promote Gateway services to
-

and actively attract enquiries from
-

potential new customers. The site

should seek to
reduce Operation Support costs by acting as a first point of support for customers
and providing direct access to information normally obtained via the Gateway team.
Site maintenance time and costs should be minimised."

A basic Intranet sit
e already exists, intended as an internal resource for members of the
Gateway team to provide links to documentation stored on the LAN, team contact details,
etc. Created using HTML authoring package, MS FrontPage, consideration was not given
during its de
sign to the volume of maintenance required by the use of stand
-
alone static
HTML pages in order to keep the site up
-
to
-
date. Content and links were updated for a
period after the site launch, but today are years out of date, rendering the site useless.

My
initial response to the brief was that a simple visual makeover, re
-
organisation and
information update would not suffice to solve the maintenance problems experienced with
the current site. I also observed that there would many security and data sensitivi
ty issues
to consider if the role of the site was to be expanded from an internal resource to a
customer
-
facing on
-
line ambassador for a business critical system with an annual turnover
of around £0.5m.

5

Project Planning & Approach

I possessed extensive exp
erience with web development projects prior to undertaking the
BT eTrading project, but much of my previous work had made limited the use of formal
techniques. Whilst I was familiar with capturing requirements and producing designs and
prototypes prior to
beginning work, I had never previously attempted to closely follow a
software
-
engineering development model and produce the associated documentation
when designing a web site.

Choosing the standard waterfall model by default (as the model with which I’d ha
d most
experience with), my assumption was that I would simply have to apply the discipline to
stick to the process specified by my chosen model. I should perhaps have realised from
previous projects that web development typically does not lend itself well

to the rigorous
Specification and Design documentation requirements of the waterfall model. I discuss the
suitability of my choice of development model and the problems I found with it in section
10
, “
Project Evaluation
”.

BT eTrading Intranet Site
-

Development Documentation


Page
6

6

Customer Requirements

The EDI Gateway is a complex system spanning a variety of platforms, including MVS
mainframes and Windows NT processing farms, and comprising hundreds of data
processing scripts and applications written i
n a number of different languages. A great deal
of research was required, therefore, to understand the workings of the system, its users
and their work
-
flow patterns sufficiently to identify required functionality and non
-
functional
metrics and guidelines.

In order to identify and document these factors, a variety of techniques were employed.
First and foremost, a regular series of formal and one
-
on
-
one meetings were held with key
Gateway personnel, to discuss workflow, procedures that could be supported or

replaced
by the site, requested functionality and security issues. Useful too were discussions with
colleagues with experience working on BT Intranet sites (including the developer of the
original Gateway site) particularly for ascertaining technical rest
raints placed by hardware
and highlighting formal BT development procedures.

BT Intranet provided a wealth of information on subjects such as the workings of EDI,
presentation guidelines and requirements for BT Intranet sites and rules and specifications
r
egarding use of corporate artwork such as the famous BT piper mark (estimated
commercial value £9.4bn). It also provided access to BT guidelines on recommended
software development approaches and techniques ("The Way We Work"), providing me
with my first t
aste of how Software Engineering theory can be applied in a commercial
environment.

In the case of the ISE Swindon Intranet site
-

which is an alternative application of the
system behind the eTrading site
-

a user questionnaire was used to gain understand
ing of
the profile and behaviour of existing visitors. Information gathered included platform and
browser used to access the site (to allow visitor client capabilities to be assessed) and
most popular reasons for visiting (see Appendix
11.1
). Unfortunately, this technique could
not be used to profile visitors to the old Gateway site, since traffic was virtually non
-
existent.

A systematic user
-
orientated approach was taken when documenting the requirements
gathered using these techniq
ues. First the principle groups of users of the system were
identified (Gateway Team, Existing Gateway Customers, Potential Gateway Customers)
and then use
-
cases identified for each of these groups (e.g. "view gateway
documentation"). Each use
-
case was the
n translated into one or more uniquely numbered
requirement statements (e.g., "site must provide access to gateway documentation").

I later discovered the approach used to document requirements was very similar to the
Use
-
Case diagram used in UML modelling
, as exploited as part of the UML:DARK project
which ran parallel to eTrading. See Appendix
11.2
, "
User Profil
es, Task Scenarios and
Associated Requirements
", for the final list of requirements for the eTradi
ng site.

BT eTrading Intranet Site
-

Development Documentation


Page
7

7

System Specification

Having identified an enumerated list of requirements covering all aspects of the site, a
more refined view of what was expected from the site was required. Typically in a software
development situation, this would take the for
m of a System Specification document that
presents highly specific and detailed recording of the features required from the site. In
this scenario, however, it was decided a full specification would be constrictive and
unhelpful for a system where regular

additions and changes to provided functionality were
expected during development, as user feedback was received.

More useful to project development was to set out the components of the system and their
expected functionality. From experience with previous

web development projects, I was
aware that the on
-
screen appearance of the site can and should be developed
independently from the design of its navigational structure, the backend page delivery
system, etc., therefore each may be designed and implemented

as a separate component.

Constructing the system in this manner offers two considerable benefits: delegation and
component re
-
use. Firstly, it would have been entirely possible, had the project been
assigned to a team instead of a single developer, for se
parate teams/developers to each
work on a component, which, with regular integration testing, would have accelerated
development of the final solution. Secondly, the development of the BT eTrading site as an
application of several re
-
usable components open
ed the possibility of developing other
sites based on the same system (the ISE Intranet site project).

The key component deliverables were identified as follows:

7.1

Content Delivery Backend System

Responsible for processing site pages before delivery to the c
lient, ensuring only available
capabilities are utilised, adding boilerplate page elements and performing value
-
added
processing of page data. Should support requirements such as reducing site maintenance
by minimising the need for duplicated or quickly ou
tdated information on pages (e.g., hard
-
coded staff contact details).

7.2

Navigation Structure and Content Organisation

Design for actual site content and its organisation. Should closely reflect the requirements
of the identified user groups and support their

use
-
cases, making it easy for site visitors to
locate specific documents and functionality and minimise distractions and obstacles
preventing them from completing their task in hand.

7.3

On
-
screen Layout and Page Appearance Design

Design for on
-
screen layout
of boilerplate elements common to each page (e.g., company
logo, navigation devices) as well as frames usage and styling for page elements such as
titles and page text. Should support requirements such as ease of navigation and
adherence to BT Intranet gui
delines. Also includes re
-
branding of EDI Gateway services.

BT eTrading Intranet Site
-

Development Documentation


Page
8

8

System Design

With a clear list of customer requirements and a specification of the required component
deliverables, the next task was to design a workable solution to meet each specification.
Wo
rking as a single developer, I decided to tackle the re
-
usable backend delivery system
first, then plan out on paper the site structure and content to be delivered using this system
and then finally design the site's polished appearance and user
-
friendly i
nterface.

With few dependencies between components, however, I found it useful to consider
possible solutions for each component concurrently, before delving into more detailed
implementation details. This involved outlining a draft site structure, sketchi
ng possible
interface designs and performing a large amount of research on
-
line into the latest web
development technologies (i.e., dynamic alternatives to a static collection of HTML
documents), the latter of which also highlighted how others had tackled
similar problems.

The following sections give an overview of the steps taken in reaching a design for each of
the site components, including example key design decisions:

8.1

Content Delivery Backend System

By far the most challenging and time
-
consuming task i
n creating the site, the need for a
more advanced method of content delivery than static HTML files became apparent from
the requirements to minimise the time taken to develop new site content and reduce the
volatility of page data. Examples of volatile da
ta include styling and presentation code,
boilerplate elements (such as navigation devices, site logo, etc.) and contact details (e.g.
telephone number) for staff referenced on the page.

Client
-
side alternatives to some kind of page pre
-
processing system w
ere considered
carefully first, since they were likely to reduce development time. The inclusion of a link to a
Cascading Style Sheet (CSS) file on each page as a solution to the problems with
embedded style information was considered, as was the use of a
standard HTML
hyperlink on each person's name to their contact details on BT Directory, instead of
including details within the text.

Research and experimentation found that reliance on client
-
side CSS yielded
unacceptably different results according to th
e client browser in use (with particularly poor
results in most Netscape browsers) and that control over page data presentation is limited
to simple element styling. Use of hyperlinked staff names was a good idea in principal, but
required page authors to
manually look up each person's BT Directory profile URL (which
could then change) and meant an additional step for visitors, instead of having the
information at a glance.

Instead the decision was taken that a system was needed that could perform value
-
add
ed
processing on page data in order to minimise publishing effort for page authors and solved
the data redundancy problems discussed. I envisaged a system that allowed page data to
be provided by the author more
-
or
-
less as a set of raw text fields, without

needing to
consider page presentation, target client type, etc. This data would then be transformed by
the system into a web page tailored to the visiting client, complete with additional
information, functionality and boilerplate elements.

Changes could
then easily be made to the appearance and functionality of all pages
delivered by the system, without modifying the original page data. Alternatively, the same
data could be presented in different ways around the site, or even by other sites. New
BT eTrading Intranet Site
-

Development Documentation


Page
9

functiona
lity
-

such as a custom menu when a person’s name is clicked or an information
pop
-
up when the mouse is hovered over a meeting/event name
-

could be added to all
pages at any time.

Having determined the type of delivery system required, it was time to iden
tify suitable
technologies. Research amongst web
-
development technology resources such as
micosoft.com

and
asptoday.com

revealed a wealth of potential solutions, including:



Store page as complete HTML file and fine
-
tune before delivery using ASP



Store page

data in a database and access via an ASP script which inserts data
into an internal HTML page template



Store page data in an XML file and access via an ASP script which inserts data
into an internal HTML page template



Store page data in XML file which is
accessed directly by the client and
transformed on the client
-
side before display, using the specified XSL filter



Store page data as XML and transform on server
-
side using XSL and ASP,
outputting HTML tailored to the client type

From researching discussion
s of these approaches and testing the technologies for
myself, merits and drawbacks were identified for each of these approaches. My conclusion
was that while often slower, XSL transformations offer more powerful, structured
processing capabilities than st
andard ASP template scripting. Its usage necessitates
storage of page data as XML (or an intermediate step to convert it to XML, e.g. from a
database), which has the benefit of making the data accessible to a wide range of
platforms. Finally, client
-
side X
SL transformations are only supported by recent browsers
such as IE5+, making server
-
side processing the best option.

From these observations, a delivery system based on server
-
side XSL transformation of
XML data using ASP scripting was identified as the b
est solution. I therefore set about on
numerous on
-
line training courses to familiarise myself with the XML meta
-
language and
the XSL rules
-
and
-
templates transformation language. I also investigated examples and
case studies of ASP architectures suitable f
or binding the two technologies and then
added my own ideas and features as required by the system to produce the architecture
illustrated in Appendix
11.3
, "
N
-
Tier Web Content Delivery Architecture
".

The resu
lting system divides the process of returning an HTML page (or WML, etc.)
corresponding to a specific Article ID between five distinct layers. The Data Procurement
Layer obtains raw article data from the Data Access Layer, corresponding to a given Article
ID, and returns it formatted as XML to the Business Logic Layer. The BLL performs value
-
added XSL filtering of the XML data, such as inserting contact details data, before
returning it as XML to the Presentation Layer. This layer is then responsible for
tr
ansforming the XML page data via XSL into a displayable page (e.g. HTML) tailored to
the client making the request (the Client Layer).

This architecture allows page data to be processed in a highly modular manner, allowing
XSL filters to be slotted into or

removed from the BLL chain at any time as required. It also
abstracts over the actual physical storage of the page data, with the Data Access Layer
returning the data as XML regardless of its native format. The Presentation Layer takes
care of outputting
a page tailored to the client, so filters in the BLL can safely ignore the
client type. Finally the architecture allows for caching at each layer, meaning repeated
requests do not generate unnecessary reprocessing.

BT eTrading Intranet Site
-

Development Documentation


Page
10

8.2

Navigation Structure and Content Organisa
tion

Work on the structure and organisation of the site resumed with perfect timing, since work
within the separate UML Study Group project had brought to my attention a number of
techniques for profiling users and their use
-
cases. I used these techniques
to identify the
site's key user roles ("Actors") and the tasks each role would wish to perform (use
-
cases)
then construct a site structure that accurately reflected these tasks.

Following the guidelines for constructing UML Use
-
Case diagrams
-

which state
that each
user group should gain benefit from the system and have a markedly different set of tasks
that they wish to perform, but that an individual visitor can switch roles at any time during a
visit
-

I identified the following user roles expected to us
e the site:



eTrading Operation Support



eTrading Developer



eTrading Existing Customer



eTrading Potential Customer



Generic Surfer

For each user role I then identified as many use
-
cases as possible, listing tasks that the
Actor would visit the site in order t
o complete. For example, an eTrading Potential
Customer would be interested in reading an overview of the gateway, while an eTrading
Developer might visit the site in order to access a technical document. For the full list of
Actors and use
-
cases, see Appe
ndix
11.4
, “
BT eTrading Site Actor & Use
-
Case Analysis
”.

The next task was then to logically group these use
-
cases onto pages, bearing in mind the
need to collect related tasks and minimise the time to initiat
e (i.e., navigate to the relevant
page) and complete common tasks. Each page represented a physical page (or set of
pages) on the site and could contain names of tasks that could be initiated there and links
to other pages where related tasks could be perf
ormed.

To create this structure of pages, I started with a main page linked to one page for each of
the Actors except the "Generic Surfer" role. Next, tasks specific to an Actor were placed on
that Actor's page, while tasks common to several Actors were ge
nerally given their own
page and a link placed on the Actors' pages instead. Use
-
cases for the "Generic Surfer"
role were also added to every page.

The result of this exercise was a set of around seven interconnected pages, each with a
list of use
-
cases th
at could be initiated from that page, thus forming the hierarchical
navigation structure of the site. Since this structure was designed to minimise the time
taken to initiate a given task by collecting together related tasks and organising tasks by
user ro
le, it should result in a site that is quick and easy to navigate. Fine
-
tuning of the
structure is to be expected after user feedback, however.

8.3

On
-
screen Layout and Page Appearance Design

In order to meet its new role as a primary means of attracting new G
ateway customers, it
was vital that the branding of the site
-

by which I mean the look and feel, visual elements,
narrative style, etc.
-

be given careful consideration. By identifying the benefits and values
associated with the Gateway (or which we would

like to be associated with the Gateway)
and presenting the visitor with an experience that consistently enforces this image, we
increase the chances of acquiring a new customer.

The first step in building this new brand and position was to take a close lo
ok at the role of
the Gateway and the benefits offered to customers, as well as key competitors and any
BT eTrading Intranet Site
-

Development Documentation


Page
11

negative perceptions/stigmas associated with the service. The latter is an important
consideration, since often the most powerful re
-
branding exercises
focus on dispelling
negative perceptions rather than trying to hammer across the benefits of a product or
organisation (a good example would be the “You Either Love It Or Hate It” campaign for
Marmite, a food spread with an acquired taste).

Research and br
ainstorming revealed that the basic role of the Gateway is to act as a
business interpreter for the customer, allowing them to communicate with any external
system, regardless of distance and technological differences. The Gateway can
understand and speak
any language. It is based on tried
-
and
-
tested technology that is
reliable, stable and trustworthy. Metaphors abound, it is a wise old friend that stands sturdy
and tall above the restless sea of inexperienced cutting
-
edge alternatives.

Clearly a familiar f
ace who symbolises all these qualities is required; someone who is wise,
friendly, reliable, experienced and an expert

with technology. After considering various
possibilities, Universal Studios’s ET™ (the Extra Terrestrial™) was identified as
possessing all these qualities. Conveniently too, he is currently the face of a series of
nation
-
wide advertising campaigns for BT
, thanks to a two
-
year licensing deal with U.S.
allowing the use of ET(™)’s name and image in conjunction with BT promotions.

Discussing the concept with members of the Gateway team proved extremely worthwhile;
not only was the idea well received but disc
ussions led to the suggestion that
BT eTrading

be used as the brand name for Gateway services, potentially shortened to ‘
eT
’ for the logo
and slogan lines. From these discussions too, tag lines such as “
eT Speaks Your
Language
” and “
eT Takes Your Business
Further
” were devised as a means of
communicating the role of the Gateway in a minimum of words.

In developing a logo to symbolise the new brand and positioning, the aim was to convey
the message that BT eTrading is a business
-
critical system integral to B
T
-

through use of
recognisable elements from the main BT brand such as typeface and colouring
-

but that it
is a value
-
added self
-
supporting service with its own identity rather than a behind
-
the
-
scenes mechanism.

The next task was to develop an on
-
screen

identity for the site which reflected this new
brand and positioning. This standard website design exercise took into account BT Intranet
guidelines and existing examples on the BT Intranet, which recommend the inclusion of a
static vertical navigation ba
r to the left of each page, plus the e
-
BT logo and a set of
standard Intranet links at the top. It also tried to reflect elements of the BT eTrading brand,
through use of BT colouring and typefaces, broad shapes with rounded corners, etc.

The resulting des
ign (see Appendix
11.5
, “
BT eTrading Site On
-
screen Interface Design
”)
is simple and uncluttered, lending itself to either a frames or non
-
frames interface. The
horizontal bar along the top of the screen echoe
s elements of the standard vertical BT bar
and serves to highlight the page title and separate BT Intranet links from the rest of the
page. The official corporate BT blue and two tints are used as background colours across
the design, giving it a professio
nal but welcoming BT feel, without reducing the readability
of the high contrast white text and yellow hyperlinks/sub
-
titles.

As part of developing this design, a rough HTML mock
-
up (i.e., prototype) was used to
allow screen dimensions, HTML element sizes,

etc., to be more accurately taken into
account. In order to provide them with experience with web design work, production of
proof site design artwork was delegated to a colleague, which involved production of a full
assignment brief that included project

background and deliverables specification (see
Appendix
11.6
, “
EDI Site Design Artwork
-

P
roject Briefing & Deliverables
”).

BT eTrading Intranet Site
-

Development Documentation


Page
12

9

Design Implementation

9.1

Implementation Approach

With the design for all three componen
ts of the system complete, as well as a static HTML
mock
-
up of the site interface and various experiments with XML, XSL and ASP, coding
began for the backend delivery system, dubbed
Content Delivery XML Platform

(
cdXP
).
Again a modular approach was taken,
coding one layer at a time and using ‘dummy’ layers
that returned valid static data but performed no real processing, allowing integration testing
before the whole system was complete. The layered architecture meant it would have
been possible to delegate
development to other team members, had the project been
assigned to a team.

Once the delivery system had reached a stable working state (albeit still using dummy
routines for the Data Access and Business Logic layers), work began on producing proof
code fo
r the site interface. The decisions had to be made whether to use HTML frames in
order to avoid persistent element having to be downloaded and redisplayed each time the
user visited a new page or to have the cdXP Presentation Layer append boilerplate
eleme
nts to each page before delivery. The frames option was chosen in order to reduce
page
-
loading times, but it would be simple enough to provide both versions, depending on
client capabilities or user preference.

Having decided on frames, the next decision w
as whether to use static HTML pages for
the persistent top and navigation frames or have them delivered by cdXP. Since the
appearance of these frames wouldn't need to be re
-
used on any other page, it did not
seem that cdXP lent any advantage over a static
page and indeed could potentially slow
down each visit to the site. Static HTML was used, therefore, until it was recognised that
anything but the simplest of navigation devices would be extremely difficult to maintain.

With nested levels of hyperlinks, ea
ch with associated client
-
side scripting and
presentation information, even updating the navigation structure using an HTML editing
package such as MS FrontPage would have proved difficult. The solution found was to
make use of cdXP after all, storing just

the raw navigation structure for the site in the
source XML file, then having this translated by the Presentation Layer into a working
navigation device.

This approach has the added benefit that the site structure information could be presented
differentl
y elsewhere, e.g. on a site roadmap page showing a visual tree of the site
structure with all nodes expanded. This scenario is an excellent example of the re
-
use and
ease of maintenance benefits of separating data from display information when developing
a

web site, as illustrated in Appendix
11.7
, "
Delivering the BT eTrading Navigation Bar via
cdXP
".

The final implementation task
-

one that continues to
-
date, along with developments to
cdXP
-

was the translation

of the user
-
orientated site structure into actual working content
pages delivered by cdXP. This was approached by firstly creating a cdXP
-
delivered page
for each page in the structure design, then adding the list of associated use
-
cases to each
plus worki
ng links to other pages, creating a navigable skeleton of the final site. Currently
these use
-
cases titles are now being replaced one by actual functional content.

9.2

Issues Encountered & Their Resolution

The development environment used for the duration of t
he BT eTrading project was
Windows NT equipped with an HTML text editor (Allaire HomeSite) and Microsoft
BT eTrading Intranet Site
-

Development Documentation


Page
13

Personal Web Server. For much of the project, the latter web server was used for testing
the site (including ASP scripts) instead of an external dedica
ted server running IIS. Only
recently, once the eTrading site had taken shape as a whole, did I realise the drawbacks of
testing on the Localhost (PWS) platform.

Developing sites should always be tested regularly (or all the time) on a production web
serve
r, because performance, proxy behaviour and server configuration/capabilities can
vary considerably from that for Localhost. For example, it may turn out that a required
component installed locally cannot be installed on the server due to compatibility pro
blems
or security restrictions.

Another big problem encountered when developing using cutting
-
edge technologies such
as XSL and XMLHTTP was the limited amount of documentation, guidelines, examples
and expertise available. Often I would find myself unsure
whether a technology was
designed to cope with a creative way I'd found to use it, or I would find a technology
exhibiting strange behaviour for no obvious reason, later turning out to be due to an
undocumented bug or incompatibility.

One important means o
f tackling this problem was the advanced use of structured error
handling within the cdXP system. A JScript
-
ASP technique called "try..catch" error handling
allows errors within a block of code to be caught and dealt with (or reported in detail),
rather th
an an error message being displayed to the user. This was particularly useful for
tracking errors through a multi
-
layered architecture such as cdXP, where returning error
message text to a higher layer would cause problems.

BT eTrading Intranet Site
-

Development Documentation


Page
14

10

Project Evaluation

10.1

Internal & Ex
ternal Evaluation

It is inappropriate to conduct full black box testing and requirement tracking for the BT
eTrading site at this stage, because with several months development time still remaining
for continued implementation, followed by testing and docu
mentation, it is a far from
finished project. This report can only document progress so far, so the following comments
only address obvious successes and failures in the current implementation, which is
essentially limited currently to a base implementatio
n of the cdXP system.

Looking at the current implementation of the Content Delivery XML Platform, I would firstly
underline the success of the current main example of value
-
added functionality, the
automatic look up of contact details for persons reference
d on a page. In its current form, a
page author can automatically make available contact details for a person simply by
placing HTML
-
like "<person>" tags around that person's name. Doing so causes cdXP to
look up that person's details via BT's TeamConnect
Directory and embed them on the
page so that they are displayed when a visitor's mouse hovers over the person's name
(see Appendix
11.8
, "
cdXP Contact Details Lookup Functionality
").

This kind of transparent s
ystem interconnectivity (made possible by XML data exchange)
is typical of the effortless data sharing being pushed as the cornerstone of the next
generation of distributed computing systems. It is functionality that is indisputably valuable
to both the au
thor and visitor system users, saving the author both publishing and
maintenance time and enabling the visitor to access up
-
to
-
date information about any
person whose name is tinted blue on the BT eTrading site. I would argue this functionality
alone justi
fies the use of a delivery system such as cdXP.

Keen followers of Microsoft's latest addition to the Office application suite may recognise
similarities between the above functi
onality and the new SmartTags™ technology included
in MS Office XP™. One function of this technology is the recognition, as one types, of
certain keywords (e.g., place names) and subsequent procurement of related data from an
external Internet system ready

for utilisation in the document. The similarity is coincidental,
but clearly demonstrates a growing emphasis in computing on distributed interconnectivity.

Clearly this functionality contributes to meeting requirement 2a, "
Day
-
to
-
day site
maintenance MUST

be absolutely minimal, with automated processes implemented
wherever practical
" (see Appendix
11.2
, "
User Profil
es, Task Scenarios and Associated
Requirements
"). As expected, however, the implementation is no
t perfect; in the absence
of any form of caching at present, using a large number of names on a page can slow
delivery time considerably.

Another major success is the ability of cdXP to allow pages to be edited from any web
browser, without the need for kn
owledge of HTML. The current implementation accepts a
parameter to specify a viewing mode for the specified page. Current available modes are
normal, XML (which returns the raw XML page, ready for alternative processing) and
cdXPEdit. The latter presents a

form view of the underlying page data, allowing it to be
modified and saved directly back to the server, using just a browser (see Appendix
11.9
,

cdXPEdit Form View
”). This meets requirement 3a, "Site should n
ot require HTML
knowledge for day
-
to
-
day maintenance".

BT eTrading Intranet Site
-

Development Documentation


Page
15

10.2

Meta
-
level Evaluation

As mentioned in section
5
, "
Project Planning & Approach
", my approach to developing the
BT eTrading was far from perfect. First and
foremost I believe I chose a slightly ill fitted
development model, which I found myself having to bend and mould to the true nature of a
web development project. The waterfall model does not lend itself well to situations where
not enough is known about t
he implementation technology to lay down detailed Design
documentation before implementation starts.

When using a very new implementation technology, particularly a complex multi
-
layered
one such as the XMLHTTP interconnectivity interface, there is often n
ot enough
documentation and expertise available to know exactly how the technology should best be
exploited and applied to the problem. Furthermore, it is common for new web technologies
to change dramatically as feedback is received from the developer com
munity, meaning
improved new functionality can become available or redundant features withdrawn.

Rather than recognising this degree of uncertainty and making use of prototyping
techniques to assist with the system design, my approach was to attempt to com
plete
Design documentation prior to starting the Implementation stage, as encouraged by the
waterfall model. This may have resulted in the Implementation stage taking longer than if I
had experimented with XML/XSL, etc., prototypes until I was confident I
understood the
applications and limitations of these technologies, then applied this knowledge to create a
detailed design with well
-
defined boundaries.

In my defence, guidelines on appropriate development models to use for web
development appear to be few

and far between. The shift from treating a web site as a
collection of static documents to being the product of a full software
-
engineering project
has only taken place over the past few years. Consequently the practice is still in its
infancy, despite at
tempts by companies like Microsoft to lay down new models tailored to
web development, such as the Microsoft Solutions Framework (MSF).

Were I to re
-
approach the development of the BT eTrading Intranet site, the most
important change I would make to my app
roach would be to increase my communication
with the customer, since face
-
to
-
face consultation dropped considerably during
implementation stages, resulting in poorly managed expectations. I would arrange for
regular demonstrations of the site in action, to

ensure expectations remained realistic and
would take the opportunity to gather valuable feedback to ensure I was on track to meeting
the customer's needs.

10.3

Further Work

Whilst the cdXP system is currently stable and usable, the potential for easier change
s to
the chaining of XSL filter still exists, since currently the cdXP ASP code must be modified
directly. Allowing the chain of filters for each page type to be specified in an external file
(XML being an obvious storage candidate) would accomplish this.
In particular, the
Presentation Layer would benefit from improvements to means of specifying alternative
presentation based on the client (e.g., allow output for WAP phones).

Many more opportunities for value
-
added functionality exist, with contact details

look
-
up
being an excellent example of what can be achieved. Ideas include "<event>" elements
that display details when hovered over and send an Outlook appointment to the visitor
when clicked. Links to other pages are another obvious target; hovering over

a link could
cause the last modified date, author, etc., of the linked page to be displayed.

An essential improvement to cdXP, if it is to scale to higher traffic loads and increase its
delivery performance, is the implementation of intelligent caching th
at caches data at
BT eTrading Intranet Site
-

Development Documentation


Page
16

various stages in
-
between layers and intelligently minimises unnecessary reprocessing.
Caching of other data, such as contact details, would also help, as would the
implementation of client
-
side contact detail look up for platforms that s
upport it (IE5+),
which would also reduce load on the server.

With regards to the BT eTrading interface, proof production of brand artwork and
procurement of

ET™ imagery and associated permissions is still outstanding. Polish is
needed for the expanding and collapsing navigation device and
-

as with several client
-
side
script based features
-

cross
-
browser compatibility needs to be addressed. Consideration
may

be given to production of a non
-
frames version of the interface (see Appendix
11.10
,
"
BT eTrading Home Page
").

Finally, of course, full system testing is still outstanding, including exception and extreme
dat
a testing, code
-
path analysis, server stress
-
testing and black box customer and user
trials, with subsequent feedback review and implementation of suggested changes.

BT eTrading Intranet Site
-

Development Documentation


Page
17

11

Appendices

11.1

ISE Swindon Intranet Site Visitor Questionnaire

See next TWO pages

BT eTrading Intranet Site
-

Development Documentation


Page
18

11.2

User Profil
es, Task Scenarios and Associated Requirements

See next THREE pages

BT eTrading Intranet Site
-

Development Documentation


Page
19

11.3

N
-
Tier Web Content Delivery Architecture

See next page

BT eTrading Intranet Site
-

Development Documentation


Page
20

11.4

BT eTrading Site Actor & Use
-
Case Analysis

See next TWO pages

BT eTrading Intranet Site
-

Development Documentation


Page
21

11.5

BT eTrading Site On
-
screen Interface Design

BT eTrading Intranet Site
-

Development Documentation


Page
22

11.6

EDI Site Design Artwork
-

P
roject Briefing & Deliverables

See next page

11.7

Delivering the BT eTrading Navigation Bar via cdXP

See next TWO pages

BT eTrading Intranet Site
-

Development Documentation


Page
23

11.8

cdXP Contact Details Lookup Functionality

See next TWO pages

BT eTrading Intranet Site
-

Development Documentation


Page
24

11.9

cdXPEdit Form View

See next page

BT eTrading Intranet Site
-

Development Documentation


Page
25

11.10

BT eTrading Home Page

See next page

BT eTrading Intranet Site
-

Development Documentation


Page
26

11.11

PageEdit Pr
oject Proposal

See next TWO pages