ITHACA: An Open Source Framework for Building ... - Semantic Scholar

14

ITHACA: An Open Source Framework for Building Component-Based Augmentative and Alternative Communication Applications ALEXANDROS PINO and GEORGIOS KOUROUPETROGLOU National and Kapodistrian University of Athens

As an answer to the disabled community’s odyssey to gain access to adaptable, modular, multilingual, cheap and sustainable Augmentative and Alternative Communication (AAC) products, we propose the use of the ITHACA framework. It is a software environment for building componentbased AAC applications, grounded on the Design for All principles and a hybrid—community and commercial—Open Source development model. ITHACA addresses the developers, the vendors, as well as the people who use AAC. We introduce a new viewpoint on the AAC product design-developdistribute lifecycle, and a novel way to search-select-modify-maintain the AAC aid. ITHACA provides programmers with a set of tools and reusable Open Source code for building AAC software components. It also facilitates AAC product vendors to put together sophisticated applications using the available on the Web, independently premanufactured, free or commercial software parts. Furthermore, it provides people who use AAC with a variety of compatible AAC software products which incorporate multimodal, user-tailored interfaces that can fulfill their changing needs. The ITHACA architecture and the proposed fusion of past and current approaches, trends and technologies are explained. ITHACA has been successfully applied by implementing a family of AAC products, based on interchangeable components. Several ready to use ITHACA-based components, including on-screen keyboards, Text-to-Speech, symbol selection sets, e-chatting, emailing, and scanning-based input, as well as four complete communication aids addressing different user cases have been developed. This demonstration showed good acceptance of the ITHACA applications and substantial improvement of the end users’ communication skills. Developers’ experience on working in ITHACA’s Open Source projects was also positively evaluated. More importantly, the potential contribution of the component-based framework and Open Source development model combination to the AAC community emerged. Categories and Subject Descriptors: K.4.2 [Computers and Society]: Social Issues—Assistive technologies for persons with disabilities; D.2.13 [Software Engineering]: Reusable Software— Part of the work reported in this article was carried out within the M-PIRO project funded by the Information Society Technologies (IST) Program of the European Union and the AENEAS project co-funded by European Community Funds and Greek National resources under the EPET II Program, Hellenic General Secretariat of Research and Technology. Authors’ address: A. Pino and G. Kouroupetroglou, Department of Informatics and Telecommunications, National and Kapodistrian University of Athens, Panepistimiopolis, Ilisia, GR-15784 Athens, Greece; email: {pino, koupe}@di.uoa.gr. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from the Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or [email protected]. c 2010 ACM 1936-7228/2010/06-ART14 $10.00 DOI: 10.1145/1786774.1786775. http://doi.acm.org/10.1145/1786774.1786775. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 2

·

A. Pino and G. Kouroupetroglou

Domain engineering; reusable libraries; reuse models; D.2.9 [Software Engineering]: Management—Life cycle; H.5.2 [Information Interfaces and Presentation]: User Interfaces—Graphical user interfaces; input devices and strategies; interaction styles; user-centered design General Terms: Design, Human Factors, Management Additional Key Words and Phrases: Augmentative and alternative communication, open source, component, framework, design for all ACM Reference Format: Pino, A. and Kouroupetroglou, G. 2010. ITHACA: An open source framework for building component-based augmentative and alternative communication applications. ACM Trans. Access. Comput. 2, 4, Article 14 (June 2010), 30 pages. DOI = 10.1145/1786774.1786775. http://doi.acm.org/10.1145/1786774.1786775.

1. INTRODUCTION For people with complex communication needs, those with speech and/or motor impairment, cognitive limitations, learning disabilities and aging, daily routine as well as rehabilitation and educational programs often include the use of Augmentative and Alternative Communication (AAC) aids [Beukelman and Mirenda 2005]. In the past, AAC was dominated by low-technology or nonelectronic devices [Reichle et al. 1991]. A few decades ago, several electronic aids were introduced in the international market, incorporating voice recording and playback capabilities. Such noncomputer-based products are still widely used and are available from companies such as Ablenet,1 Attainment,2 and Crestwood.3 Although these devices are considered very useful for the persons using AAC, they provide a limited vocabulary, need extra effort from the facilitator to add new recordings, and cannot keep up with the nontrivial progress usually achieved by their users [Cumley and Swanson 1999]. Recently, a number of computer-based communication aids that support a range of symbolic communication systems, incorporate special I/O devices, configurable User Interfaces (UIs), and speech synthesis, have been developed by various companies such as Ablenet, Mayer Johnson,4 Assistive Technology,5 Dynavox,6 and Prentke Romich.7 All these devices have larger vocabularies, but they support a very limited number of natural languages and it is rather impossible to add new ones. These modern computer-mediated interpersonal communication systems should be adaptable in order to satisfy the wide variety of the users’ changing needs [Light 1989] and the specific user profiles; nevertheless, from the software engineering perspective, they are usually monolithic and rather difficult to modify or extend. 1 Ablenet,

Inc., North Roseville, MN. Web site: http://www.ablenetinc.com. Company, Inc., Verona, WI. Web site: http://www.attainmentcompany.com. 3 Crestwood Communication Aids, Inc., Milwaukee, WI. Web site: http://www.communicationaids.com. 4 Mayer Johnson, LLC., Solana Beach, CA. Web site: http://www.mayerjohnson.com. 5 Assistive Technology, Inc., Dedham, MA. Web site: http://www.assistivetech.com. 6 Dynavox Technologies, Pittsburgh, PA. Web site: http://www.dynavoxsys.com. 7 Prentke Romich Company, Wooster, OH. Web site: http://www.prentrom.com. 2 Attainment

ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

ITHACA: Open Source Framework for Building Communication Applications

·

14: 3

The computer-based AAC systems that originated during the past decade can be classified as: (a) “dedicated” AAC systems housed in specially designed hardware, (b) proprietary AAC software applications functioning on a mainstream Operating System (OS) and housed in specially designed hardware, and (c) proprietary AAC software applications functioning on a mainstream OS and housed in a mainstream device. DeRuyter et al. [2007] sketch out the main strengths and drawbacks of these three approaches, concluding that the third approach is the most applicable and affordable. The main problems that disabled users face with existing computer-based commercial solutions include: costly products, absence of multilingual support, difficulty in locating products because of the geographically dispersed and fragmented market, lack of proper support for customization, low adaptivity and adaptability of the UI and the vocabulary, difficulty in adding or removing functionality or components when needed, and a limited number of complete products to choose from. Moreover, designing and developing interpersonal communication aids for people with disabilities is a domain for which modern software engineering approaches such as those that combine ComponentBased Development (CBD) and the Open Source model have not yet been applied. DeRuyter et al. [2007] refer to the development of Open Source software that runs on mainstream computers, as a better alternative in order to provide maximum flexibility and accessibility. In the next sections, details of the ITHACA framework that addresses the aforementioned problems are presented. Section 2 is an overview of the approaches that ITHACA combines, namely CBD, Open Source development model, and Design for All. In Section 3 the fusion of the technologies that ITHACA proposes and the resulting novel AAC product life cycle are explained, followed by technical aspects of the framework and the features it offers to developers and integrators. Section 4 lists implementations of specific ITHACAcompliant components. Section 5 presents an evaluation of the framework involving 20 developers and researchers who used the system over a period of nine months. Section 6 illustrates the application of the framework through the development and deployment of four distinct systems and includes a number of observations based on the subsequent use of these system and conversations with the family members and therapists who were involved. 2. DOMAIN OVERVIEW ITHACA framework introduces the fusion of three modern trends in software engineering: CBD, Open Source software, and Design for All. A brief overview of each domain will be given in order to reveal how an AAC framework can benefit from their main contributions. Other relevant AAC projects and initiatives will be presented along with a discussion of their drawbacks related to ITHACA. 2.1 Component-Based Development Software engineering offers several technical solutions [Larsen 2000] including turnkey solutions, custom implementations, and CBD. Turnkey solutions are ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 4

·


ready-to-go, “out of the box” applications that address a wide market. However, specific and restricted user groups are not easily catered for. Usually, these applications do not have enough adaptation capabilities, and when they do, they require extensive configuration. Custom implementation solutions typically involve building most of the system functionality from scratch, according to specific user needs. This results in final products with a very steep price and high maintenance costs. On the other hand, CBD solutions can result in families of products, with interchangeable pieces of software. Such a modular approach can address different user groups or needs. Component-based frameworks are partial implementations, specifying the nature and interconnectivity of software components and the way to extend the resulting applications with pluggable features. Final products are cheaper because they can incorporate a variety of components coming from independent developers, encourage software reuse, and allow each specialized engineer or manufacturer to deal only with the area of his/her expertise. Software components can be considered mature software engineering concepts [Hopkins 2000]. D’Souza and Wills [2006] define a software component as: a coherent package of software artifacts that can be independently developed and delivered as a unit and that can be composed, unchanged with other components to build something larger. D’Souza and Wills [2006] generalize to a component-based framework description. In general, a component-based framework is a collaboration in which all the components are specified with type models; some of them may come with their own implementations. To use the framework you plug in components that fulfill the specifications. 2.2 Open Source Software The term “Open Source” can be described from three different standpoints (solely or in conjunction): a) software protected under special copyright licenses aimed at ensuring availability and free (re)distribution of the source code; b) a process of software development that incorporates some unique technical and social characteristics, such as volunteer programming, the ability of users to suggest new features, report faults in programs, etc.; c) a movement based on the ideals of the hacker culture which is premised upon the freedom to use, create, and tinker with software [Kollock 1999]. Prominent examples of Open Source software include the GNU/Linux operating system,8 the Apache server program9 and the Python10 computer language. Initially, most of the software produced by the Open Source movement had an infrastructural character. As Castells [2001] indicates, this meant that 8 The

