Recent Advances in Information Science and Technology

Nikos E. Mastorakis (Editor)

World Scientific, Athens, Greece 1998

The specification of dynamic behaviour in Web page design

José Bulas-Cruz (*), Leonel Morgado (*), Luís Barbosa (*), Arsénio Reis (*),

João Barroso(*), Pedro Melo-Pinto (*) and Pedro Henriques (**)

 

(*) Projecto GeIRA, University of Trás-os-Montes e Alto Douro

Apt. 202, 5001 Vila Real Codex

Tel (059) 320356   Fax (059) 320480

(**) Projecto GeIRA, University of Minho

Campus de Gualtar, 4710 Braga

Tel (053) 604140   Fax (053) 612251

 

The development of a large number of Web pages, under the GeIRA project, requires co-operation between designers and Web page developers. A mixed team is usually the best option: designers and Web-page developers working together. This may produce a synergetic effect, using the best of both worlds. However, all the information regarding behaviour, related with the variable dimensions of a page, is absent from a traditional design, which relies on fixed dimensions. This results in problems for the implementation team, that should be detected and corrected at an earlier stage.

This paper presents a model for the description of the dynamical behaviour of Web pages. This approach minimises the occurrence of errors, saving time and resources in the development process. The model lays a common ground between designers and computer experts, allowing for the development of tools that support the site development process. These tools will speed up the development process, ensure greater quality, and introduce an element of clarification of the design specifications.

A specification language and a layout tool are being developed under this model. The layout tool will provide a designer with the means to graphically implement several page elements, and at the same time see how these elements are positioned in the page for different page dimensions.

Overall, the improved communication between designers and developers results in a Web-site creation process that is more efficient, flexible and economical.

1         Introduction

