Download Web Application Design: A Comprehensive Guide to Principles and Practices and more Schemes and Mind Maps Web Design and Development in PDF only on Docsity!
WEB APPLICATION DESIGN
3.1 Introduction
Web application developers should break down Web applications into three logical layers which, in turn, are split in two halves each by the same principle. We can separate the components (particularly Web nodes, i.e. media, Software components, databases access) from arrangements of the components in a mesh. The three logical layers are: (1) the presentation design, where we design the look and feel, and where multi-modal user interfaces come into play; (2) the interaction design, where we design the navigation by use of meshes, and the specific dialog by use of components; and (3) the functional design, which specifies the ―core‖ of our Web application.
To reflect this large number of different aspects in the design of Web applications, we will use Web application design subtasks, as shown in Figure 5-1. This is basically distinguishing the components of Web applications, i.e., the nodes and links that connect them, and their start and destination points within nodes ("anchors"), from the mesh consisting of such components, i.e., from the entire Web application.
In addition to the two-part structure mentioned above, Figure 5-1 shows a three-part layering, with a clear differentiation between presentation and interaction, similar to the Model-View-Controller (MVC) concept and to the way its large number of extensions distinguishes between view and controller. On the one hand, the presentation concerns the mesh, taking the node (the "cursor" on the way through the mesh; there might be several in parallel) currently visited by a user into account. On the other hand, the presentation of components, i.e., node contents, is a central design task; this early stage emphasizes the relevant characteristics of Web applications, particularly content-related characteristics, such as document character and multimodality, and presentation-related characteristics such as
3.2 Web Application Design
3.1.1 Basic elements of hypertext documents.
aesthetics and self-explanation. This means that it is important to involve experts (called media designers in this context) and coordinate them with other Web application developers (called engineers in this context).
The separation of meshes from components continues on the interaction level. Interaction within a mesh is normally referred to as navigation.
The design principle shown in Figure 5-1 requires an additional layer, referred to as functional design in the following discussion. A functional design document describes a software product's capabilities, appearance, and functions it needs to ultimately perform. Design documents are also referred to as functional specifications or functional specifications documents (FSDs), or functional requirements specifications.
3.2 Web Design from an Evolutionary Perspective
3.2.1 Information Design: An Authoring Activity
The beginning of the HTML era was exclusively focused on authoring. Only hypertext documents were supported, as the name of the so-called Web programming language, HTML, suggests: Hypertext Markup Language, a language for instructions - or tags - strewn throughout text documents. In the course of time, HTML supported other media: images, time-sensitive media, such as video and audio, etc., reflected in the term hypermedia, which is sometimes used to distinguish HTML from hypertext and sometimes synonymously to hypertext. We will use hypertext as a generic term in the following discussion.
The hypertext concept is older than HTML; its basic idea was formulated by Vannevar Bush as early as at the end of World War II in view of the emerging wealth of technical information carriers. Ted Nelson coined the term itself in the 1960s. Hypertext documents are composed of the following:
Nodes, links, and anchors and
Meshes and other aggregates.
Meshes designate coherent nodes and links, and were called hypertext documents in the era before the Web. Examples for aggregates include views (e.g., for experts and laymen
3.4 Web Application Design
The XML era began when standard SGML parsers were ready to "digest." It almost recommended that a condensed version of SGML be standardized to make the rich capacity of a common markup language available. Together with the emergence of XML, an enormous number of "simple programming languages", defined as XML-DTDs (more recently called XML schemas), had been defined, including a language to describe remote procedure calls (SOAP), a language to describe financial transactions (XML-EDI), a counterpart to HTML (XHTML), and many more.
3.2.2 Software Design: A Programming Activity
Programmable Web
The first steps towards "dynamics" were HTML forms. With their introduction, the significance of script languages increased dramatically, since they could be tailored specifically to the processing needs of browsers or servers and were easy to handle. Scripts are generally used to create HTML pages on the fly, depending on inputs in an HTML form.
Regardless of the language used to create new HTML pages, the script or program should offer pre-defined data structures and operations to be able to create typical HTML page elements, such as headers of different levels, paragraphs, lists, and other things, fill them with contents, and put it all together (as a tree-type structure of elements). This is virtually always based on the Document Object Model (DOM), which has been defined consistently as new HTML versions came along over the years, and which is available in script languages or programming languages.
The Java developers originally set out to introduce "the language of the Web" with the idea that browsers should represent not only HTML, but also run Java. Similar to HTML documents, so-called Java applets were designed for download from servers, and instead of a static document, a program's (applet) user interface would appear in the browser window. Accordingly, the main focus was placed on security aspects to prevent third-party applets from executing undesired operations on end-users' machines. Apart from scripts and applets, browsers run programs particularly for dynamic representation of multimedia presentations, for example those developed with Macromedia Flash.
Distributed Programming
Initially, distributed internet programs were directly connected to TCP; inter process communication (IPC) that means the exchange of messages between two equal peers was dominant. IPC (improved by the guaranteed quality of service for "streams") seems to have gathered some value for multimedia, but was replaced by Remote Proceedings Call (RPC) in the 1990's, along with client / server architectures. The following evolutionary move was incorrectly named "distributed object-oriented programming," i.e., the adaptation of the RPC to object-oriented programming languages with technologies like CORBA and Java's Remote Method Invocation (RMI). The above name is incorrect because object-oriented principles, such as modularity and flexibility, contradict the RPC world of monolithic clients and servers, which continue to exist in CORBA and RMI. Instead, event-based communication (EBC for short), and publish/subscribe architectures have become increasingly important. In EBC the
Web Engineering 3.
information creator determines when to communicate ("when a new event occurs") using the push principle in contrast to the pull principle where the requester initiates the communication. Clients register event types they are interested in via subscription. These event types, rather than the connections, determine the group of receivers. Receivers originally not included in a group can be added easily. JavaBeans and message-oriented middleware use rudimentary forms of EBC.
3.2.3 Merging Information Design and Software Design
Object-oriented software development meaningfully encapsulates coherent data together with the pertaining operations - the methods. Obviously, meshes consisting of objects and the call relationships between them are very similar to node-link meshes in hypertext. On the one hand, a hypertext node could be thought of as an object with methods, e.g. "present human-readable data", "select anchor", and "follow link to selected anchor". On the other hand, buttons in HTML forms often hide JavaScript methods. So, investing some time and effort, we could implement many general object-oriented software designs as HTML documents.
Clearly, both the Web and the distributed programming technology are not fully integrated nor the "cultures" of the people involved in the development of web applications. However, it might be useful to simply ignore an artificial "technology-driven" separation of the object world from the hypertext world in a design process. We would then design Web applications from elements (object-node hermaphrodites) and links (which could also be method call relationships). This approach lets us identify technologies to be used later on, or from case to case.
The following greatly simplified alternatives should be observed in this approach:
Elements can be implemented as either static, client-generated pages (e.g., JavaScript), or as server-generated pages (ASP, JSP). In addition, they can be implemented as applets, user interfaces of distributed object-oriented programs (Java), or static or generated media. What users see in their browser can be media contents, forms, or software user interfaces, depending on the characteristic of the presented (rendered) HTML. Things that users can select, click, and run are links.
Links stand for URLs in HTML, or for XLinks in XML, if the target is information rather than a program, and if both the content and the address are known at time of implementation (plain HTML) or at presentation time (dynamic HTML). Otherwise, links represent remote calls to, for example, remote scripts (if information has to be "calculated"), or methods (if the calculations required are algorithmic).
3.2.4 Problems and Restrictions in Integrated Web Design
The path towards hypertext, information and software design integration into web design is difficult, due in particular to three specific barriers: "cultural", technological, and conceptual problems.
Web Engineering 3.
Functional design: Section 5.5 introduces the core design of components and meshes, emphasizing the software developer's perspective, because this is important for the latest categories of Web applications. Accordingly, the component side will be described as an information design, rather than a software components' design. Similarly, the mesh side will focus on the composition of active components into business processes (workflows) and highly customized ubiquitous Web applications.
3.3 Presentation Design
In a presentation design, "media designers" define the look and-to some extent- the structure of how multimedia contents are presented. Based on the original idea that content is king, classic HTML specified contents together with format instructions, links, and programs (scripts). In contrast, modern presentation design follows the conceptual separation of a Web application's content and its presentation. The content of a Web application results from the composition of explicitly developed multimedia contents on the component side and implicitly defined contents on the mesh side. This means that a good presentation design allows us to flexibly adapt the presentation to various cultural, technological, and contextual requirements.
3.3.1 Presentation of Nodes and Meshes
A Web page's content results from the composition of explicitly developed multimedia contents on the component side and implicitly defined contents on the mesh side (e.g., navigation options).
When creating multimedia contents, developers have a large number of design options at their disposal. With regard to the desired concept of separation of content and presentation, these design options are often competing. For a simple example, let's assume that the HTML elements and were specified to format text in bold. The format is normally lost on devices that do not support bold presentation, because no alternative was specified. XHTML 2.0 replaces the element by the element. The presentation of this element is controlled in the presentation design, so that it can be adapted to the technical capabilities of a device, e.g., by using underline if bold is not supported.
While the developer specifies the fundamental look of multimedia contents on the component side, on the mesh side the interaction and functional design implicitly result in unformatted contents.
As an example of tasks involved in the navigation design, let's look at a presentation design for navigation interfaces. Navigation interfaces should help to find answers to three important navigational questions:
(1) Where am I?
(2) Where was I? and
(3) Where can I go?
3.8 Web Application Design
A presentation design is a typical example of tasks for which experienced knowledge is more important and more feasible than formal methods.
The question "Where am I?" can often be answered by using the "breadcrumbs" navigational scheme. In a user interface involving navigation through data or pages, breadcrumbs can be a useful mechanism for retracing steps, leaving a visual trail of the path taken. At any point, the user can retrace his or her steps to any previous point visited.
The question "Where was I?" is not that easy, because HTTP as a core Web technology is a stateless protocol, and linking techniques are primitive. The "Back" button and lists of pages previously visited are generally used in browsers. This simple example shows that there is a need to coordinate the presentation and interaction design.
The question "Where can I go?" consists in listing all top levels of a Web site. In connection with the "breadcrumbs" navigation scheme and suitable marking of the destinations that can be reached from within the current page, the user basically obtains sufficient information about his or her position within the mesh.
3.3.2 Device-independent Development Approaches
Enhanced requirements on the presentation design result from an increasing demand to consider the trend towards a large number of different Web-enabled devices in the design of Web applications.
The spectrum of these Web-enabled devices includes almost all conceivable classes of mobile devices, from very small mobile phones with WAP browsers over smart phones and organizers to tablet PCs with touch-sensitive displays. Cooperative and very large devices are currently not relevant in practice. When looking at the technical features of mobile devices, a very different set of presentation and interaction options results for use in Web applications.
The presentation design considers these requirements within the scope of special activities to support the device-independent development of applications. For example, the Device Independent Working Group (DIWG) (W3C 2001c) of the W3C is currently working on this issue. The tasks of the DIWG include aspects from the field of application development, the adaptation of applications to the user's context, and different representations of information.
3.4 Interaction Design
Interaction design concerns the intersection of the visual, dynamic, functional, and technical elements of Web applications. Its major purpose is to combine these elements and smooth conflicts between them, in order to offer the users an interesting and attractive as well as consistent and easy-to-understand experience. This section suggests a systematic approach that divides the interaction of Web applications into four aspects: user interaction, user interface organization, navigation, and user activities.
3.10 Web Application Design
Figure 3.4.1 Comparison of the main interface development technologies.
ActiveX, Applets AJAX DHTML HTML
Maintainability Low Low Medium Low
Reusability Low Low High Low
Scalability Low Medium High High
Expandability Low Low High Low
Sustainability Medium Low Medium High
Table 3.4 Implementation alternatives for web application user interfaces
interfaces usually have presentation, data and logic tightly coupled, resulting in difficulties in development and maintenance. On the other hand, there are alternatives such as DHTML and Portlets that, due to a stricter separation of concerns, allow a higher modularity and overall maintainability.
Reusability refers to the possibility of factoring out code of a particular application for use in other applications without (many) changes. Development technologies provide different reuse mechanisms such as code/scripting libraries. As the first web pages need to be quickly generated, the need to look for reusability at user interface level is often neglected.
Web Engineering 3.
Scalability refers not only to the capability of sustaining larger amounts of users but also, from a development point of view, to the ability of discerning different development activities that can be carried out in parallel by a development team.
3.4.2 User Interface Organization
A frequent problem occurs when a node contains more information than fits on a screen. When we try to weigh the presentation design aspects against the interaction design aspects, we could let ourselves be guided by the following questions: Should the screen dimensions have priority over the concept that nodes are atomic units (and navigation units)? Should or can a node be split into several smaller nodes? Can additional navigation be an alternative to scrolling? How should complex behavior of the user interface and portability be balanced against each other? As in the previous section, the particular technology blend has implications, this time in terms of navigational semantics (whether navigation is triggered to continue reading or, instead, to access a related topic), portability and usability. We can differentiate different approaches (see Table 3.4.2):
- The entire node is sent to the user as HTML. The HTML page includes either scripts or a custom plug-in technology to let the user access subsets of the information. The use of embedded programming avoids further, unnecessary navigation.
- The entire node is sent to the user as one large HTML page without scripts. The user selects relative links on the page to navigate in the page.
- A partial view to the node is sent to the user. This page shows meaningfully arranged subsets of information. The user can navigate to other pages to fully read the desired information.
Linked pages avoid to overly use scrolling but they lead to additional navigation and, conse¬quently, to larger latency when retrieving the same information again.
For example, intranet applications might make assumptions about the used browsers. In contrast, e-commerce providers have to focus on portability to make sure all potential customers can access their pages.
Table 3.4.2 Implementation alternatives for nodes. The table shows how different implementation approaches have a positive or negative impact on navigation semantics, portability and usability
Implementation approaches Navigation Semantics Portability Usability
HTML + scripting + (^) — +
HTML + relative links + + —
Linked HTML pages - + —
Web Engineering 3.
The introduction of XML meant a large progressive step for links and anchors. Combined XML standards like XPath, XPointer, and XLink, offer an infrastructure for general hypermedia functionality, reaching far beyond HTML links. Chapter 6 will discuss the technological details, so that we will limit this discussion to a brief look at design-relevant aspects.
Overall, it is important for Web application designers to know the expanded capabilities of links in XML. For example, so-called multidirectional links can be used to link an XML document with several resources.
3.4.6 Navigation and Orientation
Navigation tools should help to limit the cognitive stress for users. We identify three basic strategies to achieve this goal:
Navigation organization: This strategy determines the entire navigational structure.
Orientation aid: This strategy addresses the questions "Where am I?" and "Where was I?" under interaction aspects of the presentation design.
Link perception: This strategy concerns mainly issues related to the association of links to motivation and consequence.
3.4.7 Structured Dialog for Complex Activities
When designing complex Web applications, we often have to make extensive processes that users should activate visible. "Extensive" can mean that an activity extends over several pages. In this case, we can identify three categories of forward navigation: (1) An action is triggered as a result of the navigation step. (2) The navigation calls "only" one additional page, e.g., page 2 of a form. (3) The navigation step leads to a node not directly involved in the activity (additional information, etc.). These alternatives jeopardize both the clarity for the user and the consistency of supported activities. One example is the last step of an activity, which seals binding agreements between a user and a Web application, the so- called checkout. If a user decides to move to an independent page prior to completing the checkout, then we have to clarify the state the activity is in. The same is true when a user presses the "Back" button before the checkout is completed.
The characteristics of a business process differ strongly from those of a hypertext application shown in below table.
3.14 Web Application Design
Table 5-4 Differences between hypertext and business processes
Hypertext Business Process
Control
The user controls the sequence of pages visited. The next page is called by following a link.
The process defines the next activity within a sequence. Activities are executed sequentially, but the control flow can be complex.
Leaving a page/activity
The user leaves a page by selecting an anchor. The state of this page does not change. A page cannot be ended.
When an activity is left, then it should be clear whether or not it has been completed or interrupted or aborted. The concept of ending activities is an important part of business processes.
Reassume/undo
Returning to a page (e.g., by selecting "Back" in the browser) means merely that the page is called again.
Returning to an activity means that the state that prevailed when the activity was interrupted is reassumed. An explicit call is required to undo an activity.
Approaches to implement business processes in Web applications range from simple HTML (processes are a navigation by-product) to methods and tools for workflow management (workflow-driven hypertext). In the second case, workflow interactions are generally not mapped to a Web application's navigation system in an automated way. Process definitions generally describe how processes are embedded in workflows, but not how users interact with processes. Therefore, the interaction design should try to map complex tasks by cleverly using the navigation possibilities.
3.4.8 Interplay with Technology and Architecture
We have emphasized repeatedly that design, architecture, and technology are closely related in Web application development. This concerns particularly the transition from simple to complex activities. This transition has an impact on the technology and software architecture of our choice, sometimes being a harsh transition to more complex architectures and better performing technologies as our Web application evolves.
Simple activities that retrieve information can be implemented by simple "3-layer architectures", which use templates to generate HTML outputs matching client requests (e.g., based on ASP.NET, JSP, or PHP). In such simple architectures, the application control and the application logics are embedded in the script source code of the templates.
As the information to be represented becomes more complex, for instance, when it is combined from several sources, scripts can become extremely large. It would then be better to replace script languages by user-defined server-side tags. These tags allow separating and hiding the code required for representation from the HTML page. However, even if we
3.16 Web Application Design
3.5.2 Communication Paradigms and Middleware
Middleware has been mentioned above as a technology to link applications. Existing approaches differ strongly in their complexities and objectives, where we briefly described Inter-Process Communication (IPC), Remote Procedure Call (RPC), Event-Based Communication (EBC), Message-Oriented Middleware (MOM), and distributed object- oriented approaches.
The XML-based approaches mentioned in different places in this book will be summarized below in preparation for the following sections. XML as an emerging lingua franca of the Internet is the basis not only for a "better Web/HTML" and the portable specification of semi-structured data, but also for new distributed application standards, particularly the Simple Object Access Protocol (SOAP), the Web Service Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI), to mention a few. SOAP handles message and calls over different Internet protocols, e.g., HTTP, SMTP, etc. WSDL serves to describe interfaces and address Web services, and UDDI provides a sort of database to publish and search for Web services.
3.5.3 Distributed Cross-corporate Web Applications
The distribution aspect has gained increasing importance in the software-side implementation of Web applications. Just as links to remote Web pages are common today, distributed software will emerge from the meshed access to remote Web applications in the future. This can be interpreted as service-to-service communication, where the term service characterizes functionality offered over a well-defined interface. Web services have increasingly been implemented on the basis of XML. For example, eBay provides not only one single authentication system, but also supports Microsoft's Passport, and Google allows you to integrate their search function into external applications via SOAP.
Building on XML and basic technologies like SOAP, WSDL, and UDDI, other protocols are currently emerging, of which some are complementary and some are competing. These are protocols of the type necessary to handle business across the boundaries of a company. Figure 3.5.1 gives an overview of how these protocols depend on each other.
Figure 3.5.1 Protocol stack for Web services.
Web Engineering 3.
The Web Services Transactions Specifications (WS-Transaction) describe an extensible framework to coordinate actions in distributed applications (WS-Coordination) and specific coordination types for atomic transactions and business transactions (IBM 2005a). Atomic Transactions allow you to coordinate short actions based on the 2-Phase-Commit protocol. This approach is suitable particularly to encapsulate proprietary formats of current transaction-oriented systems. Business activities in contrast are intended for long-lived actions, since they do not block resources over a lengthy period of time.
The Web Service Choreography Interface (W3C 2002a) and the competing Web Services Conversation Language (W3C 2002b) offer a way to specify messages participating in a service and their structures as well as the sequence in which these messages should be exchanged. BPEL4WS (Business Process Execution Language for Web Services), or BPEL for short (IBM 2005a), builds on the former, allowing describing complex business processes (workflows). BPEL can be used to describe control flows and dependencies between participating processes.
In addition to BPEL4WS and WSCI/WSCL (which is suitable not only for the purpose discussed here), a number of other manufacturer-specific protocols are available to describe business processes in XML.
Another important issue for business over the Internet concerns security aspects, briefly outlined in Figure 3.5.1 with WS-Security as an example. Authenticity, confidentiality, integrity, and non-repudiation play a central role in this issue.
Based on the business-to-business (B2B) approach, Web applications appear to evolve into huge systems distributed over many computers. This approach integrates not only a company's internal applications, but also third-party applications (services). Some companies already have extensive access to third-party applications under the catchword Supply Chain Management (SCM). Web services are expected to standardize this approach on the Web. Some research work has already been undertaken to select services on the fly as needed, depending on the situation. The Service Provisioning Markup Language (SPML), which can be used for the billing of services used, represents a first step towards this direction.
Web Engineering 3.
On the technological side, the available tools and methods are insufficient. In addition, the merging of these fields has not yet materialized.
And finally, on the conceptual side, the integrated concept drawn there would really have to be adapted to latest developments and findings before it can reach the maturity needed to be implemented in tools and methods, or even proliferate.
- Compare hypertext and business processes.
Hypertext Business Process
Control The user controls the sequence of pages visited. The next page is called by following a link.
The process defines the next activity within a sequence. Activities are executed sequentially, but the control flow can be complex.
Leaving a page/activity
The user leaves a page by selecting an anchor. The state of this page does not change. A page cannot be ended.
When an activity is left, then it should be clear whether or not it has been completed or interrupted or aborted. The concept of ending activities is an important part of business processes.
Reassume/ undo
Returning to a page (e.g.. by selecting "Back" in the browser) means merely that the page is called again.
Returning to an activity means that the state that prevailed when the activity was interrupted is reassumed. An explicit call is required to undo an activity.
- Predict major weakness of HTML documents.
HTML can be understood as a (classic) document description language with hypertext tags grafted on.
HTML mixes orthogonal aspects like hypertext structure (via tags for links and anchors), document structure (headers, lists, etc.), and layout (background color, italics, etc.)
HTML is text-centric. Other media often occur only as link destinations (dead-end roads).
- List the basic strategies for navigation and orientation.
Navigation organization: This strategy determines the entire navigational structure.
3.20 Web Application Design
Orientation aid: This strategy addresses the questions ―Where am I?‖ and ―Where was I?‖ under interaction aspects of the presentation design.
Link perception: This strategy concerns mainly issues related to the association of links to motivation and consequence.
- Summarize navigation designs.
The result from a navigation design is two-fold: the elements users can access on the one hand and the navigational structure on the other hand. Elements become nodes in the simplest case. The structure defines the relationships between nodes. These relationships will later become visible link anchors in the user interface.
- Show how different implementation approaches have a positive or negative impact on navigation semantics, portability and usability.
- Write the differences between customization and presentation design.
Customization can influence all levels of a Web application modeling process. Changes can be limited locally to one level or affect several levels. Separation of the customization model from the content, hypertext, and presentation models are recommended with regard to changeability, flexibility, and encapsulation, but most existing methods do not provide for this separation. And sometimes, as in the reviewing system, such a separation is difficult.
- Recall component side and mesh side in presentation designs.
Presentation design: This design has the output of documents, media, and data (in the sense of an information system, or in the sense of application data of a software component) on its component side. On its mesh side, this design should focus on the visualization, auditory or multi-modal output of meshes, and the component(s) currently visited by a user.
Interaction design: This part is concerned with the control flow of a user’s interaction with a Web application. On the mesh side, the term navigation has become customary, while the term dialog is used on the component side.
Functional design: The component side will be described as an information design, rather than a software components’ design. Similarly, the mesh side will focus on
