Copyright ACM, 2000

Prototyping Web Applications

Mario Bochicchio, Roberto Paiano

SET-Lab, Software Engineering and Telemedia Laboratory

Department of Innovation Engineering, University of Lecce, Italy

tel. +39 0832 320216, +39 0832 320296

Email:{bomal, rpaiano}



Design of large WWW sites can be a very complex task if not supported by a suitable theoretical model. A good structural design model, in fact, is able to precisely define the information structures of this kind of multimedia applications and the related navigation patterns. Moreover, through a good design model the designer is able to precisely formulate his/her ideas, discuss them and revise them, without actually starting any implementation.

The modeling activity necessarily implies rough initial ideas, revisions, versions, etc. For these reasons a design-supporting environment, allowing the modeler to be effective and precise, is essential.

Moreover the site prototyping, starting from the structural design model, is very helpful for at least three reasons: non-expert "readers" can't fully grasp what the designed application is about, unless they can see it. The second reason is that even expert designer, once the design is pretty mature, may need to visualize the outcome of the design itself, before going to actual implementation. The third reason is that "visual designers" need also to step in their own idea, to develop it and try it, before completing the design process.

In this paper we do not discuss design models, which are a research field on its own. The paper discusses, instead, a design/prototyping environment and presents the relevant features of JWeb, a design/prototyping environment being developed as a joint effort from Politecnico di Milano and Università di Lecce, in Italy.


Hypermedia Design Model, prototyping of Web applications.


The design of Hypermedia application has been a concern since the very beginning of the development of Hypertext. In fact the focus of research was more, at the beginning, on the authoring environments, rather than on the conceptual aspects of design.

The Dexter Model [13], HyDev [24], HyTime [22], AHM [14-16], SMIL [17], HDM [6-11,25] and other models, took into serious consideration the conceptual problem of designing complex hypermedia applications, borrowing many concepts from Data Base Design and introducing concepts specific to hypermedia modeling.

As "side effect", since the very beginning it was clear that, with a good design model at hand, a number of activities can be supported and automated. Following this idea, several projects, such as HYTEA[18], MINERS [21] and HIFI [20], have built up supporting systems. More recent projects, such as CMIF [16], RMM [19], Autoweb [5] and Araneus [20], have a similar goal. One feature common to all the above projects is that they blend together design and development environment. In other words the design support is conceived and implemented as part of a larger environment, aiming at the actual development of the application. The underlying goal is to speed up the development process, and this is particularly relevant when large amount of (more or less) rapidly changing information must be managed, and therefore a supporting database is needed.

In the following of the paper the main concern is the definition of JWeb, an environment to support design and prototyping of complex WWW sites.

It is not the purpose of this paper to discuss the specific aspects of each model, but, in our opinion, HDM [6-11], OOHDM [25], RMM [19], HDMlite [5], Araneus [20] and other similar models, based on the separation of the structural and navigational aspects from the visual aspects, are particularly effective and expressive. Among others, HDM is very well documented referring to a number of complex projects, such as HYTEA[18], MINERS [21] and HIFI [4], all of them partially funded by the European Commission.

For these reasons HDM is the model we selected for the implementation of JWeb.

Referring to the previous HDM-based projects [4,18,21], JWeb is innovative for two main reasons: it is reusable over different application fields and it supports the complete range of HDM primitives and constructs, so that high quality visual interfaces based on sophisticated HDM features can be implemented.

The general guidelines on which JWeb is based are described illustrated in section 2. In section 3 we describe the main features and the overall architecture of the development part of JWeb; in section 4 we examine the runtime engine for the dynamic page generation; in section 5 we shortly examine an application for which JWeb is currently being used; in section 6 conclusions and future work are described; in section 7, finally, the bibliography is presented.

2. Automatic implementation and design/prototyping: general problems

