Accessible
Content Access & Authoring
by Ben R. E. Johnson, BSc Computation with IE, 2002
ACCESSIBLE CONTENT ACCESS & AUTHORING chapter 210 / page 2
1 Abstract
The Accessible Content Access & Authoring project applied Jacobson et al‘s Object-Orientated Software Engineering (OOSE) methodology to produce a web-based system allowing children of upper-primary/secondary school age to create and maintain a page (or pages) on the Internet, using a standard web browser at school and at home. Solving this problem required the development of a system that facilitates the viewing and authoring/editing of server-side structured data (e.g., web page information) by a variety of web-enabled clients.
The project centred around two key design problems: the technical problem of how to provide data storage and retrieval services to a range of web clients with widely differing capabilities and the usability problem of designing a user interface that allows the young target users to take advantage of these services. Design techniques used to capture and solve these problems included Petrounias’s Non-Functional Requirements (NFR’s) Elicitation & Specification method and Nielsen’s five dimensions of usability.
The resulting ACAA system comprises Active Server Pages (for easily maintainable scripting of application flow logic) and Component Object Model (COM) objects (encapsulating core system data and services) arranged in a 3-tier (‘N-tier’) client-server architecture. The system operates from any standard Internet Information Server (IIS) platform and utilises SQL Server 2000 and XSL ISAPI Filter as the key components of its Data and Presentation layers, respectively.
This project represents a culmination of skills and techniques studied as part of the UMIST BSc Computation degree syllabus, including:
■ Requirements Capture & Modelling (CT318)
■ Software Analysis & Design (CT203)
■ Emerging Technologies in Information Systems (CT321)
■ Project Management (CT311)
■ Distributed Systems & Internet Technology (CT337)
■ Human Computer Interaction (CT204)
■ Network and Open Systems (CT211)
■ Database Theory (CT213)
2 Acknowledgements
The author would like to express his thanks to the supervisor of this project, Dr Donal Flynn, who was responsible for ensuring a practical outlook was maintained throughout its progress; his assistance was invaluable in driving analysis of the problem area beyond theoretically musing and into consideration of real world issues that would affect ACAA were it deployed as described.
Warm thanks are also due to the author’s family; four younger brothers, one little sister and a mother from the teaching profession have ensured no shortage of eager interviewees while seeking a more realistic outlook on the problem. Their assistance was gratefully (and at times grudgingly, in the case of more demanding requirements!) received.
3 Table of Contents
1 Abstract 1
2 Acknowledgements 2
3 Table of Contents 3
4 Report Introduction 4
5 Problem Background 5
6 Project Planning & Approach 6
6.1 Design Methodology & Rationale 6
7 Requirements Specification 9
7.1 Object Inventory 9
7.2 Stakeholders & Associated Outline Requirements 10
7.3 Use-Case Model 11
7.4 Environmental Factors & Constraints (NFR’s) 13
8 Analysis & Design 14
8.1 Ideal-Object Model 14
8.2 System Architecture Design & Rationale 18
8.3 Real-Object Model 20
9 Implementation & Testing 22
9.1 Implementation Approach 22
9.2 Issues Encountered & Their Resolution 23
9.3 Testing Strategy & Results 24
10 Evaluation & Conclusions 25
10.1 Key System Features & Benefits 26
10.2 Further Work 27
11 References 28
12 Bibliography 30
13 Appendices 31
A Use Case Descriptions 32
B Ideal-Object Models for Individual Use Cases 36
C Technology Design Rationale 37
D Requirements Traceability 41
List of Figures
· Figure 4‑A - Correlation Between Report Chapters & Phases of the Waterfall Model 4
· Figure 7‑A - Use-Case Model for ACAA 12
· Figure 8‑A - Entity-Relationship Diagram for ACAA 15
· Figure 8‑B - Ideal-Object Model for ACAA 17
· Figure 8‑C - Real-Object Model for ACAA 21
4 Report Introduction
This chapter presents an introduction to the layout of this report.
Each chapter of this report features an introduction explaining its contribution toward the project. Starting from the current point in the report, Chapters 5 through to 10 each correspond to a phase in the standard software development life cycle (‘waterfall’) model, as illustrated by Figure 4‑AFigure 4‑A below and discussed in greater detail in Chapter 6, “Project Planning & Approach”:
· Figure 4‑A - Correlation Between Report Chapters & Phases of the Waterfall Model
Chapter 11 presents a list of references for the report, giving full details of every publication and online resource referenced in the main text (e.g., “[Jacobson et al, 1996]” ), while chapters 12 and 13 present the report bibliography and appendices, respectively.
5 Problem Background
This chapter describes the problem scenario that ACAA aims to solve.
Accessible Content Access & Authoring aims to provide schoolchildren with the means to single-handedly create and maintain a web presence that would otherwise be out of their reach due to the level of technological skill required to author and publish material on a server. Even if existing web development tools such as FrontPage are used, the barrier to entry for young children is too high, due to the time and skills required to use such solutions.
An alternative might be thought to lie with one of the many personal web page hosting providers, such as GeoCities or Tripod. Investigation into the support for younger users provided by these services reveals most only go as far as offering web development tutorials. Sites such as Webmonkey For Kids, Web Genies and Classroom Tripod make an admirable effort to teach skills such as HTML to school kids. Ultimately, however, aspiring young webmasters would need a teacher’s assistance to complete such a course and upload their site to a web server, which is a requirement that ACAA seeks to avoid.
A few combination web page authoring/hosting services exist that take support for children a step further by providing a simple step by step interface for creating basic web pages, meaning no technical skills – such as Hypertext Mark-up Language (HTML) – are required. Examples include AlphaDesk FunPages and MatMice, which both do a good job of guiding the user through a simple content creation and style selection process. However, the current range of services of this type suffers from the following problems:
■ Page content is entered using a web form (i.e., a series of fields for items such as page title, author, etc.), making it difficult for the child to visualise their page as they write
■ Once the page design has been chosen, it often cannot be changed. This is due to pages being created as static HTML documents containing content mixed with presentation information such as layout tables, text colour, etc
■ Some services – including AlphaDesk – do not allow page content to be changed (without editing the raw HTML code) once they have been generated
■ Advanced web page features (e.g., animated page elements) would only be possible by manually editing the page HTML and inserting special code; writing this code (particularly code that works in all web browsers) would be beyond children of the target age
■ In order to edit, link to or insert an image into a particular web page, the young webmaster has to know the correct URL / filename
ACAA aims to fill the gap in this range of options, by providing the young webmaster with an easy to use page authoring/editing interface that does not suffer the above problems and which can be used by the child at home and at school to keep their web site up-to-date, regardless of their means of web access.
6 Project Planning & Approach
This chapter presents a literary review of systems engineering techniques to be applied during the course of this project, ranging from Flynn’s web development framework and Jacobson’s OOSE software design methodology to Petrounias’s NFR Capture & Specification method and Nielsen’s Usability Assessment Criteria.
6.1 Design Methodology & Rationale
Flynn’s “Method for Web Site Development” [Flynn, 2002] provides a guideline framework for web development, based around the ubiquitous software development life cycle (‘waterfall’ model) but tailored to the context of developing web applications. It presents a sensible set of recommended activities, such as stakeholder-orientated requirements gathering, without placing unnecessary constraint on design technique or implementation technology. This project will adhere to this framework, but will also employ a range of additional techniques and methodologies, as follows.
The underlying functional requirements of ACAA are relatively simple; we need a container that allows us to put information in and get it back again later. This is the “Content Access & Authoring” part of the project title; ‘Accessible’ is where the challenge lies. In the problem context, accessibility refers to two design problems:
■ Technical – How do we ensure that as wide a range of client devices - and therefore users - as possible can make use of ACAA’s services?
■ Usability – Having made ACAA’s services available, how do we ensure they are ‘user-friendly’ enough literally for a child to use them?
Technical Problem
The outline requirements state that the system must provide information storage and retrieval services to a wide range of web client devices. Some of these may support powerful client-side processing features and the latest mark-up standards such as HTML 4 and Cascading Style Sheets; some won’t even have graphical capabilities, e.g., mobile devices. Some may not even be under human control; the school may have other systems that wish to interact with ACAA automatically.
Each client type will need to interact with the system using different interface technologies.[1] At the same time, the function of the system - once communication and presentation issues have been handled – does not change. Users need to store and retrieve the same information regardless of their means of access, so the underlying processes remain the same.
To achieve this, it is likely that the system will require a layered or component-based architecture design, where the presentation logic is kept separate from processes common to all clients, such as data access and security rules. In some cases it may even be possible to take advantage of advanced functionality in newer clients and have them handle presentation processing themselves in order to relieve strain on the server [Microsoft Corp., 2001].
If we are to divide the system into more than one distinct component in this way, it is vital that the responsibilities of each component are modelled closely before implementation starts. I have experience with previous client-server projects (namely the cdXP system for British Telecommunications PLC) where poor component design (or lack thereof!) caused problems later in the project; it was discovered that data encapsulated in the presentation layer of the system was needed elsewhere, but was difficult to access because the need had not been anticipated during the inadequate design phase.
The design methodology selected to prevent similar problems is Jacobson’s OOSE approach, as described in “Object-Orientated Software Engineering: A Use Case Driven Approach” [Jacobson et al, 1992]. Jacobson – co-author of the Unified Modelling Language standard [Booch et al, 1998] – demonstrates in his text how effectively the functional requirements of a system can be captured through simple descriptions of the desired interactions between user and system (use cases).
Using these use-cases as the basis for the rest of the design process, Jacobson then illustrates how entity, control and interface objects can be found (Ideal-Object Model), mapped to real-world implementation technologies (Real-Object Model) and finally described in detail through Class / Interaction Diagrams. The individual steps of this process are described in greater detail in individual chapter introductions.
Usability Problem
Usability may be defined as “the quality of a user’s experience when interacting with a product or system” [Nielsen, 2001]. If the ACAA system successfully managed to conquer the discrepancies of every client type in popular use, but failed to meet its goal of being simple enough for a child to use, it would be useless as a real-world application. Therefore, ACAA must aim to excel in the following dimensions of usability, according to Nielsen:
■ Ease of Learning – How fast can a user who has never seen the user interface before learn it sufficiently well to accomplish basic tasks?
■ Efficiency of Use – Once an experienced user has learned to use the system, how fast can he or she accomplish tasks?
■ Memorability – If a user has used the system at some earlier date, can he or she remember enough to use it more effectively next time (or does the user have to start over again learning everything every time)?
■ Error Frequency & Severity – How often do users make errors while using the system, how serious are these errors, and how easy is it to recover from a user error?
■ Subjective Satisfaction – How much does the user actually LIKE using the system?
Nielsen’s study of web usability for children [Nielsen, 2002] and UMIST researcher Cassaigne’s techniques for ensuring web usability [Cassaigne, 1999] will be considered and applied during the user interface design process in order to maximise these usability measurements.
Some usability aspects cannot be ensured through simple user interface design, however. A key finding of Nielsen’s study was the lack of patience held by younger users; unfortunately, no amount of graphics pruning and hand-crafted HTML code can alleviate the problem of an under-performing database on the server. A step toward ensuring this situation does not arise is to include a ‘non-functional’ requirement for pages to display quickly. But how quick is quick?
UMIST researcher Petrounias’s methodology for the elicitation and specification of Non-Functional Requirement (NFR’s) [Petrounias, 2001] provides a formal means of gathering and representing environmental factors and constraints that can be traced and evaluated in the finished system. This project will use this methodology to create an NFR Repository (section 7.4) containing quantitative functional constraints such as “content pages must load in under 10 seconds”.
7 Requirements Specification
This chapter defines the behaviour and characteristics required of the finished ACAA system. It does this by considering the stakeholders expected to interact with the system (section 7.2), then building a Use-Case Model of typical interactions between these users and the system (7.3). From this we build a comprehensive picture of the ACAA’s responsibilities. Section 7.4 completes this picture by building a Non-Functional Requirements repository, containing measurable behavioural constraints the completed system is expected to adhere to, e.g., performance requirements.
7.1 Object Inventory
The following presents an inventory of real-world objects relevant to the ACAA problem. Its main purpose is a glossary for the problem domain, to clarify the meaning of references used during the course of this project.