GNU/Linux Operating System Web site: http://www.linux.org. Apache HTTP Server Project Web site: http://httpd.apache.org. 10 PYTHON high level computer programming language Web site: http://www.python.org. 9 The



·

14: 5

its users consisted of programmers and system administrators and very few applications were addressed to the average, nontechnical user. However, this is rapidly changing. Open Source is being adopted by a growing number of public and corporate organizations, and reaching a wider and more diverse non-technical user base compared to its earlier phases of development. Open Source licenses (namely copyleft) were developed in order to prevent anyone hijacking the Open Source code. While copyright law protects the rights of the creator by providing control of distribution and modification, the idea of copyleft is to grant subjective freedom to end users. Copyleft licenses specify clauses which explicitly remove those restrictions the creator considers to not provide freedom to the end user. Open Source copyleft licenses ensure that information helpful in supporting modification of software (e.g., source code) will be made available to a user with a copy of the licensed software, and allows the original author to be acknowledged [Lessig 2002]. The best known example of a copyleft license is the GNU Public License (GPL).11 There are two types of Open Source software [Richle 2007]. Community Open Source is software that a community develops. Rather than a single corporate entity owning the software, a sometimes broad community of volunteers determines which contributions are accepted into the source code base and where the software is headed. Individual developers, and not a specific company, make decisions about the software, as in the case of the Apache Web Server. Commercial Open Source is software that a for-profit entity owns and develops. The company determines what is accepted into the software code base and what to implement next, as in the case of MySQL database.12 2.3 Design for All Design for All or Universal Design constitutes an approach for building modern applications that need to accommodate for heterogeneity in user characteristics, devices and contexts of use [Stephanidis 2001]. However, one of the main difficulties encountered by developers is the general lack of indication on how to instantiate its principles [Burzagli et al. 2009]. In the AAC domain, a Design for All approach can be implemented in such manner so that everybody can communicate with everybody either face-to-face or in distance, in an asynchronous way (e.g., by exchanging email) or in real time (e.g., by e-chatting). Most people do not usually need to use AAC aids, but they occasionally meet users of AAC devices or persons who use symbolic languages. In these cases, a Designed for All system should allow for both parties of communication to understand each other. The same also stands for people of different ages, speaking different languages, or using different symbolic communication systems. While Universal Design does not necessarily solve all accessibility problems, it does incorporate a human factors “user-centered approach” to producing products, so that they can be used by as many individuals as possible regardless of age, abilities, skills, requirements, situations, and preferences 11 GNU 12 Sun

General Public License Web site: http://www.gnu.org/copyleft/gpl.html. Microsystems, MySQL Web site: http://www.mysql.com. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 6

·