Since the development of WWW technology, the goal of improving the development process has become more and more relevant, therefore it is understandable why all the above projects aimed, and still aim, at tackling the actual implementation aspects. In this paper, however, we advocate the advantage of having tools to support just design and prototyping, leaving aside, for a while, implementation issues (with the term "prototyping" we mean a fast, cheap and reliable development of a mockup of the final application).

There are several reasons why an environment supporting design/prototyping, and not necessarily implying implementation, is useful:

  1. Support in the early stage
  2. Design needs to be checked, tested, discussed and revised several times before it is completed. Design must therefore be supported in an early stage of the development, when several details are still unclear or missing. Actual development, instead, requires all the design details to be laid down.

  3. Multidelivery
  4. More and more it happens that the same content must be delivered in several different ways: off-line, on-line, with different levels of depth and completeness, etc. If this is the situation, it is clear that design must be completed independently from any implementation, that, afterward, can proceed in several different ways.

  5. Technological flexibility
  6. More and more delivery environments for the web are emerging; mostly for the multimedia aspects, for the graphic, for the interface etc, so that new possibilities are open every day. Given this situation having to choose a specific delivery environment, or be cut out from new exciting possibilities, as it would inevitably happen in a full scale development environment, is not advisable. In addition many (large) organizations have specific delivery constraints, obliging the implementation to choose not the best possible technology (assuming that such a dream exists), but rather a technology compatible with their organization, compatible with their Information System, compatible with previously chosen technologies, compatible with their cultural background, etc.

  7. Design advanced options
  8. Sophisticated applications requires advanced design features, for which fully automated implementation could not be devised. It would be negative to not include those features in the design, just because automatic implementation could not support them.

  9. Design incompleteness
  10. For advanced applications, there are specific features, which can't be described by even the best design model. These features are therefore not modeled in the schema, but they are rather described through words, diagrams and ad-hoc means. It is clear that these features will be left out by any automatic implementation based on the design model.

  11. Visual Communication bandwidth

One of the biggest problems for deriving an actual implementation from a design, is the need to implement, for sophisticated applications, high visual communication bandwidth, consisting of complex graphical objects, special effect, animations, local interactions, etc. These advanced communication features can be (relatively) easily implemented with modern graphic interface tools, but they are hard to be automatically derived from design.

Finally, we believe that fast prototyping is an additional important feature of a design environment; fast prototyping means that the application somehow gets implemented, more or less directly from design, but in a fashion not binding for the final implementation, and not necessarily in an efficient manner.

3. The features and the overall architecture of JWeb

Before describing the actual architecture of the JWeb design and prototyping environment, a few words about the design model and the methodology are needed.

In a nutshell, the HDM methodology [23] requires that after a requirement analysis, a schema of the application is defined. The schema is organized in two different parts: the hyperbase schema describes the basic navigational capabilities offered by the application, while the access schema describes the organizations of the access structures (collections in the HDM terminology).

An hyperbase schema is organized into entity types, defining the structure of the objects managed by the application, and link types, defining the basic navigation capabilities.

An access schema defines, instead, the basic indexes (possibly hierarchically organized), guided tours, etc., that allow one to start browsing within the application.

Both for the hyperbase schema and the access schema there is a sharp distinction between design in-the-large, where the general features of the design are defined, and design in-the-small, where the details are provided. This distinction is useful in methodological sense for a number of different reasons [7,8], and also it plays an important role in terms of shaping up the supporting environment.

The hyperbase schema, on its own, can be examined, discussed and revised. Moreover, starting from this schema, it is possible to develop a sample of actual data, to "visualize" the outcome of the design being developed.

At this stage different options are possible:

The combination of the different options actually defines a number of different scenarios; we are convinced that an effective supporting environment should not enforce a specific way of proceeding, assuming that the "best practice" exists, but rather it should allows a great level of flexibility. It is our experience, in fact, that in different situations, for different projects, we have used different strategies and different tactics.

The JWeb system is a design environment with fast prototyping capabilities, based upon the HDM methodology, with the following features:

