Developing a Redbourne Application
Redbourne recommend a simple structured process for developing web
applications and deploying them using the Redbourne system. This process
has much in common with rapid application development techniques and
methodologies and can be considered a superset of static web application
development and deployment.
The process is summarised in the diagram above. 'Click' on the individual elements
for details of the process steps.
Although the process delineates a number of distinct steps - recognise that
the steps in fact overlap and are iterative. At each stage you will learn
more about the problem you are trying to solve and will be able to refine
the previous stages.
The important points of
the process as a whole are:
- Agree the business requirements up front in a statement of
requirements, paying particular attention to the clients expectations
from the application.
- It's a good idea to stage the implementation if this is possible, breaking
the application into a number of deliverable stages. This will allow you
to build confidence with the client and to get their site live as
soon as possible.
- The process is iterative. You work on a static 'look and feel', Review
this with the client, make revisions. When you do the dynamic design
you may realise the look and feel needs to be modified.
- Make use of the Redbourne test site facility to test and review
the operational site before making it live.
- Get the client to accept the application before making it live.
- Once the site is live, you can continue with the next phase using the
test site, without fear of damaging the live site.
Statement of Requirements
A Statement of Requirements (SOR) should form the basis for agreeing to undertake
a project for the Redbourne system. The client and the integration partner should
work together to agree this as part of negotiating the design contract. The
following list highlights some of the things that should be considered upfront
in any successful application development. Note that this is not an exhaustive
- The business requirements for the application. Why does the
client want a web application - what is the perceived business
benefit. If this is unclear there is a good chance that the application
will be perceived as deficient by the client.
- Required performance, availability and anticipated traffic load/visitor load as
- Data Maintenance. The application may be fed from external data - for example
an existing client database. How is that data going to be transferred and
who has responsibility for the transfer. Has the Client understood the internal
business processes that may need to change.
- Security Requirements. What are the clients expectations? Is a secure site
appropriate, or an insecure site with authenticated access, or an open site?
- Understanding of both the 'public' interface to the application and
any (hidden from public view), management interface requirements.
- Expected/required timescales.
- Delivery phases. Ideally it is a good idea if a web application development can be
delivered in phases. Both the client and the partner can benefit from a
phased approach: The client by having an active web application faster; The
partner by proving the application, and their reputation with their client.
Only once the requirements are clearly defined should serious work begin on the
In the static design phase concentrates on the basic model for the application,
the result being a set of functional specifications for the site that should
be reviewed by the client. In practice this phase is very close to that which
would be produced for a static website.
This design aims to answer the following questions:
- The overall look and feel for the site.
- The top level 'site-map', how are end-users going to
navigate around the site?
- The security model for the site. Which elements of the site
are going to be protected, and how?
This phase should result in the following items being completed:
Look and Feel
Agreed look and feel for the site. Generally a common look and feel
across all the pages in the site leads to a stronger site and can
enhance and reinforce a companies image.
- Does the client have an existing corporate look and feel? Can that be integrated
into the web design?
- What company images are to be used?
- What is the overall navigation mechanism for the site?
- Will any pages need to be made printer-friendly?
Administration and User Interface
All but a trivial site will require different facilities for different users.
The clearest example of this would be the public pages seen by users and a set
of 'private' pages used by clients to update things like catalogue data. More
sophisticated sites still may have more classes of user. Bear in mind the requirements
of, and facilities required by, each class of user. (If you look at the sample
applications you will see many of them documented in two parts, the administration
part often has two classes of user. The "user administrator" is allowed
to manage users, the "site adminitrator" is allowed to managed, for
eample, site catalogue contents.)
It can be easy to forget about the management requirements for a site by concentrating
overly on the external look and feel of a site, but in cases the management
interface can be the most difficult to produce. From an integration partners
point of view - if the management interface is deficient the client is going
to rely on the partner to make up for those deficiencies. This will use up valuable
resources at the integration partner.
Ideally the integration partner should aim to make the site as manageable by
the client as possible - ideally with no intervention for from the Partner.
Consider the Redbourne site as an example of this. The Site
Management Application allows our clients - the integration partners
- to manage their area of the site with minimal intervention from us.
What is the layout for the site? Which pages will exist and how are they
related to one another in a formal menu structure. The designer must consider
the need for easy and rapid access the information required by the user.
If the information is not easy to locate the user will get frustrated and
may seek and alternative - which could be a competitor!
What, if any, are going the be the external links from the site.
The overall site map should be produced and reviewed by the client. There is
currently no standard way of describing a web site and so Redbourne have produced
a graphical documentation nomenclature
that may be used.
Example Site Map - taken from one of our example applications
Static web pages utilising the proposed look and feel of the site. Use this
in conjunction with your client to test usability, look and feel etc. Make a
few links active on the navigation menu so that the Client can get a feel for
Dynamic or Active Design
The basic application look and feel has now been determined, as have the pages
that need to be produced. Now it is necessary top translate the design and the
demonstration pages into a real web application. The following things should
be considered when developing the application:
Common Look and Feel
The static design agreed a basic look and feel for the site, and probably agreed
a single style to be applied to most, if not all pages within the site. When
considering the site implementation investigate whether some or all of this
look and feel can be encapsulated in a single file - to be included at the top
of each page in the application. This has the following advantages:
- The look and feel can be forced onto all pages - no opportunities for it
to evolve so some of the later pages look subtly different from the earlier
ones. If the look and feel evolves then the changes apply to all pages - no
need to revisit all pages at the end.
- Corporate images change. Companies change there logos, their names. If that
information can be encapsulated in one place then the a new look can be rolled
out over an entire site very quickly.
- If menus and other top level elements are defined in one place testing is
much easier - test the look and feel on a single page and be pretty sure it'll
The Redbourne system incorporates some very powerful mechanisms (using include
files and XML processing) that make it very easy to produce a "wrapping"
for main page content. The page that you are currently looking at is designed
as an HTML document with no left hand or top border, just a plain page the only
addition being a single
/> tag at the top. The borders and menus were generated by the Redbourne
system based on the content of the defaultstyle.inc file when you requested the
page. See the sample applications section
where the source code is available and its operation is is explained in detail.
Decide how the features required by the application are going to be mapped to
the services offered by the Redbourne system. Obviously you will have some idea of
this in-order to agree the specification of the application. This is now the addition
of detail - and may require you to revisit the static as well.
Data Storage/Session Data
Most web applications need to store some context sensitive information. Part of
the dynamic design is to decide where and how that information will be stored. Some of
the options are:
|Client Side Cookie||Limited data - can be deleted.|
|Redbourne Session||Space not a problem - data lost at end of session|
|Contact Template||If people have to register with your application
then you can store information - such as preferences - against that
users record in the Contact Template.
This option provides the most reliable solution.|
For a discussion of these options see the 'Tracking
User Sessions' technical note.
At some point during the development of the web application it will be necessary
to test it on the Redbourne system. Redbourne provides a completely separate
'test' virtual web server for each registered client. The basic process is to
load the application into the test site, run tests against it until both the
integration partner and the client are satisfied and then to 'make the site
Redbourne supplies a Site Management Application
that co-ordinates the management of most data centre activities in a logical
and secure manner. This application provides integration partners with
the ability to upload applications to a
In practice the design and test phases are closely linked. It is usually best
to get a part of the site running at a time and have an iterative approach to the
implementation. You need to design the site as a whole - but then implement small parts
at a time.
Client Acceptance Testing
As well as the the designer being happy - the client has to be happy. The
best way to achieve this is to involve them in reviewing the application
at each stage. Finally - before the site can go live - the client should
agree that it meets his requirements. If there have been frequent
demonstrations and reviews then this should be a formality! The client
can access the test site on a special Redbourne test URL.
When the client is happy with the site - it is ready to be released.
Activating the Application
The final action is to promote the application from the test
environment to the production or live environment. Once again
using the Site Management Application,
that has a 'Make Live' facility.
Once the site is live the integration partner can go back to phase 2 of a staged
project, or enhance/fix the existing site using the test site. No changes to
the test side, or the data maintained by the test site, has any effect on the
To make the testing even more representative of the final site
the Site Management Application also has a facility to make a copy of the "live"
data available in the test site.