[Newell and Gregor 2000; Abascal and Nicolle 2005]. Some have challenged the idea of Universal Design, arguing that the desire to make devices that are highly flexible will result in devices that are highly complex. However, the goal of Universal Design is not a single product; instead it is a design approach that takes into account alternative user and usage-context characteristics [Emiliani 2006]. Following this methodology, the ITHACA framework facilitates the design and development of families of AAC products, allowing interpersonal communication between both people with complex communication needs as well as the non-disabled. 2.4 Related Work ¨ et al. 1998] and ACCESS [Kouroupetroglou et al. Projects COMSPEC [Lundalv 1997], funded by the European Union (both within the Technology Initiative for Disabled and Elderly People—TIDE) have made significant steps towards CBD. ComLink13 and ATIC were two component-based approaches produced by these projects as an answer to the problems of the AAC market. Although both these frameworks were characterized “open” (which meant that thirdparty developers could theoretically develop compatible components), essentially they were Closed Source, as their code was not freely available. The AAC industry’s response was not (at least was not reported) encouraging, as no third-party components were delivered to enrich the basic component collection that accompanied these two frameworks. ¨ et al. 1999] (an outcome of COMSPEC) was an AAC apComLink [Lundalv plication generator that imposed a rather rigid UI on the resulting aids. Another problem was an immature software platform (Java at that stage) and a too limited starter set of software components. ATIC (an outcome of ACCESS) was introduced as a proprietary development environment for communication aids based on components and software agents. The main disadvantages of ATIC were that it required all the components to be available before the time of integration, and that there was too much programming involved in the integration process. ATIC, which ran on MS-Windows 3.11, can be considered as the predecessor of the ULYSSES framework [Kouroupetroglou and Pino 2001; 2002], and was based on the “proprietary AAC software functioning on a mainstream OS and housed in a mainstream device” approach. The main difference from the ULYSSES approach was that ATIC used a proprietary Message Manager and a complex communication protocol between components, making the conformance with the specific architecture difficult for the developers. On the other hand, ULYSSES used a widely available and known infrastructure and messaging system (COM+) that was embedded in the OS, and a simpler object model (COM), making its guidelines and specifications straightforward. The ULYSSES framework employed a refined architecture, taking advantage of the new possibilities and features offered by MS-Windows 2000. Nevertheless, ULYSSES had the main drawback that the whole AAC industry needed to be accustomed to its proprietary guidelines and code, in order to comply with the 13 COMSPEC/ComLink

Web site: http://www.handicom.eu/en/projects/Comspec.html.



·

14: 7

framework. This is very unlikely to happen, especially when the framework is closed-source (such as all three frameworks described in this paragraph). The World Wide Augmentative and Alternative Communication14 (WWAAC) project has contributed towards the direction of Open Source development, in the domain of Internet accessibility for AAC users [Poulson and Nicolle 2004]. The most important contribution of the WWAAC project was the Concept Coding Framework (CCF)15 [Judson et al. 2005]. CCF provides direct support for symbol users on Web pages through its open-sourced concept coding infrastructure and protocol. The vision of concept coding is that instead of images and symbols having to be transferred from one computer to another, it should be possible to transmit a unique code designating the meaning of the symbol needing to be transferred. Using this infrastructure, the WWAAC project has also developed a Web authoring tool which enables Web developers to embellish their Web pages with symbols using the online ¨ and Judson 2005]. These important issues concept coding database [Lundalv are also being discussed within the W3C’s Web Content Accessibility Guidelines Working Group.16 Nevertheless, the WWAAC project did not develop a framework for building applications such as ComLink, ATIC, ULYSSES, and ITHACA, and its resulting applications were not compatible with any of these frameworks. WWAAC Web browser and CCF have recently been hosted by OATSoft.17 OATSoft [Judge et al. 2006] is an Open Source software repository and forge (where software is developed) dedicated to Assistive Technology (AT). It currently lists more than 150 Open Source projects and it is considered to be the most important initiative in this domain. Project:Possibility18 is a similar initiative that hosts more than 10 Open Source AT projects. Project:Possibility aims at University students in order to form its developer’s community. Potential Open Source programmers are motivated through interesting competitions and events, like SS12, Code for a Cause19 and the Semester Project.20 Both initiatives (OATSoft and Project:Possibility) have an active community formed, populating their mailing lists and using their development fora. One can find various Open Source projects regarding educational applications, alternative input/access methods, music, video games, accessible Web authoring tools and browsers, navigation aids, on-screen keyboards, symbol libraries, Text-to-Speech, environmental control, etc. Nevertheless, neither Web site contains an Open Source component-based AAC development framework project. All software products listed in these repositories are rather standalone applications without any compatibility or interconnection between them. 14 WWAAC

World Wide Augmentative and Alternative Communication. Web site: http://www.wwaac.eu. 15 CCF Concept Coding Fremework. Web site: http://www.conceptcoding.org. 16 W3C WAI - Web Content Accessibility Guidelines Working Group Web site: http://www.w3.org/WAI/GL. 17 OATS Open Source Assistive Technology Software. Web site: http://www.oatsoft.org. 18 Project:Possibility Web site: http://projectpossibility.org. 19 SS12, Code for a Cause challenge event. Web site: http://ss12.info. 20 The Semester Project. Web site: http://semesterproject.info. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 8

·


3. THE ITHACA FRAMEWORK What mainly sets ITHACA apart from the aforementioned projects is that it proposes a hybrid approach, by combining CBD, a free Open Source framework, and core components, along with community and commercial Open Source peripheral components in order to increase competition, while maintaining the interests of software manufacturers for this market. Universal Design or Design for All completes the framework, by offering the important aspects of adaptability and multiple users’ needs inclusion [Savidis and Stephanidis 2006]. Previous research conducted on the CBD frameworks’ domain [Emiliani et al. 1996], focused on the conception and development of proprietary software agents and infrastructure to support AAC frameworks. On the contrary, the modern OSs incorporate such an infrastructure, namely component services, such as component catalogues, component consoles, event services and filtering procedures. These OS services help the easier realization of a component framework, and allow developers to concentrate on other important and tricky issues like component synchronization. The ITHACA framework relieves programmers from the burden of familiarizing themselves with complex interfaces and rules for building AAC software components, while facilitating the creation of sophisticated applications from off-the-shelf independently premanufactured parts. ITHACA’s goal is to provide end users access to a large variety of state-of-the-art, inexpensive, and easily accessible AAC products with versatile and adaptable UIs (i.e., not rigid) that fit their exact needs. Two main user groups of the ITHACA framework are identified: the AAC manufacturers or software developers, and the AAC systems integrators or communication aids resellers. Although both user groups are aware of the basic characteristics of the framework, each must know different aspects of ITHACA in detail. 3.1 The ITHACA-Based AAC Software Lifecycle Traditionally, software application developers in the domain of communication aids were creating stand-alone, monolithic applications based on their studies of user needs and market research. Retailers did not get actively involved in the development or in the configuration and adaptation process of communication aids. The only possible feedback in the product life cycle was between the end user and the reseller and that feedback was difficult to propagate to the developer. Furthermore, AT products were very few and expensive due to the small market and the lack of software reuse, as many manufacturers developed the same functionalities and features from scratch again and again. Throughout each product’s life cycle, from the original idea to the end user, there was no significant feedback and evaluation. Finally, finding the right product for specific user needs was a difficult task due to the dispersed information and selling points. ATIC and ULYSSES are ITHACA’s predecessors. The ATIC architecture of the TIDE-ACCESS project [Kouroupetroglou et al. 1997], proposed a different life cycle that solved some of these problems and introduced an extended role ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 9

for communication aids resellers. They were considered as an important user group (namely the integrators) having an essential part in the life cycle of the developed products, with the task of assembling the whole AT system from available software components and suitable I/O devices and techniques. ULYSSES introduced the important role of the Internet as a widely accessible medium for gathering and propagating information about the framework and available software components and I/O devices. In ATIC, the stores that were specialized in AT products played the role of the component repository. ULYSSES replaced the traditional stores with a specialized Web site offering a higher degree of availability, variety, and flexibility. With ITHACA, the decision as to which AAC device or software is purchased, how instruction is provided, and how the device is maintained and developed typically involves many individuals, including the person who uses AAC, family members, communication and education professionals, and funding agencies [Rackensperger et al. 2005]. All stakeholders included in the AAC product life cycle can participate and contribute to Open Source software development, both on technical and nontechnical aspects. Developers (including software companies, individual programmers, and high technology rehabilitation product manufacturers) concentrate on the technical aspects of the framework regarding the Open Source software engineering techniques, interfaces, and guidelines. On the other hand, integrators (including AAC resellers, rehabilitation consulting centers, specialized therapists, and facilitators) focus on the proposed product life cycle, integration methods, and administrative tools for installing, configuring, modifying, and maintaining the applications. ITHACA proposes an extended and upgraded (compared to the traditional) AAC product life cycle by introducing a Web-based AAC knowledge base and the Web-based component inventory (Figure 1). Most importantly, the online ITHACA components may be Open Source (community or commercial) or Closed Source, thus modifying the lifecycle to a new form of hybrid Open Source/Closed Source product lifecycle. A substantial aspect of the new life cycle is the high importance that is given to information propagation between all stakeholders and all stages. The framework allows for a new viewpoint from the side of AAC production stakeholders (AAC companies, designers, developers, vendors). The following procedures are positively affected: Design. ITHACA framework promotes Design for All principles making the newly designed AAC components more usable. For example, if AAC component designers have those principles in mind, according to ITHACA guidelines, they take caution so that the Graphical User Interface (GUI) of the components is not rigid, but it is adaptable to various user needs and can be modified following users’ progress and preferences [Law et al. 2006]. ITHACA online knowledge base and the corresponding suggested specifications offer documentation and techniques to easily achieve this [Kouroupetroglou et al. 2001]. Development. Open Source code provided by the knowledge base and the online component inventory allows for code reuse and facilitates the job of developers [Spinellis and Szyperski 2004]. Code reuse in software development denotes that a part of a computer program of any size (code lines), written ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 10

·


Fig. 1. Proposed ITHACA AAC product life cycle.

at one time can be used in another program written at a later time. It is often achieved through using common libraries, components, subroutines, and interfaces. The reuse of programming code is a common technique that attempts to save time and energy by reducing redundant programming work. Furthermore, ITHACA’s component model allows developers to create software modules (i.e. software components) according to their expertise, in contrast to developing complete applications from scratch. This speeds up and lowers the cost of the development process. For example, a company that develops a word prediction component for the Greek language will not worry if it does not possess a Greek Text-to-Speech (TtS) system to complete an AAC application; another company may have already published a TtS on the ITHACA component inventory. The Open Source development model is a key aspect, opening ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 11

new ways and possibilities for volunteer or other institutional contributions and interference [Freeman 2007]. Distribution. AAC components are catalogued and available online, and there is no need for shipping or physical packaging of software and documentation, thus speeding up the distribution procedure. Licensing can also be managed online, as well as payment for components that are not free. For free ITHACA components, the GNU General Public License (GPL) is used, and the Lesser General Public License (LGPL)21 copyleft license is recommended for all third party commercial components. Open Source and commercial components can coexist, maintaining the companies’ interests while increasing competition [Shah 2006]. From the end users’ viewpoint (people with complex communication needs, facilitators, therapists, integrators, special education professionals and organizations) ITHACA also allows for innovative approaches in lifecycle: Search. AAC products and components are no longer geographically dispersed; they are gathered in the Web-based inventory, providing easy and accurate detection. This is important, especially given the usual mobility difficulties of the potential users; shopping can be done from home. Selection. In ITHACA’s Web site users are able to rate the components they use; this feature, along with easy pricing and ordering systems, will help potential clients to easily decide what to choose from a variety of available components. Users will not have to worry about compatibility issues, as all components will be ITHACA-compliant and interoperate as expected. Modification. ITHACA components are pluggable so they can be added to or removed from an AAC application at any time. Integrators or facilitators can download new components to replace the old ones as user needs change or technology advances are made. They can also download new vocabulary sets or new languages from ITHACA Symbol and Languages database. These advanced modification features lead to a more versatile lifecycle and longevity of the AAC product. Maintenance. New updates of the framework core files or new versions of components can be downloaded or automatically distributed and installed remotely from the ITHACA Web site. Component licensing may also be remotely managed for the commercial components. Developers, facilitators with programming skills, and even hobbyist volunteers can contribute to the testing, evolvement, and upgrade of software from the community side, continuously upgrading the quality and reliability of the ITHACA components. 3.2 Technological Background ULYSSES—the framework on which ITHACA is based—proposed the use of a combination of the following specifications, models, and services for the development of components and software applications [Kouroupetroglou and Pino 2002]: Application Specification for Microsoft Windows 2000 for Desktop

21 GNU

Lesser General Public License Web site: http://www.gnu.org/copyleft/lesser.html. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 12

·


Applications;22 Component Object Model (COM) specification;23 and COM’s Extension for Component Services (COM+).24 ITHACA proposes an update of ULYSSES specifications and guidelines by replacing Application Specification for Microsoft Windows 2000 for Desktop Applications with the contemporary Microsoft UI Automation25 for upgraded application accessibility. This Microsoft specification was chosen against its older version Microsoft Active Accessibility26 and IBM’s IAccessible227 as the best practice for designing and developing Windows-based accessible applications, and will be explained in the next paragraph. ITHACA also adopted COM and COM+ specification as they were updated for the .NET programming environment used by ITHACA. Microsoft UI Automation constitutes the latest accessibility framework for MS-Windows. It provides programmatic access to most UI elements on the desktop, enabling AT products to provide information about the UI to end users and to manipulate the UI by means other than standard input. It provides dynamic-link libraries that are incorporated into the operating system as well as a COM interface and methods for exposing information about UI elements. By using this infrastructure, guidelines and documentation, and appropriate design practices, developers can make applications running on MS-Windows more accessible to people with vision, hearing, or motor disabilities. MS-Windows Vista was chosen as the OS on which ITHACA-based communication aids run, because of the advanced accessibility options it provides, the user-friendliness, the increased system stability, and the incorporated technological infrastructure, which we could use to make the resulting AAC Applications more flexible and efficient. Due to the large installed basis and availability of the OS, users will not need to buy a new computer platform or have to install a non-common or hard to use OS to use ITHACA-based communication aids. The COM specification was adopted by ITHACA, first because it is selfcontained in MS-Windows and does not need any additional infrastructure or libraries to be installed. Also, the widespread use of MS-Windows and the related object model to both final users and developers were considered to be very important. Additionally, most software developers already have experience in programming applications using this model, its services and the OS-embodied Dynamic Link Libraries (DLLs) available. ITHACA framework also makes extensive use of COM+ Events [Platt 1999] and the corresponding model, which is an evolution of the client-server model. COM+ was chosen as the basis of the framework’s architecture because its services are widely used and accepted by the developer’s community. One of the most important features that COM+ provides is the Component Management 22 http://msdn2.microsoft.com/en-us/library/ms954115.aspx 23 http://msdn2.microsoft.com/en-us/library/aa286559.aspx 24 COM+

(Component Services) Web site: http://msdn2.microsoft.com/en-us/library/aa286558.aspx. 25 Microsoft UI Automation Web site: http://msdn.microsoft.com/en-us/library/ms747327.aspx. 26 Microsoft Active Accessibility Web site: http://msdn.microsoft.com/en-us/library/ms697707.aspx. 27 IAccessible2 Web site: http://www.linuxfoundation.org/en/Accessibility/IAccessible2. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 13

Console, which is a powerful tool for managing and maintaining COM+ applications; this tool clears many technical problems and restrictions previous frameworks had. For many years there has been discussion about platform-independent software products. Similar specifications and accessibility toolkits exist for other platforms too, like the Mac OS X Accessibility Protocol,28 Accessibility/ATK/ AT-SPI29 for Linux, and Java Accessibility.30 But, as far as a CBD framework is concerned, the need for cross platform support may lead to a complex, hard to learn proprietary infrastructure that contradicts ITHACA’s choice to run on a specific mainstream platform with the largest installed basis of OSs and developers. Based on this rationale, we chose to incorporate in ITHACA the specific platform (i.e., MS-Windows) dependent COM and COM+ features. COM+ technology, as a longer term foundation, is fully compatible with the contemporary .NET framework and programming environments used in ITHACA. The ITHACA framework produces .NET applications that use COM+ services, and provides a specific communication protocol between software components (Figure 2). This protocol is open and easily modified according to the application’s needs for data exchange between its components. The protocol is based on the consideration that the fundamental data used in AAC are the “Concepts” (an idea widely accepted in the AAC domain). Abstract/logical concepts can engage various data types at the presentation level; that is, concepts may be represented by strings (i.e., words or phrases), video, sound, or icons. A concept that is conveyed from one component to another, locally or remotely, may be processed and may change data type and/or language between components, making its management rather complex. To simplify the situation, we defined a base language (database of concepts) named “Interlingua,” that is a pseudo-language based on English, in which all concepts can be represented as character strings. Language-independent components can communicate using Interlingua, while output components or language-aware (natural or symbolic) components use the equivalent representation (in any form) of the Interlingua concept in their own language or symbolic system according to the database’s relations. The database of natural and symbolic languages (including Interlingua, photograph, sound, or videobased languages) is the heart of the framework and allows simplification of intercomponent communication by using strings only. Final users and/or facilitators and educators can easily add new content to the database, and add or modify concepts of the Interlingua. The creation of a nontrivial Interlingua for topics not restricted to a narrow domain is quite difficult; the possibility of adding new concepts or correcting possible errors at any time overcomes this

28 The

Mac OS X Accessibility Protocol Web site: http://developer.apple.com/documentation/Accessibility/Conceptual/AccessibilityMacOSX. 29 Accessibility/ATK/AT-SPI Web site: http://www.linuxfoundation.org/en/Accessibility/ATK/AT-SPI. 30 Java SE Desktop Accessibility Web site: http://java.sun.com/javase/technologies/accessibility/index.jsp. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 14

·


Fig. 2. ITHACA data interfaces and component communication model.

complexity as the Interlingua is created continuously and gradually, and can be modified or adapted to specific users’ needs. The ITHACA concept transmission protocol consists of a set of interfaces used as a common channel for propagating strings of data, that is, characters, words, sentences, or complete messages that the user composes. This communication protocol and interfaces, in cooperation with the ITHACA database and the Interlingua concepts, helps to overcome translation and intercomponent communication related challenges that AAC component-based framework research has encountered for many years. There are four available interfaces named according to the string data type they convey: Character, Word, Sentence, and Message. Furthermore, there is a fifth interface called Configuration, which is used to convey control messages to the components (e.g., “initiate” or “terminate”). Components that need access to data (write or read), may simply implement appropriate interfaces and Publish (write) or Subscribe (read) to these interfaces, gaining access to the corresponding “communication channels.” 3.3 ITHACA for Developers ITHACA guides developers of AAC components to program their software modules as Publishers or Subscribers to data provided through the COM+ Event ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 15

Service. A developer who uses the corresponding Event Classes following straightforward guidelines, can create components incorporating their own GUI, Speech User Interface (SUI) or plain transparent functionality, which can interoperate with other ITHACA-compliant components that may have been created by other developers. An executable program, also provided with ITHACA, initializes and configures the AAC application when run for the first time, and activates all components and interfaces every subsequent time that it is executed. The framework’s executable program, all DLLs, along with their Open Source code and guidelines, can be downloaded from the ITHACA Web site.31 Furthermore, ITHACA provides ready-to-use software components to AAC developers for testing the communication of their components with the Event Service and other components. These test or “template” components serve as Publishers, Subscribers or both Publishers and Subscribers of data. Test components are also Open Source offering basic framework code examples, and can create a real application environment in order to verify the correct operation of the component being tested. The framework provides guidelines and tools to build data-aware software components, so that they can operate effectively and interact with each other transparently, without even being aware of each other’s existence. The ITHACA database is a framework tool that not only provides extensive symbol libraries, but also allows the spontaneous translation between symbolic or natural languages, so that even users speaking different languages or using different symbolic systems can communicate. We will further discuss the ITHACA symbol and translation database later. Finally, ITHACA framework is intrinsically Internet-ready; that is, it provides all the necessary infrastructure and support for components that implement remote synchronous (chat) or asynchronous (email) interpersonal communication using available Internet technologies and data transfer protocols [Viglas and Kouroupetroglou 2003]. A number of real AAC components have already been implemented, as shown in Section 4, forming a family of products that cover a wide area of needs for people with disabilities that affect their ability to communicate. These components, as well as all future Open Source or Closed Source components created by any developer, are catalogued in the ITHACA Web site in a way that integrators can easily find them and choose among them, and developers can easily check on the competition, fill the gaps or contribute to Open Source component development projects. 3.4 ITHACA for Integrators An integrator can easily assemble and manage communication aids from various independently developed components, which cooperate to provide the application functionality and UI. For integrators of interpersonal communication aids, ITHACA offers a detailed user guide and an installation program as well as a World Wide Web information center with a catalog of ITHACA-compatible components (free or commercial) to choose from. Furthermore, the database 31 ITHACA

Web site: http://speech.di.uoa.gr/ithaca. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 16

·


of symbolic communication systems and natural languages is also available to integrators, and ready to be connected with ITHACA components to provide concept mapping for interpersonal communication applications. For a specific AAC application, only parts of the database are needed and can be downloaded separately. 4. ITHACA COMPONENTS The most common functionality in AAC products has already been developed using the ULYSSES framework, in the form of pluggable components [Kouroupetroglou and Pino 2002]. All these components are now reprogrammed, converted to ITHACA-compliant .NET modules, Open Source and freely available on the ITHACA Web site. Based on an Open Source software development project, without formal funding, software companies and hobbyist programmers including special education professionals contributed to the final result. The code reuse was extensive and this allowed for better UI refinement and better interoperability between all modules. The main components we developed are: Virtual Keyboard. Displayed in a separate window, the On-Screen Keyboard component is configurable to various layouts such as alphabetic, QWERTY or sorted by most frequently accessed letters. Word Selection Set. This component is a two-dimensional rectangular selection array with a configurable number of rows and columns of buttons. To each button a word or phrase can be assigned. By activating the built-in selection bar, the user can toggle between multiple cascaded vocabulary sets. Symbol Selection Set. The buttons on this component can be configured to display most kinds of popular image formats. These images are usually symbols of alternative graphic communication systems such as Blissymbolics, PIC, PCS, Rebus, Lexigrams, SIGSYM, MAKATON, etc. Symbol or Text Editor. A simple editor in a separate window displays the messages that users compose. It displays either symbol or text messages, and provides a simple button interface to correct the displayed message deleting wrong characters or symbols or completely clearing the display area for composing a new message. Scanning. The GUIs of ITHACA-compliant components are compatible with the scanning techniques that this module offers. Automatic (one switch) or directed (three or five switches) scanning is supported in three scanning levels: window level, button group level and button level. Syntactic parser. Most of the symbolic systems do not have syntax and grammar similar to natural languages. These systems rely on prestored words or messages and do not support generative language production; that is, users are unable to construct novel well-formed sentences. This is a problem when the communication counterpart expects to hear typical and intelligible utterances. We have developed a novel technique for expanding spontaneous telegraphic input to well-formed sentences, by adopting a feature-based surface realization for natural language generation [Karberis and Kouroupetroglou 2002]. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 17

Text-to-Speech (TtS) System. The DEMOSTHeNES modular and scalable TtS system extends the traditional TtS structure to enable an open set of module-defined functions to interact with the processed text at any stage of the Text-to-Speech conversion. The speech synthesizer supports Greek and English and various voices [Xydas and Kouroupetroglou 2001]. Moreover, ITHACA supports the integration of any SAPI-based Text-to-Speech system. Chat. This component offers synchronous remote communication, using either symbols or natural language. Users who take part in these conversations may not even use the same language (for example one user may use BLISS and the other may use English). This has been achieved through the databasedriven real-time translation module that can be connected to this component. E-mail. This component realizes asynchronous remote communication. An ITHACA integrated mail server manages the entire remote communication functionality. The module described in the next paragraph also provides translation features to the email component. Database/Translation. The database system developed by Viglas and Kouroupetroglou [2002] served as the pillar for the ITHACA-based interpersonal communication aids. It has taken into account software building technologies particularly regarding database connectivity and Web-enabled access. In this respect, the implementation of the database is very straightforward using a contemporary database management system. Storing and manipulating data is ensured via software tools that deal with adding, deleting, updating and reorganizing data in a transparent and secure way. Interlingua concepts can be modified locally in an AAC application by an integrator or the user. Mappings can be changed locally without affecting the central database. Whoever makes the changes or modifications is responsible for avoiding redundancy, and the system can be reset by simply downloading the original database again. A variety of media such as speech, text, icons and pictures, and video were associated with languages and symbolic communication systems. Translation is facilitated by the database by means of relating the corresponding words and symbols via Interlingua that primarily gets all supported concepts defined, categorized, marked for synonyms, and indexed. The database can contain any required language and symbolic system, utilizing the proper structures to best incorporate their properties and values. Concepts are also defined for each language or system including any associated media representation needed. The Interlingua concepts [Andona et al. 1999] are mapped onto the elementary communicative blocks of the defined languages (i.e., their words) and symbolic systems (i.e., their graphic symbols) with which they share the same meaning. In this way we ensure a simple first degree of concept-by-concept translation. 5. DEVELOPERS’ EVALUATION For a nine-month period, 20 programmers and researchers were involved in the process of designing and developing ten framework core components and eleven ITHACA compliant AAC components. Developers were mainly recruited following email announcements in student email lists. The developers’ team consisted of six pregraduate, five postgraduate, and four doctoral ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 18

·


students of the Information and Telecommunications Department of the University of Athens (Greece). Additionally, two professional developers (employees of a major software company) also participated in the development team. The project leaders’ team consisted of three researchers (including the authors of this work) who were previously involved in ATIC and ULYSSES and are currently in ITHACA project. This team also played the role of the frameworks’ designers, core components’ developers (version alpha), and integrators. Forum and online chatting were used for inter- and intrateam communication. The programming environment was .NET-based, and Visual Basic, C++, and C# programming languages were used. 5.1 Framework Quality Several models in the literature for evaluating Open Source projects [Crowston et al. 2006], Open Source software quality [Stamelos et al. 2002; Wheeler 2008], and Open Source repositories success,32 were considered for the selection of the aspects of ITHACA that were evaluated. A combination of features and measures was used for a subjective evaluation of the quality framework by the 17 participating developers, using an online survey with 5 measured domains and a 1–5 Likert rating scale. The scale was defined as: 1 = very bad; 2 = bad; 3 = moderate; 4 = good; and 5 = very good. A total number of 16 indicators were rated. The ISO 9126 standard that classifies software quality in a structured set of characteristics was taken as a reference, though some modifications were made to the set of subcharacteristics that the standard suggests in order to better suit an Open Source framework evaluation as opposed to a software application evaluation. Opinions were also asked in the form of open type questions, investigating ITHACA’s functionality, maintainability, reliability, portability, and usability. The most important findings follow (see Table I): Functionality. All developers’ answers were affirmative to the question “Does the framework do what you expect it to do?” Suitability, accurateness, and interoperability were individually rated. This measure had the highest degree of approval. In cases where scanning features and ITHACA database connectivity were needed, programmers reported that more effort was required, although no one commented on the functionality of the framework in a disapproving manner. Maintainability. The required support was added as a sub-characteristic and was rated along with changeability, stability and testability of the framework. The continuous feedback coming from the end users and their environment had mixed results on developers. Eight of them were tired by the procedure of continuously having to improve components and making changes to the UI, and thought that this process should have more strict boundaries. The rest were intrigued and assumed their responsibility to maintain and improve their code with pleasure. Nevertheless, all of them highly appreciated the potential that the results of this team work would be publicly available for 32 Flossquality

- Open Source quality research Web site: http://www.flossquality.eu.



·

14: 19

Table I. Developers’ Rating Results Measure Functionality

Rating 4.39

Maintainability

4.09

Reliability

3.73

Portability

4.35

Usability

4.31

Indicators Suitability Accurateness Interoperability Required support Changeability Stability Testability Maturity Fault tolerance Recoverability Adaptability Installability Replaceability Understandability Learnability Operability

mean 4.82 4.35 4.00 3.24 4.65 3.65 4.82 3.59 3.53 4.06 4.65 3.59 4.82 4.65 4.71 3.59

std dev 0.39 0.61 0.87 0.66 0.49 0.61 0.39 0.80 0.80 0.83 0.49 1.18 0.39 0.61 0.47 1.12

others to continue, and evolve. The Open Source test components were highly appreciated in this domain. Reliability. The framework’s maturity, fault tolerance, and recoverability were individually rated. Generally, ITHACA tools and components run smoothly. Bugs and problems were reported for the scanning component that overloaded the OS Event Service with requests and sometimes crashed after a long time of usage (more than 1 hour). The scanning system was repaired between version alpha (preliminary version) and version beta (testing version) of the framework, and ran correctly at the final stable version. The low rating of this measure does not reflect the quality of the framework itself, as most of the developers stated, but rather the long time spent on debugging and fixing errors during the initial phases of development. Portability: Adaptability, installability, and replaceability were rated. ITHACA worked well on developers’ computers with the programming environment installed, but some libraries were initially missing from the end users’ computers in the beta version of ITHACA; the project leaders who also played the role of the integrators of the produced applications, were the ones who came across this issue, and had difficulties in installing the produced applications on the first try. Almost all components needed some file additions in their installation packages. After these observations were made, all files and libraries needed were detected and added to the framework’s installation files, and the users’ computers were updated with the latest Microsoft .NET Framework updates, so this issue was solved in the stable version of ITHACA. The framework’s design that allows for easy addition or removal of compliant components was highly appreciated and confirmed by all participants. Four contributors stated that the framework should eventually be converted using platform independent technology. Usability. Understandability, learnability, and operability were rated in this domain. ITHACA’s documentation was considered adequate, although many developers required additional communication with the project leaders in ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 20

·

A. Pino and G. Kouroupetroglou Table II. ITHACA Project Activity in Comparison with Other Studies 120 Open Source projects form SourceForge [Crowston et al. 2006] Average Median Std dev

Community size Bug fixes Downloads per day Forum posts

20.22 405

14.0 234

4.32

4.44 2.24 17 Open Source CMS projects33 184 5,438

3,163

20.57 489

ITHACA 20 196 3.32 236

order to clarify several issues. On the other hand, everybody agreed that more work needs to be done on users’ documentation for the final AAC products. Test components code was comprehensive for all programmers, in order to learn and understand how ITHACA’s components interact with the OS services and with each other. Unfortunately, developers’ quality evaluations of frameworks for developing AAC applications are not available in the literature, and ITHACA-like Open Source solutions do not exist. Hence, it is not possible to compare ITHACA quality evaluation results with other similar projects. 5.2 Project Activity Project activity evaluation data from Open Source projects in various domains (but not in the AAC domain) are available. Typically, the data used for the evaluation of Open Source projects in terms of activity include: number of developers, number of downloads per day, number of forum posts and number of bug fixes. Table II presents the developer’s community activity for 120 selected active projects with a lifespan of five years from the SourgeForge repository [Crowston et al. 2006], along with corresponding data from ITHACA. The size of the development team, which is considered quite important for Open Source projects, and the number of downloads per day were close to the average. The number of bug fixes in ITHACA is smaller compared to those reported in Crowston et al. [2006] as the lifespan of the former was much shorter. Another study33 monitored the developers’ communication activity in terms of posts in the Open Source project’s forum for 17 Course Management Systems (CMS). The standard deviation of the results (Table II) is a good indicator of how much project activity fluctuates even for projects in the same domain. Eleven of these projects had lower activity than ITHACA, while the average number of posts was raised by the four top projects that had over 10,000 posts each (these were very popular CMS with a very wide market, i.e., millions of downloads). Additional important observations we made concerning ITHACA’s success as an Open Source project include: Code reuse. Code reuse in ITHACA was extensive and ranged from above 80% for the most complex components to above 40% for most of the rest; code reuse was calculated as the number of reused lines of code divided by the total 33 http://www.karinvandenberg.nl/Thesis.pdf

(last visited September 10, 2009).



·

14: 21

Table III. Code Reuse in ITHACA and ULYSSES Code reuse in ITHACA (%) Code reuse in ULYSSES (%) Component Total OS and .NET Project Total OS Project Core components 62 36 26 32 16 16 Database 76 44 32 38 28 10 Virtual keyboard 45 16 29 12 8 4 Word selection set 54 16 38 14 8 6 Symbol selection set 46 16 30 19 8 11 Text editor 48 24 24 18 0 18 Symbol editor 52 16 36 24 8 16 Scanning 36 14 22 11 9 2 Syntactic parser 85 22 63 0 0 0 Text to Speech system 88 28 60 26 8 18 Chat 38 20 18 18 8 10 E-mail 34 20 14 14 7 7 Mean 55.33 22.67 32.67 18.83 18.83 18.83 Standard deviation 18.61 9.20 15.15 10.13 7.27 6.22

lines of code (including comments) for each component. Table III summarizes the code reuse percentages for several ITHACA components and compares the results with those from the ULYSSES project which was Closed-Source. Both reused libraries and reused parts of code were considered; also, both internal (code generated in the context of the current project or previous similar projects) and external libraries (Operating System and COM+ DLLs, as well as .NET programming environment libraries) were taken into account. Representative examples of reused code were the component data interfaces we described in Section 3.2 (internal code reused in all components), and a special UI element (an external picture-button reused as a DLL in virtual keyboards and selection sets). Code documentation. A prominent benefit from the Open Source development procedure was the well documented code; 36% of ITHACA’s (and its components’) code is comments in contrast to the 12% of comments in the Closed Source ULYSSES code (33% is an average documentation percentage in Open Source projects). While Closed Source projects produce code for the individual developers’ eyes only, in ITHACA’s case everybody knew that their code would be eventually revisited, informally evaluated and probably reused in other components. This led to solidarity between programmers who saw producing intelligible and well documented Open Source code as a form of competence to strive for. Developers familiarization with ITHACA. The specialized domain of the developed software (AAC) imposed some overhead in involving programmers in our Open Source project, as all developers were experienced in general purpose applications’ programming, but not in AAC applications. It was essential to familiarize all participants with the project’s scope and context, and this needed to be done with each programmer that showed interest in participating separately, as the turn-out was dispersed across the whole timetable of the project. On the other hand, there was no need to spend much time conveying the frameworks’ architecture and functionality. The password-protected developers’ area of the ITHACA Web site provided the overview, extensive documentation and code of the framework. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 22

·


Developers’ motivation. The eagerness of the participant developers to provide fast results was notable. Based on volunteer work and not on strictly scheduled financed labor, programming was more of a hobby than a job, as most of the developers stated. The knowledge that their work would be promptly put to use, evaluated, and appreciated by users with disabilities and their families and educators was a strong motivation. The production of free applications that would help people to improve their communication and living was considered as a much more important “humanitarian cause” than merely contributing to Open Source projects in any other domain. Finally, on the “additional comments” area of the survey they completed, three developers stated that part of the framework’s infrastructure would need to be reconsidered in the near future, especially when a new mainstream OS and programming environment will prevail. This process is considered straightforward for ITHACA, as its modularity allows for easy future adaptation to a new OS. Eight participants stated that they thought ITHACA’s contribution to the AAC domain could be proven valuable if the framework followed an extended dissemination plan. This would also allow us to better measure the framework’s effectiveness in team building, the speed of the Open Source project at responding to bug reports and the project’s popularity. The eventual dissemination of our project in international and experienced audience (developers) in both domains of Assistive Technologies and Open Source development will offer much better opportunities for a more extensive evaluation. 6. ITHACA-BASED AAC APPLICATION DEMONSTRATION In order to confirm the breadth of software that can be produced as a proof of concept of the ITHACA framework, we have further conducted a number of demonstrations with real users. Making combinations of the aforementioned components, we assembled a range of customized AAC applications addressing various user needs and communication requirements. We briefly summarize our observations regarding the experiences of the users, their family members, and their teachers. Our goal is not to provide a formal evaluation of the resulting systems, but to provide a sense as to how the systems were received by the individuals for whom they were designed. Four users (referred to as PD, JK, AT, LH) were selected from a special education and rehabilitation center in Greece; they were all children monitored in their special school environment, and the appropriate communication aids were selected following the main guidelines proposed in Woltosz [1987]. All participants were diagnosed as having cerebral palsy, with different symptoms that ranged from mild to very severe. All users had severe speech problems, and for PD and AT, their initial intellectual ability was difficult to evaluate due to the lack of communication. None of the users had ever used computerbased AAC before. The aim was to help all four users communicate in their Greek-speaking environment, firstly at school and secondly at home. Some of the users’ characteristics are summarized in Table IV. Table IV also summarizes the features of the personalized AAC systems assembled for each participant. All configurations were set up in cooperation ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

·


14: 23

Table IV. Overview of the Four Users of ITHACA AAC Applications User Sex Age Motor disability

Intellectual disability Speech production

Communication manner

AAC input language Input device Input method Input components

Intermediate components

Output

PD Male 6 Severe: Can use only his left hand with great difficulty.

JK Male 13 Mild: Can use both hands with difficulty.

AT Female 11 Severe: Can only control head movement with great difficulty.

LH Female 8 Moderate: Can use her right hand.

Mild

Moderate

Severe

Mild

Nonexistent

Nonintelligible

Nonexistent

Gazing on objects, sounds for yes/no

Pointing to objects, use of symbol cards,

Gazing on symbol cards for yes, no, pain (i.e., please change my sitting position)

Speech

PCS

BLISS

MAKATON

Natural Greek

Five switches Directed scanning 8x8 symbol selection set, Dialog bar, Emergency bar

Touchscreen Direct selection

Puff switch Automatic scanning 3x2 symbol selection set, Dialog bar, Emergency bar

One Switch Automatic scanning QUERTY Greek virtual keyboard, 8x8 word selection set, Emergency bar

Symbol editor, Chat, email, Syntactic parser Speech synthesis, email message, chat message

Symbol editor, Chat, email, Syntactic parser Speech synthesis, email message, chat message

6x4 symbol selection set, Dialog bar, Emergency bar

Intelligible, but with very low volume

Symbol editor, Syntactic parser

Text editor

Speech synthesis

Speech printed text

with their therapists, facilitators, and families. Email communication took place with all stakeholders every week, when integrators asked them for observations and feedback. Comments and requests for improvements were subsequently incorporated into the systems. Screenshots of the final GUIs of the four applications are illustrated in Figures 3 and 4. The users’ therapists declared that, in all four cases, little progress had been made in the previous years using traditional methods and progress had more or less reached a deadend. After three months of using the ITHACAbased AAC aids, each disabled user’s therapist completed a questionnaire that focused on the following aspects: Communication [McNaughton and Lindsay 1995]; Cognitive Abilities [Todman et al. 1995]; Behavior [Remington 1994]; Social Integration [Bedrosian 1997]; and Installation, upgrade, maintenance and commercial value [Newell 1987]. The last part of the questionnaire aimed ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 24

·


Fig. 3. PCS (user PD), and Bliss (user JK) communication aids.

Fig. 4. MAKATON (user AT), and Natural Greek (user LH) communication aids.

to investigate how the ITHACA proposed life cycle was affecting final users and their facilitators and families. Efforts were made to involve them in the selection, installation, debugging and modification procedures, and their comments were requested about all these phases. 6.1 Observations Although the demonstration period was relatively small (3 months) the study and analysis of the answers given by the facilitators lead to the following observations: Vocabulary. By the end of the testing period the vocabulary of the users was enriched by: 990% for user PD; 50% for user JK; and 400% for user AT (Table V). Furthermore, users’ messages were more intelligible because the system “spoke” for them. Therapists provided positive feedback, especially when comparing the outcomes to those experienced with traditional methods (and the users’ initial vocabularies). This progress shows that for the cases of speech impairments with mild or severe intellectual and speech disabilities studied, and for the specific ages (6–13), symbolic systems of interpersonal communication combined with synthetic speech are effective concept learning tools. Training time. For symbol users the time of training was very important. All three months of study were considered as training time and the progress made ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 25

Table V. Concepts/Symbols Attained by All Users during Demonstration Period User Initial vocabulary Month 1 Month 2 Month 3 Total (after testing period)

PD 10 PCS symbols +16 concepts +31 concepts +42 concepts 99 concepts

JK ∼ 100 BLISS symbols +9 concepts +15 concepts +26 concepts 150 concepts

AT 3 MAKATON symbols +2 concepts +4 concepts +6 concepts 12 concepts

LH Rich (Greek)

No apparent change

was directly related to the accumulative time each user spent with his/her communication aid (see Table V). These users had previously attained the symbols of their initial vocabulary (using paper symbol cards), but were not familiar with computer interaction or with the synthetic speech output corresponding to the symbols/concepts they previously used. In the first week of using the system they got accustomed to the new form of the symbols they had previously learned and started learning new ones. Device. The answers of educators and families to the open-type questions showed that the use of the computer as the communication device was welcomed and positive in all cases. The participants’ educators rated the possibility of producing synthetic speech and the ability to correct errors as highly significant. Furthermore, the computer-based AAC system itself encouraged all users, facilitators, and families to develop extra communication skills and improved their psychological condition. Feedback. The importance of the direct participation of therapists, facilitators, and family in configuring the UI was clear; in many cases they gave insightful directions and requests to developers. This feedback helped the developers to better understand the needs of the users. Modifications were made through the demonstration period to the users’ vocabulary as well as to features like colors, sizes, labels on/off, positions of the components, etc. These frequent changes did not have any negative impact on users; on the contrary, they renewed their interest in the AAC device, while maintaining their attention and the device’s appeal to them. User LH, who already used a rich (natural language) vocabulary before the use of the communication aid, enjoyed archiving her printed manuscripts, and appreciated that her writings could remain on paper for future demonstration to friends, teachers, and family. 6.2 Discussion All observations are in agreement with similar studies [Salminen 2000; Schlosser 2003]. However, a formal evaluation of the AAC applications is not the scope of this work, as we focus on the framework and not the resulting application. What other studies do not provide is the involvement of the end users human environment in Open Source–like initiatives and processes for evolving the given products. Users, therapists, facilitators and families were continuously testing, helping with debugging, and commenting on technical aspects according to their knowledge level and abilities. Mailing lists were used to inform on the status of application development and report on how ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 26

·


stakeholder comments were utilized and how they affected the product evolution. End users were informed by their facilitators and therapists about these procedures and were able to locate and appreciate changes made to their UIs. Consistent with other instances of participatory design, all of the people involved reported that they enjoyed their involvement in the development process. As a positive side effect of this reaction, our participants appeared motivated to use the AAC product. This participation would not be possible with a Closed Code, standard commercial, company generated AAC application. Although the everyday training sessions at school were quite amusing and pleasant for the users, they could not use the system the rest of the day. The drawback was that the communication aids were installed only on desktop computers at school and not at home. Nevertheless, the AAC system was a valuable learning aid as therapists stated. The anticipated cost of the computer and special input devices, given the free Open Source AAC software, was considered normal for what the system was offering. Even if some cost was added for including commercial components to the system (like a commercial Text-to-Speech system), it was considered acceptable. 7. CONCLUSIONS We have presented the integrated ITHACA approach for the development of computer-based AAC applications. ITHACA consists of an Open Source, component-based framework that aims to simplify the integration of multivendor components into low cost AAC products and maximizes modularity and reusability [Spinellis and Szyperski 2004]. ITHACA suggests technical (CBD), as well as business and management (Open Source, combined free and commercial) models for AAC assistive technology support provision. It also suggests an existing concrete implementation platform for this model. Following the Design for All approach, developers can build reliable application components, adaptable to various user needs and requirements. Even if a component is not designed for all (and this is usually the case when it comes to user or task specific components) it can be easily replaced by another one that fits the user needs in a specific application context. The mixed model that includes an Open Source framework, running on a mainstream OS and a mainstream computer, changes the life cycle of AAC products. It allows for Open Source, Closed Source, free, and commercial components, to compete for a place in the end users’ application. Community volunteer work in an Open Source project context could be part of the solution for the high costs of AAC products. This way, the cost of debugging or even modifying software components remains low also, thus making both the development process and the final applications more sustainable [Tate 2005]. Furthermore, AAC researchers have the opportunity to easily test their novel ideas and technology in an Open Source, component-based integrated environment without having to develop additional infrastructure. ITHACA is a result of several research projects, and the entire life cycle we introduced could be realized only if all stakeholders embraced this framework ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 27

or a similar one. This could only be achieved with joined efforts by companies, institutes, funding organizations, and people who use AAC. An important aspect for the success of this life cycle is the continuous flow of feedback information from all stakeholders and stages of the life cycle in all directions. The modified production and maintenance procedures we described should be coupled with a business model and a central administration system in order to be complete. A hybrid Open Source/Commercial model of management is proposed, meaning that an Organization (profit or nonprofit) should coordinate development and distribution procedures. It is expected that the adoption of such an approach by the AAC industry and community will lead to affordable AAC products and upgrade their quality and variety. As research advances and mainstream technology is continually redefined [Vanderheiden 2007], AAC must not be left behind due to its small market or expensive development. The developers’ evaluation showed that the potential contribution of the framework to the AAC domain is considered very important. The extensive code reuse, as well as the good functionality of the framework, was highly appreciated. To reach a critical mass of basic components and functionality and to attract enough interest and more development resources is a concern for all Open Source initiatives, and the success of their dissemination is crucial. The listing of ITHACA in OATSoft and Project:Possibility Web sites, or SourceForge,34 the largest hub for Open Source development projects, will be our next step in order to disseminate the framework as an Open Source project. Multiple combinations of ITHACA-compliant Open Source components, implementing various functionalities and UIs for interpersonal communication applications, have been used to assemble four different applications utilizing different accessibility options as well as I/O devices and interaction techniques, revealing the flexibility of the model used. The demonstration of the four systems and real users’ and their facilitators’ comments showed that interacting computer-based AAC is always a new and interesting way of learning and communicating. Progress was made even after more traditional methods had reached their limits. Involving users and facilitators in the development, testing, debugging, and evolving procedures was considered very valuable and effective. REFERENCES A BASCAL , J. AND N ICOLLE , C. 2005. Moving towards inclusive design guidelines for socially and ethically aware HCI. Interact. Comput. 17, 484–505. A NDONA , M., S TEPHANIDIS, C., AND K OUROUPETROGLOU, G. 1999. Access to lexical knowledge in interpersonal communication aids. Augment. Altern. Commun. 15, 4, 269–279 B EDROSIAN, J. L. 1997. Language aquisition in young AAC system users: Issues and directions for future research. Augment. Altern. Commun. 13, 179–185. B EUKELMAN, D. R. AND M IRENDA , P. 2005. Augmentative and Alternative Communication: Management of Severe Communication Disorders in Children and Adults 3rd ed. Paul H. Brookes Publishing Co., Baltimore, MD. B URZAGLI , L., E MILIANI P. L., AND G ABBANINI F. 2009. Design for all in action: An example of analysis and implementation. Expert Syst. Appl. 36, 985–994. 34 http://sourceforge.net/


14: 28

·


C ASTELLS, M. 2001. The Internet Galaxy. Oxford University Press, Oxford, UK. C ROWSTON, K., H OWISON, H., AND A NNABI , J. 2006. Information systems success in free and open source software development: Theory and measures. Softw. Proc. Improvem. Pract. 11, 2, 123–148. C UMLEY, G. D. AND S WANSON, S. 1999. Augmentative and alternative communication options for children with developmental apraxia of speech: Three case studies. Augment. Altern. Commun. 15, 110–125. D’S OUZA , D. AND W ILLS, A. C. 1999. Objects, Components, and Frameworks with UML: The Catalysis Aproach. Addison Wesley, Reading, MA. D E R UYTER , F., M C N AUGHTON, D., C AVES, K., B RYEN, D. N., AND W ILLIAMS, M. B. 2007. Enhancing AAC connections with the world. Augment. Altern. Commun. 23, 3, 258–270. E MILIANI , P. L., E KBERG, J., K OUROUPETROGLOU, G., P ETRIE , H., AND S TEPHANIDIS, C. 1996. The ACCESS project: Development platform for unified access to enabling environments. In Proceedings of the International Conference on Computers and Handicapped People (ICCHP’96). J. Klaus, E. Auff, W. Kresmer, and W. L. Zagler, Eds. R. Oldenbourg Verlag GmbH, 69–75. E MILIANI , P. L. 2006. Assistive technology (AT) versus mainstream technology (MST): The research perspective. Technol. Disabil. 18, 19–29. F REEMAN, S. 2007. The material and social dynamics of motivation: Contributions to open source language technology development. Sci. Stud. 20, 2, 55–77. H OPKINS, J. 2000. Component primer. Commun. ACM 43, 10, 27–30. J UDGE , S., LYSLEY, A., WALSH , J., J UDSON A., AND D RUCE S. 2006. OATS - Open source assistive technology software—a way forward. In Proceedings of the 12th Biennial Conference of the International Society for Augmentative and Alternative Communication (on CD-ROM), ISAAC Press. ¨ , M., AND FARRE , B. 2005. Empowering disabled users through J UDSON, A., H INE , N., L UND ALV the semantic Web. In Proceedings of the 1st International Conference on Web Information Systems and Technologies (WEBIST’05). J. Cordeirdo, V. Pedrosa, B. Encarnacao, and J. Filipe, Eds. INSTICC Press, Portugal, 162–167. K ARBERIS, G. AND K OUROUPETROGLOU, G. 2002. Transforming spontaneous telegraphic language to well-formed Greek sentences for alternative and augmentative communication. Lecture Notes in Computer Science, vol. 2308 (Methods and Applications of Artificial Intelligence). Springer, 155–156. K OLLOCK , P. 1999. The economies of online cooperation: Gifts and public goods in cyberspace. In Communities in Cyberspace, M. Smith and P. Kollock, Eds. Routledge, London, 220–242. K OUROUPETROGLOU, G. AND P INO, A. 2001. ULYSSES: A Framework for Incorporating MultiVendor Components in Interpersonal Communication Applications. In Proceedings of the 6th European Conference for the Advancement of Assistive Technology (AAATE’01). C. Marincek, Ed. IOS Press, Amsterdam, The Netherlands, 55–59. K OUROUPETROGLOU, G. AND P INO, A. 2002. A New Generation of Communication Aids under the ULYSSES Component-Based Framework. In Proceedings of the 5th International ACM SIGCAPH Conference on Assistive Technologies (ASSETS’02). ACM Press, New York, NY, 218–225. K OUROUPETROGLOU, G., P INO, A., AND V IGLAS, C. 2001. Managing accessible user interfaces of multi-vendor components under the ULYSSES framework for interpersonal communication applications. In Proceedings of the 9th International Conference on Human-Computer Interaction. Vol.3, C. Stephanidis, Ed. Lawrence Erlbaum Associates, Inc., Mahwah, NJ, 185–189. K OUROUPETROGLOU, G., V IGLAS, C., S TAMATIS, C., AND P ENTARIS, F. 1997. Towards the next generation of computer-based interpersonal communication aids. In Proceedings of the 4th European Conference for the Advancement of Assistive Technology (AAATE’97). IOS Press, Amsterdam, The Netherlands, 110–114. L ARSEN, G. 2000. Component-based enterprise frameworks. Commun. ACM 43, 10, 24–26. L AW, C. M., Y I , J. S., C HOI , Y. S., AND J ACKO, J. A. 2006. Are disability access guidelines designed for designers? Do they need to be? In Proceedings of the 20th Conference of the CHISIG of Australia on Computer-Human Interaction: Design: Activities, Artefacts, and Environments. ACM Press, New York, NY, 357–360. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.


·

14: 29

L ESSIG, L. 2002. Open source baselines: Compared to what? In Government Policy toward Open Source Software, R. W., Hahn, Ed. AEI-Brookings Joint Center For Regulatory Studies, Washington DC, 50–68. L IGHT, J. 1989. Toward a definition of communicative competence for individuals using augmentative and alternative communication systems. Augment. Altern. Commun. 5, 137–144. ¨ , M. AND J UDSON, A. 2005. Concept coding. In Theoretical and Methodological Issues L UND ALV in Research on Augmentative and Alternative Communication. S. von Tetzchner and M. de Jesus Goncalves Eds. ISAAC Press, 198–205. ¨ , M., H EKSTRA , D., AND S TAV, E. 1998. Comspec—a Java based development enviL UND ALV ronment for communication aids. In Improving the Quality of Life for the European Citizen. I. Placencia Porrero and E. Ballabio Eds. IOS Press, Amsterdam, Netherlands, 203–207. ¨ , M., LYSLEY, A., H EAD, P., AND H EKSTRA , D. 1999. ComLink, an open and component L UND ALV based development environment for communication aids. In Proceedings of the 5th European ¨ Conference for the Advancement of Assistive Technology (AAATE’99). C. Buhler and H. Knops, Eds. IOS Press, Amsterdam, Netherlands, 174–179. M C N AUGHTON, S. AND L INDSAY, P. 1995. Approaching literacy with AAC graphics. Augment. Altern. Commun. 11, 212–225. N EWELL , A. F. 1987. How can we develop better Communication Aids? Augment. Altern. Commun. 8, 36–39. N EWELL , A. F. AND G REGOR , P. 2000. User sensitive inclusive design - In search of a new paradigm. In Proceedings of the Conference on Universal Usability. ACM, 39–44 P LATT, D. 1999. The COM+ Event Service eases the pain of publishing and subscribing to data. Microsoft Syst. J. 14, 9. P OULSON, D. AND N ICOLLE , C. 2004. Making the Internet accessible for people with cognitive and communication Impairments. Univ. Access Inform. Soc. 3, 1, 48–56. R ACKENSPERGER , T., M C N AUGHTON, D., K REZMAN, C., W ILLIAMS, M., AND D’S ILVA , K. 2005. When I first got it, I wanted to throw it over a cliff: The challenges and benefits of learning technology as described by individuals who use AAC. Augment. Altern. Commun. 21, 165–186. R EICHLE , J., Y ORK , J., AND S IGAFOOS, J. 1991. Implementing Augmentative and Alternative Communication: Strategies for Learners with Severe Disabilities. Paul H. Brookes Publishing Co., Baltimore, MD. R EMINGTON, B. 1994. Augmentative and Alternative Communication and behavior analysis: A productive partnership? Augment. Altern. Commun. 10, 3–11. R ICHLE , D. 2007. The economic motivation of Open Source Software: Stakeholder perspectives. IEEE Comput. 40, 4, 25–32. S ALMINEN, A. L. 2000. Daily life with computer augmented communication. Research rep. 119, STAKES, Helsinki, Finland. S AVIDIS, A. AND S TEPHANIDIS, C. 2006. Inclusive development: Software engineering requirements for universally accessible interactions. Interact. Comput. 18, 1, 71–116. S CHLOSSER , R. 2003. Roles of speech output in augmentative and alternative communication: Narrative review. Augment. Altern. Commun. 19, 1, 5–27, S HAH , S. 2006. Motivation, governance, and the viability of hybrid forms of open source development. Manag. Sci. 52, 7, 1000–1014. S PINELLIS, D. AND S ZYPERSKI , C. 2004. How is open source affecting software development? IEEE Softw. 21, 1, 28–33. S TAMELOS, I., A NGELIS, L., O IKONOMOU, A., AND B LERIS, G. 2002. Code quality analysis in open-source software development. Inform. Syst. J. 12, 1, 43–60. S TEPHANIDIS, C. 2001. User interfaces for all: New perspectives into human-computer interaction. In User Interfaces for All—Concepts, Methods, and Tools. C. Stephanidis, Ed. Lawrence Erlbaum Associates, Mahwah, NJ, 3–17. T ATE , K. 2005. Sustainable Software Development: An Agile Perspective. Addison-Wesley Professional, Boston, MA. T ODMAN, J., E LDER , L., AND A LM , N. 1995. Evaluation of the content of computer-aided conversations. Augment. Altern. Commun. 11, 229–233. ACM Transactions on Accessible Computing, Vol. 2, No. 4, Article 14, Pub. date: June 2010.

14: 30

·


VANDERHEIDEN, G. C. 2007. Redefining Assistive Technology, Accessibility, and Disability Based on Recent Technical Advances. Technol. Hum. Serv. 25, 1, 147–158. V IGLAS, C. AND K OUROUPETROGLOU, G. 2002. An open machine translation system for augmentative and alternative communication. Lecture Notes in Computer Science, vol. 2398, 698–706. V IGLAS, C. AND K OUROUPETROGLOU, G. 2003. e-AAC: Making internet-based interpersonal communication and WWW content accessible for AAC symbol users. In Proceedings of the HCI International. vol. 4, C. Stephanidis, Ed. Lawrence Erlbaum Associates, Inc., Mahwah, NJ, 276–280. W HEELER , D. A. 2008. How to Evaluate Open Source Software/Free Software (OSS/FS) Program. Available online at http://www.dwheeler.com/oss fs eval.html. W OLTOSZ , W.S. 1987. A proposed model for Augmentative and Alternative Communication evaluation and system selection. Augment. Altern. Commun. 4, 233–235. X YDAS, G. AND K OUROUPETROGLOU, G. 2001. The DEMOSTHeNES speech composer. In Proceedings of the 4th ISCA Tutorial and Research Workshop on Speech Synthesis. Kluwer Academic Publishers, Dordrecht, Netherlands, 167–172.

Received March 2009; revised September 2009, December 2009; accepted December 2009