The overall picture of JWeb is shown in Fig. 1.

The overall environment is modular and flexible. The designer, therefore, does not need to use all the available features. If the different design alternatives are not needed, the Configurator (JWXdef) does not need to be used.

One of the relevant features of the JWeb environment, in order to keep modular and flexible, is that all the exchange of information among the different tools is based upon XML [26]. XML is used to exchange schemas, parameters and also instance data. This technical choice allows a very easy strategy of enhancement, addition, substitution or replacement of all the different tools. It could be also envisioned the exchange of information (export and import) with other design and development environments.

From the technical point of view, JWEdit, the JWData, the JWFeed, the JWXdef and JWXport has been designed using UML[3]. They share the same internal structure and the same classes: the main class, named Project, manages data structure and the user interface. The principal inner class of Project is ProjectElement, that represents the abstract HDM design element, while a number of concrete classes: Entity, Application Link, Access Structure, Collection etc., implement each specific modeling elements. The XML parser is another important inner class of Project, common to the various tools, it is able to parse and to select the XML structures defined in the HDM DTD, extracting the parameters related to the various tags; moreover it performs the validation of the current XML model. The development of the various components was performed in Java.

4. The runtime solution of JWeb and the design "in-the-small"

Figure 2 shows the runtime structure of the prototyping part of JWeb. The runtime support basically consists of an HDM Interpreter able to perform the dynamic page generation. The heart of the system is the Main Server Engine (MSE), a JAVA Servlet application, that support the interaction between client and server. MSE communicates with Navigation Engine (NE) that supports the in-the-large navigation through the application described by the Schema. At each user request the NE performs the evaluation of the "next step" of the navigation, as a function of the "current step", by applying the HDM navigation rules to the Schema.

The DB Engine (DBE) implements the unified interface of the HDM Interpreter toward the DBMS. It is responsible to send the right SQL commands to the DBMS, to get the results, and to format them for the required purpose. It sends the results to MSE in XML format.

After the NE has decided the needed slots (information items), and DBE has retrieved they them from the Hyperbase, the MSE arranges them according to the proper layout template (retrieved from the Layout repository), using the Layout Class Library (LCL)

The client-side part of the HDM Interpreter is subdivided into three more components: the Event Manager has the role to capture the user input transforming it in a request suitable for the NE; the Session Manager controls the session parameters (language, sound volume, skill level, ...); the History Manager performs the recording of a user session, to support the history navigation. Moreover it implements a simple form of "second level authoring" [12] based on the "history editing".


Figure 2 - JWeb: internal structure

According to the HDM model, the design in-the-small provides the detailed description of the media objects (slots in HDM terminology) in the hyperbase. Each slot could be as simple as a number or a string, or could be a scrolling text, a video, a number of still pictures synchronized with an audio, an animation, etc. Slots can be combined into aggregates (frames, in the HDM terminology) and sub-aggregates.

Given this situation, two prototyping approaches are possible:

The first approach, adopted by Autoweb [5], Araneus [20] and RMM [19], is more accurate in terms of information modeling, but it suffers of from a number of drawbacks:

  1. The multimedia items can't be actually stored in the database, since no DBMS actually supports all the needed technologies; therefore the actual pieces of content are stored in separate files, and the Data Base records only stores the "names" of those files.
  2. Arranging the multimedia items in an ergonomic, appealing, usable interface is a difficult job that very often requires the use of ad-hoc tools. In addition, for the uses envisioned by JWeb, specific precise decisions about the interface are premature (it may take a long time before completing the interface design for high quality applications).
  3. In order to keep the same design valid across similar applications (e.g. the same catalogue structure for different companies of the same business sector), the details should not be modeled.
  4. The detailed design of nodes is not performed by the same people doing the "in the large" structuring of hyperbase. While information designers take upon the second job, the first job, on the details of the content and upon the interface organization, requires "content specialist" and also graphic designers.

