The introduction in chapter 1 has already mentioned several typical examples for multimedia applica- tions today. This section aims to provide a more detailed understanding of the spectrum of multimedia applications by a suitable classification.
2.4.1 Existing Classifications
Two kinds of classifications can be found in the literature: The first type are classifications based on the application domain. The second type are classifications based on multiple facets. Both are explained in the following.
Classifications based on the Application Domain A large part of the existing literature on multi- media applications addresses the spectrum of applications by lists of examples which are classified into some larger example domains. For instance, [Boll01] lists the areas:
• Multimedia teaching and training
• Distributing and trading of multimedia content
• Mobile multimedia applications
[Tannenbaum98] identifies six application areas:
• Scientific Data Analysis, Research and Development, Experimentation, and Presentation
• Instruction in School and Elsewhere
• Business Applications
• Entertainment
• Enabling Technology for Persons with Special Needs
• Fine Arts and Humanities
As part of a detailed taxonomy (explained below) [Hannington and Reed02] proposes:
• Multimedia information systems:databases, information kiosks, hypertexts, electronic books, and multimedia expert systems
• Multimedia communication systems: computer supported collaborative work, videoconfer- encing, streaming media, and multimedia teleservices
• Multimedia entertainment systems: 3D computergames, multiplayer network games, info- tainment, and interactive audio-visual productions
• Multimedia business systems: immersive electronic commerce, marketing, multimedia pre- sentations, video brochures, and virtualshopping
• Multimedia educational systems: electronic books, flexible teaching materials, simulation systems, automatic testing, and distance learning
While these classes are certainly typical for multimedia it still raises the question whether they are complete and how these classes would be located within the spectrum of all possible application software. The thesis [Kraiker07] supervised by the author of this thesis examines this question. In a first step, Kraiker selected common taxonomies for software in general mainly aggregated from the taxonomies in [Klußmann01, Staas04]. In a second step, Kraiker sorted the examples given in [Tannenbaum98] into this taxonomy. It turns out that multimedia applications can be found (more or less, depending on the interpretation) inallclasses of application software.
Faceted Taxonomies As a classification purely based on the purpose is not always sufficient some literature proposes detailed faceted taxonomies. An often cited taxonomy can be found in [Heller et al.01]. They propose three dimensions:
• Media Typewith the valuesText,Sound,Graphics,Motion, andMultimedia,
• Media Expressionwith the valuesElaboration,Representation, andAbstraction. This refers to the degree of abstraction, i.e. whether content is for instance represented by a lifelike photo or by an icon.
• Context, which does not contain discrete values but a collection of categories for qualitative questions that can be asked about a software product and categorize it in a non-quantitative way. The six proposed categories concern theaudience,discipline,interactivity,quality,usefulness, andaestheticsof a multimedia product.
In contrast to [Heller et al.01] which focus more towards aesthetics, the taxonomy in [Hannington and Reed02] assumes the viewpoint of development. Thus, it is the most important for this thesis. It provides a large number of facets to describe all aspects which might influence the development of a multimedia application. Altogether they propose 21 facets together with possible values. The facets span from general facets used in other taxonomies, like the application domain, over facets like the delivery target platform (online, offline, etc.), navigation (linear, hierarchical, etc.), security re- quirements (access levels, authorization, etc.), up to very detailed properties like used media formats (JPEG, GIF, etc.), user interface widgets (button, checkbox, etc.) or authoring tools used for devel- opment (Flash, Director, etc.). A listing taken from [Hannington and Reed02] showing all facets and possible values is attached in appendix A.
The facets by [Hannington and Reed02] from above provide a very detailed understanding on properties in multimedia application development. Taking them all into account would be useful for instance to compare two concrete existing multimedia products. However, its level of detail is much too high to achieve a compact overview on the whole spectrum of multimedia applications. Thus, as intended by the authors in [Hannington and Reed02], it is possible to customize the taxonomy by selecting only those factes which are most important for our purpose. The next section elaborates such a taxonomy for this thesis.
2.4.2 A Classification for this Thesis
For this thesis it seems useful to aim for a taxonomy which covers the whole spectrum of multimedia applications from the viewpoint of development but is still manageable. A central observation in the foregoing sections was that multimedia application development is strongly affected by two different fields, media design and software programming. Many tasks, developer roles, tools, implementation technologies, etc., depend on the expression of these two aspects for a given application. Thus, it is useful to use this central theme also as main idea for a compact taxonomy.
A reasonable proposal by [Kraiker07] is to use the two facetsDomainandInteractivtiyfor this purpose. When looking at [Hannington and Reed02] (appendix A), it turns out that indeed most other facets are less important for our purpose: The taxonomy for multimedia applications here should base on the conceptual properties of applications themselves, i.e. their requirements on a certain level of abstraction. However, most facets in [Hannington and Reed02] actually describe either:
• the concrete solution chosen by the developers (solution space,navigation,interface, program- ming),
• or technical details (state,duration,size,format).
Thus, it is reasonable to omit them here. Delivery Platform and Security both indeed describe appli- cation requirements but they are considered here as too specific to really influence the development in general.
The remaining two facets from [Hannington and Reed02] are Media and Origin. Media means the media type used in the application. This facet indeed influences the development process as e.g 3D graphics requires very different experts, tools, and concepts than e.g. a mainly text-based application. Origin refers in [Hannington and Reed02] to the origin of a media artifact with the values: Acquired,
Repurposed, and Created. This also influences the development as it makes a difference whether media artifacts must be created in a possibly very complex design process or whether they are just taken from an external source and must be integrated (only).
For sake of simplicity it is possible here to omit the value “Repurposed”: Either it requires some effort to adapt the media then it is similar “Created”. Otherwise it is close to “Acquired”. Thus, for our purpose the values are substituted by two more generic values: Receivedmeans that a media object must not be designed within the development process but is taken from an external source, like another company, an existing application, or by the user at runtime (e.g. in a video editing application the videos are provided by the user herself).Designedmeans that the media object is designed as part of the development process.
However, there is an additional value which is useful in our context which can be calledGenerated. An example is Google Maps which contains complex graphics. This graphics is neither designed by graphic designer nor taken from an external source – it is generated directly from geographical data instead. This makes a significant difference, as it requires no media design but complex programming instead.
In summary, we the following facets are used, in order of their importance:
Domain Gives a basic idea on the application’s purpose and its required domain concepts. Possible values:Business,Information,Communication,Entertainment,Education(see sec. 2.4.1). Interactivity Influences the degree of programming vs. authoring. Possible Values ([Hannington and
Reed02, Aleem98, Heller et al.01]):
• Passive: The user has no control like in a movie.
• Reactive: Provides limited response for the user within a scripted sequence. For example the user can select between some predefined graphics.
• Proactive: Allows the user to play a major role in the design and construction of situa- tions, typically by manipulating values. For instance, the user can initiate changes to the properties of a graphics, like color, shape, rotation, position, etc.
• Directive:Allows the user to control the content of the application (in addition to manip- ulate values). For instance, the user can create her own graphics.
Media Origin: Influences design vs. programming vs. integration only. Possible Values: Received,
Designed,Generated.
Media Types: Influences kind of design/programming/integration. Possible Values: Audio, Video,
Graphics,2DAnimation,3DAnimation,Text,Image.
Table 2.1 shows the spectrum of multimedia applications in terms of the classification. The table columns and rows represent the first two facets, ‘Domain’ and ‘Interactivity’. In the Interactivity facet
Directive Authoring Tool CSCW System City-building Game Electronic Circuit Simu- lation Proactive Car Configurator Navigation System Video Conference Car Racing Game Flight Simulator
Reactive Online Shop Encyclopedia Media Player Medical
Course Interactivity /
Domain Business Information Communication Edutainment Education
Media Origin: Received
Designed Generated G G G G D D D R D D D D G R R R R R D G
Table 2.1: Overview on the spectrum of multimedia applications
the values ‘Passive’ has been omitted for simplicity as this work is on interactive applications. The values of the third dimension, ‘Media Origin’, are indicated inside the table cells by the letters ‘R’ for ‘Received’, ‘D’ for ‘Designed’, and ‘G’ for ‘Generated’. The fourth dimension, ‘Media Type’, is omitted for simplicity, as it has the lowest influence here.
The table contains an example for each class defined by the primary two facets. Of course, clas- sifying the examples is to some extent subjective. In particular, the media origin often depends on the detailed functionality. Often, an application combines two or three types of media origin. For in- stance, the media in authoring tool are mainly provided by the user (e.g. a video in Flash) or generated (e.g. graphics created in Flash). But an authoring tool could additionally provide predefined media which then might be designed. Similarly, the media origin for other applications depends on the de- tailed example. Nevertheless, it is not that much important here which kind of application uses which media origin but rather that all kinds of media origin frequently occur and are often also combined within the same application.
One can see in the table that applications using “generated” media are mostly proactive or directive which seems quite logical. For communication applications no “reactive” example was found. This makes probably sense as for communication software the content must by definition be influenced by the user. In turn, there is no “directive” examples for information software, as such examples are usually classified as communication software. However, again the classification is quite subjective.
In general, it is not the intention here to provide a new contribution in terms of the preciseness of a taxonomy but rather to provide a reasonable and meaningful overview. It will be used later in section 8.3.3 to evaluate the solution proposed in this thesis.