Several organisations in Northern Portugal, namely those related to archaeology, museums, libraries/archives, and universities/research organisations, are joining efforts to promote their activities using interactive and multimedia technologies. The GeIRA project (URL: http://www.geira.pt/) aims the support and integration of these activities, and includes a multidisciplinary research team. The research team integrates designers, multimedia technicians and computer experts.

The development of Web sites that wish to draw the interest of the Internet community requires an attractive design. Traditional designers, while highly skilled on conventional technologies (printed media), lack the technical expertise to efficiently implement their designs as Web pages and to maintain and manage the graphical aspects of a Web site. Increasingly complex database and geographical information-driven Web sites emphasise this aspect.

In view of the fact that the design team faces a set of different problems from those that the implementation team has to deal with, the GeIRA project adopted a pipeline organisation, as illustrated by Figure 1. This organisation enables co-operation between the designers and the site developers, providing as well an extra degree of autonomy for each group (the specific decisions of each group are less affected by the others).

An alternative organisation is proposed by the Cnet online magazine [GORMAN 1997]. Their solution is based on allocation of a job to a team of two persons: a designer and a computer expert. This solution requires design and development to work concurrently in the same Web page, which is not one of the options available to our teams. This solution seems to be generally well suited for small projects. But it is our belief that it is difficult to adopt in an environment where professionals must share their time through several distinct projects, due to the permanent assignment of two resources to one task.

Figure 1: Web-site development pipeline

The proposed solution for the GeIRA project enables the design to be relatively independent from the information sources, leading to a higher flexibility in the sequence of tasks that have to be completed. This pipeline organisation can be used for individual pages or smaller sections of a Web site, as well as for the complete project of a large Web site. This scalability is well adapted to the nature of the GeIRA project.

A closer look at Figure 1 shows the various tasks, by stages. The output of stage 1 is a site specification for use by the developers and the designers. Depending on the available resources, such output can be one single document or two separate ones, one emphasising the graphical aspects and the other focusing on the organisation of information.

At stages 2 and 3, both teams are working without formal communication and they can share their time and effort by the various projects underway. The output of stage 2 is a graphical design specification, while the output of stage 3 is a working Web site, without graphic design concerns.

At stage 4, the graphical design devised by the designers is applied to the Web site.

At stage 5, the designers check the resulting Web site, searching for possible design misunderstandings and faulty graphical elements.

Stage 6 is the clean-up phase. Any errors detected at stage 5, such as unreadable portions of text, are corrected at this stage. The final Web site is then ready at stage 7.

The circle in Figure 1 marks the point where formal communication between the designers and the developers first takes place. Improving communication support at this stage results in a smaller list of corrections as the output of stage 5. Since the communication is clearer, the probability of corrections being so serious as to impact the overall site structure is considerably diminished. This results in a faster and easier Web site development cycle.

The paper is organized as follows. Next section describes the proposed model and presents the model organization in an object oriented methodology. Section 3 is concerned with the support tools under development, namely a descriptive language and a layout tool. Finally, section .4 presents the conclusions.

2         Support for dynamic behaviour in the design phase

2.1        The conceptual Web page model

In order to clarify the interface between designers and developers, a conceptual Web page model has been devised, providing the design team with the means to specify the design of the page. This includes a specification for given page dimensions (the most common approach) and, having this design as a starting point, the specification of the dynamic behaviour of the page, i.e., how should objects change their position as the dimensions vary.

Since the positioning of an element in a Web page, when the viewing window changes dimensions, depends only on the current dimensions of the Web browser's viewing window, there are no other events or changing conditions to address. Therefore, the model is purely descriptive, i.e., it must define positioning rules for the Web page's elements.

Figure 2: Specifying the dynamic behaviour of a Web page

The basic idea is that given a starting element arrangement (static description), the designers need to specify the distances between the several page elements and between those elements and the borders of the page. These distances can be seen as fixed links (wires) whose length does not change with the dimensions of the viewing window; or as variable links (springs) whose length depends on the current viewing window dimensions.

In order to allow the designer to specify alignments, the concept of a ruler was incorporated in the model. A ruler is an invisible object, which can be used to define the position of other objects. This idea is similar to the traditional ruler in graphic design, being therefore intuitive for design professionals.

Figure 2 illustrates these concepts. Solid lines represent fixed-length links (wires); dashed lines represent variable-length links (springs). The thicker lines are rulers. Looking at the figure, it is easy to see that "Logo", "Site Name" and "Picture" are top-aligned. Some other conclusions, however, can only be drawn from a scheme of this kind: for instance, it can be seen that "Current Page" can move left, if the page width diminishes, but only as far as to reach the right border of "Logo". This kind of dynamic constraint involves the entire page structure, and its assessment is very important in avoiding major page restructuring later on. Another example is the link between "Picture" and "Current Page", indicating that the distance between these two elements is fixed (does not change with the dimensions of the page).

2.2        Model description

The model represents the result of an object-oriented analysis process [BOOCH 1994; COX 1986; MEYER 1988; WEGNER 1990; WIRSF‑BROCK 1989]. The positioning of the elements of a generic Web page, and its dynamic behaviour, are modelled using the OMT methodology proposed by Rumbaugh et al [RUMBAUGH 1991].

Under the proposed model, a Web page is a set of elements connected by links that can have fixed or variable length. The variable links allow for the dynamic behaviour of the page elements.

There are displayable elements called bricks, reference elements called rulers and links. Brick and ruler objects are connected by links, and are called fabrics. Each fabric is associated with two link objects, which represent its width and height attributes.

A brick can represent any visible page element, i. e., an image, a text block or an undefined area to be clarified on a later development phase. The bricks can be laid out on a page with the aid of placement rulers, which are non-visible objects with no other purpose beyond acting as references for brick placement.

Rulers and bricks are connected by means of links, which are (just like the rulers) non-visible objects which act as references for brick placement. A link can have fixed or variable length. For clarity, the adopted analogy for those two types of links is one of wires and springs, respectively.

A page has at least four rulers, one representing each border. But there is no upper limit to the number of rulers present on a page. It contains also at least two springs, which determine the page dimensions: one between the top and bottom borders, another between the left and right borders.

Figure 3: Sketch of the object model, following the OMT methodology

3         Support tools

3.1        A descriptive language

The proposed model can be implemented by use of an adequate language. The purpose of such a language is therefore that of the model, i.e., to accurately describe the behaviour of the elements on a Web page.

An automated interpreter for the language can be developed, for syntax and error checking. Such an interpreter can also perform other actions, such as automatic completion of the human specification. But even considering only the human specification, a page description using this language can be used as a companion document to a page's graphic design. The information forwarded to the developers in this way isn't as complete and error-free as it would be if processed by computer tools. Nonetheless, the human specification is a useful on-the-job implementation of this model, which fulfils the model's main objective: to convey clarification regarding the dynamic behaviour of a page's elements.

Each declaration produces an instantiation of one of the model's classes, with adequate properties.

The language is composed entirely by entity declarations; i.e., it has no command statements. This reflects the fact that there are no events to be processed, only objects to be instantiated.

The syntax of the proposed language, is partially described using Backus-Naur Form (BNF) rules:

Statement ::= ClassName InstanceName {Attribute}0+ | Comentary

 

Comentary ::= '//' {letter | digit | space}0+

 

ClassName ::=     'PAGE' | 'BRICK' | 'IMAGE' | 'TEXTBOX'

| 'WIRE' | 'SPRING' | 'RULER'

 

InstanceName ::=  {letter} {letter | digit}1+

| '“'{letter} {letter | digit | space}1+ '“'

 

At the time of writing, each Attribute has no identification keyword and is composed entirely by its value. All Attributes must be specified, i.e., there are no optional properties. If a given Attribute is an object, that object must be defined in another statement, and is referred to by its InstanceName. The language is case sensitive, and the keywords of the language are written in uppercase.


Keywords

Attributes

Name

Data Type

PAGE

Id

String

 

Top Border

Ruler Id

Left Border

Ruler Id

Right Border

Ruler Id

Bottom Border

Ruler Id

Left-to-Right Link

Link Id

Top-to-Bottom Link

Link Id

Path Priority

One of:
Horizontal
Vertical
None

Background

#nnnnnn

Representing the colour's RGB components in hex format.

BRICK

Id

String

Width Link

Link Id

Height Link

Link Id

IMAGE

Id

String

Width Link

Link Id

Height Link

Link Id

Image To Display

Filename

TEXTBOX

Id

String

Width Link

Link Id

Height Link

Link Id

Text To Display

String

Text Alignment

One of:
Left
Right
Centre

Background Colour

#nnnnnn

WIRE

Id

String

Orientation

One of:
Horizontal
Vertical

Reference Length

Integer

Minimum Length

Integer

Source Anchor

Fabric Id

Target Anchor

Fabric Id

SPRING

Id

String

Orientation

One of:
Horizontal
Vertical

Reference Length

Integer

Minimum Length

Integer

Source Anchor

Fabric Id

Target Anchor

Fabric Id

RULER

Id

String

Width Link

Link Id

Height Link

Link Id

Orientation

One of:
Horizontal
Vertical

Figure 4: Keyword list

The language uses the keyword list shown in Figure 4. The list is extensive, assigning to each keyword (ClassName) the Attributes of its associated class and its superclass. The notation used follows the rule: "link id" means that either a wire id or a spring id can be used, and "fabric id" means that either a brick id or a ruler id can be used.

A piece of code illustrating the use of the language follows. The code has been commented for easier understanding. It contains a partial description of the dynamic behaviour of the Web page shown on Figure 2.

//Begin

//Page definition

PAGE Page1 TopBorder LeftBorder RightBorder BottomBorder PageWidth PageHeight None #FFFFFF

//Definition of the rulers that act as page borders

RULER TopBorder TBWidth TBHeight Horizontal

RULER BottomBorder BBWidth BBHeight Horizontal

RULER LeftBorder LBWidth LFHeight Vertical

RULER RightBorder RBWidth RBHeight Vertical

//Page border rulers' width and height links

//The right border's attributes are identical to the left border's; and the bottom border's attributes are identical to the top border's. Therefore, the right and bottom borders can be defined by a computer parser, and are not required in a human specification

SPRING TBWidth Horizontal 630 0 TopBorder TopBorder

SPRING LBHeight Vertical 300 0 LeftBorder LeftBorder

//Links between the page borders, setting the page's dimensions

SPRING PageWidth Horizontal 630 0 LeftBorder RightBorder

SPRING PageHeight Vertical 300 0 TopBorder BottomBorder

//One of the rulers present on figure 2

RULER LeftMargin LMWidth LMHeight Vertical

//Link for placement of the "LeftMargin" ruler

//The complete computer-parsed specification could automatically add two zero-length wires, linking the ruler to the top and bottom page borders; and also a spring linking the ruler to the right page border.

WIRE LMPosLeft Horizontal 10 10 LeftMargin LeftBorder

// One of the images present on figure 2

IMAGE Logo LogoW LogoH "Logo.jpg"

WIRE LogoW Horizontal 20 20 Logo Logo

WIRE LogoH Vertical 20 20 Logo Logo

//Links for placement of that image

//The "TopMargin" fabric is another ruler present on figure 3

WIRE LogoPosLeft Horizontal 0 0 Logo LeftMargin

WIRE LogoPosTop Vertical 0 0 Logo TopMargin

//Generic "Information Display Area", present on figure 2

BRICK InfoArea InfoAreaW InfoAreaH

SPRING InfoAreaW Horizontal 610 0 InfoArea InfoArea

SPRING InfoAreaH Vertical 200 0 InfoArea InfoArea

//Links for placement of that brick. The fabrics "Menu" and "RightMargin" are elements present on figure 2.

WIRE InfoAreaPosLeft Horizontal 0 0 InfoArea LeftMargin

WIRE InfoAreaPosTop Vertical 10 10 InfoArea Menu

WIRE InfoAreaPosRight Horizontal 0 0 InfoArea RightMargin

WIRE InfoAreaPosBottom Vertical 10 10 InfoArea BottomBorder

//End

 

3.2        A graphic implementation of the model

Another way of implementing the proposed model, and one that most designers are comfortable with, is to graphically define the behaviour of the page elements. A designer can draw symbolic lines between the elements of the page, or within the elements themselves to specify limits to movement, references or objects whose dimensions can vary. Colour coding can also be used to visually clarify the designer's intentions. An experimental graphic representation of the specification of a Web page is shown in Figure 5 (the original uses colour).

3.3        A layout tool

A prototype graphical layout tool is under development. It is based on the proposed model, and will allow designers to express page behaviour graphically, translating it into the description language, so that the page developers get a complete specification. The tool allows a designer to place elements on a page and specify links between them. The designer would then be able at any stage to experiment, changing the dimensions of the page, to see how the elements are positioned. This can reveal aspects of the design that were not anticipated, allowing for correction at the specification stage, with no page coding involved.

Figure 5: Graphic representation of the specification of a Web page.

4         Conclusions

The paper describes a model for specifying the dynamic behaviour of a Web page. The proposed model is being well accepted by the development teams. It is an efficient form of clarifying the communication between designers and developers, when developing Web pages.

The amount of structural errors at Web page development is a major variable regarding the length of a Web page's development cycle. Diminishing the number of errors shortens this time and therefore the associated cost of Web page development also diminishes.

The proposed change in perspective of Web page design methodology, that includes dynamic behaviour, will also hopefully allow for development of new tools and methods. It is believed that the fabric-and-link model presented here is adequate for the proposed objectives. It can be implemented in most commercial Web tools, particularly in the layout-oriented ones, such as NetObject's Fusion [FUSION 1997].

Acknowledgements

This work has been supported by the EC Programm Interreg II (contract number 02/REGII/6/96).

The authors would like to thank the cooperation and advice of Professors Pedro Henriques and Alberto Proença, from the University of Minho. They are also in debt to the colleagues at CI-UTAD for their support, cooperation and helpful suggestions.

References

[BOOCH 1994] BOOCH, G. Object Oriented Design with Applications, The Benjamin/Cummings Publishing Company. California. USA, 1994.

[COX 1986] COX, B. J.. Object-Oriented Programming: An Evolutionary Approach. Addison-Wesley. Reading (Mass.). USA, 1986.

[FUSION 1997] User Guide, Net Objects FUSION 2.0, NetObjects Inc., Redwood City, California, USA, 1997.

[GORMAN 1997] GORMAN, T., How CNET does it. URL site: http://www.cnet.com/, and URL document: http://www.cnet.com/Content/Builder/Business/HowCnet/?dd. Cnet, Inc., USA, 1997.

[MEYER 1988] MEYER, B.. Object‑Oriented Software Construction. Prentice‑Hall International (UK) Ltd. Hertfordshire. UK, 1988.

[RUMBAUGH 1991] RUMBAUGH, J., BLAHA M., PREMERLANI, W., EDDY F., LORENSEN, W.. Object Oriented‑Modelling and Design. Prentice‑Hall International Editions. New York. USA, 1991.

[WEGNER 1990] WEGNER, P.. Concepts and Paradigms of Object‑oriented Programming. Expansion of October 4 OOPSLA‑89 Keynote Talk. OOPS Messenger. Vol 1, Number 1, August 1990. ACM Press, 1990.

[WIRSF‑BROCK 1989] WIRSF‑BROCK, R. and WILKERSON, B.. Object‑Oriented Design: A Responsibility Driven Approach. OOPSLA‑89 Proceedings, Special Issue of Sigplan Notices, vol. 24, number 10, Oct. 1989, Addison‑Wesley, 1989.