For all the above reason JWeb has decided to clearly separate the implementation of what there is within a node (in-the-small) from the overall organization of the nodes and the navigation across them (in-the-large). JWeb provides, therefore, two options for the designer:

This option is good for testing the design in-the-large, without bothering with the specification of the detailed information.

In technical terms a node, treated by the HDM-interpreter [2] as a single piece of information can be implemented with different technologies: e.g. an HTML page, a Java applet, a Shockwave page, XSL, etc.

For the time being we have focused upon Shockwave10, that easily ensures an excellent control over the interface and also an excellent control over multimedia items. It should be noted, however, that the HDM-interpreter is basically independent from the technology used for the node implementation, allowing therefore a great deal of flexibility.

Our choice of using Shockwave pages as visual representative of the application nodes allows the designers, if they wish to do so, to try in the prototype very high quality visual interaction. If they do not wish, instead, they may use very simplified layout (that can in fact be automatically derived from model description).

This approach is quite in contrast with the approach taken by most of the environment supporting full development: they oblige the designer to go through a precise phase of visual design (in order to fit all the details in), somehow competing with the facilities offered by advanced tools for interface design.

5. An Example Application: "Casual Ware"

One of the projects where JWeb is actually being used is "Casual Ware", a joint effort of a number of different fashion manufacturing companies, in cooperation with University of Lecce and Politecnico of Milan. The ultimate goal is to create a Web environment to support marketing and sales of items such as jeans, pants, T-shirts, shirts, accessories, etc.

The second goal is to offer a family of catalogs, based on Web technology, of the items being offered. The catalogs can be distributed off-line (as a CD-ROM, or DVD-ROM), via Extranet (to points of sales) or via Internet (for final users).

Different companies could choose different distribution strategies, and also each company may choose different strategies for different tasks.


Our approach to the problem has been to develop a basic Hyperbase schema and a number of initial access structures; for different tasks the company will develop, using the JWXdef, different versions of the basic schema. The same thing will happen for the other companies, that will use the catalogue.

The starting design in the large is shown in Fig.3, more details about the application can be found in [1].

Figure 3 - "Casual Ware": Hyperbase in the large


The HDM schema of the application consists of seven Entity types: Model, Style, Fabric, Article, Fit, Accessories and: Size Table. The links Model-Fabric and Model-Article are the most important ones, since each model is realized using various specific fabrics and various colors, that a customer could chooses by following this links. The main access structures, initially devised for the application, are:


Figure 4 - Model BRICO: prototyping layout

Figure 4 shows a sample of functional layout, directly derived from the model, just to verify the overall soundness and effectiveness of the model. Marketing experts and layout designers, from the involved company, have defined, in parallel, information details and a proper visual interface shown in Fig.5.

The prototyping of "Casual Ware" is completed (at end of March 99) with the definitive data using the final layout.

Figure 5 - Model BRICO: final layout


6. Conclusions and future work

In this paper we have tried to put forward the following argumentation:

In conceptual terms the following improvements are needed to JWeb:

As far as the implementation is concerned, a number of improvements are foreseen:

In terms of uses, although we advocate prototyping, rather than automatic application development, in a number of cases we have been asked to use the prototype as initial version of the application, to be worked on, in order to build up the final version. We accept the fact that, in simple cases, the prototype could be used as an implementation platform.

7. References

[1] Bochicchio M.A., Paiano R. and Paolini P., "JWeb: an HDM Environment for fast Development of Web Applications", Proceedings of IEEE Conference on Multimedia Computing and Systems 1999 (ICMCS '99, Firenze, Italy), 2, 809-813.

[2] Bochicchio M. A. and Paolini P., "An HDM Interpreter for On-Line Tutorials", Proceedings of MultiMedia Modeling 1998 (MMM '98,Ed. N. Magnenat-Thalmann and D. Thalman, IEEE Comp. Soc, Losanne 1998), 184-190.

[3] Booch G., Rumbaugh J. and Jacobson I., "UML User Guide", Addison Wesley, 1999.

[4] Cavallaro U., Garzotto F., Paolini P. and Totaro D., "HIFI: Hypertext Interface for Information Systems", IEEE Software 10, 6 (Nov. 1993), 48-51.

[5] Fraternali P. and Paolini P., "The Autoweb System", submitted for publication (

[6] Fraternali P. and Paolini P., "A Conceptual Model and a Tool Environment for Developing More Scalable, Dynamic, and Customizable Web Applications", EDBT 1998: 421-435.

[7] Garzotto F., Paolini P. and Schwabe D., "HDM - A Model Based Approach to Hypermedia Application Design", ACM Transactions on Information Systems, 11, 1 (Jan. '93), 1-26.

[8] Garzotto F., Mainetti L. and Paolini P., "Hypermedia Application Design: A Structured Approach", In J.W.Schuler, N.Hannemann and N.Streitz Eds., "Designing User Interfaces for Hypermedia", Springer Verlag, 1995.

[9] Garzotto F., Mainetti L., Paolini P., "Adding Multimedia Collections to the Dexter Model", ECHT 1994: 70-80.

[10] Garzotto F., Mainetti L. and Paolini P., "Navigation in Hypermedia Applications: Modeling and Semantics", Journal of Organizational Computing, in press.

[11] Garzotto F., Mainetti L. and Paolini P., "Designing Modal Hypermedia Applications", Hypertext 1997: 38-47.

[12] Garzotto F., Mainetti L. and Paolini P., "Information Reuse in Hypermedia Applications", Proc. HT'96- ACM International Conference on Hypermedia, Boston (Ma, USA), March 1996, ACM Press.

[13] Halasz F. and Swartz M., "The Dexter Hypertext reference Model", Communications of ACM 37, 2 Feb. 1994.

[14] Hardman L., "Modeling and Authoring Hypermediali Documents", PhD Thesis, Amsterdam, 1998.

[15] Hardman L., Bulterman D. and van Rossum G., "The Amsterdam Hypermediali Model: Extending Hypertext to Support Real Multimedia", Hypermedia Journal 5(1), July '93, 47-69.

[16] Hardman L., Bulterman D. and van Rossum G., "Authoring Multimedia in the CMIF environment", Visual presentation at InterCHI '93, Apr. '93.

[17] Hoschaka P., "Synchronized Multimedia Integration Language 1.0 Spec.", W3C Recommendation 15 June '98.

[18] Hytea Projects reports, available from Politecnico di Milano ( and from Siemens corporate research center (Munich, Germany).

[19] Isakowitz T., Stohr E.A. and Balasubramanian P.: "RMM: a methodology for structured hypermedia design", Communications of the ACM 38 (8), Aug. 1995, 33-44.

[20] Mecca G., Atzeni P., Masci A., Merialdo P., Sindoni G.: "The Araneus Web-Base Management System", SIGMOD Conference 1998. Pp. 544-546.

[21] MINERS Projects reports, available from Politecnico di Milano ( and from EDS-Italy Corporate Research Center (Rome, Italy).

[22] Newcomb S.R., Kipp N.A. and Newcomb V.T., "HyTime: The Hypermedia/Time based Document Structuring Language", Communications of ACM, 34(11), 67-83, 1991.

[23] Paolini P., "Lectures Notes on Hypermedia Design", unpublished (

[24] Pausen P. and Voss J., "The HyDev Approach to Model Based Development of Hypermedia Applications", 1st International Workshop on Hypermedia Development, held in conjunction with ACM Hypertext '98.

[25] Rossi G. and Schwabe D., "The Object-Oriented Hypermedia Design Model", Communications of the ACM, 38(8), 45-46.

[26] XML Spec.,


Copyright 2000 ACM

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and or fee.
SAC 2000 March 19-21 Como, Italy
(c) 2000 ACM 1-58113-239-5/00/003>...>$5.00